On Tue, Jan 26, 2016 at 06:38:31AM +0000, Adam D. Barratt wrote: > On Thu, 2015-12-17 at 23:38 +0000, Adam D. Barratt wrote: > > However 1.0.1q hasn't been in stable at all, which is presumably what > > you'd be proposing introducing to oldstable at this juncture. (and which > > we'd therefore need to introduce to stable first, if we were to agree to > > follow that path.) > > Picking this up again (I hadn't realised the above was so many weeks > ago :-|), updating OpenSSL in Wheezy to anything newer than 1.0.1k > really needs a newer upstream version to be in Jessie first. We also > likely only have two opportunities to get a package in to "Wheezy > proper" before it moves to LTS status - likely a point release in March > and then a "mop up" after the EOL of the base suite. > > > Admittedly, the description of the changes between 1.0.1k and 1.0.1q, > > according to NEWS/CHANGES don't immediately look crazy. > > Comparing those against the package changelog and Security Tracker and > ignoring changes which are apparently only relevant if SSLv2 is enabled > leaves us with: > > *) dhparam: generate 2048-bit parameters by default. > [Kurt Roeckx and Emilia Kasper] > > *) Rewrite EVP_DecodeUpdate (base64 decoding) to fix several bugs. > This changes the decoding behaviour for some invalid messages, > though the change is mostly in the more lenient direction, and > legacy behaviour is preserved as much as possible. > [Emilia Käsper] > > *) In DSA_generate_parameters_ex, if the provided seed is too short, > return an error > [Rich Salz and Ismo Puustinen <ismo.puusti...@intel.com>] > > *) Build fixes for the Windows and OpenVMS platforms > [Matt Caswell and Richard Levitte] > > The last of those is obviously irrelevant. Have there been any reports > of issues related to the other fixes listed?
I can't remember any report about one of the above changes, nor can I find any. The base64 change is that it did weird things when receiving invalid base64, which you shouldn't get in practice, and now at least acts sane. The DSA entry in CHANGES is actually wrong, that's how it was changed in the master branch. It was merged to the stable branches and then reverted without reverting the CHANGES, and then fixed to instead do what was previously documented and uses a random seed if the seed is too short. I'll see about getting that CHANGES entry fixed. We reverted that because we think it wasn't an acceptable change in behaviour in the stable branches. The dhparam thing is really about a default that if you generate DH parameters that it defaults to 2048 instead of 1024. This shouldn't break anything itself, nor do I know of any other software that would get broken by this. You can always override this default when generating them. The most reports about breakage we get actually have to do with the security fixes themself, like enforcing the minimum size of 768 bit when using DH and then finding out that there is software that uses 512 bit DH. (The upcomming release will actually change that to 1024, as announced.) Kurt