On Fri, Dec 23, 2005 at 10:38:35PM +0100, Moritz Muehlenhoff wrote:> Steve Langasek wrote: > > - Allowing automatic propagation of security fixes from testing-security to > > testing-proposed-updates *and* unstable > > That''s a very good idea. A large part of the benefits of secure-testing have been > for sid actually, so we should better rename us to non-stable-security anyway. > > However, until now all DTSAs have been following the sid fixes. >Not strictly true, I''ve prepared a cgiwrap DTSA (6-1) which incorporated sid and etch packages. However, the vast majority are indeed etch only packages :) Neil -- __ .` `. neilm@debian.org | Application Manager : :'' ! ---------------- | Secure-Testing Team member ''. `- gpg: B345BDD3 | Webapps Team member `- Please don''t cc, I''m subscribed to the list -------------- 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/20051223/ff3e1deb/attachment.pgp
On Tue, Dec 20, 2005 at 04:34:05PM -0500, micah wrote:> Additionally, AJ references his blog post[2] that discusses work he has > been doing to create embargoed vs. unembargoed queues for > security.debian.org. I have been working with him to test out his > changes and to take notes on the processes and quirks involved. This > goes a long way towards allowing for testing-security to use > security.debian.org queues instead of the alternative queues that we > currently have setup. This is beneficial for a number of reasons. Some > of them include: eliminating the need for the user to have to know Yet > Another Apt Source (YAAS); allows for the testing-security team to be > more officially underneath the project umbrella; and clears the way for > the possibility of having one Security Team (instead of two) separated > only along public vs. embargoed lines, rather than stable vs. testing.- Allowing automatic propagation of security fixes from testing-security to testing-proposed-updates *and* unstable Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/ -------------- 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/20051220/902c159c/attachment.pgp
On Tue, Dec 20, 2005 at 04:34:05PM -0500, micah wrote:> Additionally, AJ references his blog post[2] that discusses work he has > been doing to create embargoed vs. unembargoed queues for > security.debian.org. I have been working with him to test out his > changes and to take notes on the processes and quirks involved. This > goes a long way towards allowing for testing-security to use > security.debian.org queues instead of the alternative queues that we > currently have setup.This sounds brilliant :) I''d love to see advisories released which contain all our distributions. Neil -- __ .` `. neilm@debian.org | Application Manager : :'' ! ---------------- | Secure-Testing Team member ''. `- gpg: B345BDD3 | Webapps Team member `- Please don''t cc, I''m subscribed to the list -------------- 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/20051222/5dc233fc/attachment.pgp
Moritz Muehlenhoff
2006-Mar-13 12:28 UTC
[Secure-testing-team] ongoing security discussions
Steve Langasek wrote:> > Additionally, AJ references his blog post[2] that discusses work he has > > been doing to create embargoed vs. unembargoed queues for > > security.debian.org. I have been working with him to test out his > > changes and to take notes on the processes and quirks involved. This > > goes a long way towards allowing for testing-security to use > > security.debian.org queues instead of the alternative queues that we > > currently have setup. This is beneficial for a number of reasons. Some > > of them include: eliminating the need for the user to have to know Yet > > Another Apt Source (YAAS); allows for the testing-security team to be > > more officially underneath the project umbrella; and clears the way for > > the possibility of having one Security Team (instead of two) separated > > only along public vs. embargoed lines, rather than stable vs. testing. > > - Allowing automatic propagation of security fixes from testing-security to > testing-proposed-updates *and* unstableThat''s a very good idea. A large part of the benefits of secure-testing have been for sid actually, so we should better rename us to non-stable-security anyway. However, until now all DTSAs have been following the sid fixes. Cheers, Moritz
Hi all, A couple discussion points; In case some of you don''t read -project, I want to draw your attention to a recent post that AJ Towns wrote[1]. As I find it hard to follow all the different lists, so this had to be pointed out to me, so some of you may also be unaware of it. Additionally, AJ references his blog post[2] that discusses work he has been doing to create embargoed vs. unembargoed queues for security.debian.org. I have been working with him to test out his changes and to take notes on the processes and quirks involved. This goes a long way towards allowing for testing-security to use security.debian.org queues instead of the alternative queues that we currently have setup. This is beneficial for a number of reasons. Some of them include: eliminating the need for the user to have to know Yet Another Apt Source (YAAS); allows for the testing-security team to be more officially underneath the project umbrella; and clears the way for the possibility of having one Security Team (instead of two) separated only along public vs. embargoed lines, rather than stable vs. testing. It is up to us to decide how we want to move forwards with this setup. Micah 1. http://lists.debian.org/debian-project/2005/12/msg00196.html 2. http://azure.humbug.org.au/~aj/blog/2005/12/21#2005-12-21-newamber