I sent fixed the current poppler security issue a while back before squeeze was released and sent a mail, but never heard anything. I''ve just rebuilt a squeeze update. See: http://mentors.debian.net/pool/main/p/poppler Should this get a DSA? I wonder if it would help to set up a security.debian.org bug tracker (similar to the release.debian.org [0]) so stuff like this doesn''t get lost? Best wishes, Mike [0]http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org;dist=unstable
On Sun, Feb 20, 2011 at 08:30:25PM -0500, Michael Gilbert wrote:> I wonder if it would help to set up a security.debian.org bug tracker > (similar to the release.debian.org [0]) so stuff like this doesn''t get > lost?This occurred to me recently but actually it didn''t fix the problem I had, so I didn''t take it any further. In what cases would bugs be filed against this pseudo-package instead of against the package with the security issue? or do you envisage using the ''affects'' feature? The latter, affects+usertags would (I think) be a great help to me in my PRSC tracking, though I should make sure that''s the case. -- Jonathan Wiltshire jmw at debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20110221/0d1b7c41/attachment.pgp>
Hi Mike, On Monday 21 February 2011 02:30:25 Michael Gilbert wrote:> I sent fixed the current poppler security issue a while back before > squeeze was released and sent a mail, but never heard anything. I''ve > just rebuilt a squeeze update. See: > http://mentors.debian.net/pool/main/p/poppler > > Should this get a DSA?Thanks for your work. I do not believe this needs a DSA because according to Dan, "the chance of being able to exploit this for anything other than a crash is very remote". We can roll it up when another poppler issue comes up in the future. I see that for sid 0.16.2 is already pending so I''ve sent a followup mail to the BTS to ask for the CVE id''s to be included in the changelog.> I wonder if it would help to set up a security.debian.org bug tracker > (similar to the release.debian.org [0]) so stuff like this doesn''t get > lost?We already have a bug tracker, which is rt.debian.org. You may file issues there at will. We''re now just starting with the new ''front desk'' rotating schedule - one of the tasks of the front desk is to ensure issues like this end up in RT. Cheers, Thijs
On Mon, 21 Feb 2011 15:23:08 +0100, Thijs Kinkhorst wrote:> > I wonder if it would help to set up a security.debian.org bug tracker > > (similar to the release.debian.org [0]) so stuff like this doesn''t get > > lost? > > We already have a bug tracker, which is rt.debian.org. You may file issues > there at will. We''re now just starting with the new ''front desk'' rotating > schedule - one of the tasks of the front desk is to ensure issues like this > end up in RT.As a non-DD, I don''t have an RT account, so I can''t make use of that infrastructure, and even though I can use the readonly guest account, I haven''t really been following it since I can''t actually do anything. I wonder if RT is really an appropriate resource to handle unembargoed issues. It seems like the bug tracker is much more open and approachable, and just better overall. Although; I can understand the need for it (or some closed alternative) for embargoed issues. Best wishes, Mike
On Mon, 21 Feb 2011 11:16:52 +0000, Jonathan Wiltshire wrote:> On Sun, Feb 20, 2011 at 08:30:25PM -0500, Michael Gilbert wrote: > > I wonder if it would help to set up a security.debian.org bug tracker > > (similar to the release.debian.org [0]) so stuff like this doesn''t get > > lost? > > This occurred to me recently but actually it didn''t fix the problem I had, > so I didn''t take it any further. > > In what cases would bugs be filed against this pseudo-package instead of > against the package with the security issue? or do you envisage using the > ''affects'' feature?I was thinking that it would be used to categorize/track security updates in preparation. For example, categories could be "Stable/oldstable/testing security updates", "Unstable NMUs", etc (similar to release.debian.org''s "Stable proposed updates", etc). That way non-DDs (and even DDs not on the security team) can easily prepare an update, send a bug report, and it will be easy for the security team to better track what is going on at any particular time. Bug against the original package would be unchanged. In fact the security.debian.org bugs will usually resolve many other bugs. An alternative solution would be to add something like a data/updates-needing-review file to the security tracker. Personally I think the release.debian.org solution is ideal since it provides a good avenue for continued dialog, and it just plays well with the debian infrastructure. Best wishes, Mike
On Mon, Feb 21, 2011 at 12:12 PM, Michael Gilbert wrote:> On Mon, 21 Feb 2011 11:16:52 +0000, Jonathan Wiltshire wrote: >> On Sun, Feb 20, 2011 at 08:30:25PM -0500, Michael Gilbert wrote: >> > I wonder if it would help to set up a security.debian.org bug tracker >> > (similar to the release.debian.org [0]) so stuff like this doesn''t get >> > lost? >> >> This occurred to me recently but actually it didn''t fix the problem I had, >> so I didn''t take it any further. >> >> In what cases would bugs be filed against this pseudo-package instead of >> against the package with the security issue? or do you envisage using the >> ''affects'' feature? > > I was thinking that it would be used to categorize/track security > updates in preparation. ?For example, categories could be > "Stable/oldstable/testing security updates", "Unstable NMUs", etc > (similar to release.debian.org''s "Stable proposed updates", etc). That > way non-DDs (and even DDs not on the security team) can easily prepare > an update, send a bug report, and it will be easy for the security team > to better track what is going on at any particular time. > > Bug against the original package would be unchanged. ?In fact the > security.debian.org bugs will usually resolve many other bugs. > > An alternative solution would be to add something like a > data/updates-needing-review file to the security tracker. > > Personally I think the release.debian.org solution is ideal since it > provides a good avenue for continued dialog, and it just plays well > with the debian infrastructure.Also, I think this would address the current black-hole-like nature of security at debian.org. It doesn''t seem appropriate to default to privacy when most issues are already disclosed. Lets use a public resource like the bug tracker by default, and only direct to security@ for rare cases. Best wishes, Mike
On Monday 21 February 2011 18:01:32 Michael Gilbert wrote:> As a non-DD, I don''t have an RT account, so I can''t make use of that > infrastructure, and even though I can use the readonly guest account, > I haven''t really been following it since I can''t actually do anything.In any case you can file new requests there directly (http://wiki.debian.org/rt.debian.org#SecurityTeam). But what I was referring to is that we are tracking things in RT better now, so that your poppler request shouldn''t get lost so easily anymore in the future.> I wonder if RT is really an appropriate resource to handle unembargoed > issues. It seems like the bug tracker is much more open and > approachable, and just better overall. Although; I can understand the > need for it (or some closed alternative) for embargoed issues.I think the consideration was that it would be more difficult to track things in two places, and we need RT for part of the issues, so we''d better use it for everything. And it allows to switch issues from private to public. Cheers, Thijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20110221/7e549737/attachment-0001.pgp>
On Mon, 21 Feb 2011 18:48:23 +0100, Thijs Kinkhorst wrote:> On Monday 21 February 2011 18:01:32 Michael Gilbert wrote: > > As a non-DD, I don''t have an RT account, so I can''t make use of that > > infrastructure, and even though I can use the readonly guest account, > > I haven''t really been following it since I can''t actually do anything. > > In any case you can file new requests there directly > (http://wiki.debian.org/rt.debian.org#SecurityTeam).I didn''t realize that I could submit issues without an account. I''ll try to see how well that works in the future. Although, I still think that RT is too much of a barrier to entry. The debian BTS is just so nice; especially with reportbug and other tools already in widespread use.> > I wonder if RT is really an appropriate resource to handle unembargoed > > issues. It seems like the bug tracker is much more open and > > approachable, and just better overall. Although; I can understand the > > need for it (or some closed alternative) for embargoed issues. > > I think the consideration was that it would be more difficult to track things > in two places, and we need RT for part of the issues, so we''d better use it > for everything. And it allows to switch issues from private to public.There is an RT command-line interface. I wonder if this couldn''t be solved fairly easily by writing a wrapper that converts an RT thread into a new debian BTS thread with a link back to the RT ticket? I really think the BTS is a much better system. Best wishes, Mike
On Mon, Feb 21, 2011 at 01:28:32PM -0500, Michael Gilbert wrote:> On Mon, 21 Feb 2011 18:48:23 +0100, Thijs Kinkhorst wrote: > > On Monday 21 February 2011 18:01:32 Michael Gilbert wrote: > > > As a non-DD, I don''t have an RT account, so I can''t make use of that > > > infrastructure, and even though I can use the readonly guest account, > > > I haven''t really been following it since I can''t actually do anything. > > > > In any case you can file new requests there directly > > (http://wiki.debian.org/rt.debian.org#SecurityTeam). > > I didn''t realize that I could submit issues without an account. I''ll > try to see how well that works in the future. Although, I still think > that RT is too much of a barrier to entry. The debian BTS is just so > nice; especially with reportbug and other tools already in widespread > use.The RT has a different focus. It''s purpose is to organise the work of releasing/preparing a DSA among us. It doesn''t replace the Security Tracker. Cheers, Moritz
On Mon, 21 Feb 2011 19:42:28 +0100, Moritz M?hlenhoff wrote:> On Mon, Feb 21, 2011 at 01:28:32PM -0500, Michael Gilbert wrote: > > On Mon, 21 Feb 2011 18:48:23 +0100, Thijs Kinkhorst wrote: > > > On Monday 21 February 2011 18:01:32 Michael Gilbert wrote: > > > > As a non-DD, I don''t have an RT account, so I can''t make use of that > > > > infrastructure, and even though I can use the readonly guest account, > > > > I haven''t really been following it since I can''t actually do anything. > > > > > > In any case you can file new requests there directly > > > (http://wiki.debian.org/rt.debian.org#SecurityTeam). > > > > I didn''t realize that I could submit issues without an account. I''ll > > try to see how well that works in the future. Although, I still think > > that RT is too much of a barrier to entry. The debian BTS is just so > > nice; especially with reportbug and other tools already in widespread > > use. > > The RT has a different focus. It''s purpose is to organise the work of > releasing/preparing a DSA among us.Right, and I think that''s a very good thing. I just wish that process were more approachable to outsiders, and I think the BTS is a much better system for that. It should even be possible to switch to the BTS for all preparation. For the embargoed issues, just use a link to the RT ticket, and treat the BTS entry as organizational only (no technical info). I know I''m being a bit of a pain by pushing this alternative, but its somewhat discouraging as an outsider having no ability to participate in certain parts of the security process just because of the infrastructure in use.> It doesn''t replace the Security Tracker.This doesn''t have to do with the security tracker itself. It''s more about the openness of DSA preparation tracking. Best wishes, Mike