Secure testing team - Mar 2006 - Another syntax addition: <removed>

Hi,
consider the following case: Package foo has a bug, the bug affects stable
or oldstable, but the fix for sid/testing consists in the removal of foo
or it has already been removed for other reasons.
<not-affected> doesn''t fit, because older releases of Debian
_are_ affected,
while the issue is no longer relevant for testing/sid. The solution is
a new "solution state" <removed>. Please adapt external scripts
for this
new token; it''ll be used soon. (bidwatcher, libsafe)

Cheers,
        Moritz

Joey Hess wrote:
> > consider the following case: Package foo has a bug, the bug affects
stable
> > or oldstable, but the fix for sid/testing consists in the removal of
foo
> > or it has already been removed for other reasons.
> > <not-affected> doesn''t fit, because older releases of
Debian _are_ affected,
> > while the issue is no longer relevant for testing/sid. The solution is
> > a new "solution state" <removed>. Please adapt
external scripts for this
> > new token; it''ll be used soon. (bidwatcher, libsafe)
> 
> IMHO the correct thing to do is to mark it as unfixed. Then if it
> somehow re-enters testing later from sid, we will see it and go make
> sure the new version is fixed. If it''s marked as <removed>
we''ll miss
> that check.
This is only for packages completely removed from the archive, not for
packages removed solely from testing.

Cheers,
        Moritz

Florian Weimer wrote:
> > The fix is to remove the package permanantly from the archive, as
> > it''s broken anyway. This is a "fix", as etch will
not be affected,
> > but not a complete fix for those who still have bidwatcher
> > installed. So this marks a package as addressed, only not with a
> > patch, but with a big hammer.
> 
> But you can infer this information from the Sources files (and use the
> removed-packages file for double-checking).  I don''t think
it''s a good
> idea to duplicate this data.
It''s not duplication, it''s <removed> instead of
<unfixed>. I''m against
inferring information, which might as well be clearly denoted.
It''s fixed for the stable etch, that''s precise, valuable
information.
Everyone benefits from ensuring that all security bugs are tracked
and known when etch freezes, while only a subset of all users run testing
and benefit from DTSAs.

Cheers,
        Moritz

Moritz Muehlenhoff wrote:
> consider the following case: Package foo has a bug, the bug affects stable
> or oldstable, but the fix for sid/testing consists in the removal of foo
> or it has already been removed for other reasons.
> <not-affected> doesn''t fit, because older releases of Debian
_are_ affected,
> while the issue is no longer relevant for testing/sid. The solution is
> a new "solution state" <removed>. Please adapt external
scripts for this
> new token; it''ll be used soon. (bidwatcher, libsafe)
IMHO the correct thing to do is to mark it as unfixed. Then if it
somehow re-enters testing later from sid, we will see it and go make
sure the new version is fixed. If it''s marked as <removed>
we''ll miss
that check.

-- 
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/20051004/16955bd0/attachment.pgp

* Joey Hess:
> Moritz Muehlenhoff wrote:
>> consider the following case: Package foo has a bug, the bug affects
stable
>> or oldstable, but the fix for sid/testing consists in the removal of
foo
>> or it has already been removed for other reasons.
>> <not-affected> doesn''t fit, because older releases of
Debian _are_ affected,
>> while the issue is no longer relevant for testing/sid. The solution is
>> a new "solution state" <removed>. Please adapt external
scripts for this
>> new token; it''ll be used soon. (bidwatcher, libsafe)
>
> IMHO the correct thing to do is to mark it as unfixed. Then if it
> somehow re-enters testing later from sid, we will see it and go make
> sure the new version is fixed.
For the record, I agree.

Moritz, I don''t understand which problem you are trying to solve.  If
the package is not present in testing, it''s not vulnerable.

* Moritz Muehlenhoff:
> The fix is to remove the package permanantly from the archive, as
> it''s broken anyway. This is a "fix", as etch will not be
affected,
> but not a complete fix for those who still have bidwatcher
> installed. So this marks a package as addressed, only not with a
> patch, but with a big hammer.
But you can infer this information from the Sources files (and use the
removed-packages file for double-checking).  I don''t think
it''s a good
idea to duplicate this data.
> Plus, <removed> allows tsck to generate warnings for those, who
> still have the package installed (the respective dselect section is
> rather unknown to most users).
Marking the package as unfixed does the same thing, doesn''t it?

Florian Weimer wrote:
> > Moritz Muehlenhoff wrote:
> >> consider the following case: Package foo has a bug, the bug
affects stable
> >> or oldstable, but the fix for sid/testing consists in the removal
of foo
> >> or it has already been removed for other reasons.
> >> <not-affected> doesn''t fit, because older releases
of Debian _are_ affected,
> >> while the issue is no longer relevant for testing/sid. The
solution is
> >> a new "solution state" <removed>. Please adapt
external scripts for this
> >> new token; it''ll be used soon. (bidwatcher, libsafe)
> >
> > IMHO the correct thing to do is to mark it as unfixed. Then if it
> > somehow re-enters testing later from sid, we will see it and go make
> > sure the new version is fixed.
> 
> For the record, I agree.
> 
> Moritz, I don''t understand which problem you are trying to solve. 
If
> the package is not present in testing, it''s not vulnerable.
CAN-2005-XXXX [Buffer overflow in Description parsing]
        - bidwatcher <unfixed> (bug #319489; high)

woody, sarge:
Affected, fix in the hands of the security team, not of interest for us.
<not-affected> is not correct.

etch, sid:
The fix is to remove the package permanantly from the archive, as it''s
broken
anyway. This is a "fix", as etch will not be affected, but not a
complete fix
for those who still have bidwatcher installed. So this marks a package as
addressed, only not with a patch, but with a big hammer.
Plus, <removed> allows tsck to generate warnings for those, who still have
the
package installed (the respective dselect section is rather unknown to most
users).

Cheers,
        Moritz

* Moritz Muehlenhoff:
>> IMHO the correct thing to do is to mark it as unfixed. Then if it
>> somehow re-enters testing later from sid, we will see it and go make
>> sure the new version is fixed. If it''s marked as
<removed> we''ll miss
>> that check.
>
> This is only for packages completely removed from the archive, not for
> packages removed solely from testing.
Obviously, we mean different things with "removed from the archive".
When I used this phrase in the past, I meant it literally, that is,
the package is not present in woody, sarge, etch, sid (I ignore
experimental, admittedly).

I implemented <removed> for my tracker.  Right now, it just means the
same as <unfixed>.  Semantically, there isn''t a real difference,
but
it could be used to generate more informative status reports in the
future.