[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version



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.puustinen@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


Reply to: