Re: LTS progress so far [was: Draft announce of Debian 6 LTS, please review quickly]
Matt Palmer wrote:
> I was under the impression that security team members were releasing
> updates for LTS alongside the rest of the distributions, where those team
> members were also interested in LTS.
Individual members will continue to handle some updates, but from a
high level view, rather not: If we handle all security updates
we release for security.debian.org, we will quickly exceed our (already
sparse) resources.
Currently we only deal with wheezy, but in a year we need to deal with jessie
and wheezy and if we add squeeze on top it drains far too much time.
And if we need to decide between an update for security.debian.org and LTS
s.d.o will come first, since it's the bigger userbase.
Realistically Debian LTS needs to be planned w/o any contributions from
the standard security team. If we do contribute, this is icing on the cake.
> > * Noone has taken care of the linux-2.6 update, although all the patches
> > have been prepared and Carlos has made various tests
>
> For me at least, the idea of doing a kernel security update is slightly
> daunting. And, up until the last few days, there was a big comment in the
> top of lts-needed.txt that said that linux-2.6 updates were tracked
> separately, which led me to believe it was being taken care of.
Ok, this has been removed to avoid this confusion.
> > * Noone is taking care of updating lts-needed.txt or other triage
>
> I'd be happy to contribute to this, except I'm not sure *how*. Is it a
> matter of watching mailing lists (if so, which ones?) and adding issues as
> they're reported?
Anyone taking care of the LTS orga should subscribe to
http://lists.alioth.debian.org/mailman/listinfo/secure-testing-commits ,
that's the most efficient way to stay up-to-date.
The general research of new security issues is well established, the only
thing that needs to be taken care for the Debian LTS team of is the
status of squeeze.
> Reloading the security-tracker page a couple of times a
> day and manually comparing the two lists (that seems... inefficient)?
Initially there needs to be an initial analysis of the data shown at
https://security-tracker.debian.org/tracker/status/release/oldstable
as described at the bottom of lts-needed.txt
After that initial triage every item from that list should either be
in lts-needed.txt or marked as <no-dsa>, <end-of-life> or <not-affected>.
Once that initial run is done, it's only a matter of dealing with new issues, so
whenever there's a new issue in the tracker it needs to be checked
for one of the four possibility (no-dsa, end-of-life not-affected or lts-needed)
and marked in the security tracker.
For the security team we have a weekly rotating front desk. Maybe the same
can be established for Debian LTS as well.
> Watching changes to dsa-needed.txt and copying across the ones that match
> (slightly less inefficient)? So far, I've been watching for DSAs that don't
> get a matching LTS update (but which appear vulnerable in squeeze) and
> working on those.
We need to establish a work flow for this:
First question: If an issue is tagged as <no-dsa> for wheezy by the security
team, shall we directly also tag is as <no-dsa> for squeeze or does anyone
want to classify this independently? ("we" as in Debian security team)
Second question: If we add an issue to dsa-needed.txt, shall we also add it
to lts-needed (if that package is in squeeze) or does anyone want to classify
this independently?
> > So, from my view it's fairly obvious that Debian LTS will only be sustainable
> > if there's an ongoing base of sponsored work.
>
> Is that how the current security team operates, on sponsored work (I ask
> that legitimately -- I have no idea)?
It's volunteer work.
> If so, then yes, it's fairly unlikely
> that LTS will survive based entirely on volunteer effort. On the other
> hand, if the security team manages to produce the fine work it does
> primarily volunteer labour, it wouldn't seem impossible that LTS could do
> the same.
We only manage to do so because of massive time investments by the people
involved and by a frequent need to bite not only bullets, but whole cartridge
belts. As such, finding new people to participate is an ongoing challenge.
We'll have to see if there's still enough interest for Debian LTS once the
initial enthusiasm is gone. The first PHP update is interesting to work on,
the tenth hardly so. That's why I think that having a base layer of funded
work is important in the mid-term.
Also, an important factor is that some package maintainers contribute
to standard security updates, while we cannot expect the same for Debian LTS.
That said, Debian LTS is of course a wonderful pool to draft new members
for the security team :-)
> Please remember that the non-security-team members of the LTS effort are (I
> presume) all total n00bs at doing security work, so it's not *entirely*
> surprising we're not going to be great at it at first. What would really
> help *me*, at least, is if you notice things not working up-to-spec, you
> call them out (like you've done here) and help those of us who say "yep,
> that sucks, how can we do it better?" to get better.
Of course, hence my mail and all my contributions. Let's make this great!
Cheers,
Moritz
Reply to: