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
- State of the security team (Moritz):
- How testing security can help stable security
- engaging with the public vs. embargoed queue
- Use of the stable security tools on klecker (amber)
- Tracking issues
- moving tracker to debian address? Documentation?
- debescan feedback. Documentation?
- bugs without a CVE name - bring in new people to handle backlog? (Joeyh)
- How to increase DD concern with security issues in their packages
- NMU rules? More publicity?
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 (http://idssi.enyo.de/tracker/ 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: tracker.security.debian.org, 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 them.me 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:
- separate private/public (or embargoed vs. unembargoed) trees on klecker
- amber usage on klecker
This setup currently allows testing-security to use security.debian.org 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 (http://svn.debian.org/wsvn/kernel/people/dannf/pkg-checklist?op=file&rev=0&sc=0). 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)
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 at? 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: http://wiki.debian.org/SecurityScratchpad 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 [~firstname.lastname@example.org] 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 email@example.com... 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. -- http://wiki.debian.org/SecurityScratchpad | Congratulations jmm! (now real) | security team channel (testing and stable) | Tracker http://idssi.enyo.de/tracker/ | Website: http://secure-testing-master.debian.net/ 16:06 -!- Topic set by madduck [~firstname.lastname@example.org] [Wed Feb 15 11:47:10 2006] 16:06 < micah> skx: ah, I'm talking about http://idssi.enyo.de/tracker/ 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> http://svn.debian.org/wsvn/secure-testing/doc/narrative_introduction?op=file&rev=0&sc=0 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 [~email@example.com] 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. -- http://wiki.debian.org/SecurityScratchpad | Congratulations jmm! (now real) | security team channel (testing and stable) | Tracker http://idssi.enyo.de/tracker/ | Website: http://secure-testing-master.debian.net/ 16:15 -!- Topic set by madduck [~firstname.lastname@example.org] [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: http://lists.alioth.debian.org/pipermail/secure-testing-team/2005-December/000625.html (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 http://security.debian.org/debian-security/dists/testing/updates/main/ 16:24 < micah> This setup currently allows testing-security to use security.debian.org 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: http://svn.debian.org/wsvn/kernel/people/dannf/pkg-checklist?op=file&rev=0&sc=0 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 debian.net 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 debian.org 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 debian.net do for now? 16:53 < aj> and what sort of url are we talking? tracker.security.debian.org? 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 debian.net ones 16:53 < fw> mstone: It's hard to change DNS. That's why it's still under enyo.de. 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: tracker.security.debian.org would be awesome. 16:54 < micah> its kind of long, it would be better if it were security.debian.org/tracker 16:54 < madduck> or security.debian.org/tracker 16:54 < madduck> micah: dude. same length. :) 16:54 < mstone> no, make it tracker.security.debian.org 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: tracker.security.debian.org. IN A 126.96.36.199 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: svn.debian.org ? 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 email@example.com 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> http://alioth.debian.org/project/memberlist.php?group_id=30437 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. -- http://wiki.debian.org/SecurityScratchpad | Congratulations jmm! (now real) | security team channel (testing and stable) | Tracker http://idssi.enyo.de/tracker/ | Website: http://secure-testing-master.debian.net/ 17:24 -!- Topic set by madduck [~firstname.lastname@example.org] [Wed Feb 15 11:47:10 2006] 17:24 < madduck> aj: http://idssi.enyo.de/tracker/ 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: http://idssi.enyo.de/tracker/status/todo 17:27 < aj> http://idssi.enyo.de/tracker/status/todo -- 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? http://spohr.debian.org/~joeyh/testing-security.html 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> http://tinyurl.com/dmjsd 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 [~email@example.com] 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: http://wiki.debian.org/DebianSecurity/Meetings/2006-02-15 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 [~firstname.lastname@example.org] 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 http://wiki.debian.org/DebianSecurity/MeetingTemplate