Secure testing team - Mar 2006 - Guidelines for testing security fixes

Moritz Muehlenhoff wrote:
> Quoting secure-testing.debian.net:
> 1. Only upload changes that have already been made in unstable and are
> blocked by reaching testing by some other issues. This is both to keep
> things in sync once the new version from unstable reaches testing, and
> to avoid breaking secure-testing too badly with fixes that have not been
> tested first in unstable.
> 
> Rebuilding packages from sid into testing that are stuck by a larger
> transition does not work if the maintainer has fixed a vulnerability
> by upgrading to a major new upstream version. E.g. kate:
> testing has 3.3.2 and the sid fix is kdebase 3.4.1. In cases like
> this we should better prepare patched packages for 3.3 (in the
> case of KDE it''s rather simple as there are official upstream
> patches for this version). As long as the packages in sid are fixed
> as well, things don''t become out of sync here and official
upstream
> patches should normally be tested sufficiently.
> 
> Comments?
Right. On the other hand patching 3.3 before unstable has any fix for
the problem could cause issues once unstable got a new version (possibly
w/o the fix) and is the situation that guideline is intended to prevent.
Backporting fixes is of course OK.

Perhaps s/changes/fixes/ on the first line would clarify it.

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050829/114bd92a/attachment.pgp

Hi,
Quoting secure-testing.debian.net:
1. Only upload changes that have already been made in unstable and are
blocked by reaching testing by some other issues. This is both to keep
things in sync once the new version from unstable reaches testing, and
to avoid breaking secure-testing too badly with fixes that have not been
tested first in unstable.

Rebuilding packages from sid into testing that are stuck by a larger
transition does not work if the maintainer has fixed a vulnerability
by upgrading to a major new upstream version. E.g. kate:
testing has 3.3.2 and the sid fix is kdebase 3.4.1. In cases like
this we should better prepare patched packages for 3.3 (in the
case of KDE it''s rather simple as there are official upstream
patches for this version). As long as the packages in sid are fixed
as well, things don''t become out of sync here and official upstream
patches should normally be tested sufficiently.

Comments?

Cheers,
        Moritz