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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
