Re: Bad press again...
* Paul Gear:
>>>There certainly have been exceptions to that rule. The maintainer of
>>>shorewall has been trying for weeks to get a DSA issued about a
>>>vulnerability, and it seems we have to convince Joey that it *is* a
>>>vulnerability before he'll issue it.
>>
>>
>> Is this #318946?
>
> Correct.
There is very little discussion in the bug report. If this is a
Debian packaging bug, and not an upstream issue, the report should say
so. If it is an upstream issue, upstream's response should be
included or referenced.
>> This one is tagged sarge, but it's been closed by
>> Joey Hess, but probably for testing only.
>
> It seems so. We're not talking about that Joey, though.
(I know.)
> I'm not fully aware of the process that needs to be followed with
> respect to the BTS. Is there something more that we need to do to get
> the security team to action this bug for sarge?
It should remain open while it is under investigation. You should
send the command "found 318946 2.2.3-1" to <control@bugs.debian.org>,
along with anq explanation, to keep it open for the sarge version.
>> Part of "stable" means avoiding unnecessary and potentially harmful
>> changes. Clear policies could help to avoid such misunderstandings.
>
> I don't understand what you mean by that, in the context of this bug
> and the lack of a DSA for shorewall.
As far as I can see, the bug is an unexpected property of a component
which is used to enforce a user-configured security policy. Maybe
this is the intended behavior, and only the documentation has to be
updated. IMHO, something should be done about it, probably in the
form of a DSA, but I'm not sure what it should look like.
It is hard to come up with a uniform policy for such cases, but a few
general rules should be stated nevertheless. For example, I don't
think it's a good idea to add additional safety belts to Debian
packages which aren't integrated upstream because our users might get
used to them and assume that they are available everywhere.
Reply to: