>> 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.
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.
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.
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.
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).
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?
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.
--
Karl Vogel I don't speak for the USAF or my company
eBay scammer steals identity of Special Agent investigating him
--"Register" headline, 18 Nov 2015
