Security meeting: 2006.02.15

First meeting
15 Feb 2005, 2100 UTC
Meeting attended by
Maulkin, micah skx, stockholm, madduck, joeyh, voidhawk, ganeff, aj, mstone, fw, jmm, dannf


Meeting Summary


The first in a regular series of meetings with the eventual goal to get security support in Debian ready for prime time again

State of the security team

Micah gave a quick summary of updates of the security team, Moritz was added as a full member, source for 2.4 and 2.6 kernels has stabalized and updates will be coming soon. Steve said pending issues is mostly in hand, although there might be a mad rush of updates soon.

Security tracker

The security tracker that t-s uses was discussed to see if the stable security team could make use of it. Micah has been working to verify there are no false-positives (only found one so far). Clarification between trackers was discussed ( and the RT tracker that stable security never really used).

Moritz said it is quite usable for stable work, Steve said that he would not use it unless there was consensus to use it. Florian plans some fixes to make it more useful (like weeding out no-dsa and non-free), but it is very useful for triaging issues. Mike said that it does not provide what he is looking for yet, which is a process automation/workflow tool, keeping track of who is working on what. It was pointed out that the tracker is great for keeping weird things, such as xpdf, coordinated (impossible to keep in the head). Mike would like to have a tool that would tell him what needed to be worked on when he queried it. Micah pointed out that the tracker solves the tracking vulnerability issues, which is a different problem, Florian said that ownership in tracking is detrimental, but for processing and releasing updates it is important, but it should be possible to tie together different databases. Mike said it would be good to integrate a review process before issuing advisories, Steve agreed - there are too many silly typos and invalid CVE references. Automating advisories and putting it all in one interface would be best.

Madduck will send an email out with structured information about building out requirements and possibilities to integrate the existing tracker with stable workflows.

Moving the tracker to a debian address:, issues were discussed about what its written in, resources it needs. Currently it is on a machine fw has dedicated to it. Aj suggests leaving it where it is, with a new URL, and move it when some of the new .d.o machines come online. Fw says that missing pieces are glue scripts, servinfoke and instructions on how it works.

How testing-security can help stable security

Micah gave a summary of the work AJ has done to drop the stable/t-s split and public vs. embargoed queue work. AJ's blog posts on the subject, Micah's email directing people to read of you may have seen aj's blog posts, and my email directing people to look at them. Micah worked with AJ to test the changes that he did making to klecker to provide for a public vs. embargoed tree. Right now the following is available to us:. autobuilders that will build packages that we upload (although there are some autobuilder issues, we can't work those out unless we use them:

This setup currently allows testing-security to use queues instead of the alternative queues that we currently have setup. This is beneficial for many reasons At the moment, only myself and jmm have access to it. We either should modify our processes so that we can use it for DTSAs, or even better figure out what needs to be done to turn it into a true public vs. embargoed queue that is not stable vs. testing. I can write-up of how to do everything that I can fix up and put somewhere.

Micah will work on documenting how this process works. It would be good to get all the DDs on the testing team on there.

The idea is larger than just giving the testing team a new upload queue and better support, it also is ideally to merge teams so that there is only one upload queue for non-embargoed issues, with changelog info used to separate into testing and stable issues before publication. This would allow us to eliminate the separation between a stable and testing security team, yet still respect embargoed issues. It also involves "newamber" which generating templated files for advisories which will then allow for review. The newamber script spits out into /org/security.d.o/advisories/drafts which allows editing of the template before actually sending. There are two queues, ?OpenSecurityUploadQueue and ?SecurityUploadQueue, the first is for unembargoed uploads, the latter for embargoed ones. Newamber has many features such as an option to unembargo uploads made to the embargoed queue, and allows for uploads to be REJECTed.

