Security support for volatile?

[Luk Claes]

Hi

Currently the security support for the volatile archive is supposed to
be taken care of by the uploaders of the respective packages.

I think it would make sense to have someone or a team tracking security
issues for volatile.

What do you think? Is anyone up to providing such issue tracking for
volatile?

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-volatile-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Weimer]

* Luk Claes:

> Currently the security support for the volatile archive is supposed
> to be taken care of by the uploaders of the respective packages.
>
> I think it would make sense to have someone or a team tracking
> security issues for volatile.
>
> What do you think? Is anyone up to providing such issue tracking for
> volatile?

For ClamAV and ClamAV-derived packages, I'd prefer to see uploads of
new upstream versions to stable-security or stable-proposed-updates
(that is, remove it from volatile).


--
To UNSUBSCRIBE, email to debian-volatile-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matus UHLAR - fantomas]

> * Luk Claes:
>
> > Currently the security support for the volatile archive is supposed
> > to be taken care of by the uploaders of the respective packages.
> >
> > I think it would make sense to have someone or a team tracking
> > security issues for volatile.
> >
> > What do you think? Is anyone up to providing such issue tracking for
> > volatile?

On 22.02.09 22:06, Florian Weimer wrote:
> For ClamAV and ClamAV-derived packages, I'd prefer to see uploads of
> new upstream versions to stable-security or stable-proposed-updates
> (that is, remove it from volatile).

May I know why? I think that volatile is exactly the place where they should
be.

--
Matus UHLAR - fantomas, uhlar@... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod


--
To UNSUBSCRIBE, email to debian-volatile-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Kurt Roeckx]

On Sun, Feb 22, 2009 at 10:06:41PM +0100, Florian Weimer wrote:

> * Luk Claes:
>
> > Currently the security support for the volatile archive is supposed
> > to be taken care of by the uploaders of the respective packages.
> >
> > I think it would make sense to have someone or a team tracking
> > security issues for volatile.
> >
> > What do you think? Is anyone up to providing such issue tracking for
> > volatile?
>
> For ClamAV and ClamAV-derived packages, I'd prefer to see uploads of
> new upstream versions to stable-security or stable-proposed-updates
> (that is, remove it from volatile).

I think one the reason why clamav is in volatile is that the engine
might need updating to detect new viruses.  Is that something you
want to support in stable-security?  I don't think an upload only
to stable-proposed-updates is something we want for that, since
it might take a long time until the next point release.


Kurt


--
To UNSUBSCRIBE, email to debian-volatile-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Weimer]

* Kurt Roeckx:

>> For ClamAV and ClamAV-derived packages, I'd prefer to see uploads of
>> new upstream versions to stable-security or stable-proposed-updates
>> (that is, remove it from volatile).
>
> I think one the reason why clamav is in volatile is that the engine
> might need updating to detect new viruses.  Is that something you
> want to support in stable-security?

Yes, I think it would make sense.  Over time, it becomes increasingly
onerous to provide backported patches for clamav, and there is little
benefit (maybe except for cases where clamav is solely used as a spam
filter).  I also think that providing security support for volatile
makes sense, and I've been wondering if it makes sense to kill two
birds with one stone, so to speak.

Of course, there's the slight issue that some maintainers will
complain loudly because they still can't upload new upstream versions
for their packages. 8-) I guess this is something we have to deal with
for the benefit of our users, though.

> I don't think an upload only to stable-proposed-updates is something
> we want for that, since it might take a long time until the next
> point release.

On the other hand, we want quite a bit of testing before we push out a
new version.  I don't really want to tie new major upstream version to
a security update.  So perhaps there's still a reason to upload newer
versions to volatile, and we will just base security updates off that
(similiar to what we currently do with stable-proposed-updates in most
applicable cases)?


--
To UNSUBSCRIBE, email to debian-volatile-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Stone-2]

On Mon, Feb 23, 2009 at 07:27:14PM +0100, Kurt Roeckx wrote:
>I think one the reason why clamav is in volatile is that the engine
>might need updating to detect new viruses.  Is that something you
>want to support in stable-security?

