[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RfD: Debian Security Policy



Adam Di Carlo wrote:
> Martin Schulze <joey@finlandia.Infodrom.North.DE> writes:
> 
> > Debian Security Policy
> > 
> > 1. This Policy document describes the scope and duties of the Debian
> >    Security Team for Debian.
> 
> I think this is excellent!  I hope it gets posted on the web site (or
> some web site) soon.
> 
> > 2. As soon as an incident is known the Security Team work on fixing
> >    affected packages.  If no fix is known yet, they try to develop one
> >    on their own in connection with affected package maintainers.
> 
> I would say here:
> 
>  2. As soon as an incident is known the Security Team work on
>     determining where the fault is, and fixing affected packages.  If
>     no fix is known yet, they try to develop one on their own in
>     connection with affected package maintainers.  (Package
>     maintainers are responsible for corresponding with upstream
>     maintainers).

Ok.

> Actually, maybe it should be that the security team immediately notify
> both the package maintainer and the upstream maintainer of the problem

The pkg maintainer should inform the upstream maintainer.

> once the fault is known.  I think this would put it in better stead
> with upstream maintainers (who maybe would be more inclined to notify
> the Security team if security faults are detected by "third parties").
> 
> Actually, isn't everything but the first sentance redundant with what
> comes below?

Well, theoretically the whole document is redundant since it's logical
that we act this way, isn't it?

> > 7. If the maintainer of a certain package does not respond within a
> >    few days or is unable to provide a fixed package, the Security Team
> >    is permitted to work on a fixed version on their own.
> 
> Actually, I don't think the security team should have any waiting
> periods at all.  They should attempt to reach the package maintainer,
> but may (or may not) immediate fix and upload at their discretion.

We should not start stepping on other people's toes.  The maintainer
should get one or two days to wake up.

> > 8. New subreleases of the stable distribution containing security
> >    updates will be prepared every one or two months, depending on the
> >    amount of security updates.  This will keep systems relatively up
> >    to date.  It will also keep proposed-updates and
> >    security.debian.org small.  An announcement will be made covering
> >    the new subrelease.
> 
> Probably should speicify the announcement list.

Granted:

8. New subreleases of the stable distribution containing security
   updates will be prepared every one or two months, depending on the
   amount of security updates.  This will keep systems relatively up
   to date.  It will also keep proposed-updates and
   security.debian.org small.  An announcement will be released to
   debian-announce@lists.debian.org as well as to the security list
   covering the new subrelease.

> That reminds me, you should probably also specify the advisory list so
> people know how to subscribe to it.

4. If the exploit/fix is known and Debian is able to fix it within one
   week, either the maintainer or the Security Team fixes packages,
   upload them to both stable and unstable.  If the auto-compiliers
   don't catch the source files, the Security Team will ask porters to
   recompile or do that on their own.  The Security Team then releases
   a Security Advisory to debian-security-announce@lists.debian.org.

Regards,

	Joey

-- 
Experience is something you don't get until just after you need it.


Reply to: