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

[peter green]

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.
Apparently Java 6 and 7 will fail to handshake if a server tries to use 
DH with larger than 1024 bit parameters (and Java 8 apparently fails 
with anything larger than 2048 bits which is not relavent to the current 
discussion but is sad anyway). This is especially an issue with Java 6 
which does not support ECDH (most configurations put ECDH above DH in 
the ciphersuite preferences so java 7 ends up using ECDH).


Personally I think the security advantages of moving away from 1024 bit 
DH (which is probablly breakable with nsa level resources) outweigh this 
breakage (especially as afaict changing the defaults for parameter 
generation will only impact new installs not upgrades) but it is 
probablly something that should be documented.

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

[Kurt Roeckx]

On Tue, Jan 26, 2016 at 06:38:31AM +, Adam D. Barratt wrote:
> On Thu, 2015-12-17 at 23:38 +, 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 ]
> 
>   *) 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

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

[Adam D. Barratt]

On Thu, 2015-12-17 at 23:38 +, 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 ]

  *) 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?

Regards,

Adam

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

[Kurt Roeckx]

On Sun, Dec 06, 2015 at 11:46:01AM +0100, Moritz Mühlenhoff wrote:
> Hi,
> Personally I'm in favour of following the openssl point updates and I'd
> like to add an additional data point to the discussion:
> 
> CVE-2015-3196 was already fixed as a plain bugfix in an earlier point
> release, but the security impact was only noticed later on, so following
> the point updates would have fixed this bug five months ago.

So now CVE-2015-7575 (SLOTH) has been made public.  This is yet an
other example of an issue fixed a long time ago.  It only affected
wheezy because was fixed just after the version in wheezy.


Kurt

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

[Adam D. Barratt]

On Tue, 2015-12-15 at 21:19 +0100, Kurt Roeckx wrote:
> On Tue, Dec 15, 2015 at 08:00:59PM +, Adam D. Barratt wrote:
> > [dropped explicit CCs to RT and TC members]
> > 
> > On Tue, 2015-10-20 at 20:37 +0200, Kurt Roeckx wrote:
> > > On Tue, Oct 20, 2015 at 01:12:42PM -0500, Don Armstrong wrote:
> > > > So from what I'm gathering, this looks like a case where there isn't
> > > > enough eyeballs to adequately review this particularly set of updates,
> > > > coupled with the importance of making sure that these updates are
> > > > correct and don't cause any unintended issues.
> > > 
> > > There is always the case that one persons bug is an other persons
> > > feature.  But those new upstream versions have been in stable and
> > > testing for a while now without actually breaking anything.
> > 
> > (I'm assuming "unstable".)
> 
> I really meant stable.  stable has a newer version than oldstable
> from the same 1.0.1 series.

Okay.

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.)

Admittedly, the description of the changes between 1.0.1k and 1.0.1q,
according to NEWS/CHANGES don't immediately look crazy.

Regards,

Adam

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

[Adam D. Barratt]

On Sun, 2015-12-06 at 11:46 +0100, Moritz Mühlenhoff wrote:
> Hi,
> Personally I'm in favour of following the openssl point updates and I'd

Noted, thanks for the input.

> like to add an additional data point to the discussion:
> 
> CVE-2015-3196 was already fixed as a plain bugfix in an earlier point
> release, but the security impact was only noticed later on, so following
> the point updates would have fixed this bug five months ago.

In isolation, that's an argument for accepting new upstream versions of
most packages into stable, as there'll always be bugs for which the full
impact may not be immediately apparent.

Regards,

Adam

Bug#802159: New OpenSSL upstream version

[Kurt Roeckx]

On Tue, Dec 15, 2015 at 08:00:59PM +, Adam D. Barratt wrote:
> 
> Even a naively filtered diff - excluding documentation and tests -
> between the 1.0.1k tag and HEAD on upstream's stable branch is much
> larger than I'd imagined (1091 files changed, 73609+, 68591-), but
> paging through it there's a significant amount of "no-op" changes such
> as
> 
> -   seed_len,
> -   param_len;
> + seed_len, param_len;
> 
> that git diff is sadly too dumb to be able to ignore (or I'm too dumb to
> be able to drive it to do so).

