Message from discussion
Poll for v0.10 feature: Crypto default to 'binary' strings vs defaulting to buffers
Received: by 10.224.213.1 with SMTP id gu1mr15652833qab.7.1349814341072;
Tue, 09 Oct 2012 13:25:41 -0700 (PDT)
X-BeenThere: nodejs@googlegroups.com
Received: by 10.229.107.14 with SMTP id z14ls3190645qco.2.gmail; Tue, 09 Oct
2012 13:25:21 -0700 (PDT)
Received: by 10.224.31.20 with SMTP id w20mr15694355qac.2.1349814321617;
Tue, 09 Oct 2012 13:25:21 -0700 (PDT)
Received: by 10.224.31.20 with SMTP id w20mr15694353qac.2.1349814321590;
Tue, 09 Oct 2012 13:25:21 -0700 (PDT)
Return-Path: <ag4ve...@gmail.com>
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42])
by gmr-mx.google.com with ESMTPS id a27si4519103qck.3.2012.10.09.13.25.21
(version=TLSv1/SSLv3 cipher=OTHER);
Tue, 09 Oct 2012 13:25:21 -0700 (PDT)
Received-SPF: pass (google.com: domain of ag4ve...@gmail.com designates 209.85.216.42 as permitted sender) client-ip=209.85.216.42;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of ag4ve...@gmail.com designates 209.85.216.42 as permitted sender) smtp.mail=ag4ve...@gmail.com; dkim=pass header...@gmail.com
Received: by mail-qa0-f42.google.com with SMTP id t11so5575228qaa.1
for <nodejs@googlegroups.com>; Tue, 09 Oct 2012 13:25:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=9G6pvDtD9h6pqrxolLq8Iaf+NYdUHPwOJ3lluwGlMdA=;
b=muMJa/XRE1fHsU5D/tfqdC+piItMJtqBmDEzbEii53jd2kyov0JN2uZEB85HMtpGJp
mFm0WAUVwY+HK28lfXOBBlmvJRmraV34TTeDIs6lCMVdDKa/iCxfj4QWa1LYGH1bPWuM
W+dRhqK6hFohoqvj2o8SQd9M/zldfSzz7FeBTW0YUq0piOML8HfLu3xhB8b0FK+1WyxY
f4aYx2ZI7MY29GTB0duS/LfFK7yHhxvD3mAxdQfqsfGONTCfpOoqcnehww0vhXD0q1Wj
yuJir98yHRM85CqP2j6nF9OzeklMimwOLWXZt7OVZnSqfLzzVWmQhMr/5lE+L+mFG2TW
roig==
MIME-Version: 1.0
Received: by 10.49.36.199 with SMTP id s7mr49065821qej.2.1349814321478; Tue,
09 Oct 2012 13:25:21 -0700 (PDT)
Received: by 10.49.103.226 with HTTP; Tue, 9 Oct 2012 13:25:20 -0700 (PDT)
Received: by 10.49.103.226 with HTTP; Tue, 9 Oct 2012 13:25:20 -0700 (PDT)
In-Reply-To: <CADcwD-GGpFiOPsOdJYEVw-NU1=fYrJpUF_605=wNuMbiOLb...@mail.gmail.com>
References: <CADcwD-GuAEG=EZ2ZF029H2RKpWbzkCdCCcsb47VeKrFpiAS...@mail.gmail.com>
<b9dde6a3-be23-4300-a3dc-5d4adfbba07a@googlegroups.com>
<CADcwD-GGpFiOPsOdJYEVw-NU1=fYrJpUF_605=wNuMbiOLb...@mail.gmail.com>
Date: Tue, 9 Oct 2012 20:25:20 +0000
Message-ID: <CAH_OBie6XcOfC_N-p_L9eJ6CT8p=CnCh_Tb7HUzetRsXnqk...@mail.gmail.com>
Subject: Re: [nodejs] Re: Poll for v0.10 feature: Crypto default to 'binary'
strings vs defaulting to buffers
From: shawn wilson <ag4ve...@gmail.com>
To: nodejs@googlegroups.com
Content-Type: multipart/alternative; boundary=047d7b6d89c624faef04cba6235b
--047d7b6d89c624faef04cba6235b
Content-Type: text/plain; charset=UTF-8
No idea why the comment about warning when you give crypt binary didn't
gain more notice, but... why not make a new interface instead of changing
the current one and possibly breaking stuff?
You could eventually make the old API the same as the new (in a year?
Whenever github searches come up empty?) It wont affect me and it seems the
modules I use that use crypt are updated frequently enough that I trust
I'll be fine, but what's the point of breaking stuff if you don't have to?
On Oct 9, 2012 12:11 PM, "Isaac Schlueter" <i...@izs.me> wrote:
> Seems pretty unanimous here. So, unless some new objection comes up
> that is very compelling, let's assume that 0.10 will use Buffers by
> default in crypto instead of binary strings.
>
> Also, a streaming interface to the crypto classes is already underway.
>
>
> On Tue, Oct 9, 2012 at 9:06 AM, Jimb Esser <wastel...@gmail.com> wrote:
> > a) Go for it. Looks like it would have no effect on almost all of our
> > crypto code.
> >
> >
> > On Monday, October 8, 2012 4:24:36 PM UTC-7, Isaac Schlueter wrote:
> >>
> >> Currently, the crypto module defaults to using 'binary' encoded
> >> strings everywhere as the default input and output encoding.
> >>
> >> This is problematic for a few reasons:
> >>
> >> 1. It's slower than necessary.
> >> 2. It doesn't match the rest of Node.
> >>
> >> The reason for this is that crypto predates Buffers, and no one ever
> >> bothered to go through and change it. (The same reason it's got some
> >> odd hodgepodge of update/digest methods vs the Stream interface you
> >> see everywhere else in node.)
> >>
> >> The reason it persists in 0.8 (and perhaps in 0.10) is that we
> >> (perhaps overly optimistically) labelled that API "stable", and don't
> >> want to break anyone's programs. It's going to change eventually to
> >> match the rest of node. The only question is whether the change will
> >> come in 0.10 or 0.12. A stream interface to all the crypto classes is
> >> coming in 0.10; using 'binary' strings by default is thus even more
> >> obviously a departure from the rest of node.
> >>
> >> Note that, if you only use crypto for hashes, and set the 'hex'
> >> encoding, then it won't affect you. If you only ever pass the output
> >> of one crypto function to the input of another (sign/verify, for
> >> example) then it also won't affect you; you'll just pass buffers
> >> around instead of binary strings.
> >>
> >> Please select one, and reply with your choice and perhaps any other
> >> feedback you have on this issue. Thanks.
> >>
> >> a) Go for it. This won't affect me, and if by chance it does, I don't
> >> mind putting 'binary' args here and there.
> >> b) Please wait. Mark the API as unstable in 0.10, but don't change it
> >> until 0.12.
> >> c) I have no opinion, because I don't use the crypto API directly.
> >>
> >>
> >> (Disclaimer: Node is not a democracy. The "winning" vote might still
> >> be out-voted by reasonable considerations of the core dev team. This
> >> is informative only ;)
> >
> > --
> > Job Board: http://jobs.nodejs.org/
> > Posting guidelines:
> > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> > You received this message because you are subscribed to the Google
> > Groups "nodejs" group.
> > To post to this group, send email to nodejs@googlegroups.com
> > To unsubscribe from this group, send email to
> > nodejs+unsubscribe@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/nodejs?hl=en?hl=en
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
--047d7b6d89c624faef04cba6235b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p>No idea why the comment about warning when you give crypt binary didn=
9;t gain more notice, but... why not make a new interface instead of changi=
ng the current one and possibly breaking stuff?</p>
<p>You could eventually make the old API the same as the new (in a year? Wh=
enever github searches come up empty?) It wont affect me and it seems the m=
odules I use that use crypt are updated frequently enough that I trust I=
9;ll be fine, but what's the point of breaking stuff if you don't h=
ave to?</p>
<div class=3D"gmail_quote">On Oct 9, 2012 12:11 PM, "Isaac Schlueter&q=
uot; <<a href=3D"mailto:i...@izs.me">i...@izs.me</a>> wrote:<br type=3D"att=
ribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
Seems pretty unanimous here. =C2=A0So, unless some new objection comes up<b=
r>
that is very compelling, let's assume that 0.10 will use Buffers by<br>
default in crypto instead of binary strings.<br>
<br>
Also, a streaming interface to the crypto classes is already underway.<br>
<br>
<br>
On Tue, Oct 9, 2012 at 9:06 AM, Jimb Esser <<a href=3D"mailto:wasteland@=
gmail.com">wastel...@gmail.com</a>> wrote:<br>
> a) Go for it. =C2=A0Looks like it would have no effect on almost all o=
f our<br>
> crypto code.<br>
><br>
><br>
> On Monday, October 8, 2012 4:24:36 PM UTC-7, Isaac Schlueter wrote:<br=
>
>><br>
>> Currently, the crypto module defaults to using 'binary' en=
coded<br>
>> strings everywhere as the default input and output encoding.<br>
>><br>
>> This is problematic for a few reasons:<br>
>><br>
>> 1. It's slower than necessary.<br>
>> 2. It doesn't match the rest of Node.<br>
>><br>
>> The reason for this is that crypto predates Buffers, and no one ev=
er<br>
>> bothered to go through and change it. =C2=A0(The same reason it=
9;s got some<br>
>> odd hodgepodge of update/digest methods vs the Stream interface yo=
u<br>
>> see everywhere else in node.)<br>
>><br>
>> The reason it persists in 0.8 (and perhaps in 0.10) is that we<br>
>> (perhaps overly optimistically) labelled that API "stable&quo=
t;, and don't<br>
>> want to break anyone's programs. =C2=A0It's going to chang=
e eventually to<br>
>> match the rest of node. =C2=A0The only question is whether the cha=
nge will<br>
>> come in 0.10 or 0.12. =C2=A0A stream interface to all the crypto c=
lasses is<br>
>> coming in 0.10; using 'binary' strings by default is thus =
even more<br>
>> obviously a departure from the rest of node.<br>
>><br>
>> Note that, if you only use crypto for hashes, and set the 'hex=
'<br>
>> encoding, then it won't affect you. =C2=A0If you only ever pas=
s the output<br>
>> of one crypto function to the input of another (sign/verify, for<b=
r>
>> example) then it also won't affect you; you'll just pass b=
uffers<br>
>> around instead of binary strings.<br>
>><br>
>> Please select one, and reply with your choice and perhaps any othe=
r<br>
>> feedback you have on this issue. =C2=A0Thanks.<br>
>><br>
>> a) Go for it. =C2=A0This won't affect me, and if by chance it =
does, I don't<br>
>> mind putting 'binary' args here and there.<br>
>> b) Please wait. =C2=A0Mark the API as unstable in 0.10, but don=
9;t change it<br>
>> until 0.12.<br>
>> c) I have no opinion, because I don't use the crypto API direc=
tly.<br>
>><br>
>><br>
>> (Disclaimer: Node is not a democracy. =C2=A0The "winning"=
; vote might still<br>
>> be out-voted by reasonable considerations of the core dev team. =
=C2=A0This<br>
>> is informative only ;)<br>
><br>
> --<br>
> Job Board: <a href=3D"http://jobs.nodejs.org/" target=3D"_blank">http:=
//jobs.nodejs.org/</a><br>
> Posting guidelines:<br>
> <a href=3D"https://github.com/joyent/node/wiki/Mailing-List-Posting-Gu=
idelines" target=3D"_blank">https://github.com/joyent/node/wiki/Mailing-Lis=
t-Posting-Guidelines</a><br>
> You received this message because you are subscribed to the Google<br>
> Groups "nodejs" group.<br>
> To post to this group, send email to <a href=3D"mailto:nodejs@googlegr=
oups.com">nodejs@googlegroups.com</a><br>
> To unsubscribe from this group, send email to<br>
> <a href=3D"mailto:nodejs%2Bunsubscribe@googlegroups.com">nodejs+unsubs=
cribe@googlegroups.com</a><br>
> For more options, visit this group at<br>
> <a href=3D"http://groups.google.com/group/nodejs?hl=3Den?hl=3Den" targ=
et=3D"_blank">http://groups.google.com/group/nodejs?hl=3Den?hl=3Den</a><br>
<br>
--<br>
Job Board: <a href=3D"http://jobs.nodejs.org/" target=3D"_blank">http://job=
s.nodejs.org/</a><br>
Posting guidelines: <a href=3D"https://github.com/joyent/node/wiki/Mailing-=
List-Posting-Guidelines" target=3D"_blank">https://github.com/joyent/node/w=
iki/Mailing-List-Posting-Guidelines</a><br>
You received this message because you are subscribed to the Google<br>
Groups "nodejs" group.<br>
To post to this group, send email to <a href=3D"mailto:nodejs@googlegroups.=
com">nodejs@googlegroups.com</a><br>
To unsubscribe from this group, send email to<br>
<a href=3D"mailto:nodejs%2Bunsubscribe@googlegroups.com">nodejs+unsubscribe=
@googlegroups.com</a><br>
For more options, visit this group at<br>
<a href=3D"http://groups.google.com/group/nodejs?hl=3Den?hl=3Den" target=3D=
"_blank">http://groups.google.com/group/nodejs?hl=3Den?hl=3Den</a><br>
</blockquote></div>
--047d7b6d89c624faef04cba6235b--