Re: [openssl.org #3203] Normalize PFS key exchange labels
On Mon 2014-05-12 15:18:35 -0400, Daniel Kahn Gillmor via RT wrote: I'm happy that the PFS key exchange normalization changesets have been merged into master. I've submitted https://github.com/openssl/openssl/pull/106 for the 1.0.2 stable branch to add similar aliasing for the library input strings. This provides forward compatibility with any documentation produced using the standardized labels (DHE and ECDHE). Since this is on a stable branch, it doesn't change the output. I've done the same thing now for the 1.0.1 branch, which is published here: https://github.com/openssl/openssl/pull/168 I've also updated PR 106 to be up-to-date wth the current stable 1.0.2 branch. I can do this for the other supported stable branches if that would be useful. If there's no interest in applying these changes to stable branches, please say so. --dkg pgp8i7yD4qwJO.pgp Description: PGP signature
RE: [openssl.org #3203] Normalize PFS key exchange labels
I think there's interest for 1.0.1 and beyond. But I thought we already had a similar alias mechanism?
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 09/02/2014 03:34 PM, Salz, Rich wrote: I think there's interest for 1.0.1 and beyond. But I thought we already had a similar alias mechanism? With the version of openssl 1.0.1i that i have in front of me, openssl ciphers EDH succeeds, but openssl ciphers DHE fails. So i don't think the alias is in place. or are you talking about some other alias mechanism? thanks for looking into this, Rich. --dkg signature.asc Description: OpenPGP digital signature
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 05/12/2014 03:18 PM, Daniel Kahn Gillmor via RT wrote: I'm happy that the PFS key exchange normalization changesets haveb been merged into master. I've submitted https://github.com/openssl/openssl/pull/106 for the 1.0.2 stable branch to add similar aliasing for the library input strings. This provides forward compatibility with any documentation produced using the standardized labels (DHE and ECDHE). Since this is on a stable branch, it doesn't change the output. I considered replacing all the internal #defines to use the standardized labels by default within the code as well (e.g. using SSL_kDHE instead of SSL_kEDH everywhere internally) -- the aliases exist so the two terms are equivalent, and both will remain #define'd. But i decided to leave the internal code as untouched as possible for the stable branch. I'm happy to go through and clean up the internal uses as well if folks think that'd be a good idea for 1.0.2. If this patch is considered acceptable for 1.0.2, i can go back and create similar pull requests for the other stable branches. Any thoughts on this? I'd be happy to see this fixed in 1.0.1 and 1.0.0 and 0.9.8 as well, so that we can use the standard terminology on every stable branch. --dkg signature.asc Description: OpenPGP digital signature
Re: [openssl.org #3203] Normalize PFS key exchange labels
I'm happy that the PFS key exchange normalization changesets haveb been merged into master. I've submitted https://github.com/openssl/openssl/pull/106 for the 1.0.2 stable branch to add similar aliasing for the library input strings. This provides forward compatibility with any documentation produced using the standardized labels (DHE and ECDHE). Since this is on a stable branch, it doesn't change the output. I considered replacing all the internal #defines to use the standardized labels by default within the code as well (e.g. using SSL_kDHE instead of SSL_kEDH everywhere internally) -- the aliases exist so the two terms are equivalent, and both will remain #define'd. But i decided to leave the internal code as untouched as possible for the stable branch. I'm happy to go through and clean up the internal uses as well if folks think that'd be a good idea for 1.0.2. If this patch is considered acceptable for 1.0.2, i can go back and create similar pull requests for the other stable branches. --dkg pgptsjDwMy7Sz.pgp Description: PGP signature
Re: [openssl.org #3203] Normalize PFS key exchange labels
Hi Stephen-- On Thu 2014-01-02 16:36:39 -0500, Stephen Henson via RT wrote: On Mon Dec 30 22:47:32 2013, d...@fifthhorseman.net wrote: I don't mean to be impatient -- if it's just a matter of playing catchup over the close of the winter holiday, i can wait :) Yes that's pretty much it. I'll be looking reviewing the patches in the next few days. This is a ping to see if there is anything holding up the patchsets for normalizing PFS key exchange labels on the master branch. If there's anything that seems wrong with the series, or additional work needed to make it acceptable or more attractive for inclusion, please let me know. Regards, --dkg __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3203] Normalize PFS key exchange labels
On Sun, Jan 19, 2014, Daniel Kahn Gillmor via RT wrote: Hi Stephen-- On Thu 2014-01-02 16:36:39 -0500, Stephen Henson via RT wrote: On Mon Dec 30 22:47:32 2013, d...@fifthhorseman.net wrote: I don't mean to be impatient -- if it's just a matter of playing catchup over the close of the winter holiday, i can wait :) Yes that's pretty much it. I'll be looking reviewing the patches in the next few days. This is a ping to see if there is anything holding up the patchsets for normalizing PFS key exchange labels on the master branch. If there's anything that seems wrong with the series, or additional work needed to make it acceptable or more attractive for inclusion, please let me know. They've been committed to the master branch. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 01/19/2014 11:40 AM, Dr. Stephen Henson wrote: On Sun, Jan 19, 2014, Daniel Kahn Gillmor via RT wrote: This is a ping to see if there is anything holding up the patchsets for normalizing PFS key exchange labels on the master branch. If there's anything that seems wrong with the series, or additional work needed to make it acceptable or more attractive for inclusion, please let me know. They've been committed to the master branch. thanks, i see them now. Should I expect this label normalization to be merged into 1.0.2 before it is released, or is this scheduled for some future future release (e.g. 1.1.0)? aside from 1.0.2, i'd like to offer this label normalization on the stable branches as well, if possible, so that any updated documentation, code, and recommendations can make use of them even on systems that track a stable branch of OpenSSL. Presumably, this would mean that the patchsets for already-released stable branches would add the input aliases, but would *not* modify the output in the two relevant places (full ciphersuite names with EDH in them, and packet tracing output). So that both openssl's input and output would change for new full releases, but the input aliases would be available on any new stable revision. Does this sound reasonable? If so, i'm happy to propose a modified series that applies to OpenSSL_1_0_1-stable, for starters. If you think i'm misunderstanding the OpenSSL release process, i'd be very happy to get constructive feedback or pointers to documentation that would help me understand it better. Regards, --dkg signature.asc Description: OpenPGP digital signature
Re: [openssl.org #3203] Normalize PFS key exchange labels
On Sun, Jan 19, 2014, Daniel Kahn Gillmor wrote: If you think i'm misunderstanding the OpenSSL release process, i'd be very happy to get constructive feedback or pointers to documentation that would help me understand it better. A brief description of the versioning scheme is at: http://www.openssl.org/support/faq.html#MISC8 Generally we try to keep stable branch releases as close to 100% compatible as possible so shared libraries can be updated with negligible chance of breaking anything. That isn't always successful... What actually counts as a new feature and what is a bug fix is open to some interpretation. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 01/19/2014 01:34 PM, Dr. Stephen Henson wrote: A brief description of the versioning scheme is at: http://www.openssl.org/support/faq.html#MISC8 thanks, this is useful. However, the changes i'm proposing don't seem to fall neatly into the categories of new feature or API change or ABI change or bug fix. I'd argue that the closest they come is security fix because they provide coherent mechanisms to identify specific security parameters to the library. If people write security configuration guides, those guides will make more sense if they can apply to all current releases, stable or bleeding-edge. Is that plausible? I'm attaching a single collapsed patch for the 1.0.1 stable branch that just adds a minimal aliases without changing internal code or modifying output. That patch is also now at: https://github.com/openssl/openssl/pull/40 If this makes sense to you, i'm happy to craft and test and submit similar patches for whatever other stable branches you would like to see covered. I'm still unclear on whether you think the full range of changes (including output changes) should make it into 1.0.2, or whether we should stick to just the aliases in that case. Let me know what next steps would be most helpful. Regards, --dkg From 3bb46e4bd4fa718131ad994bfad001626a5f79f2 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor d...@fifthhorseman.net Date: Thu, 19 Dec 2013 13:18:30 -0500 Subject: [PATCH] Allow ECDHE and DHE as forward-compatible aliases for EECDH and EDH see PR #3203 Future versions of OpenSSL use the canonical terms ECDHE and DHE as configuration strings and compilation constants. This patch introduces aliases so that the stable 1.0.1 branch can be forward-compatible with code and configuration scripts that use the normalized terms, while avoiding changing any library output for stable users. --- doc/apps/ciphers.pod | 26 +- doc/ssl/SSL_CTX_set_cipher_list.pod | 2 +- doc/ssl/SSL_CTX_set_options.pod | 2 +- doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod | 2 +- doc/ssleay.txt | 2 +- ssl/ssl.h| 4 ssl/ssl3.h | 17 + ssl/ssl_ciph.c | 17 + ssl/ssl_locl.h | 2 ++ ssl/tls1.h | 12 ++-- 10 files changed, 63 insertions(+), 23 deletions(-) diff --git a/doc/apps/ciphers.pod b/doc/apps/ciphers.pod index f44aa00..07058fb 100644 --- a/doc/apps/ciphers.pod +++ b/doc/apps/ciphers.pod @@ -172,7 +172,7 @@ attack and so their use is normally discouraged. cipher suites using RSA key exchange. -=item BkEDH +=item BkDHE cipher suites using ephemeral DH key agreement. @@ -306,12 +306,12 @@ e.g. DES-CBC3-SHA. In these cases, RSA authentication is used. SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHANot implemented. SSL_DH_RSA_WITH_DES_CBC_SHA Not implemented. SSL_DH_RSA_WITH_3DES_EDE_CBC_SHANot implemented. - SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-DSS-DES-CBC-SHA - SSL_DHE_DSS_WITH_DES_CBC_SHAEDH-DSS-CBC-SHA - SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA EDH-DSS-DES-CBC3-SHA - SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-RSA-DES-CBC-SHA - SSL_DHE_RSA_WITH_DES_CBC_SHAEDH-RSA-DES-CBC-SHA - SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA + SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA EXP-DHE-DSS-DES-CBC-SHA + SSL_DHE_DSS_WITH_DES_CBC_SHADHE-DSS-CBC-SHA + SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE-DSS-DES-CBC3-SHA + SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-DHE-RSA-DES-CBC-SHA + SSL_DHE_RSA_WITH_DES_CBC_SHADHE-RSA-DES-CBC-SHA + SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE-RSA-DES-CBC3-SHA SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 EXP-ADH-RC4-MD5 SSL_DH_anon_WITH_RC4_128_MD5ADH-RC4-MD5 @@ -342,12 +342,12 @@ e.g. DES-CBC3-SHA. In these cases, RSA authentication is used. TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHANot implemented. TLS_DH_RSA_WITH_DES_CBC_SHA Not implemented. TLS_DH_RSA_WITH_3DES_EDE_CBC_SHANot implemented. - TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-DSS-DES-CBC-SHA - TLS_DHE_DSS_WITH_DES_CBC_SHAEDH-DSS-CBC-SHA - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA EDH-DSS-DES-CBC3-SHA - TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-RSA-DES-CBC-SHA - TLS_DHE_RSA_WITH_DES_CBC_SHAEDH-RSA-DES-CBC-SHA - TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA + TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA EXP-DHE-DSS-DES-CBC-SHA + TLS_DHE_DSS_WITH_DES_CBC_SHADHE-DSS-CBC-SHA + TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE-DSS-DES-CBC3-SHA + TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-DHE-RSA-DES-CBC-SHA + TLS_DHE_RSA_WITH_DES_CBC_SHADHE-RSA-DES-CBC-SHA + TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE-RSA-DES-CBC3-SHA
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 01/01/2014 12:48 PM, Ben Laurie wrote: Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). OK, i've rebased the series against the current master, and submitted a github-specific pull request: https://github.com/openssl/openssl/pull/37 Cool, tho didn't I read that Steve already pulled it? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 20 December 2013 18:51, Stephen Henson via RT r...@openssl.org wrote: On Fri Dec 20 19:04:32 2013, d...@fifthhorseman.net wrote: I can do whatever you think is most useful, but i need a bit more guidance to be sure i'm giving you what will be most useful for you. I've pulled the update now, thanks. Well I have to admit to being far from a git expert. For me it's best if it's easy to get the patches with commit messages and authorship somewhere I can review them. If I manually have to apply multiple patches and add appropriate credit it's a pain. Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 01/02/2014 03:32 PM, Ben Laurie wrote: On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 01/01/2014 12:48 PM, Ben Laurie wrote: Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). OK, i've rebased the series against the current master, and submitted a github-specific pull request: https://github.com/openssl/openssl/pull/37 Cool, tho didn't I read that Steve already pulled it? I read that as well, but I assumed that just meant that he now has access to the changesets in his local copy. I don't think he's applied them to his master branch, or if he has, he hasn't pushed that master branch to the canonical repository. or maybe i'm not looking at the correct repository? i don't see them applied to the master branch at https://github.com/openssl/openssl, and i don't see them at http://git.openssl.org/gitweb/?p=openssl.git;a=summary should i be looking somewhere else? --dkg signature.asc Description: OpenPGP digital signature
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 01/02/2014 03:32 PM, Ben Laurie wrote: On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 01/01/2014 12:48 PM, Ben Laurie wrote: Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). OK, i've rebased the series against the current master, and submitted a github-specific pull request: https://github.com/openssl/openssl/pull/37 Cool, tho didn't I read that Steve already pulled it? I read that as well, but I assumed that just meant that he now has access to the changesets in his local copy. I don't think he's applied them to his master branch, or if he has, he hasn't pushed that master branch to the canonical repository. or maybe i'm not looking at the correct repository? i don't see them applied to the master branch at https://github.com/openssl/openssl, and i don't see them at http://git.openssl.org/gitweb/?p=openssl.git;a=summary should i be looking somewhere else? --dkg signature.asc Description: PGP signature
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 01/01/2014 12:48 PM, Ben Laurie wrote: Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). OK, i've rebased the series against the current master, and submitted a github-specific pull request: https://github.com/openssl/openssl/pull/37 Cool, tho didn't I read that Steve already pulled it? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 01/01/2014 12:48 PM, Ben Laurie wrote: Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). OK, i've rebased the series against the current master, and submitted a github-specific pull request: https://github.com/openssl/openssl/pull/37 hth, --dkg signature.asc Description: OpenPGP digital signature
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 01/01/2014 12:48 PM, Ben Laurie wrote: Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). OK, i've rebased the series against the current master, and submitted a github-specific pull request: https://github.com/openssl/openssl/pull/37 hth, --dkg signature.asc Description: PGP signature
Re: [openssl.org #3203] Normalize PFS key exchange labels
Hi Stephen-- On Fri 2013-12-20 13:51:06 -0500, Stephen Henson via RT wrote: I've pulled the update now, thanks. Any update on this change? I don't see the patches as having been included in the master branch of https://github.com/openssl/openssl yet. Is there any other information, review, or modification i could provide to help get you to adopt them (either via git merge dkg or some other mechanism)? Is this a question about whether such a change belongs on master or on any of the stable branches? I figure it should go into master first, before we would even start to discuss whether these terminology changes made sense for any of the stable branches. I don't mean to be impatient -- if it's just a matter of playing catchup over the close of the winter holiday, i can wait :) Regards, --dkg __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3203] Normalize PFS key exchange labels
Hi Stephen-- On Fri 2013-12-20 13:51:06 -0500, Stephen Henson via RT wrote: I've pulled the update now, thanks. Any update on this change? I don't see the patches as having been included in the master branch of https://github.com/openssl/openssl yet. Is there any other information, review, or modification i could provide to help get you to adopt them (either via git merge dkg or some other mechanism)? Is this a question about whether such a change belongs on master or on any of the stable branches? I figure it should go into master first, before we would even start to discuss whether these terminology changes made sense for any of the stable branches. I don't mean to be impatient -- if it's just a matter of playing catchup over the close of the winter holiday, i can wait :) Regards, --dkg __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 12/20/2013 12:52 PM, Stephen Henson via RT wrote: On Fri Dec 20 18:37:18 2013, d...@fifthhorseman.net wrote: I posted a series of 10 changesets to openssl-dev which standardizes OpenSSL's input, API, and output on the standard names (DHE and ECDHE) while retaining backward compatibility for string input and API for the older EDH and EECDH terminology. Could you include the lot in a single attachment using git format-patch or as a pull request? It's easier to review and apply that way. Thanks for the quick followup, Stephen. I can do whatever you think is most useful, but i need a bit more guidance to be sure i'm giving you what will be most useful for you. I used git send-email to send these patches earlier, which is how it is usually done on the linux-nfs and notmuch mailing lists (two places i follow that use git heavily). I've also made these patches available as the standardize-on-dhe branch at git://lair.fifthhorseman.net/~dkg/openssl -- you can add that to your local repo with: git remote add dkg git://lair.fifthhorseman.net/~dkg/openssl git remote update dkg and then review it with your local repository browser of choice. If you want them via format-patch: my understanding is that git format-patch produces a directory of patches, one per commit. i'm not sure how you want that as a single attachment. is a tarball of the directory produced by git format-patch OK, or do you want them squashed down to a single aggregated patch? I think having the separate patches makes them easier to review. let me know what else you'd like me to do. Regards, --dkg signature.asc Description: OpenPGP digital signature
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 20 December 2013 18:51, Stephen Henson via RT r...@openssl.org wrote: Well I have to admit to being far from a git expert. For me it's best if it's easy to get the patches with commit messages and authorship somewhere I can review them. If I manually have to apply multiple patches and add appropriate credit it's a pain. I had this problem with my ocb patch recently. For future reference, I solved it by creating a temporary branch and using git merge --squash. So if your commits are on my-branch, and you want to create a patch against master: #Create temp branch git checkout master git checkout -b my-branch-tmp #Merge commits into one git merge --squash my-branch git commit -m my commit message #Create patch git format-patch master --stdout ../my-branch.patch #Delete temp branch git checkout master git branch -D my-branch-tmp Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 12/20/2013 01:51 PM, Stephen Henson via RT wrote: I've pulled the update now, thanks. great! Well I have to admit to being far from a git expert. For me it's best if it's easy to get the patches with commit messages and authorship somewhere I can review them. If I manually have to apply multiple patches and add appropriate credit it's a pain. sure, understood. If you can get the patches all into one maildir or mbox locally (i'm not sure what MUA you use, or what it is capable of), then you should also be able to just run git am /path/to/maildir-or-mbox. For example, in the notmuch MUA's emacs interface, you can just ensure that the patches you want to apply are open in a notmuch-show buffer, and then do: C-u | cd ~/src/openssl git am As regards the patches themselves (and indeed any patch) an important question is what (if anything) it will break. As I understand it cipher strings will still be compatible which is great. yep, i figured something like this wouldn't be acceptable to the community if we actually broke existing cipher specifications. A nice-to-have additional feature might be to have some way to emit warnings when the older EDH and EECDH strings are used (either in cipher strings or at compile time), so that we could ultimately deprecate them -- but i leave that for Future Work :) What about the actual cipher suite names as returned by the various APIs? If an application compares that string to an expected value which is changed it will fail. Anyone know of anything that does that? I searched the entire source of the debian archive for places where those strings might be used: http://codesearch.debian.net/search?q=EDH-RSA There is a lot of non-code that appears to just be translation lists between a library's own idiosyncratic strings and OpenSSL's idiosyncratic strings. Then there are just embedded copies of OpenSSL (e.g. in chromium(!)). Neither of these categories are an issue, i think. Then there is code like erlang's implementation that appears to map controls to strings for OpenSSL itself to use: http://sources.debian.net/src/erlang/1:16.b.3-dfsg-1/lib/ssl/src/ssl_cipher.erl?hl=887#L887 PolarSSL appears to have the same sort of framework: http://codesearch.debian.net/show?file=pdns_3.3-1%2Fpdns%2Fext%2Fpolarssl-1.1.2%2Flibrary%2Fssl_tls.cline=1998numfiles=107#L1998 I don't think this code will break, because i think it's being used to pass strings *to* OpenSSL rather than the other way around. There might be some issues raised in the yaSSL and tcltls and polarssl test suites: http://sources.debian.net/src/mysql-5.5/5.5.33+dfsg-1/mysql-test/r/openssl_1.result?hl=199#L199 http://sources.debian.net/src/tcltls/1.6+dfsg-3/tests/ciphers.test?hl=44#L44 http://codesearch.debian.net/show?file=pdns_3.3-1%2Fpdns%2Fext%2Fpolarssl-1.1.2%2Flibrary%2Fssl_tls.cline=1998numfiles=107#L1998 but those alerts look like they'd be useful to help downstream to be aware that OpenSSL cares about the standard vocabulary too, which is one of the goals of this change (so we can all know that we're talking about the same thing). Those are the only concerns that i see, and while i can imagine some downstream folks getting peeved because they need to adjust their test suites, i think that's an acceptable price to pay for having a sane and normalized vocabulary to be able to talk about this stuff. I didn't see any other significant types of use of these strings in the debian archive. I know debian isn't exhaustive, but it covers a lot of the free software world, at least. btw, since you only raise concerns about the string value returned for the ciphersuites, It sounds like you're OK with the change to the packet tracing output -- i didn't think that the packet tracing would be contentious, but just want to make sure that change is on your radar too. Should be fine :) Regards, --dkg signature.asc Description: OpenPGP digital signature
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 12/20/2013 01:51 PM, Stephen Henson via RT wrote: I've pulled the update now, thanks. great! Well I have to admit to being far from a git expert. For me it's best if it's easy to get the patches with commit messages and authorship somewhere I can review them. If I manually have to apply multiple patches and add appropriate credit it's a pain. sure, understood. If you can get the patches all into one maildir or mbox locally (i'm not sure what MUA you use, or what it is capable of), then you should also be able to just run git am /path/to/maildir-or-mbox. For example, in the notmuch MUA's emacs interface, you can just ensure that the patches you want to apply are open in a notmuch-show buffer, and then do: C-u | cd ~/src/openssl git am As regards the patches themselves (and indeed any patch) an important question is what (if anything) it will break. As I understand it cipher strings will still be compatible which is great. yep, i figured something like this wouldn't be acceptable to the community if we actually broke existing cipher specifications. A nice-to-have additional feature might be to have some way to emit warnings when the older EDH and EECDH strings are used (either in cipher strings or at compile time), so that we could ultimately deprecate them -- but i leave that for Future Work :) What about the actual cipher suite names as returned by the various APIs? If an application compares that string to an expected value which is changed it will fail. Anyone know of anything that does that? I searched the entire source of the debian archive for places where those strings might be used: http://codesearch.debian.net/search?q=EDH-RSA There is a lot of non-code that appears to just be translation lists between a library's own idiosyncratic strings and OpenSSL's idiosyncratic strings. Then there are just embedded copies of OpenSSL (e.g. in chromium(!)). Neither of these categories are an issue, i think. Then there is code like erlang's implementation that appears to map controls to strings for OpenSSL itself to use: http://sources.debian.net/src/erlang/1:16.b.3-dfsg-1/lib/ssl/src/ssl_cipher.erl?hl=887#L887 PolarSSL appears to have the same sort of framework: http://codesearch.debian.net/show?file=pdns_3.3-1%2Fpdns%2Fext%2Fpolarssl-1.1.2%2Flibrary%2Fssl_tls.cline=1998numfiles=107#L1998 I don't think this code will break, because i think it's being used to pass strings *to* OpenSSL rather than the other way around. There might be some issues raised in the yaSSL and tcltls and polarssl test suites: http://sources.debian.net/src/mysql-5.5/5.5.33+dfsg-1/mysql-test/r/openssl_1.result?hl=199#L199 http://sources.debian.net/src/tcltls/1.6+dfsg-3/tests/ciphers.test?hl=44#L44 http://codesearch.debian.net/show?file=pdns_3.3-1%2Fpdns%2Fext%2Fpolarssl-1.1.2%2Flibrary%2Fssl_tls.cline=1998numfiles=107#L1998 but those alerts look like they'd be useful to help downstream to be aware that OpenSSL cares about the standard vocabulary too, which is one of the goals of this change (so we can all know that we're talking about the same thing). Those are the only concerns that i see, and while i can imagine some downstream folks getting peeved because they need to adjust their test suites, i think that's an acceptable price to pay for having a sane and normalized vocabulary to be able to talk about this stuff. I didn't see any other significant types of use of these strings in the debian archive. I know debian isn't exhaustive, but it covers a lot of the free software world, at least. btw, since you only raise concerns about the string value returned for the ciphersuites, It sounds like you're OK with the change to the packet tracing output -- i didn't think that the packet tracing would be contentious, but just want to make sure that change is on your radar too. Should be fine :) Regards, --dkg signature.asc Description: PGP signature
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 12/20/2013 03:30 PM, Matt Caswell wrote: I had this problem with my ocb patch recently. For future reference, I solved it by creating a temporary branch and using git merge --squash. So if your commits are on my-branch, and you want to create a patch against master: fwiw, i think squashing all the patches would make this change significantly more difficult to review. I deliberately broke the changes into logical units that are reviewable and understandable; merging all 10 of them down to one squashed patch would render that one patch much more difficult for me to make sense of (if i was on the reviewing side of the patch submission process), even though the effect on the code would be the same. Regards, --dkg signature.asc Description: OpenPGP digital signature