I think there's a couple of questions to answer:
1) is there any point in deploying a virus scanner with outdated
definitions?
2) is volatile well known enough that everyone installing a virus
scanner with debian is using the version in volatile?

Mike Stone


--
To UNSUBSCRIBE, email to debian-volatile-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Stephen Gran]

This one time, at band camp, Michael Stone said:
> On Mon, Feb 23, 2009 at 07:27:14PM +0100, Kurt Roeckx wrote:
> >I think one the reason why clamav is in volatile is that the engine
> >might need updating to detect new viruses.  Is that something you
> >want to support in stable-security?
>
> I think there's a couple of questions to answer:
> 1) is there any point in deploying a virus scanner with outdated
> definitions?

Not in my opinion.

> 2) is volatile well known enough that everyone installing a virus
> scanner with debian is using the version in volatile?

Sadly, no.  We still get people using the version shipped in etch on
#clamav and the clamav-users list, although the numbers are going down
over time.  I'm hoping that the lenny release will help, as volatile is
more likely to end up in people's sources.list.
--
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@... |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

[Michael Tautschnig-4]

> This one time, at band camp, Michael Stone said:

> > On Mon, Feb 23, 2009 at 07:27:14PM +0100, Kurt Roeckx wrote:
> > >I think one the reason why clamav is in volatile is that the engine
> > >might need updating to detect new viruses.  Is that something you
> > >want to support in stable-security?
> >
> > I think there's a couple of questions to answer:
> > 1) is there any point in deploying a virus scanner with outdated
> > definitions?
>
> Not in my opinion.
>
> > 2) is volatile well known enough that everyone installing a virus
> > scanner with debian is using the version in volatile?
>
> Sadly, no.  We still get people using the version shipped in etch on
> #clamav and the clamav-users list, although the numbers are going down
> over time.  I'm hoping that the lenny release will help, as volatile is
> more likely to end up in people's sources.list.

I'm right now in the process of preparing an upload of clamav 0.95rc1; as such,
the question is: where to upload to? unstable? volatile? Any of the other
queues?

Thanks,
Michael

[Tom Furie-2]

On Fri, Mar 13, 2009 at 12:37:35PM +0100, Michael Tautschnig wrote:

> I'm right now in the process of preparing an upload of clamav 0.95rc1; as such,
> the question is: where to upload to? unstable? volatile? Any of the other
> queues?

Maybe I'm not quite clear on the concept of volatile, but I would have
thought both.  One built against stable goes to volatile, the other goes
to unstable.

Cheers,
Tom

--
The opossum is a very sophisticated animal.  It doesn't even get up
until 5 or 6 PM.

[Teodor-Adrian]

On Fri, Mar 13, 2009 at 1:37 PM, Michael Tautschnig <mt@...> wrote:
> I'm right now in the process of preparing an upload of clamav 0.95rc1; as such,
> the question is: where to upload to? unstable? volatile? Any of the other
> queues?

IMO release candidate versions should not be uploaded to volatile.
Being a RC it is not desirable to be put in production yet, only the
final stable version. Probably an upload to 'experimental' is the best
for RCs, not even 'unstable' (but this might be acceptable for some
specific cases).

Thanks


--
To UNSUBSCRIBE, email to debian-volatile-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jim Popovitch-2]

On Fri, Mar 13, 2009 at 13:59, Teodor <mteodor@...> wrote:
> IMO release candidate versions should not be uploaded to volatile.

IMO "volatile" as used in "debian-volatile" is indicative of the
project, not the package.  ClamAV, a "moving target" type project, is
an excellent example of a debian-volatile candidate.

-Jim P.


--
To UNSUBSCRIBE, email to debian-volatile-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Teodor-Adrian]

On Fri, Mar 13, 2009 at 8:31 PM, Jim Popovitch <jimpop@...> wrote:
> On Fri, Mar 13, 2009 at 13:59, Teodor <mteodor@...> wrote:
>> IMO release candidate versions should not be uploaded to volatile.
>
> IMO "volatile" as used in "debian-volatile" is indicative of the
> project, not the package.  ClamAV, a "moving target" type project, is
> an excellent example of a debian-volatile candidate.

