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

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



[CCs adjusted to drop archived TC bug and add team@security]

On Mon, 2016-03-28 at 19:46 +0200, Kurt Roeckx wrote:
> 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.
> 
> And we're currently already at the end of March ...

Somehow, yes. :-| In the meantime, my hope that I'd manage to find more
free time appears to have been forlorn, as evidenced by my starting to
write this reply during the 7.10 freeze and its having lurked in my
drafts folder since. Given the timing, I'm inclined to suggest that the
best solution for wheezy might be moving straight to -lts, rather than
waiting for whenever 7.11 might be.

In the meantime, I tried to cut through the huge diff for Jessie by
applying upstream's indent rules for the mass reformatting, but while
that improves the situation it still leaves a lot of noise, not least
due to changes in comment layout (as they note themselves). Ideally I'd
have liked to trial a point release or two before committing to that
path for the future, but given that we'll always have to take a large
change the first time I'm not sure how feasible that is.

Assuming that we went ahead with upstream updates to Jessie (and future
supported stable distributions), I'm presuming that the preferred
workflow would be similar to other packages for which we ship upstream
stable trees - via the security archive for issues that merit a DSA,
with lesser severity issues being updated via p-u and thus pushed out to
users as part of a point release. Does that make sense to everyone?
(Does anyone have alternative suggestions?)

Regards,

Adam


Reply to: