On 23/11/2015 21:36, Karl Vogel wrote: >>> On Mon, 23 Nov 2015 05:17:33 +0100, >>> Jakob Bohm <jb-openssl at wisemo.com> said: > J> You all seem to misunderstand the fundamental release engineering issues > J> involved. > > Actually, we don't. > > J> 1. Very shortly after you release OpenSSL 1.1.0, many distributions > J> and pointy haired managers will blindly switch to the new version as > J> the only version available. > > I've installed new OS releases and distributions for over 20 years, > and I don't ever remember having that particular problem with OpenSSL. > On the contrary, our vendors are very conservative and I frequently end > up replacing their version. I am saying that some distributions will switch to the branch currently planned to be named 1.1.0 long before support for 1.0.2 ends. And those distributions will then run try to routinely recompile all openSSL- referencing software packages against the new OpenSSL (along with the new libc, the new kernel, the new zlib etc. etc.) and dispatch bug fixers to fix the resulting compile errors with no special considerations for crypto expertise. (More on this later in this e-mail). By the time such an 1.1.0-based OS release is shipped, that 1.1.0 code will probably be a few letter-patches behind the latest upstream, at least in name (some distributions backport the changes but don't change the letter in the version number, naming it instead something like 1.1.0d+ourpatch7). > J> This will not at all await the "end of support" for OpenSSL 1.0.x. > J> So breaking changes will cause harm much sooner than you claim. > > If we'd waited for the lowest common denominators (aka PHBs) to start > doing their jobs right, we'd still be using DOS 5 and looking forward > to that new-fangled windows thing. I am talking about the breakage caused by PHBs that insist on using the highest OpenSSL version listed as "fixed" in the most recent CVE entry, even when a letter patch to an earlier branch is equally safe. This combined with code that has not (for any reason) been ported from 1.0.2 to 1.1.0 by its primary authors, perhaps because they need some featureremoved in 1.1.0. > > J> 2. Because of the need to easily keep up with routine security updates to > J> OpenSSL, it is highly impractical to maintain locally reconfigured build > J> scripts and patches, though some of us have no choice (and are still > J> struggling with the massively huge and disorganized code reformatting > J> in the middle of the 1.0.1 security update series). > > Do you mean reformatting or refactoring? Would the API itself undergo > significant changes just because some obsolete crypto was removed? > Not being snarky, honestly curious. > > I understand that people do more complex things than simply install > the openssl binary and associated libraries, but I keep CentOS-6, > Solaris-10, and Solaris-11 boxes patched with the same set of scripts. > Aside from the (rare) portability tweak, I don't touch them. I am talking about applying usage/application specific patches to the OpenSSL source tree and the fact that the reformatting requires all such patches to be reimplemented one by one to apply to the reformatted code. > > J> 3. When distributions upgrade OpenSSL, many applications that have not > J> been actively and deliberately ported to the new OpenSSL version will > J> be blindly recompiled with the new versions, and if they break, random > J> developers with no understanding of either the application, OpenSSL or > J> even security will do ill-informed rushed patches to try to undo the > J> breakage you caused. > > If you blindly recompile *anything* just because a version number > changed, any resulting breakage is YOUR problem. People who understand > release engineering issues know better; they also know how to read a > changelog and tell their customers when (and why) to expect something > different. > > When OpenSSL-1.1.whatever comes out, I'll do the same thing I've > always done -- wait a bit for the initial reactions, install it on my > workstation first to make sure it doesn't barf, and then move it out > to the production boxes. You are talking about internal corporate careful roll-out procedures, I am talking about OS distributions such as *BSD and *Linux doing their usual preparations for a new OS release by importing new versions of upstream sources, recompiling and fixing obvious bugs until it "looks OK", while failing to detect subtle breakage or new security issues. A classic example is how Debian (a few years back) did a patch to the OpenSSL RNG, creating an RNG that worked but had way too little entropy. It is that kind of crypto- unskilled mistakes that I fear will proliferate in the fall-out from the breaking changes in OpenSSL 1.1.0. > > J> 4. OpenSSL is THE primary crypto library for the FOSS universe. > J> You may be volunteers, but you are working on a massively important > J> piece of software, not some random optional library. > > Most of them *are* volunteers, and they seem to be taking their > work more seriously than the people disparaging them, not to mention > the folks who are supposed to get this right (i.e., U.S. Office of > Personnel Management). It would be more interesting to compare to teams such as the volunteers on the Linux kernel teams and how they deal with user mode API compatibility. > > J> 5. In these times of panic and marshal law, it is essential that the > J> key resources for open source crypto remain unrestrained by the politics > J> of any single country... > > What does this have to do with removing obsolete crypto from a library? It is just another (unrelated) set of mistakes happening in the new OpenSSL team after the large infusion of money. > > J> 6. All of this requires a lot more caution and a lot less arrogance > J> from the people making decisions about changes in the OpenSSL library > J> and project. > > "Arrogance" would be slamming the changes in without discussion or > notification and saying "like it or lump it". Haven't seen that. Saying "we here you" and then high-handedly deciding to do the deed anyway would also count as arrogance in my book. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151124/10d2d9e9/attachment-0001.html>