There was a reformat of the code between those releases.  See:
https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/

It includes the tags before and after the reformat.


Kurt

Bug#802159: New OpenSSL upstream version

[Kurt Roeckx]

On Tue, Dec 15, 2015 at 08:00:59PM +, Adam D. Barratt wrote:
> [dropped explicit CCs to RT and TC members]
> 
> On Tue, 2015-10-20 at 20:37 +0200, Kurt Roeckx wrote:
> > On Tue, Oct 20, 2015 at 01:12:42PM -0500, Don Armstrong wrote:
> > > So from what I'm gathering, this looks like a case where there isn't
> > > enough eyeballs to adequately review this particularly set of updates,
> > > coupled with the importance of making sure that these updates are
> > > correct and don't cause any unintended issues.
> > 
> > There is always the case that one persons bug is an other persons
> > feature.  But those new upstream versions have been in stable and
> > testing for a while now without actually breaking anything.
> 
> (I'm assuming "unstable".)

I really meant stable.  stable has a newer version than oldstable
from the same 1.0.1 series.


Kurt

Bug#802159: New OpenSSL upstream version

[Adam D. Barratt]

On Wed, 2015-10-21 at 15:02 -0500, Don Armstrong wrote:
> It certainly doesn't seem reasonable to expect the SRMs to review line
> by line, but maybe a summary of the changes would help them make a
> decision?
[...]
> SRMs: what would be the best way for Kurt to move forward? Would a list
> of the specific bug fixes and additional features be enough for an
> initial yes/no, given the review process upstream?

As you may have deduced, and mindful of the upcoming TC meeting, I
haven't yet found sufficient tuits to look over the scale and reach of
the changes properly. I'm hoping to have some quiet time over the
weekend that I can devote to looking in to this however.

Regards,

Adam

Bug#802159: New OpenSSL upstream version

[Kurt Roeckx]

On Wed, Nov 04, 2015 at 11:57:00AM -0600, Don Armstrong wrote:
> 
> In this specific case, the specific set of changes which have been made,
> coupled with documenting the policy of upstream for testing and making
> changes to openssl would be a good start.

I've pointed to upstream's policy before, but the URL has actually
changedin the mean time:
https://www.openssl.org/policies/releasestrat.html

I've also gave some information about testing that is happening in
the stable branches at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639#110

I'm not sure what you mean with "specific set of changes which
have been made".  There have been more than 900 upstream commits
since the 1.0.1e release that's in wheezy.  Most of those are
security issues being solved and bug reports that are getting
fixed.  Then there are lots of things we notice in the master
branch that we also fix in the other branches like not checking
return values, memory leaks, and so on.  But there really is too
much to get into details here I think and if you really want to
know just look at the git commit messages.


Kurt

Bug#802159: New OpenSSL upstream version

[Don Armstrong]

On Sat, 31 Oct 2015, Kurt Roeckx wrote:
> On Fri, Oct 30, 2015 at 02:38:13PM -0700, Don Armstrong wrote:
> > On Tue, 20 Oct 2015, Don Armstrong wrote:
> > > If there's something specific that you'd like the CTTE to try to do
> > > beyond what I've just reported now, let me know.
> > 
> > Let me know if you'd like the CTTE to do something beyond what I've
> > already done.
> 
> I guess I would like to know what the options are.  The way I see
> it:
> - The release team makes a decision
> - The release team asks someone else to make the decision

If the SRMs want to delegate their decision to the CTTE in this specific
case, they can, and then the CTTE would be able to decide.

> - Someone makes a policy of what is acceptable, not the current
> situtation where there don't seem to be any rules.

This doesn't require the CTTE itself, though certainly we could be
tasked with suggesting a policy. I'd much rather have the SRMs task a
specific individual with this, though.

In this specific case, the specific set of changes which have been made,
coupled with documenting the policy of upstream for testing and making
changes to openssl would be a good start.

This is necessary for the SRMs (or CTTE if delegated) to decide, and
would be a basis for someone else developing a policy for newer upstream
revisions in stable.

-- 
Don Armstrong  http://www.donarmstrong.com

An elephant: A mouse built to government specifications.
 -- Robert Heinlein _Time Enough For Love_ p244

Bug#802159: New OpenSSL upstream version

[Adam D. Barratt]

On Sat, 2015-10-31 at 00:02 +0100, Kurt Roeckx wrote:
> On Fri, Oct 30, 2015 at 02:38:13PM -0700, Don Armstrong wrote:
> > On Tue, 20 Oct 2015, Don Armstrong wrote:
> > > If there's something specific that you'd like the CTTE to try to do
> > > beyond what I've just reported now, let me know.
> > 
> > Let me know if you'd like the CTTE to do something beyond what I've
> > already done.
> 
> I guess I would like to know what the options are.  The way I see
> it:
> - The release team makes a decision
> - The release team asks someone else to make the decision
> - Someone makes a policy of what is acceptable, not the current
>   situtation where there don't seem to be any rules.

If one of those things happened and the resulting decision was that new
OpenSSL upstream releases don't get blanket exceptions, would that be
the end of this discussion?

> - The DPL removes that power from their delegation.
>   (One can argue that the DPL didn't have the power to delegate
>that in the first place.)

I have to admit that this really doesn't fill me with confidence that
the aim is to get "a decision", rather than force a particular decision.

Regards,

Adam

Bug#802159: New OpenSSL upstream version

[Kurt Roeckx]

On Sat, Oct 31, 2015 at 02:22:04PM +, Adam D. Barratt wrote:
> On Sat, 2015-10-31 at 00:02 +0100, Kurt Roeckx wrote:
> > On Fri, Oct 30, 2015 at 02:38:13PM -0700, Don Armstrong wrote:
> > > On Tue, 20 Oct 2015, Don Armstrong wrote:
> > > > If there's something specific that you'd like the CTTE to try to do
> > > > beyond what I've just reported now, let me know.
> > > 
> > > Let me know if you'd like the CTTE to do something beyond what I've
> > > already done.
> > 
> > I guess I would like to know what the options are.  The way I see
> > it:
> > - The release team makes a decision
> > - The release team asks someone else to make the decision
> > - Someone makes a policy of what is acceptable, not the current
> >   situtation where there don't seem to be any rules.
> 
> If one of those things happened and the resulting decision was that new
> OpenSSL upstream releases don't get blanket exceptions, would that be
> the end of this discussion?

Yes.


Kurt

Bug#802159: New OpenSSL upstream version

[Kurt Roeckx]

On Fri, Oct 30, 2015 at 02:38:13PM -0700, Don Armstrong wrote:
> On Tue, 20 Oct 2015, Don Armstrong wrote:
> > If there's something specific that you'd like the CTTE to try to do
> > beyond what I've just reported now, let me know.
> 
> Let me know if you'd like the CTTE to do something beyond what I've
> already done.

I guess I would like to know what the options are.  The way I see
it:
- The release team makes a decision
- The release team asks someone else to make the decision
- Someone makes a policy of what is acceptable, not the current
  situtation where there don't seem to be any rules.
- The DPL removes that power from their delegation.
  (One can argue that the DPL didn't have the power to delegate
   that in the first place.)
- Start a GR to overrule the DPL's delegate.

And I guess I would like advise on how to proceed.


Kurt

Bug#802159: New OpenSSL upstream version

[Bdale Garbee]

Kurt Roeckx  writes:

> The alternative is that I go and cherry pick the important bug
> fixes.  By this time there are really a lot that I would like to
> have in the stable releases and I think going that way actually
> has a higher chance of breaking things.

We've run into this before a number of times, and always end up
scratching our head about what to do.  Here's my thinking.

While I generally agree with the notion that we should feature-perturb
stable as little as possible, with software that gets intense upstream
scrutiny (which openssl does now thanks to the LF CII, etc), it often
seems lower risk to me to just accept a new upstream version than to do
this sort of ad-hoc cut and paste activity to back-port security fixes.

In this case, I'd be inclined to let the new version in.

Bdale


signature.asc
Description: PGP signature

Bug#802159: New OpenSSL upstream version

[Don Armstrong]

On Tue, 20 Oct 2015, Kurt Roeckx wrote:
> So as already pointed out before, since the 1.0.0 release there is a
> new release strategy that in the 1.0.x series, where x doesn't change,
> no new features are added unless it's really needed for either
> security reasons or compatibility reasons. As far as I know between
> the version in oldstable (a patched 1.0.1e) and 1.0.1p only 1 feature
> got added, and people really have been asking for that one.
> 
> OpenSSL upstream also already has a policy that at least 2 people from
> the team should review all the changes. Since there are so many
> changes I don't think it's reasonable for the release team to review
> all of them.

It certainly doesn't seem reasonable to expect the SRMs to review line
by line, but maybe a summary of the changes would help them make a
decision?

> The alternative is that I go and cherry pick the important bug fixes.
> By this time there are really a lot that I would like to have in the
> stable releases and I think going that way actually has a higher
> chance of breaking things.

Right.

SRMs: what would be the best way for Kurt to move forward? Would a list
of the specific bug fixes and additional features be enough for an
initial yes/no, given the review process upstream?

-- 
Don Armstrong  http://www.donarmstrong.com

There is no more concentrated form of evil
than apathy.

Bug#802159: New OpenSSL upstream version

[Kurt Roeckx]

On Tue, Oct 20, 2015 at 09:57:04AM -0500, Don Armstrong wrote:
> On Sat, 17 Oct 2015, Kurt Roeckx wrote:
> > I've been waiting for the release team for a while to make a decision
> > on #765639 for a year now. Could you help in getting a decision?
> > 
> > I've actually been waiting for longer than that, I can't directly find
> > all links, but previous discussions about it are at least:
> > https://lists.debian.org/debian-devel/2013/09/msg00466.html
> > https://lists.debian.org/debian-project/2013/12/msg00140.html
> 
> Is there anything that it would be helpful for the technical committee
> to do here to help facilitate coming to a decision on this?
> 
> Specifically, this being (FWICT), bringing a new(er) version of openssl
> into jessie and/or wheezy.
> 
> I personally don't have enough information to form an opinion yet, but
> I recognize that some decision should be made.

So to clarify my point of view, I just want to have a decision on
my issue.  I understand that the release team is having a hard
time making a decision, but I'm not sure why.  So I guess my
initial question is to try and understand why they don't make a
decision.  I also wonder if it would help them if they delegated
the decision to the ctte.

There might also be a need to clarify the policy for such updates.


Kurt

Bug#802159: New OpenSSL upstream version

[Don Armstrong]

On Tue, 20 Oct 2015, Don Armstrong wrote:
> On Sat, 17 Oct 2015, Kurt Roeckx wrote:
> > I've been waiting for the release team for a while to make a decision
> > on #765639 for a year now. Could you help in getting a decision?
> > 
> > I've actually been waiting for longer than that, I can't directly find
> > all links, but previous discussions about it are at least:
> > https://lists.debian.org/debian-devel/2013/09/msg00466.html
> > https://lists.debian.org/debian-project/2013/12/msg00140.html
> 
> Is there anything that it would be helpful for the technical committee
> to do here to help facilitate coming to a decision on this?

From discussions (briefly) on IRC:

   my general thoughts offhand are that new upstream versions in
 stable always make me twitchy, new upstream versions that
 introduce features or are sensitive / important packages more
 so, new upstream versions that do both doubly. and we try and
 avoid ending up saying no to people, which often ends up
 actually making things worse as they linger (and we're not
 doing that well at keeping up with the "easy" requests right
 now)

So from what I'm gathering, this looks like a case where there isn't
enough eyeballs to adequately review this particularly set of updates,
coupled with the importance of making sure that these updates are
correct and don't cause any unintended issues.

There was some discussion of whether a more concrete process might help
alleviate the time requirements of these reviews, but I think that's
something for the stable release managers (and other interested parties)
to hash out.

If there's something specific that you'd like the CTTE to try to do
beyond what I've just reported now, let me know.

-- 
Don Armstrong  http://www.donarmstrong.com

Where I sleep at night, is this important compared to what I read
during the day? What do you think defines me? Where I slept or what I
did all day?
 -- Thomas Van Orden of Van Orden v. Perry

Bug#802159: New OpenSSL upstream version

[Kurt Roeckx]

On Tue, Oct 20, 2015 at 01:12:42PM -0500, Don Armstrong wrote:
> On Tue, 20 Oct 2015, Don Armstrong wrote:
> > On Sat, 17 Oct 2015, Kurt Roeckx wrote:
> > > I've been waiting for the release team for a while to make a decision
> > > on #765639 for a year now. Could you help in getting a decision?
> > > 
> > > I've actually been waiting for longer than that, I can't directly find
> > > all links, but previous discussions about it are at least:
> > > https://lists.debian.org/debian-devel/2013/09/msg00466.html
> > > https://lists.debian.org/debian-project/2013/12/msg00140.html
> > 
> > Is there anything that it would be helpful for the technical committee
> > to do here to help facilitate coming to a decision on this?
> 
> From discussions (briefly) on IRC:
> 
>my general thoughts offhand are that new upstream versions in
>  stable always make me twitchy, new upstream versions that
>  introduce features or are sensitive / important packages more
>  so, new upstream versions that do both doubly. and we try and
>  avoid ending up saying no to people, which often ends up
>  actually making things worse as they linger (and we're not
>  doing that well at keeping up with the "easy" requests right
>  now)

So as already pointed out before, since the 1.0.0 release there is
a new release strategy that in the 1.0.x series, where x doesn't
change, no new features are added unless it's really needed for
either security reasons or compatibility reasons.  As far as I
know between the version in oldstable (a patched 1.0.1e) and
1.0.1p only 1 feature got added, and people really have been
asking for that one.

OpenSSL upstream also already has a policy that at least 2 people
from the team should review all the changes.  Since there are so
many changes I don't think it's reasonable for the release team to
review all of them.

The alternative is that I go and cherry pick the important bug
fixes.  By this time there are really a lot that I would like to
have in the stable releases and I think going that way actually
has a higher chance of breaking things.

> So from what I'm gathering, this looks like a case where there isn't
> enough eyeballs to adequately review this particularly set of updates,
> coupled with the importance of making sure that these updates are
> correct and don't cause any unintended issues.

There is always the case that one persons bug is an other persons
feature.  But those new upstream versions have been in stable and
testing for a while now without actually breaking anything.


Kurt

Bug#802159: New OpenSSL upstream version

[Don Armstrong]

On Sat, 17 Oct 2015, Kurt Roeckx wrote:
> I've been waiting for the release team for a while to make a decision
> on #765639 for a year now. Could you help in getting a decision?
> 
> I've actually been waiting for longer than that, I can't directly find
> all links, but previous discussions about it are at least:
> https://lists.debian.org/debian-devel/2013/09/msg00466.html
> https://lists.debian.org/debian-project/2013/12/msg00140.html

Is there anything that it would be helpful for the technical committee
to do here to help facilitate coming to a decision on this?

Specifically, this being (FWICT), bringing a new(er) version of openssl
into jessie and/or wheezy.

I personally don't have enough information to form an opinion yet, but
I recognize that some decision should be made.

-- 
Don Armstrong  http://www.donarmstrong.com

Rule 30: "A little trust goes a long way. The less you use, the
further you'll go."
  -- Howard Tayler _Schlock Mercenary_ March 8th, 2003
 http://www.schlockmercenary.com/d/20030308.html

Bug#802159: New OpenSSL upstream version

[Kurt Roeckx]

Package: tech-ctte

Hi,

I've been waiting for the release team for a while to make a
decision on #765639 for a year now.  Could you help in getting a
decision?

I've actually been waiting for longer than that, I can't directly
find all links, but previous discussions about it are at least:
https://lists.debian.org/debian-devel/2013/09/msg00466.html
https://lists.debian.org/debian-project/2013/12/msg00140.html


Kurt