Re: Bits from the Security Team
Steve Langasek wrote:
>> The Security Team is now using Request Tracker to coordinate work
>> and our RT processes have already been refined a lot.
>> If you're a package maintainer working towards a security update,
>> you're now encouraged to open a ticket directly. You will be kept in
>> CC during the life time of the ticket. If you're opening a ticket for
>> a security problem, which is not yet publicly known, e.g. if you've
>> discovered it by yourself or if you have been contacted by upstream,
>> please open a ticket in the "Security - Private" queue. These
>> issues will only be visible by the Security Team.
>
>> If you're opening a ticket for a security problem which is publicly
>> known, e.g. if it's announced on the project web site, please open a
>> ticket in the "Security" queue. These issues will be visible publicly.
>
> As far as I can see, this announcement mail doesn't mention where the RT
> instance is running, nor the means of opening a ticket in the appropriate
> queue. Where is this information available?
We're using the official rt.debian.org.
Full details will be folded into the developer's reference soon.
>> We're planning to improve our quality assurance process for security
>> updates by providing a public security update beta test program in
>> addition to the existing QA done for security updates.
>> During the preparation of security updates, there's an inherent delay
>> between the initial upload of the fixed packages and the time until
>> the packages have been built on porter machines. This time gap will be
>> used for a new security update beta program. The test program will be
>> targeted at large installations, which install security updates in a
>> test environment before installing them into the production
>> environment. This test group will be initially limited.
>
> Is this meant to apply only to unembargoed security updates? AIUI, the
> practice today is that for embargoed security updates, all of the binaries
> are kept in the queue until they're ready for release; so I don't really see
> a gap when the security update is public but the binary packages aren't
> built?
Yes, this is limited to non-embargoed security issues.
Cheers,
Moritz
Reply to: