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 ;)
On Mon, Oct 8, 2012 at 4:24 PM, Isaac Schlueter <i...@izs.me> 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 ;)
My vote is a', "Please for the love of all that is holy go for it." The
incongruence is annoying, and I have to context-switch every time I work
with our crypto code.
On Mon, Oct 8, 2012 at 4:33 PM, Joshua Holbrook <josh.holbr...@gmail.com>wrote:
> On Mon, Oct 8, 2012 at 4:24 PM, Isaac Schlueter <i...@izs.me> 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 ;)
michael.r.schoonma...@gmail.com> wrote:
> My vote is a', "Please for the love of all that is holy go for it." The
> incongruence is annoying, and I have to context-switch every time I work
> with our crypto code.
> On Mon, Oct 8, 2012 at 4:33 PM, Joshua Holbrook <josh.holbr...@gmail.com>wrote:
>> I say go for it. :)
>> --Josh
>> On Mon, Oct 8, 2012 at 4:24 PM, Isaac Schlueter <i...@izs.me> 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 ;)
michael.r.schoonma...@gmail.com> wrote:
> My vote is a', "Please for the love of all that is holy go for it." The
> incongruence is annoying, and I have to context-switch every time I work
> with our crypto code.
> On Mon, Oct 8, 2012 at 4:33 PM, Joshua Holbrook <josh.holbr...@gmail.com>wrote:
>> I say go for it. :)
>> --Josh
>> On Mon, Oct 8, 2012 at 4:24 PM, Isaac Schlueter <i...@izs.me> 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 ;)
> 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 ;)
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 ;)
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 ;)
On Monday, October 8, 2012 6:24:36 PM UTC-5, 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 ;)
On Tuesday, 9 October 2012 10:24:36 UTC+11, 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 ;)
a) Go for it. API-breaking changes are somewhat expected in Node and the quality and consistency of Node's API is one of it's strongest points. Keep the quality high even if you make a few breaking changes pre-1.0. The sooner the better.
On Tuesday, October 9, 2012 6:24:36 AM 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 ;)
a), though in interest of full disclosure, the impact on my current code will be minimal, and for future stuff, I'd rather get the change over with rather than have even more things to change at a later date.
On Monday, October 8, 2012 5:08:54 PM UTC-7, Joshua Gross wrote:
> I like B) in theory, as a way to manage APIs. Anyone not reading this > newsgroup will at least have *some* advanced warning.
Understandable, but with Node not at 1.0 yet, I'd hope that anyone using node in a production environment has at least one team member keeping up with this list. Then again, we're talking reality, not some place that makes sense.
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.
I definitely support (a). Might I make a plea also for a proper
X509Certificate class to be supported in addition to PEM and other
encodings of certificates in the factory methods for Credentials, Signer
and Verifier?
We have a glimpse of a certificate class in the tls module
with cleartextStream.getPeerCertificate(); but this is the only place in
the API where fields of a certificate are exposed. There are also use-cases
in signing and verifying where you want to know about certificate details,
and details also about non-trivial certificate paths that were constructed
in the course of verifying a signature. An example would be knowing whether
or not your validated path qualifies as a valid EV path, or verifying the
signature on in an XML signature document.
I know the argument is always that this functionality can go in user land
in an independent module, instead of in core; and there are modules that do
some of this such as dcrypt [1]. The problem is that when you do that you
have to re-implement all of the core functionality as well on top of your
external certificate library, just because you're unable to pass a
certificate object into the APIs in the core.
So my suggestion would be to include X509Certificate and X509CRL classes
that wrap native OpenSSL X509 structures, and for these to be supported as
well as strings in the relevant APIs. Once that is in place, I think the
more esoteric use cases can be supported in userland without lots of
duplication of code.
I'm happy to contribute to the work, and some time ago started implementing
support for this [2] based on dcrypt. You can see from the amount of code
in there that's simply cut+paste from core that it really would be a fairly
modest delta; much of the functionality is already there, but disorganised.
I go for a) but also agree that b) would be better for people outside this list. Could we have some kind of mixing, having the old and new interface together, a warning on old interface and then on the next version it could be removed (or throw..).
On Tuesday, October 9, 2012 at 8:30 , Paddy Byers wrote:
> Hi,
> > 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.
> I definitely support (a). Might I make a plea also for a proper X509Certificate class to be supported in addition to PEM and other encodings of certificates in the factory methods for Credentials, Signer and Verifier?
> We have a glimpse of a certificate class in the tls module with cleartextStream.getPeerCertificate(); but this is the only place in the API where fields of a certificate are exposed. There are also use-cases in signing and verifying where you want to know about certificate details, and details also about non-trivial certificate paths that were constructed in the course of verifying a signature. An example would be knowing whether or not your validated path qualifies as a valid EV path, or verifying the signature on in an XML signature document.
> I know the argument is always that this functionality can go in user land in an independent module, instead of in core; and there are modules that do some of this such as dcrypt [1]. The problem is that when you do that you have to re-implement all of the core functionality as well on top of your external certificate library, just because you're unable to pass a certificate object into the APIs in the core.
> So my suggestion would be to include X509Certificate and X509CRL classes that wrap native OpenSSL X509 structures, and for these to be supported as well as strings in the relevant APIs. Once that is in place, I think the more esoteric use cases can be supported in userland without lots of duplication of code.
> I'm happy to contribute to the work, and some time ago started implementing support for this [2] based on dcrypt. You can see from the amount of code in there that's simply cut+paste from core that it really would be a fairly modest delta; much of the functionality is already there, but disorganised.
Although, probably wise to make sure that it's publicised a fair bit; Anyone who hits issues can hang around on an older version of Node, until they can upgrade.
On 09/10/2012, at 12:24 AM, Isaac Schlueter <i...@izs.me> 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 ;)
d) I use it a lot and find the strangeness of binary strings so dumb that I'd rather have it changed sooner or later even if that means having to rewrite/modify a bit of code.
On Tuesday, October 9, 2012 1:24:36 AM UTC+2, 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 ;)
On Mon, Oct 8, 2012 at 7:24 PM, Isaac Schlueter <i...@izs.me> 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 ;)
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 ;)
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 ;)
On Mon, Oct 8, 2012 at 4:24 PM, Isaac Schlueter <i...@izs.me> 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 ;)
