Re: security in testing
On Mon, May 26, 2003 at 03:24:49PM +0200, Gerfried Fuchs wrote:
> * Sven Luther <sven.luther@wanadoo.fr> [2003-05-16 13:33]:
> > Such a package should be as close to possible to the version actually
> > in testing, and not depend on packages and/or versions that are not
> > yet in testing.
>
> So, you request more or less that every developer should backport fixes
> themself from the usual new upstream version that fixes the problem (and
> mostly always have new features too) to the version in testing, which
> might even be older than just one upstream release, due to usual holdups
> in the transition. It sounds like you like to have every developer be
> able to do what the security team does. That requires much skill -- much
> more than most of us possess!
Well, that would be the ideal thing, but then, notice that i said
'should' and not 'must'. Clearly each debian developer is the person to
take the decision on which version should go into
testing-proposed-updates, it is just that by minimizing the changes, it
makes it easier for the RM or his assitant to feel secure about this. If
the package maintainer sense that the same version as the unstable one
should be uploaded, then he can, but it should be with a lower version
number than the unstable has.
> I for my part don't think that I could spend enough efforts in doing
> this correct, and I don't think that I'm that far below average in
> skills of the usual debian developer.
Notice that in most case, the version in testing and in unstable should
be very close, especially once we have this scheme working, and will
often differ only in debian revision. If this is such, applying a bugfix
to the unstable version and applying it to the testing version is the
same work, if there is a new upstream release that fix the bug, then
this should be built for unstable, provided it is buildable in testing.
> What _is_ needed to do it correct to make it work is having people that
> are *willing* to do such backport fixes -- and still people only keep
> repeating that it is needed and needed, but still noone is stepping
> forward to do the actual work. I for my part would be pleased to be of
> help when it's needed, but I'm afraid that I lack of skill to be in the
> core team (hell, I'm JAPH, with some C knowledge, but when it comes to
> python, C++, java or whatever I'm out of luck), left aside the time
> constraints I'm currently facing.
No, i don't think that the same strenous version restriction that e have
for stable also apply for testing. So a maintainer is much more
qualified to do the job, and can also easily do it.
> > Also, we could add 2 things, first the RM assitants, which are debian
> > developers who have voluntereed to help the RM in this, and have the
> > right to give the green light to uploads.
>
> Off topic: I haven't seen it on d-d-a, are they decided yet? Just
> curious.
No, i think it has fallen in forgoteness (or something such, there must
be a english sentence to express this properly).
> > Second, what could be done about NMUs. Maybe a small group of apprentice
> > security team members could scan the security announcements, and prepare
> > NMU of such security holed packages, in close contact with the
> > maintainer and the RM or his assistants, or maybe even the security
> > team, especially if the problems are also present in stable packages.
>
> This is nothing new and was said over and over again -- just that noone
> yet seem to have raised interest to do the work! Sorry for my pessimism
> but I doubt that this thread will really make anyone step forward this
> time.... I'd love to be told otherwise!
As said, it has fallen in forgeteness, but then, since developers cna
now do this for their packages, maybe some of them will like this and
step forward ?
> > So, with such an announcement, everyone wins
>
> Noone wins if noone likes to do the work, like I said before in this
> thread. It would just make us look even more awkward, I guess.
I think the maintainers are responsible enough and care enough about
their packages to do it themselves, i certainly would, if they can get
past the frustration of having all their effort stalled in unstable
because this or that packages current brokeness.
> > the maintainer will be able to fix things in testing more easily
>
> I've I understand you correct it wouldn't be easy, for backporting
> fixes seldom is easy.
No, it is just a matter of backporting the unstable package to testing
dependencies and have it built in testing environment. It is not a full
testing-security, but would at least make testing as secure as unstable
is, and not orders of magintude less.
But again, the RM has not commented on this plan, and has he has the
ultimate decision on this, nothing happened.
That said, since testing is becoming more and more in a releaseable
shape, it may not be as important at it was previously.
Friendly,
Sven Luther
Reply to: