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.c&line=1998&numfiles=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.c&line=1998&numfiles=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