I'm not sure what you want to say, maybe I wasn't clear enough. The
discussion is not whether or not "clamav" should be in volatile or not
(I'm on the PRO side), but if an intermediate beta version should be
updated in volatile or not (rc1, rc2...). I'm still convinced that
clamav 0.95rc1 should *NOT* be updated in volatile, for sure I won't
upgrade to a RCx until the stable version 0.95 (or greater) is
released.

Thanks


--
To UNSUBSCRIBE, email to debian-volatile-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jim Popovitch-2]

On Fri, Mar 13, 2009 at 14:54, Teodor <mteodor@...> wrote:
> On Fri, Mar 13, 2009 at 8:31 PM, Jim Popovitch <jimpop@...> wrote:
>> On Fri, Mar 13, 2009 at 13:59, Teodor <mteodor@...> wrote:
>>> IMO release candidate versions should not be uploaded to volatile.
>>
>> IMO "volatile" as used in "debian-volatile" is indicative of the
>> project, not the package.  ClamAV, a "moving target" type project, is
>> an excellent example of a debian-volatile candidate.
>
> I'm not sure what you want to say, maybe I wasn't clear enough.

Sorry, yes  I too agree that RC versions belong in experimental, not
volatile.  I only wanted to make sure (based on earlier comments) that
volatile's purpose is clear.

-Jim P.


--
To UNSUBSCRIBE, email to debian-volatile-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Boyd Stephen Smith Jr.-3]

On Friday 13 March 2009 13:54:35 Teodor wrote:
> On Fri, Mar 13, 2009 at 8:31 PM, Jim Popovitch <jimpop@...>
wrote:
> > On Fri, Mar 13, 2009 at 13:59, Teodor <mteodor@...> wrote:
> >> IMO release candidate versions should not be uploaded to
volatile.
> >
> > IMO "volatile" as used in "debian-volatile" is indicative of the
> > project, not the package.  ClamAV, a "moving target" type
project, is
> > an excellent example of a debian-volatile candidate.
>
> I'm not sure what you want to say, maybe I wasn't clear enough. The
> discussion is not whether or not "clamav" should be in volatile or
not
> (I'm on the PRO side), but if an intermediate beta version should
be
> updated in volatile or not (rc1, rc2...). I'm still convinced that
> clamav 0.95rc1 should *NOT* be updated in volatile, for sure I
won't
> upgrade to a RCx until the stable version 0.95 (or greater) is
> released.

I'm in agreement with Teodor.  I think clam-av is probably a good
candidate for volatile--at least virus definitions and also the
binary/library if needs to take advantage of the new definitions. But
if the package is not suitable for unstable (and generally RCs
aren't), it is not suitable for volatile or even volatile-sloppy.

(Maybe this warrants a new thread, but what's the real difference
between volatile-sloppy and backports?)
--
Boyd Stephen Smith Jr.           ,= ,-_-. =.
bss@...             ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/            \_/

[Florian Weimer]

* Tom Furie:

> On Fri, Mar 13, 2009 at 12:37:35PM +0100, Michael Tautschnig wrote:
>
>> I'm right now in the process of preparing an upload of clamav 0.95rc1; as such,
>> the question is: where to upload to? unstable? volatile? Any of the other
>> queues?
>
> Maybe I'm not quite clear on the concept of volatile, but I would have
> thought both.  One built against stable goes to volatile, the other goes
> to unstable.

Yes, this is the correct approach in principle, but I don't think
release candidates should be uploaded to volatile.  But I can't speak
for debian-volatile, really.


--
To UNSUBSCRIBE, email to debian-volatile-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Tom Furie-2]

On Fri, Mar 13, 2009 at 09:21:44PM +0100, Florian Weimer wrote:
>
> Yes, this is the correct approach in principle, but I don't think
> release candidates should be uploaded to volatile.  But I can't speak
> for debian-volatile, really.

Never noticed the rc in the version number there. I suppose also that a
new version should only be uploaded to volatile if the current version
will have reduced functionality as a result of changes in the new
version.

Cheers,
Tom

--
"Beware of programmers carrying screwdrivers."
                -- Chip Salzenberg