Workflow issues were discussed, namely that uploaded packages need to be inspected by security, and this takes a lot of work. It was pointed out that testing-security could fix issues in stable and upload them into the stable queue (assuming rigorous QA was done to not waste time in the building process, as historically proposed stable packages are problematic). Having test scripts to pre-validate their security uploads was suggested as part of integration into the workflow. Joey has some scripts to automatically check for dependency changes, etc. Dannf made a checklist of problems Joey found for -sarge1 that is part of the -sarge2 preparation workflow ( Mike mentioned it would be nice to see them automatically run and the output available for review in the workflow process.

Suggestions for having a "review team" for stable and testing. Madduck suggests creating a workflow from the maintainer via the upload team to the queues and the reviewers to acceptance and advisory creation. Documenting and automating the workflow would go a long way towards allowing the security team to scale, that and trivial bottlenecks in the process.

Aj offers to move the stable security team to the newamber tool, it would involve minor changes to the existing workflow (different queue directory where (new)amber is run, not where things are uploaded to (instead of queue/accepted it would be queue/embargoed), couple more keypresses for an advisory), this would provide the ability to REJECT and UNEMBARGO issues. Steve said he had no objections as long as there is a recipe of instructions.

Getting new DDs involved

Joey points out that t-s is currently tracking 140 holes that are not fixed in unstable, and there are 4,823 TODOs that have not been reviewed. Thoughts about bringing more people in. Moritz notes that most of those unprocessed TODO items are things from earlier than 2002 that are probably not issues now. Joey offers to move those issues to the EOF where we are ignoring other really old unchecked CVEs. Florian says that in order to integrate more DDs, we need to provide clear instructions for how to resolve a TODO:, ie. which steps are needed and which sources should be trusted.

Steve suggesting talking to debian-mentors / debian-women to try and show people how to get involved.

Moritz talked about ideas for tracking embedded code copies and packages slinking statically (like xpdf mess)

Meeting Log

15:53 < Maulkin> Do we want the channel moderated for this meeting BTW?
15:54 < micah> it seems to me that if we all make an effort to stay on topic, becasue there aren't many of us, we can probably keep from doing th
15:55 < micah> afterall, we are all adults :)
15:55 < Maulkin> :)
15:55 < micah> or we can at least act like them
15:56 < skx> better!
15:56 < micah> has everyone had a chance to input on the agenda:
15:56 < stockholm> will we have adult content?
15:56 < Maulkin> stockholm: Is that a request ;)
15:57 < stockholm> Maulkin: no, not really.
15:57 < Maulkin> Aww.
15:57 -!- voidhawk [] has joined #debian-security
15:58 < madduck> i need to take a short break for my wrists. let's start at like 21:02 UTC, okay?
15:58 < joeyh> hi folks
15:58 < skx> hi
15:58 < Maulkin> Hia
15:58 < skx> madduck: sure
15:58 < Maulkin> madduck: No probs
15:58 < micah> maybe folks who are new can introduce themselves?
15:59 < micah> i guess I'm thinking of voidhawk and skx, don't usually see you around these parts :)
15:59 < voidhawk> hi, I am Stefan Fritsch.
15:59 < Ganneff> Maulkin: i *am* here :)
15:59 < stockholm> am i new?
15:59 < Maulkin> Ganneff: :)
15:59 < micah> voidhawk: great, didn't know your nick :)
16:00 < skx> I'm Steve Kemp, I go through phases of irc-love and irc-hate.
16:00 < voidhawk> I don't really have time to work for debian ATM, but I would like to stay up to date.
16:00  * joeyh is here until 2150, then have to go
16:00 < micah> skx: are you in a love mood now? :)
16:00 < stockholm> 21:59  * joeyh is here until 2150, then have to go
16:00 < stockholm> joeyh: 9 minutes over time (c:
16:00 < micah> stockholm: joeyh travels in reverse
16:00 < Ganneff> stockholm: adjust your clock, it was 22:00 already then
16:00 < skx> micah: tonight is good.  I just find irc to be a huge time sink so I try to minimize my exposure
16:01 < micah> skx: it definately is a huge time sink
16:01 < skx> micah: I'm glad I'm not alone in thinking that...
16:02 < stockholm> GONG: please start the meeting now!
16:02  * Maulkin is starting to think the same about debian-devel@l.d.o...
16:02 < madduck> ok, i am ready I think.
16:02 < micah> just so everyone knows, I'm logging this meeting and will make a summary available afterwards
16:02 < Maulkin> \o/
16:02 < madduck> so this is supposed to be the first in a regular series of meetings
16:02 < madduck> with the eventual goal to get security support in Debian ready for prime time again
16:03 < madduck> i think the first thing is that we should all get on the same page.
16:03 < madduck> jmm: could you fill us in on the current state of stable security, or is that asking too much? :)
16:03 < madduck> (since Joey isn't here)
16:03 < micah> jmm may not be here yet, I can say what I know in his absense
16:04 < micah> also steve kemp is here!
16:04 < madduck> please do
16:04 < madduck> w00t
16:04 < madduck> a brief overview then?
16:04 < micah> the only thing I was going to say is that Moritz has been added to the security team, and can issue DSAs now, the kernel update (-sarge2) is happening much faster than the previous one
16:05 < madduck> this is very good news. skx anything to add?
16:05 < micah> source has stabalized and there will be DSAs for 2.4 and 2.6 in the next week? or quite soon afterwards
16:05 < skx> nothing much more to add, except to say that the list of pending issues is mostly in hand.  I dont have the perception of anything getting left behind
16:05 < dannf> micah: possibly; the number of packages involved is immense though, due to the ABI change
16:05 < skx> I'd say Moritz has been doing a good job at helping / taking part.  
16:05  * skx wonders if I can mention potential embargoed issues
16:06 < micah> skx: i know jmm has been trying to push for the security team to use the tracker that we have, and I've been working to verify that there are no false-positives, do you know much about that?
16:06 < madduck> skx: maybe not...
16:06 < skx> micah: I used the tracker, as in request tracker, a few times but I seemed to be the only one.  so I ceased
16:06 < skx> micah: otherwise I'm ignorant
16:06 -!- Topic for #debian-security: Meeting here tonight at 2100 UTC. -- | Congratulations jmm! (now real) | security team channel (testing and stable) | Tracker | Website:
16:06 -!- Topic set by madduck [] [Wed Feb 15 11:47:10 2006]
16:06 < micah> skx: ah, I'm talking about
16:06 < madduck> is there documentation about the tracker you use for t-s?
16:06 < jmm> skx: the other tracker :-)
16:06 < micah> skx: the tracking system I emailed you about a while back
16:07 < micah> welcome jmm!
16:07 < micah> madduck: there is documentation available, let me get the URL
16:07 < skx> micah: yeah, I used that for a bit, but nobody seemed to be following along so I stopped.
16:07 < madduck> micah: add it to the wiki
16:07 < micah>
16:07 < skx> madduck: probably a good idea.  Still tehre is likely to be a mad rush "soon" for a whole bunch of packages, that has me a little concerned.  but otherwise as I said things are in good shape
16:07 < madduck> the current situation is a split between stable and testing.
16:08 < micah> skx: I know jmm and the rest of testing security use it
16:08 < madduck> with stable subdivided into embargo and not
16:08 < jmm> right now it's quite usable for stable work
16:08 < madduck> micah and i seem to agree that it would be much better to eliminate the stable/testing division
16:08 < skx> grand.
16:08 < madduck> and leave only embargo and not
16:08 < madduck> with the rationale being that
16:08 < stockholm> i hear currently the autobuilders are the bottleneck in the stable security side?
16:08 < madduck> once someone fixes a bug in one version of a package, fixing it in another is going to be easier.
16:08 < skx> I'd agree too, I have no real problem using *any* tracker.  The issue is only if everybody will use it - since if not then it will be painful
16:08 < jmm> fw plans some fixes to make it more useful (like weeding out no-dsa and non-free) but it's quite useful to triage issues
16:09 -!- mstone [] has joined #debian-security
16:09 < skx> stockholm: I /think/ that autobuilders have been good for a while
16:09 < madduck> weren't there issues about not being able to upload too separate .orig.tar.gz without tricking them?
16:09 < madduck> s/too/two/
16:09 < stockholm> skx: joey mentioned that he would have released more DSAs today if he could
16:09 < fw> jmm: And this will happen once things have settled down a gain over here (it's not that I've lost interest or something like that).
16:10 < skx> madduck: no.  I've done that several times, so long as you do them in the correct order things work.  (Or worked the last time I was in that situation a few weeks ago)
16:10 < madduck> joey == Joey and joeyh == joeyh right?
16:10 < jmm> stockholm: if there're problems they're more or less inherent, like m68k being legacy crap
16:10 < stockholm> madduck: yes
16:10 < stockholm> jmm: right
16:11 < micah> madduck: perhaps we can get to that topic when we move onto the agenda item ". engaging with the public vs. embargoed queue" and stick with the tracker discussion now?
16:11 < jmm> fw: yeah, I know
16:11 < skx> to be honest a lot of the pain will go away when we drop woody :S
16:11 < skx> but that wont be for a while yet
16:11 < madduck> micah: sure, but they are related.
16:11 < jmm> madduck: that's a katie bug, not directly related to the autobuilders
16:11  * dannf wonders if there's an agenda for this meeting posted somewhere?
16:11 < micah> dannf: yes there is, see topic
16:11 < madduck> dannf: /topic
16:11 < Maulkin> dannf: /topic :)
16:12 < dannf> ah
16:12 < dannf> sorry
16:12 < micah> I guess what I am wondering is if there is a way to get the tracker more in use by stable security
16:12 < madduck> we do agree that the current RT stuff is inappropriate and that fm's tracker works fine for t-s
16:12 < micah> that means making commits and tracking issues, more than just checking it
16:12 < madduck> right?
16:12 < micah> I would say for testing and stable security
16:12 < madduck> yeah
16:13 < skx> micah: I'd use it immediately if there was a consensus that others would do so
16:13 < micah> i've found only one false positive in the sarge checks I've done, out of quite a large number
16:13 < madduck> skx: the only one not going to go along is Joey, probably, huh?
16:13 < Maulkin> The current system works very well for t-s, in terms of using the tracker :)
16:13 < skx> madduck: I don't know.  he certainly seemed interested in the rt test
16:13 < jmm> Everyone's free to use one's own source of information, I don't see a problem with that
16:14 < mstone> jmm: the problem is coordination
16:14 < micah> skx: maybe if you and jmm use it, it will become clear that its immensely useful to stable security and others will then agree?
16:14 < skx> micah: perhaps
16:14 < madduck> jmm: well, the source should be the same for all in terms of coordination.
16:14 < stockholm> skx: you and moritz are already a good part of the involved peopel, so ...?
16:14 < micah> hey welcome mstone!
16:14 < CIA-1> joeyh * r3494 /data/CVE/list: automatic update
16:14 < micah> heh, that was good timing cronjob
16:14 < madduck> mstone: would you be willing to give the fm tracker a whirl too?
16:14 < skx> stockholm: I've been less involved of late, since moritz keeps picking up all the new issues before I get a chance!  Still that's kinda good for him, and all of us
16:14 < jmm> mstone: well, but it's working right now, some people rely on bug reports only and some use the idssi tracker
16:14 < mstone> madduck: I haven't seen that it provides what I'm looking for yet
16:15 < madduck> mstone: and that would be?
16:15 -!- Topic for #debian-security: Meeting here tonight at 2100 UTC. -- | Congratulations jmm! (now real) | security team channel (testing and stable) | Tracker | Website:
16:15 -!- Topic set by madduck [] [Wed Feb 15 11:47:10 2006]
16:15 < mstone> the thing I was hoping to get from rt (before that test disappeared) was the beginning of an actual process automation tool.
16:15 < jmm> micah: I guess that has been shown so far, for weird crap like xpdf it's close to impossible to keep everything just in head
16:15 < madduck> mstone: like a workflow?
16:15 < mstone> madduck: exactly
16:15 < madduck> mstone: hehe, that will be my phd thesis. :)
16:16 < micah> I think that the vulnerability tracker solves a different issue than workflow
16:16 < mstone> none of the extant debian bug systems is good at assigning something to someone. 
16:16 < madduck> micah: but mstone has a point, we would need some tool to coordinate.
16:16 < mstone> that's by debian's volunteer nature, but stable security updates are different beast
16:16 < skx> that was somethign that I did like about the RT install - there was a concept of ownership
16:16 < madduck> issues and states.
16:17 < mstone> what I want is to have some free time, see what's currently *not being worked on* and work on it
16:17 < madduck> can we use a psuedo package in the BTS for that?
16:17 < skx> not without embargo support I'd guess
16:17 < micah> I should note that with the testing-security tracker, we do have a rudimentary way of noting when someone is working on issues
16:17 < mstone> madduck: trying to cram everything into the bts isn't necessarily a useful approach
16:17 < fw> mstone: For the tracking stuff, ownership is detrimental.  For actually realsing updates, it's surely not.  But it should be possible to tie together different databases based on CVE keys.
16:17 < madduck> let's forget embargo for now. it's only a small portion as far as i understand anyhow.
16:17  * dannf notes there is a owner feature in debbugs, fwiw
16:18 < madduck> mstone: sure, but if we start using it, we can figure out the requirements and get down with a tool.
16:18  * madduck thinks trac...
16:18 < madduck> plone has been deploying trac with immense success.
16:18 < mstone> it would also be nice to integrate a review process before issuing advisories
16:18 < madduck> mstone: usertags could do that.
16:18 < mstone> (more workflow)
16:18 < madduck> usertags could implement states
16:18 < skx> mstone: seconded.  too many silly typos + invalid CVE references recently.  it'd be nice to avoid that
16:18 < mstone> skx: it's not "recently", it's always
16:18 < madduck> add to that some scripts and we could have a first tool.
16:18 < aj> the BTS has an owner command as well
16:19 < madduck> aj: welcome, and thanks for joining at short notice!
16:19 < mstone> beyond that, it would be nice to automate the advisories 
16:19 < mstone> (all stuff that should be integrated into the *same* interface, whatever it is)
16:19 < joeyh> and of course the BTS already gets CVE usertags based on data in the tracker
16:19 < madduck> how about this? interested people talk over email about requirements and possibilities to integrate the fm tracker with the bts
16:19 < madduck> and work out some workflows
16:20 < madduck> and then we set out with some tools to do it.
16:20 < madduck> see how it works
16:20 < micah> i personally find the idssi tracker contains an immensse amount of valuable information for tracking issues in debian packages, which solves one problem. Tracking ownership and workflow could perhaps be built into that tracker?
16:20 < madduck> then successively make it fit our needs better.
16:20 < madduck> micah: or trac, or the bts...
16:20 < fw> madduck: "fm tracker"?
16:20 < madduck> sorry
16:20 < madduck> idssi tracker, that's the fw tracker, no?
16:20 < Maulkin> ahh, ok :)
16:20 < micah> yeah it is
16:20 < fw> Ah. I wondered if there was yet another one I didn't know about.
16:21 < madduck> :)
16:21 < madduck> my bad.
16:21 < madduck> let's do this if noone objects. i shall send an email tomorrow with structured info and we go from there.
16:21 < madduck> and now move on with the agenda cuz joeyh has little time.
16:21  * Maulkin nods
16:21 < madduck> i think the comunication problem could also be solved that way.
16:21 < madduck> or at least approached.
16:22 < micah> as joeyh pointed out the fw tracker just pulls info from svn, and svn already has post-commit hooks to auto-BTS-user tag things, it would be easy to expand that to work in a way that stable security would find useful
16:22  * micah nods towards moving on
16:22 < madduck> so the next topic would be how t-s can help stable
16:22 < madduck> suggestion is to drop the stable/t-s split and merge for non-embargoed issues
16:22 < joeyh> well, it's not actually a post commit hook, but a cron job. Post-commit hook is a niceidea
16:22 < micah> i can say some things about the public vs. embargoed queue work that aj has done
16:22 < madduck> micah: please do.
16:23 < madduck> (all of aj's posts are linked on the wiki)
16:23 < micah> Some of you may have seen aj's blog posts, and my email directing people to look at them: (I think his blog posts are on the wiki too)
16:23 < micah> to summarize, I worked with aj test the changes that he did making to klecker to provide for a public vs. embargoed tree. 
16:23 < micah> Right now the following is available to us:. autobuilders that will build packages that we upload (although there are some autobuilder issues, we can't work those out unless we use them
16:24 < micah> . separate private/public (or embargoed vs. unembargoed) trees on klecker
16:24 < micah> . amber usage on klecker
16:24 < micah> . and
16:24 < micah> This setup currently allows testing-security to use queues instead of the alternative queues that we currently have setup. This is beneficial for many reasons
16:24 < joeyh> think you could document how to use amber there? And I assume we'd need to be in a special group for it
16:25 < micah> At the moment, only myself and jmm have access to it. We either should modify our processes so that we can use it for DTSAs, or even better figure out what needs to be done to turn it into a true public vs. embargoed queue that is not stable vs. testing.  I can write-up of how to do everything that I can fix up and put somewhere.
16:25 < micah> </done>
16:25 < skx> it is my understanding that the stable team need do nothing differently with this setup - it just means the testing team get a new upload queu and better support.  is that correct?
16:25 < micah> oh! I didn't see aj was here, aj chime in to correct me
16:26 < joeyh> well we should get all the DDs on the testing team on there if possible. Would we need to worry about exposure to embagroed issues at all?
16:26 < madduck> skx: ideally it'll just be one upload queue for non-embargoed issues, with changelog info used to separate into testing and stable before publication.
16:26 < micah> skx: right, if we wanted to continue separating teams into testing vs. stable, yes
16:26 < joeyh> skx: iirc you don't use amberdo you?
16:26 < Maulkin> skx: Not exactly. Instead of queue/accepted, you now have queue/embargoed IITC
16:26 < joeyh> at least,you write advisories by hand
16:26 < Ganneff> would that move drop amd64 testing security until its in the main archive?
16:26 < skx> joeyh: no I don't use amber, since I can't push advisories out.
16:26 < micah> Ganneff: thats one of the autobuilder issues that need to be worked out
16:26 < skx> madduck: thats what I thought, thanks.
16:26 < mstone> joeyh: the amber advisory generation is unused
16:26 < micah> Ganneff: but it shouldn't stop things from happening, chicken and egg issue
16:27  * madduck nods
16:27 < Ganneff>  micah in a worst case we could do a similar setup like we have with stable.
16:27 < madduck> mstone: can we use it? or is it lacking?
16:27 < mstone> joeyh: the templates it spits out don't match what we're using, and the latency for email from klecker is huge (hours sometimes?)
16:27 < joeyh> iirc aj or someone was working on it do something more sane such as emit a file
16:27 < micah> so this all dovetails into the actual agenda item, how testing security can helps table security... 
16:27 < aj> that's what newamber does
16:27 < madduck> mstone: uh oh. maybe we can have the DT?SAs published by another server then, as part of the workflow improvements?
16:28 < skx> that sounds good.  especially the file generation, since that allows review which is something already mentioned as being a good thing
16:28 < mstone> currently we generate the checksums using a script joey wrote, and that's the most useful piece that amber spit out anyway
16:28 < aj> ewamber spits out into /org/security.d.o/advisroeis/drafts/
16:28 < aj> sorry fo rmy typing i'm half asleep
16:28 < madduck> :)
16:28 < Maulkin> heh
16:28 < aj> it also allows editing of the template before actually accepting
16:28 < joeyh> mstone: well, aside from accidentially referring to n-1 DSA's package in DSA n :-)
16:29 < madduck> micah: is there a reason why you want it "t-s helping stable"?
16:29 < mstone> joeyh: yeah, that requires review
16:29 < aj> see queue/unembargoed/advisory.DTSA-*, kinda
16:29 < madduck> micah: rather than assuming that there's only one non-embargoed process?
16:29 < mstone> joeyh: on the other hand, sometimes we push stuff out in pieces and would have to paste together the amber stuff anyway
16:29 < micah> let me pose a question to the stable security people: what if testing security people used this setup for DTSAs as well as helping stable by doing uploads for stable/DSAs that then would just need to be unlocked by a stable security team member?
16:29 < madduck> mstone: a good workflow could address that...
16:30 < mstone> madduck: yes
16:30 < skx> micah: that sounds sane.
16:30 < jmm> micah: that can already be done
16:30 < mstone> micah: that could be done now
16:30 < Ganneff> everyone can upload packages for stable security
16:30 < Ganneff> (every DD that means)
16:30 < micah> yes, I mean using this infrastructure
16:30 < mstone> the reality is that a *lot* of packages that created for stable security require damn near as much work from the stable security team as doing it ourselves
16:30 < micah> I suppose aj would have to answer that
16:30 < madduck> so if we make it such that dak just does the right thing once an upload hits either the stable or testing queues, we're game, no?
16:31 < madduck> both queues would include review steps
16:31 < mstone> micah: if you upload to stable-security it'll get built. the only thing the security team does it make it public
16:31 < madduck> for stable, the existing stable team would do the review, and for t-s some in t-s team would do...
16:32 < aj> there's currently two queues, OpenSecurityUploadQueue and SecurityUploadQueue, the first is for unembargoed uploads, the latter for embargoed ones
16:32 < madduck> mstone: so there is actually nothing keeping us from fixing a bug in both versions and uploading it.
16:32 < Maulkin> Personally, I would like to see DTSAs dissapear completely in the long term, and just DSAs being issued, for all distributions.
16:32 < mstone> madduck: no
16:32 < madduck> excellent.
16:32 < madduck> Maulkin: disagree
16:32 < aj> newamber has an option for uploads made to the embargoed queue to unembargo them, also
16:32 < mstone> madduck: the trouble has historically been (as I said above) that a *lot* of the proposed stable packages we get are fucked up
16:32 < madduck> Maulkin: because if i operate only stable servers, i don't care about issues in testing.
16:32 < madduck> and i want fewer mails
16:33 < aj> newamber also allows uploads to be REJECTed
16:33 < madduck> mstone: interesting info. something we can work from!
16:33 < mstone> madduck: so if we encourage people to upload them we could end up with some really heinous changelogs
16:33 < skx> mail filters are your friend.  
16:33 < micah> mstone: yeah, I'm thinking if t-s used this new setup and we also targetted uploads to stable/woody, we'd get the autobuilder results and work those out, and then when they are all ready we could theoretically run newamber to put it in a place with a DSA all prepared for stable-security to do a once over and review
16:33 < madduck> mstone: that's where reviews come in?
16:33 < madduck> skx: my friend, sure. but john doe admin?
16:33 < mstone> madduck: once they're uploaded they start building. the review happens before upload, which is how we get back to a workflow (so you know who's reviewing what)
16:34 < stockholm> madduck, mstone: you two miss each others point, i think.
16:34 < skx> madduck: john doe admin almost certainly doesn't subscribe to d-s-a...
16:34 < madduck> skx: ouch.
16:34 < skx> sorry.
16:34 < jmm> skx: then he's screwed for a reason
16:34 < stockholm> madduck: mstone means that most maintainers dont do proper security packages
16:34 < madduck> i would like to return to that in a bit...
16:34 < stockholm> and cant be used in the security queue as is
16:34 < micah> yes, but I think we are talking about testing-security doing this, not "most maintainers", my suspicion is that t-s maintainers are more careful about the process
16:35 < skx> I just meant to say that suggesting an increase in mailing list traffic doesn't strike me as a valid reason to vote against a combined source for security notices for stable/testing.
16:35 < jmm> stockholm: yes, at least half of all updates provided have problems (possibly even more)
16:35 < madduck> micah: exactly.
16:35 < stockholm> mstone: madduck means *cluefull* people making the uploads.
16:35 < jmm> micah: DTSAs are a lot simpler, you can mess-up less
16:35 < skx> micah: thats what I assumed too.
16:35 < stockholm> jmm: like beeing build against unstable. (c:
16:35 < aj> are logs of this going to be public, btw?
16:35 < madduck> aj: yes.
16:35  * dannf thinks a set of test scripts would be useful for maintainers to pre-validate their security uploads
16:35 < madduck> dannf: linda/lintian?
16:35 < mstone> dannf: even better would be integrating that into the workflow :)
16:35 < dannf> i know that a lot of the mistakes i made w/ the sarge1 security updates could've been caught automatically
16:36 < dannf> madduck: extensions to them, perhaps
16:36 < skx> testing package upgrades is something I do manually, but testing that a package works is hard - eg. recent Mail::Audit mess.
16:36 < mstone> joey has some scripts to automatically check for dependency changes, etc
16:36  * madduck wants unit tests in every debian package
16:36 < stockholm> me too
16:36 < skx> +1
16:36 < fw> madduck: Wrong. You need integration tests.
16:36 < madduck> whatever the name... :)
16:36 < dannf> mstone: right; but i only found out about problems after i'd submitted & forced him to review
16:37  * dannf made a checklist of problems Joey found & that is part of the sarge2 prep workflow
16:37 < skx> dannf: is this public? it'd be nice to see ...
16:37 < madduck> so how would this sound? we have a review team for stable and testing each, and maintainers interact with the current t-s people who make sure that the packages are suitable for upload?
16:38 < mstone> dannf: the scripts could be publicized, I'm sure. But I'd like to see them automatically run and the output available for review in the workflow process, to save busy work.
16:38 < dannf> skx:
16:38 < madduck> the current t-s people also provide the review team.
16:38 < skx> dannf: thanks
16:38 < madduck> and we create a workflow from the maintainer via the upload team to the queues and the reviewers to acceptance and DT?SA creation?
16:38 < dannf> skx: mostly notes to myself, so not many details
16:39 < micah> what I keep hearing from mstone and skx is that documenting and automating the workflow would go a long way towards making things better
16:39 < madduck> micah: i am interested in that. definitely.
16:39 < stockholm> can that be helped in some way? 
16:39 < madduck> maybe that can be my contribution.
16:39 < mstone> micah: IMO, it's the biggest problem we've had in scaling the security team
16:40 < skx> mstone: that and trivial bottlenecks in some processes
16:41 < madduck> mstone: i can totally see that.
16:41 < aj> mstone, whoever: so should stable security be moved over to the newamber tool? it makes minor changes to the workflow (different queue directory, a couple more keypresses to do an advisory) ?
16:41 < madduck> mstone: and it's an issue i raised back in my massive flamefest with aj on APT 0.6.
16:41 < skx> aj: I have no objection so long as you have a recipe of instructions ;)
16:41 < aj> (but buys the ability to REJECT and UNEMBARGO)
16:41 < mstone> aj: there's no change to the queue directory in the common case, right?
16:41 < micah> thats good to hear, hopefully we can help smooth those workflows out, automate them and make the information available
16:41 < aj> mstone: yes -- it moves from queue/accepted to queue/embargoed
16:42 < madduck> okay, joeyh has another 10 minutes, i'd like to get another topic on the table...
16:42 < madduck> how to get DDs to better work on security issues...
16:42 < madduck> and how to recruit people for security work.
16:42 < aj> mstone: queue directory as in where you cd to to run (new)amber, not where you upload to
16:42 < micah> madduck: we skipped one topic
16:42 < madduck> micah: tracking?
16:42 < mstone> aj: I'd suggest sending an email to team@. I think it sounds good in principle, but we need to bring joey in and get the changes in one place
16:42 < micah> madduck: yeah, tracking issues
16:43 < madduck> micah: i saw joeyh added an issue here that also applies to the DDs
16:43 < madduck> thus i wanted to do it first before he leaves.
16:43 < madduck> we can discuss tracking afterwards, okay?
16:43 < fw> Okay.
16:43 < micah> aj: I guess I should write up some notes that i took on this
16:43 < joeyh> fwiw, testing security is tracking 140 holes that are not fixed in unstable, and have about 5000 CVEs that we have not reviewed
16:43 < micah> ok, sounds good, the only reason I note that is because joeyh did add an item to the tracking issue one
16:43 < micah> joeyh: 4823 TODOs
16:44 < joeyh> yep
16:44 < joeyh> I wanted to see what people thought about trying to pull more people in to review those
16:44 < jmm> most of that is crap from 2002 backwards, you won't find a real world issue in it
16:44 < madduck> joeyh: you have a lot of experience with getting people excited to work on shortcomings in debian. how do we get more volunteers?
16:44 < micah> we definately need more people doing tracking work, its really crazy how many issues have come in this year alone already
16:44 < joeyh> jmm: I think statistically you'll find one or two :-)
16:45 < joeyh> I also worry sometimes what happens when jmm goes on vacation..
16:45 < micah> jmm: you are right, a lot of those are old ones, regardless it would be good to recruit more people
16:45 < jmm> joeyh: if you spend the time on audits you'll find more :-)
16:45 < madduck> yeah.
16:45 < madduck> i certainly want to see us progressing to a point where we have so much redundancy that jmm, micah, joeyh and Joey can go on vacation together. :)
16:45 < micah> in fact jmm, fw and myself have been quite busy/sick recently, so a backlog has accumulated
16:45 < madduck> and fw.
16:46 < micah> well, all of us!
16:46 < madduck> oaxtapec...
16:46 < stockholm> yes!!!
16:46  * Maulkin nods
16:46 < fw> I think for integrating more DDs, we need to provide clear instructions how to resolve a TODO:, i.e. which steps are needed and which sources should be trusted.
16:46 < joeyh> I can also just move these to the EOF where we're ignoring all the other really old uncheckedCVEs
16:46 < madduck> i see this boiling down again to a logical workflow and good docs about it...
16:46 < joeyh> if the effort isn't worth it to fix them
16:47 < aj> is there an existing workflow documented somewhere to be improved upon, or does it need to be documented in the first place?
16:47 < micah> yes, fw is right -- there is some documentation in the narrative introduction that I did, but we need to solidify that more
16:47 < madduck> aj: i am afraid it may be the latter...
16:47 < mstone> aj: we need to start from scratch
16:47 < madduck> i stand corrected.
16:47 < stockholm> would it help to throw money at the documentation issue?
16:47 < jmm> aj: doc/narrative_introduction in secure-testing SVN
16:47 < madduck> i would like the opportunity to design a workflow though...
16:47 < micah> well for testing security there is workflow and docuentation
16:48 < voidhawk> Joeh: yes, checkin pre 2002 CVEs against new versions is a lot of work with few issues found
16:48 < voidhawk> s/joeh/joeyh/
16:48 < fw> stockholm: For documentation?  Doubt it.  This kind of knowledge is not very widespread.  It's not just writing things down.
16:48 < aj> "Gentile Introduction" -- heh. gentle, itym :)
16:48 < micah> but it needs to be updated more, and if things change for the newamber stuff we need to update that... 
16:48 < mstone> aj: don't go brining religion into it :)
16:48 < micah> aj: ahhh finally someone caught my mistake
16:49 < aj> in theory newamber can implement some of the workflow itself
16:49 < madduck> voidhawk: can you estimate how much work?
16:49  * joeyh prepares to offline
16:49 < madduck> joeyh: okay with you if we reconvene in two weeks?
16:49 < joeyh> sure
16:49 < madduck> same time /place?
16:49 < aj> at a different time? :)
16:49 < madduck> aj: right...
16:49 < madduck> jmm also doesn't like it...
16:49 < joeyh> it's not much work if you get suckers to do it. That's how I started the testing team ;-)
16:49 < madduck> and Horms neither.
16:49 < micah> myself and jmm put a lot of work into the narrative introduction to make it clear to people who haven't done any tracking how to get involved and what to do 
16:49 < madduck> joeyh: we'll quote that. :)
16:49 < skx> wednesday is my weekly drinking night, so I'm unlikely to be free many wednesdays
16:50  * joeyh offlines
16:50 < voidhawk> madduck: no, often there is no hint about it being fixed, and the source has changed quite a bit
16:50  * mstone wonders why skx has a weekly drinking night
16:50 < dannf> wednesday is my only sober night so... :)
16:50 < madduck> i'll send out an email about finding a good time.
16:50  * joeyh wants one
16:50 < micah> but it needs to be expanded to incldue the reliable sources info that fw mentioned, as well as the other things that are noted in there
16:50 < micah> haha
16:50 < madduck> joeyh: bye and thanks.
16:50 < skx> mstone: tradition - can't wait for weekends ;)
16:50 < madduck> mh, the meeting is degrading...
16:50 < madduck> tracking is on the list still.
16:51 < mstone> wasn't there another topic?
16:51 < madduck> micah: what did you have in mind.
16:51 < micah> well, some people have expressed discontent that the tracker is not on a debian address
16:51 < jmm> i have two more, but I've been too busy to add them to the wiki
16:51 < madduck> micah: will do? i can do that *now*
16:51 < fw> Regarding DD motivation, I still plan to create that "vouching for security support" database.
16:51 < madduck> fw: a bounty thing? or what?
16:51 < mstone> I think it's worth putting on an actual machine, and hopefully a faster one :-P
16:52 < madduck> jmm: /msg them to me now and i'll add them, or you do now.
16:52 < fw> madduck: No bounties.  Users can see "oh, if I use BIND 8, I'm screwed".
16:52 < micah> well, it is clear that there is a subset of developers who find security issues in their packages as very important issues to resolve ASAP, and then there are some who don't care less
16:52 < madduck> mstone: then we have to deal with DSA, which is something we may not need at this stage...
16:52 < jmm> I'll mention if the tracking business is discussed through
16:52 < madduck> fw: interesting.
16:52 < fw> madduck: Completely orthotogonal to the rest.
16:52 < mstone> madduck: I think it is
16:52 < aj> so is the t-s tracker to be made the official security.d.o tracker?
16:52 < mstone> madduck: if it's worth doing, it's worth doing right
16:52 < madduck> mstone: it might just take resources away from more important things?
16:53 < madduck> wouldn't do for now?
16:53 < aj> and what sort of url are we talking?
16:53 < madduck> aj: that's the plan.
16:53 < mstone> it's that hard to create a dns entry?
16:53 < madduck> mstone: DSA has been known to take long.
16:53 < micah> its easy to create ones
16:53 < fw> mstone: It's hard to change DNS.  That's why it's still under
16:53  * mstone scratches head
16:54 < madduck> mstone: we'll fix DSA when security is working :)
16:54 < aj> (it's that hard to get an answer what sort of url y'all want...)
16:54 < madduck> aj: would be awesome.
16:54 < micah> its kind of long, it would be better if it were
16:54 < madduck> or
16:54 < madduck> micah: dude. same length. :)
16:54 < mstone> no, make it
16:54 < mstone> the other can be put in as a redirect, np
16:54 < aj> security.d.o is the machine that users point apt at
16:54 < madduck> trckr.s.d.o
16:55 < skx> tracker.s.d.o seems nicer to me 
16:55 < micah> madduck: dude, shorter domain, same length url
16:55 < aj> probably not good to try to use it for admin stuff
16:55 < mstone> make a friggin bookmark :-P
16:55 < madduck> micah: yeah. make a bookmark. :)
16:55 < micah> i'm outvoted, so I'll just agree :)
16:55 < aj> okay, and where should it be hosted? (what's it written in?)
16:55 < madduck> aj: can you make the DNS change?
16:55 < micah> aj: python
16:55 < madduck> fw: your machine?
16:56 < mstone> sure as shit we don't need to introduce potential vulnerabilities on security.d.o. (And since it's a round-robin now it would suck for a tracker.)
16:56 < micah> fw: didn't you mention it requires a bit of cpu resources to chew through things at regular intervals?
16:56 < fw> madduck: I wouldn't object.
16:56 < madduck> i also have plenty of machines if there's a need.
16:56 < madduck> fw: but that sounds good.
16:56 < fw> micah: Yeah, but I've put it on a dedicated box.  It needs five minutes after each commit (if there isn't a syntax error).
16:57 < madduck> aj: IN A
16:57 < aj> leaving it where it is (with a new url), and moving it when some of the new .d.o machines come online (like newklecker?) might work?
16:57 < mstone> the current tracker is painfully slow for me. is that something that can be fixed with hardware?
16:57 < aj> is the tracker public or (partially) secret?
16:57 < fw> aj: Public.
16:57 < jmm> aj: which?
16:57 < mstone> aj: nothing in that is secret
16:57 < micah> mstone: really? its quite quick for me
16:57 < madduck> mstone: which tracker is slow?
16:58 < jmm> mstone: do you mean the RT tracker or the idssi tracker?
16:58  * Maulkin has seen it bth quick and slow :)
16:58 < mstone> jmm: idssi
16:58 < madduck> fw: maybe set up a reverse proxy?
16:58 < aj> can we get a tarball or something of it for download then, so it can be moved to a DSA controlled box easily should one become available, or whoever is currently running it needs to go AWOL?
16:58 < micah> perhaps it is just the route to the machine ATM? Its instantaneous for me
16:58 < Maulkin> What's the RT tracker BTW?
16:58 < madduck> Maulkin: the stable-security tracker that's not consistently used.
16:58 < Maulkin> Ahh, ok
16:59 < mstone> it's not used at all. it never got off the ground.
16:59 < jmm> it's setup by noahm and tracks some embargoed stuff, mostly stuff found by Debian Audit people
16:59 < fw> The thing that's illegal according to the SC. 8-)
17:00 < Maulkin> It's about time for another flamewar that we're hiding problems...
17:00 < micah> fw: you mean providing a tarball?
17:00 < fw> micah: Forget it, I wasn't being helpful.
17:00 < madduck> fw: is it easy to provide a tarball of only the software and keep the data somewhere up to date to later merge it?
17:00 < aj> or just a cronned weekly tarball of software + data?
17:00 < micah> madduck: the data is in svn at the moment
17:01 < madduck> perfect.
17:01 < fw> micah: The software as well.
17:01 < micah> in fact, I think the software is also :)
17:01 < aj> ah, cool
17:01 < madduck> micah: ?
17:01  * Maulkin nods
17:01 < micah> its in the testing-security svn repo, madduck -- yes
17:01 < madduck> aj: then a software tarball will do, right?
17:01 < madduck> fw: can you prepare a weekly software tarball for the tracker?
17:02 < fw> Only missing piece is some glue scripts, and of course servinvoke.
17:02 < fw> madduck: I could upload servinvoke as a Debian package, and commit my scripts to the Subversion repository, together with a few instructions what needs to be done (mailing list subscriptions as triggers etc.).
17:02 < micah> ok, it would be good to get it all together so it is clear in the case you get hit by a bus (hopefully that will not happen)
17:03 < madduck> fw: sounds good. or put servinvoke into SVN for now?
17:03 < madduck> fw: the DSA machines run stable...
17:03 < fw> madduck: servinvoke is C without dependencies, so it's fine.  idssi is on stable, too.
17:04 < micah> on the tracking subject, we do have "bugs without a CVE name" and the issues that jmm mentioned, so maybe fw can work out those issues "offline"?
17:04 < aj> fw: you currently host the tracker on one of your own machines, right?
17:04 < fw> Basically, servinvoke just makes the trust transition from Apache to a long-running Python script.
17:04 < madduck> fw: no libc dependency?
17:04 < fw> madduck: Trivial to compile.
17:04 < micah> aj: thats correct, its on a dedicated machine of fw's
17:04 < madduck> fw: i doubt they will install a .deb
17:04 < micah> aj: do you have the ability to make that DNS change?
17:05 < fw> madduck: *shrug* gcc -o servinvoke main.c will do.
17:05 < madduck> fw: put it into SVN if you don't mind too, please.
17:05 < fw> madduck: It can be reimplemented in Perl, if this is a showstopper.
17:05 < madduck> nooooooooo! :)
17:05 < fw> madduck: I'll make some separate release as a darcs repository.  It's not related to testing-security at all.
17:06 < madduck> ok
17:06 < aj> fw: servinvoke is setuid something?
17:06 < micah> ok, can we move on so we can wrap up soon? :)
17:07 < madduck> let's wrap up, or is there anything left?
17:07 < fw> aj: No, it runs under www-data and opens a UNIX domain socket to the actual server process.
17:07 < madduck> wait... jmm?
17:07 < micah> we do have "bugs without a CVE name" and the issues that jmm mentioned
17:07 < micah> and debescan feedback, but we can hold off on that until next time?
17:07 < fw> aj: That process typically runs under a separate UID.
17:07 < madduck> micah: you decide. let's not draw this too long.
17:08 < madduck> micah: are these issues we can discuss over email?
17:08 < micah> or next meeting is fine as well
17:08 < madduck> jmm?
17:08 < micah> perhaps we should quickly discuss when a better time would be?
17:08 < jmm> sure
17:08 < aj> how much cpu does the tracker actually use/need, also how much disk?
17:08 < fw> debsecan is not a central issue IMHO.
17:08 < madduck> should we set up a mailing list for this stuff?
17:08 < madduck> i can, or @teams.d.o?
17:09 < micah> well, the testing-security list is fairly quiet, it just doesn't include some people who are part of this conversation at the moment
17:09 < jmm> use secure-testing-team, it exists
17:09 < skx> madduck: list would be excellent idea, and might mitigate people having difficulty with meetings
17:09 < madduck> skx: i'll see to it.
17:09 < skx> madduck: :)
17:09 < madduck> skx: possibly s-t-t@l.a.d.o
17:09 < madduck> jmm: your two issues?
17:09 < fw> aj: 600 MB for the archive metadata mirror.  The post-commit upates are not really critical.  They need 5 minutes on my box (Pentium II 450 MHz).
17:10 < aj> 5 minutes how often?
17:10 < micah> if we used s-t-t, we'd need to make sure that skx, mstone, aj and others who are part of this conversation are subscribed, or at least CC'd
17:10 < fw> aj: Moment...
17:10 < jmm> I'm planning more extensive and complete coverage of code incest to make Etch more supportable security-wise
17:10 < micah> incest?
17:10 < madduck> micah: sounds like a new list may be better. i'll take this on and report via email.
17:10 < jmm> right now we don't have complete knowledge, which packages have embedded code copies, nor for package slinking statically and that sucks big time
17:11 < micah> agreed
17:11 < jmm> micah: like the xpdf mess
17:11 < skx> jmm: thats a great thing to know about as per the pdf issues, and the upcoming stuff
17:11 < micah> yeah, we have a list of embedded code copies in t-s svn, but its rudimentary
17:11 < fw> aj: About ten times per day (after each Subversion commit that touches the data files).  There are 30 minutes processing for the daily archive upgrade, I forgot.
17:11 < jmm> I'm planning some coordinated effort, which includes maintainers, they should know best
17:12 < fw> aj: This will change drastically with some refactoring, though (I aim for something in the 20 seconds range for the per-commit thing).
17:13 < fw> jmm: Martin Pitt also put that file on some Ubuntu wiki, BTW.  I don't know what this means for us, though.
17:13 < jmm> fw: I send it to him, but seems he never added something into it since then
17:14 < madduck> btw: mpitt has offered his help long ago, we just need to find something that's worthy of his time...
17:14 < fw> madduck: He wants to port everything to Launchpad, it seems. 8->
17:15 < fw> But we a digressing.
17:15 < micah> jmm: let us know if we can help with your effort
17:15 < madduck> fw: yeah, we're not going there.
17:15 < aj> the tracker's data is updated via svn commits, right? who can do that?
17:15  * skx adds reminder for self to look at automatic package testing
17:15 < madduck> fw: he *has* to port everything to lp
17:15 < jmm> yeah, will do, but I need to detail it more and right now I don't have much time
17:15 < aj> are there any non-DDs with commit access?
17:15 < madduck> aj: like jmm...
17:15 < madduck> aj: it's the secure-testing alioth project
17:15 < micah> madduck: jmm is a dd
17:16 < madduck> ooops
17:16 < madduck> that's new though. :)
17:16 < madduck> i haven't been following...
17:16 < micah> some months ago :)
17:16 < madduck> aj: theoretically yes. i can check if you want.
17:16 < fw> aj: There are some -guest accounts.
17:16 < jmm> aj: Stefan Fritsch is the only non-dd commiting
17:16 < micah> but none of them commit at the moment
17:16 < micah> ah, except stefan
17:17 < madduck> i see 6 people with non-DD accounts.
17:17 < voidhawk> aj: yes, me
17:17 < madduck>
17:17 < micah> madduck: one of thsoe is jmm-guest
17:17 < jmm> and it's not a problem, we have peer review and you can't break stuff
17:17 < madduck> micah: no, i skipped that one, and dilinger.
17:17 < fw> Here's the list: dilinger-guest kbk-guest finnarne-guest jmm-guest greuff-guest pdwerryh-guest dom-guest djoume-guest stef-guest
17:17 < dannf> fw: dilinger is a dd now
17:18 < micah> yes, i dont find it a problem either, I know myself, fw and jmm all read commits fairly regularly
17:18  * Maulkin does too
17:18 < jmm> half of the people are inactive anyway
17:19 < skx> maybe prod debian-mentors / debian-women to see if any newcomers are interested in the security area?
17:19 < micah> jmm: you said you had 2 issues, I only counted 1?
17:20 < madduck> skx: good idea. maybe with some mentoring arrangements?
17:20 < skx> yes
17:20 < madduck> maybe some of us would be interested to take 1-2 mentees
17:20 < madduck> then we send an announcement to the list
17:20 < jmm> the other is more vague, it's like to see some tracking, which packages do not have a security perspective
17:20 < mstone> ?
17:20 < madduck> perspective?
17:21 < jmm> inherently insecure crap with a long history of being faulty and insecure
17:21 < skx> *pdf ?
17:21 < micah> jmm: I have been thinking the same thing
17:21 < jmm> I'm sure someone will package php-nuke within 2006
17:21 < mstone> php
17:21 < fw> jmm: Or things which are officially unsupport upstream.
17:21 < micah> skx: thats a great idea actually
17:21 < skx> I've been doing low-level stuff on that front already in an unorganised manner.
17:22 < skx> quick automated scans of all *new* packages entering the archive
17:22 < jmm> or apps, which intentionally hide security problems behind non-sec changes
17:22 < micah> it would be n ice if we could integrate that info into aptitude/apt so that if you have a base "security level" set it will prompt you when you try to install a package that has a bad security history :)
17:22 < madduck> micah: you want a core/universe separation? :)
17:22 < jmm> wordpress was kicked out of sarge because upstream doesn't handle this in a good manner and otherwise we'd have been bitten by this several times
17:23 < fw> micah: I'm not sure if we should propagate such a metric.  I find it more important to document which packages are actually worked on, security-wise.
17:23 < mstone> yeah, I'd rather just see stuff kicked out than have some funky warning
17:23 < jmm> mstone: yeah, me too
17:23 < skx> but that doesn't help much if people don't know that their installed package has been removed
17:23 < micah> fw: yes, definately, there are packages that maintainers take an active disinterest in their security
17:23 < aj> what's the current tracker url?
17:23 < mstone> there are certain things that you *know* are going to be more work every time you do an advisory
17:24 < micah> aj: topic
17:24 -!- Topic for #debian-security: Meeting here tonight at 2100 UTC. -- | Congratulations jmm! (now real) | security team channel (testing and stable) | Tracker | Website:
17:24 -!- Topic set by madduck [] [Wed Feb 15 11:47:10 2006]
17:24 < madduck> aj:
17:24 < mstone> micah: it's not a maintainer issue as much as an upstream issue. If the maintainer doesn't care it's not nearly as big an issue as when upstream doesn't care.
17:24 < jmm> it has limits, though. We can hardly remove PHP
17:24 < voidhawk> sometimes a package might get worse during stable's lifetime
17:24 < mstone> it's not php itself, just the apps. :)
17:24 < aj> todo doesn't work, and is slow
17:24 < voidhawk> so adding warnings later might be a good idea
17:25 < micah> hehe
17:25 < jmm> PHP upstream intentionally hides security problems behind unrelated changes
17:25 < micah> aj: probably because its nearly 5,000 items, but fw can comment on that?
17:25 < micah> not just php...
17:25 < fw> aj: It's slow because of general network latency.
17:25 < aj> (as in, it gives interal server error)
17:26 < aj> and it's slower to do that than other pages are to work
17:26 < fw> aj: Sorry?
17:26 < micah> many places hide security changes, althought they wouldn't call it "hiding", the linux kernel for example doesn't do a good job of letting people know about issues... I know of issues that were silently fixed in openbsd and silc, two things that are known to be security "conscious"
17:26 < Maulkin> fw: The TODO list gives "500 - Internal Server error"
17:27 < micah> fw:
17:27 < aj> -- takes longer than all the other links, then.. see maulkin
17:27 < micah> lets all sing in unison
17:27 < fw> aj: Ah, okay, will investigate it.
17:27 < aj> samba fixes (unexploited, potential) security bugs without notifying anyone too
17:27 < madduck> so which days of the week and what time would work for people here?
17:28 < madduck> i suggest a one hour meeting every two weeks, just to keep the pace up.
17:28 < aj> madduck: just vary it so if you can't go one week the next is probably fine?
17:28 < micah> yeah, we can do shorter meetings in the future so that people will actually continue to attend
17:28 < madduck> yeah, at most one hour.
17:28 < madduck> aj: what would be your preferred UTC times?
17:29 < mstone> I thought the meeting ended a half hour ago, it's just chatter at this point 
17:29 < mstone> (which is fine)
17:29 < madduck> mstone: pretty much, yeah.
17:29 < madduck> but we have some things to do.
17:29 < madduck> my todo list is long at least.
17:29 < aj> 00:00-14:00 ideally *shrug*
17:29 < madduck> so that's 01:00 to 15:00 CET and 19:00 to 9:00 EST
17:30 < madduck> i can certainly do 15:00 CET
17:30 < aj> the tracker doesn't include joeyh's stuff?
17:30 < Maulkin> aj: It does :)
17:30 < madduck> question is whether skx, jmm, fw, and the other europeans can do afternoons
17:30 < Maulkin> aj: They both come from teh same data source.
17:30 < jmm> aj: it more or less replaces it, it has a testing section as well
17:30 < Maulkin> It depends on the day.
17:30 < madduck> and whether micah and the other us people wanna get up early
17:30 < micah>
17:30 < skx> afternoons is fine barring work/sleep issues.
17:31 < fw> I can do Debian work on company time.
17:31 < aj> jmm: but it doesn't have pretty colours...
17:31  * Maulkin can also, on some days :)
17:31 < madduck> so let's try 28 Feb at 1300 UTC?
17:31 < fw> So 1400 UTC is certainly fine by me.
17:31 < madduck> that's 1400 in CET, 1300 in UK, 08:00 in EST?
17:31 < micah> I'm also unencumbered by work
17:32 < madduck> so 09:00 EST?
17:32 < fw> Maulkin: Yeah, not exclusively, of course.
17:32 < skx> sounds fine to me
17:32 < madduck> ok. i will announce 1400 UTC on tuesday, 28 feb
17:32 < Maulkin> Well, 13:00 is normally when I get my lunch, so that's probably ok :)
17:32 < madduck> who of you will be at fosdem btw.
17:32 < madduck> ?
17:32 < micah> thats earlier than I am normally caffeinated by, but i can do it
17:32 < madduck> because that's right before.
17:33 < Maulkin> madduck: Unfortunately not, I'm off to .de for OpenVas Devcon shortly after so can't afford both.
17:33 < micah> 1500-1530 UTC is better for me :)
17:33 < skx> I'm gonna have to run just now
17:33 < micah> skx: good drinkin'
17:33 < madduck> jmm: would you be okay if we set up a new list for us? secure-testing-team has a bunch of other people on it, not sure if we want that for now...
17:33 < aj> "This is the experimental issue tracker for Debian's testing security team. Keep in mind that this is merely a prototype. Please report any problems to Florian Weimer.Note that some of the data presented here is known to be wrong (see below), but the data for the testing suite should be fine."
17:33 < madduck> skx: thanks for your time!
17:34 < skx> madduck: you're welcome
17:34 < aj> experimental, prototype, known wrong...
17:34 < skx> micah: thanks
17:34 < skx> goodnight all
17:34  * dannf won't be awake for 1300, but Horms might be
17:34 < jmm> madduck: why not? It's a public security list
17:34 < madduck> jmm: mh, okay, i'll try.
17:34 < Maulkin> laters skx 
17:34 -!- skx [] has quit [Quit: leaving]
17:34 < jmm> I can't attend on 28th neither, but that's fine if someone sens the log around
17:35 < Maulkin> 15:00 is possible too, if it's a Tuesday/Wednesday
17:35  * Maulkin can do the log if needed
17:35 < madduck> jmm: should be do the 2nd of March instead?
17:35 < aj> fw, whoever: if this is going to be official, whatever's need to make it not experimental, and not "known to be wrong" needs to happen...
17:35 < micah> aj: I suppose I wouldnt call it experimental/prototype anymore, but the known wrong issues seem acceptable and good to document
17:35 < aj> the warning shouldn't be the first thing you see...
17:36 < micah> I agree, it should be available, but it could be moved
17:36 < jmm> madduck: several people already acked the date, let's stick to it
17:36 < madduck> jmm: ok.
17:36 < micah> fw: what do yout hink about that?
17:36 < aj> if something in particular is known to be wrong, it should just be fixed; if it's known that someone's made mistakes, or that it's not complete in general, but not in specific, that's different...
17:37 < jmm> aj: the only thing incorrect is kernels for sarge and woody
17:37 < jmm> because of the weird build system, it's exact for the rest (barring a few display bugs)
17:37 < micah> personally i think that it should say that if you find something wrong, here is how to correct it
17:37 < fw> micah: Yes, that makes sense.
17:38 < fw> jmm: But I think this is pre-DSA, post-DSA, the data should be correct.
17:38 < jmm> fw: what do you mean by pre-DSA, post-DSA
17:39 < micah> aj: I think fw's text is being over careful so that nobody takes this information and then screams when something is incorrect, but it should instead just say this is how you contact people to get it updated, or this is how you get invovled to help improve the quality of this information
17:40 < madduck> i am going to move the wiki page and place a redirect, just fyi.
17:40 < micah> there *always* is going to be things that are incorrect as the data changes and we have to update it, but its incredibly complete and accurate
17:41 < fw> jmm: We should have no false negatives after a DSA has been released because we have the CVE/version mapping at this point.
17:41 < jmm> yeah, but that works as of today?
17:41 < fw> micah: Yes, it's somewhat outdated.  It dates back to the days when we still were arguing whether we should use the data to track sid and stable/oldstable.
17:42 < madduck> new wiki URL for today's meeting:
17:42 < micah> madduck: thanks
17:42 < fw> jmm: I used dsa2list after the last kernel update.  *If* the DSA contained the correct CVE information, we should be fine (modulo the "arch-specific bug gets reported everywhere" issue).
17:43 < mstone> fw: hopefully you pull that from the web data, since that gets updated on error?
17:43 < jmm> mstone: I maintain a mapping :-)
17:43 < fw> mstone: No.
17:44 < fw> mstone: I fetch most data directly from the archive, to get correct version numbers. 8-P
17:44 < micah> fw: would you be willing to make text changes on the front page to make the tracker less "experimental/prototype/known wrong" as the first thing?
17:45 < micah> and maybe include info on how to get things updated (where to contact maybe?)
17:45 < fw> micah: Sure.  Just send a proposal to the list.
17:45 < micah> ok
17:46 < fw> Oh, servinvoke seems to have a really embarrassing bug.
17:46 < micah> I think I need to get going, thanks for the good meeting all
17:47 < Maulkin> Question: If I issue a DTSA now, should I use the existing system, or the new one?
17:47 < Maulkin> Laters micah 
17:48 < micah> Maulkin: at the moment only myself and jmm(?) have access to the new system, I think I need to write up how the new system works and we can adjust our DTSA workflow for it before we start using it?
17:48 < CIA-1> jmm-guest * r3495 /data/CVE/list: new honeyd issue
17:49 < madduck> micah: i'll leave the page to you now. For the next meetings I will create a template.
17:49 < Maulkin> micah: Ok :)
17:49  * joeyh returns
17:49 < joeyh> meeting still going? :-)
17:49 < Maulkin> joeyh: More or less finished :)
17:51 < micah> jmm: I was going to ping steven regarding CVEs for the outstanding kernel issues, but I thought that if you submitted them to him, it might be better if the ping came from you?
17:51 < jmm> micah: please go ahead, I'm busy with my DELE exams and my thesis
17:51 < fw> Okay, that TODO page's been fixed.  But it's *slow*.
17:52 < fw> Ah, we need to discuss our CVE-related processes the next time.
17:52 < fw> Once we know that we can get a unique ID for each issue quickly, it's much easier to use that as a primary index across databases.
17:53 < micah> jmm: ok, i will do so, is it safe to assume that all the issues listed in the DSA drafts you sent to him?
17:53 < jmm> micah: wrt kernel?
17:53 < micah> fw: maybe it would be good to add to the wiki so it is not forgotten for next time
17:53 < micah> jmm: yes
17:53 < fw> micah: I added it before today's meeting. 8-P
17:54 < jmm> I don't remember lost_sockfd, that must've been you, ia64-preempt was be me
17:54  * Maulkin needs to go to bed. Laters all.
17:54 < micah> ok, I'll look them up and send him a ping
17:54  * voidhawk too. Cheers.
17:54 < jmm> micah: on request he can allocate them w/o writing (he did so for elog, e.g)
17:55 -!- voidhawk [] has quit [Quit: Verlassend]
17:55 < jmm> micah: w/o writing the full description, I mean
17:55 < micah> ok, i think we have full descriptions for everything though
17:56 < micah> ok, really gone now, I'll try and get a summary out about the meeting soon
18:02 < madduck> thanks everyone. i hope this meeting will be able to spark some changes.
18:02 < madduck> email pending.
18:07 < madduck> micah: you may want to use