--- Log opened Mon Jul 14 19:00:29 2008
19:00 <@vorlon078> ok... it is 1900 UTC and thus time to begin I guess
19:01 <@vorlon078> we have rbu mjf_ p-y and keytoaster on board
19:01 <@vorlon078> anyone else?
19:01  * adir waves
19:01 <@vorlon078> :)
19:02 <@vorlon078> so let's start with a short status overview
19:02 <@vorlon078> btw... the agenda didn't change since the invitation went out, but we can append any topic that comes up during the meeting
19:03 <@p-y> yep, I've noted a few topics that i'd like to discuss
19:03 <@vorlon078> ok
19:03 -!- rbu changed the topic of #gentoo-security to: Project Meeting: *now* http://dev.gentoo.org/~vorlon/security/meeting-20080714.xml
19:04 <@vorlon078> for the sub projects... I guess both of them, kernel and auditing can be considered dead at the moment
19:04 <@vorlon078> and we are currently lacking recruits/scouts/...
19:04 <@p-y> solar: still around?
19:05 <@vorlon078> and some team members are missing or busy with real life issues
19:05 <@rbu> what's the point in listing dead subprojects? as for the kernel project, i believe we should put effort in reviving it. but i think we should drop the audit project and put the docs elsewhere
19:05 <@vorlon078> all that resulting in quite some delays in bug fixing and especially glsa drafting/sending
19:06 <@p-y> for auditing i think it's not very important, but kernel is a little bit more problematic
19:06 <@vorlon078> rbu: agreed... audit will come back when we have someone interested
19:07 <@vorlon078> kernel is important in the long term, because we really should start considering kernel security again
19:07 <@vorlon078> but so much about the current status of the project...
19:07 <@p-y> yeah, but what do we do with the tons of open kernel sec bugs?
19:07 <@rbu> vorlon078: until then, i think we should remove the audit project
19:07 <@vorlon078> let's append kernel security to the list of topics
19:07 <@rbu> ++
19:08 <@mjf_> p-y: surely many of them can be closed?
19:08 <@p-y> mjf_: maybe, but that needs to be checked out for every kernel version that we ship, it's a *lot* of work
19:08 <@vorlon078> p-y: mjf_ let's kinda stick with the agenda and just append kernel sec
19:08 <@rbu> p-y: mjf_: if we append kernel security to the agenda, we should discuss it later
19:08 <@p-y> ok
19:09 < armin76> bumb!
19:09 <@vorlon078> next big thing is recruiting...
19:09 <@rbu> vorlon078: wait one second
19:09 <@vorlon078> rbu: sure... sorry
19:09 <@vorlon078> rbu: and yeah... we could just remove auditing or put a note on the page that it is dead
19:09 <@rbu> vorlon078: you wanted to discuss the project in general, and i guess that should include the way we do in security bugs
19:10 <@rbu> vorlon078: what do your stats say about that? why are late so often?
19:10 <@vorlon078> http://dev.gentoo.org/~vorlon/security/stats.xml
19:10 <@rbu> oh wait, that's another topic
19:10 <@rbu> argh
19:10 <@vorlon078> yeah ;-)
19:11 <@vorlon078> so let's start with recruiting...
19:12 <@vorlon078> I cleaned up our padawans page and it turned out we only have one person left as a recruit more or less
19:12 <@vorlon078> and adir who wants to contribute again
19:12 <@vorlon078> we have lost quite some recruits after only a short time they were active
19:12 <@vorlon078> although some also became devs
19:12 <@p-y> i think some people wanted to join recently, but they didn't sent a mail on security@g.o
19:13 <@vorlon078> so the question would be how to improve our recruitment process
19:13 <@p-y> I have some ideas on that
19:13 <@vorlon078> :)
19:13 <@p-y> in archs teams, archs testers have some more privileges on bugzie
19:14 <@p-y> with security scouts, they can't do anything on bugs that they didn't open
19:14 <@p-y> that's problematic, since you can't do much then
19:14 <@p-y> maybe they should be allowed to edit bugs earlier
19:14 <@rbu> oh god, that must be annoying :-o
19:15 <@p-y> ?
19:15 <@vorlon078> so at what point should we give editbugs priv to recruits?
19:15 <@rbu> not being able to edit bugs
19:15 <@rbu> i believe there is enough people watching the bugmail that we can survive some mistakes with early participation.
19:15 <@p-y> agreed with rbu
19:16 <@p-y> i always check every bugmail
19:16 <@rbu> so i think one or two weeks might be enough if the person is active and does do goo
19:16 <@vorlon078> should we wait like a week or so before giving privs out?
19:16 <@p-y> the problem is if they change a bug which is not assigned to security
19:16 <@vorlon078> rbu: yeah
19:16 <@vorlon078> p-y: exactly
19:17 <@p-y> vorlon078: yeah, probably
19:17 <@rbu> p-y: i wonder if that can be limited
19:17 <@p-y> me too, don't know how bugzie works with this
19:18 <@vorlon078> just asked in #-infra
19:18 <@p-y> ok, good
19:18 <@vorlon078> another problem is that sometimes mails from potential scouts are not answered in time
19:19 <@vorlon078> does not happen often, since there are not many mails, but we should be quick with stuff like that
19:19 <@vorlon078> and an old idea was to assign a mentor to each padawan
19:19 <@rbu> i think that we can do better in describing the "daily" process, as in: where to look for bugs, how to open a bug. maybe some examples
19:19 <@vorlon078> rbu: yeah
19:20 <@p-y> evelyette: still around? I remember you wanted to join
19:20 <@vorlon078> we should update some of our docs for sure
19:20 <@vorlon078> and we need to get the word out more... since there are not many even contacting us about joining
19:21 < evelyette> p-y, yes I'm still here... I've been very busy with my exams and now I'm coding something c/c++ so I don't have so much time...but before I do any work here I have to research a little more what I have to do...so I need time
19:21 <@p-y> ok, sure
19:21 <@mjf_> i have some input on more info for new recruits, ping me when you wann hear it
19:21 <@p-y> mjf_: please do
19:22 <@vorlon078> mjf_: go ahead
19:22 <@rbu> i can write up some padawan docs, to put them up. -- mjf_, i hope you can help there?
19:22 <@mjf_> yes.
19:22 <@vorlon078> great
19:22 <@mjf_> you should have a run-through of opening a bug, getting arch teams in etc
19:22 <@rbu> mjf_: let's get together about that later then
19:22 <@mjf_> like a full example.
19:22 <@mjf_> rbu: sure.
19:22 <@rbu> vorlon078: what do you have in mind in terms of recruiting?
19:23 <@vorlon078> we could get something up in the GMN
19:23 <@rbu> one thing that is very important IMO is to *encourage* people to join --- i have seen comments sometimes when people were new
19:23 <@vorlon078> or try with a blog post for now
19:23 <@rbu> that it's "all day the same work" and everything
19:23 <@vorlon078> yeah... that is not very helpful
19:23 <@p-y> you can't deny it
19:24 <@vorlon078> yes, but it can also be fun
19:24 <@rbu> p-y: yes, and no. there are certain boring tasks, but as usual you can either automate them, or have them handy
19:24 <@p-y> it's useless to lie to people so they help, and when they realize it, they leave, generally after a month
19:24 <@keytoaster> yes, that's important, i actually joined when p-y sent a mail to -dev back in 2007, otherwise i wouldn't have done so
19:24 <@rbu> p-y: but if you approach people with that attitude, you will not win anyone
19:25 <@p-y> true
19:25 <@vorlon078> so let us be honest but not scare everyone away right at the beginning
19:25 <@rbu> vorlon078: you said you could write up something in your blog? what else would you have in mind?
19:25 <@vorlon078> and with more privileges and more integration into the whole sec work we might make it more interesting
19:26 <@p-y> that's the point, but it's not easy
19:26 <@vorlon078> gmn article might help... i believe we have done that in the gwn a long while ago and we had quite a few people coming
19:26 <@rbu> ok, sounds good. could the forums be a place to advertise?
19:26 <@vorlon078> or talking to people who file bugs
19:27 <@p-y> basically, you 1)watch sec list, 2)file a bug, 3)draft a GLSA, 4)back to 1)
19:27 <@vorlon078> if we see somebody shows interest we should just approach them
19:27 <@rbu> p-y: you missed the steps between 2 and 3, which are fun. reading up, understanding the issue -- testing exploits, and so on
19:28 <@rbu> dberkholz: i guess the main page could be more inviting to help in general gentoo areas -- how is that coming?
19:28 <@p-y> rbu: yeah, but it's not mandatory...
19:28 <@vorlon078> rbu: i actually don't use the forums that much
19:28 <@rbu> vorlon078: well, we could note down the intent, and decide who posts it later
19:29 <@vorlon078> p-y: but recruits should be welcome to help with that too if they want... or help develop better tools for us like rbu's cve stuff
19:29 <@p-y> of course
19:29 <@vorlon078> ok... what is something concrete we can achieve quickly
19:29 <@p-y> vorlon078: got an answer about bugzie privileges?
19:30 <@rbu> if mjf_ and me can get that padawan "howto" done in, say, a week -- we could start rolling the drums after that?
19:30 <@keytoaster> p-y: only possible in bugzilla-3, we run bugzilla-2
19:30 <@vorlon078> rbu: yeah... that would be great
19:30 <@p-y> :/
19:30 <@vorlon078> I can try and write something up for a blog or article
19:31 <@rbu> so, here's the deal about bugzilla: i think we can still do it. but a mentor for each padawan would have to *monitor* the padawan's mail alias
19:32 <@vorlon078> rbu: that would work i guess
19:32 <@p-y> mail alias is for mail *received*, not sent? or am I missing something?
19:32 <@rbu> it should be fairly easy to set up a rule to find all non-security changes by that person, so the mail should be low
19:32 <@keytoaster> shouldn't be a big problem anyways, arch testers can edit other bugs, too
19:33 <@vorlon078> ok... so we will ask infra about adding privs to people or for us to be able to set them
19:33 <@vorlon078> and a mentor will watch over a padawan
19:33 <@vorlon078> and help where needed
19:33 <@vorlon078> also rbu and mjf_ will write new docs for padawans
19:33 <@vorlon078> and i will get something together to invite more people to join
19:33 <@vorlon078> ok?
19:34 <@p-y> 21:29) (@p-y) mail alias is for mail *received*, not sent? or am I missing something?
19:34 <@p-y> I mean, for monitoring
19:34 <@mjf_> vorlon078: sounds good
19:34 <@rbu> vorlon078: ++
19:34 <@vorlon078> p-y: hm... you are right i think... but a search should be possible
19:34 < dberkholz> rbu: (sorry for lag) it's coming slowly because nobody besides neysx knows enough xslt to be useful
19:35 <@rbu> p-y: https://bugs.gentoo.org/userprefs.cgi?tab=email "Email is sent or not according to your preferences for their relationship to the bug (e.g. Assignee). "
19:36 <@rbu> so i enable it to send "all comments i leave, all bugs i close" and get all bugs the padawan closes
19:36 <@rbu> etc
19:37 <@rbu> dberkholz: well, i hope you two are still driving it though, thanks for answering
19:37 <@vorlon078> wfm
19:37 <@p-y> and what if they've no relationship?
19:37 <@p-y> like they're not assignee nor in CC?
19:38 <@vorlon078> rbu: ^
19:38 <@rbu> p-y: ok, very good point. then a search/rss will help, i guess
19:38 <@vorlon078> i could not find a search for that actually
19:39 <@vorlon078> well... let's do some research on that
19:39 <@vorlon078> anything else wrt recruiting?
19:39 <@rbu> nop
19:39 <@p-y> nope
19:40 <@vorlon078> then let's stick with my above summary and also try to find a way for the editbugs priv problem
19:40 <@p-y> ok
19:40 <@vorlon078> the next topic is our current delays with glsas
19:41  * rbu has a solution to editbugs ;-)
19:41 <@vorlon078> see http://dev.gentoo.org/~vorlon/security/stats.xml
19:41 <@rbu> but later*
19:41 <@vorlon078> heh ok
19:41 <@p-y> rbu: dont forget it ;)
19:41 <@vorlon078> the page shows some rough stats about delays and such... not 100% accurate bug a good hint
19:41 < dberkholz> rbu: we could really use someone new who has both interest and mad xslt skillz.
19:42 <@vorlon078> and it shows we are really behind on the timeframes given by our policy
19:42 < mariok> hello
19:42 <@vorlon078> i.e. not even 50% of bugs are closed in time
19:43 <@p-y> yeah
19:43 <@rbu> vorlon078: you don't have any numbers about the state that it is in the longest?
19:43 <@vorlon078> i guess it started going down around the time koon left
19:43 <@vorlon078> rbu: unfortunately not
19:44 <@vorlon078> to me it seems drafting/reviewing is taking the longest atm
19:44 <@vorlon078> but that is more of a guess
19:44 <@vorlon078> earlier we used to have more problems with maintainers and stable marking
19:44 <@rbu> except for some exceptions, i think most of the rot is in [glsa] state :-/
19:45 <@p-y> rbu: yeah
19:45 <@vorlon078> rbu: yeah... that is where more recruits are needed i guess
19:45 <@p-y> some glsa requests have been there for months :/
19:45 <@rbu> since we still stay at close peer reviewing, and i think we really need to, ...
19:46 <@rbu> ... we should find a way to enable earlier contributions
19:46 <@p-y> like the emul-baselibs stuff
19:46 <@rbu> but i don't see that happening with that glsamaker
19:46 <@vorlon078> rbu: what do you mean with earlier contributions?
19:47 <@rbu> vorlon078: well, right now editing GLSAs stands at the end of the recruiting process. why not allow contributions earlier?
19:47 <@rbu> as we do with ebuilds. anyone can add an ebuild to a bug.
19:48 <@p-y> rbu++
19:48 <@vorlon078> actually it comes right after scouting... which can be quite quick
19:48 <@vorlon078> but you might be right
19:48 <@p-y> that could be a real benefit I think
19:48 <@rbu> i know *i* had to fight for that glsamaker access, and i think keytoaster will agree :-)
19:48 <@keytoaster> right
19:48 <@vorlon078> heh
19:48 <@p-y> heh
19:48 <@keytoaster> i was scouting for about half a year until i got access
19:49 <@keytoaster> was slacking some time though :>
19:49  * vorlon078 remembers being invited to it ;)
19:49 <@p-y> I stayed scout during a few months too
19:49 <@vorlon078> ok... so earlier contribution by recruits to glsa drafting would be a +
19:49 <@rbu> just how do we do this?
19:49 <@keytoaster> also, falco told me that glsamaker access is the last step because it might contain classified stuff
19:49 < hoffie> mhh, when i first touched glsamaker code i thought about re-implementing it. unfortunately i havent had any time for that (and cant make promises for the near future anyway). one of my ideas (of course i'd asked before actually doing sth) was making it a bit more decentralized
19:49 <@vorlon078> especially since many bugs are filed bug us or other devs nowadays
19:49 <@keytoaster> which should be hidden for new recruits until they become devs
19:49 <@p-y> keytoaster: didn't think about that
19:50 <@vorlon078> keytoaster: that is correct
19:50 <+adir> I agree with rbu :) I didn't have to fight for it, but it took me a long time until I got that glsamaker access :)
19:50 < hoffie> like providing a readonly glsamaker interface to the public (or at least to all scouts etc.), making glsamaker a standalone tool (or extend it with one) and allowing simply importing/exporting glsa drafts
19:50 <@keytoaster> and yes, that's not possible with our current glsamaker, but i think it's not a problem to implment a simple checkbox for the new one
19:50 < hoffie> i.e. anybody could draft a glsa locally and attach the xml file to a bug or something
19:51 <@rbu> hoffie: that could be an option.
19:51 <@vorlon078> hoffie: that would work too
19:51 <@vorlon078> so either seperated privs for glsamaker or something like what hoffie proposed
19:51 < dertobi123> jaervosz: around? been in contact with DerCorny lately and know a way for me to contact him? :)
19:52 <@vorlon078> dertobi123: jaervosz isn't available currently
19:52 < dertobi123> hrmkay
19:52 <@vorlon078> what would be easier to implement?
19:52 <@vorlon078> or are the other ideas
19:53 <@p-y> hoffie: would it be feasible quickly to show when the glsa request was pooled?
19:53 <@rbu> rewrite glsamaker, and include privilege separation
19:53 <+adir> it was a bit frustrating, but it was worth it and I really liked to contribute. However, there might be some people who might not like such a long process. the question is what the team acheives from a long process of recruiment. there's some tradeoff between long process and motivation, I believe.
19:53 <+adir> jaervosz and dercorny... where are they? I miss them :)
19:54 <@rbu> adir: dercorny retired, jaervosz is just on travel
19:54 <@p-y> dercorny retired, jaervosz is in vacation IIRC
19:54 <@p-y> :p
19:54 <@vorlon078> rbu: who would do that... and how fast could that be achieved_ ,ss)
19:54 < hoffie> p-y: sorry, didnt get the question, i'm not into the glsamaker stuff that much, i mainly looked at the code when i touched it
19:54 < dertobi123> adir: that's why i want to get in contact with him (Corny) again :)
19:54 <+adir> nice :)
19:54 < hoffie> p-y: pooled as in "filed the request"?
19:54 <@vorlon078> s/_ ,ss/;)/
19:54 <@p-y> hoffie: exactly
19:55 <@rbu> vorlon078: i already do that, but i cannot promise anything. i drafted a database model for GLSAs, and could already file one in the new tool
19:55 <@rbu> but it's still missing some features :-(
19:55 <@rbu> like xml import and export, and edit... and so on
19:55 <@vorlon078> rbu: sounds interesting
19:56 <@vorlon078> although i am not sure if a db is needed ,)
19:56 <@vorlon078> anyways... the idea about earlier contribution to glsa drafting is a good one
19:56 <@rbu> vorlon078: well, it is not -- when you store and edit XML all the time.
19:56 < hoffie> p-y: erm.. so your question was if it is possible to show those requests to the public in the current glsamaker? or did i get you wrong?
19:56 <@rbu> vorlon078: *but* i object to that ;-)
19:56 <@p-y> hoffie: nope
19:56 <@p-y> it's for us only
19:57 <@vorlon078> but it appears that it would need some work on the tools
19:57 <@p-y> to show when the request was filed, so we can prioritize older requests
19:57 <@p-y> or at least try to ;)
19:57 <@vorlon078> so are there any suggestions on short/mid-term changes
19:57 <@rbu> p-y: where, in the list? because the details page shows that date
19:57 < hoffie> p-y: ah, you are currently missing a date there?
19:57 <@p-y> rbu: yeah, directly in the list
19:58 <@p-y> ideally, we could sort columns with that date
19:58 <@rbu> p-y: no sorting... not in that code!
19:58 <@p-y> :(
19:58 <@vorlon078> lol
19:58 <@rbu> p-y: displaying the date should be simple --> git.overlays.gentoo.org ;-)
19:59 <@rbu> vorlon078: for the short term -- i do not think we will find a technical solution for earlier contribution
19:59 <@rbu> or any other real issues in glsamaker
19:59 <@vorlon078> rbu: yeah, that's how i see it too
19:59 <@p-y> rbu: what am I supposed to do with that? I don't know PHP :p
19:59 <@rbu> so if we would allow people to contribute, it would have to be organized via plain text / mail
20:00 < hoffie> at least we now have a specific task to do rather than "do something to make it easier to contribute"
20:00 <@rbu> p-y: excuses!
20:01 <@rbu> hoffie: of the two solutions, implement privilege separation -- or have a central tool, and an external draft-tool, which would you prefer?
20:01 <@p-y> rbu: writing a draft with no tool is not handy at all
20:01 <@vorlon078> p-y: rbu: plain text would be ok though... could be copy&pasted to glsamaker
20:01 <@rbu> p-y: people would only contribute Synopsis, Description and Impact then
20:01 < hoffie> rbu: in the long time, definitely the latter. implementing privilege seperation is probably easier, but i guess noone wants to touch the current code..
20:02 <@vorlon078> but then the person could no see the reviews etc
20:02 <@vorlon078> ^ which would be the case for the external draft tool too
20:03 <@vorlon078> we just passed the first hour btw
20:04 <+adir> :)
20:04 <@rbu> vorlon078: do you have a better solution for the short term than manual contribution -- i mean all that is given that someone really wants to contribute GLSAs anyway
20:04 <@rbu> and i don't think anyone will touch the existing code for this feature
20:05 < hoffie> vorlon078: well, what about making all non-private (embargoed) drafts+comments (semi-)publically accessible? would be the same if we chose to go the other way (keeping central stuff, using privilege seperation)
20:05 <@vorlon078> this way of contributing drafts would actually not look very appealing to recruits i guess
20:06 < hoffie> the difference is mainly that in one case the user can directly edit drafts at the central place (and as such needs an account) and in the other case he doesnt (as someone from security will import the xml file)
20:07 <@vorlon078> you mean we should do it the other way around and keep non-public drafts out of glsamaker at first but allow people easier access to the rest?
20:07 <@rbu> hoffie: maybe we have a different understanding of privsep,  but i would imagine that devs can see and edit all drafts, and non-devs can sign up, and contribute drafts -- but not see any but their own
20:08 <@vorlon078> rbu: that is what i had in mind too
20:08 <@p-y> rbu: sounds good
20:08 < hoffie> vorlon078: well no, just like bugzilla, certain drafts could be marked private, everything else is public
20:08 < hoffie> rbu: ah well, didnt think of user-can-signup-himself :)
20:08 <@p-y> but they would need to see the requests to be drafted too
20:09 <@vorlon078> hm... self sign up... dunno about that
20:09 <@p-y> hoffie: even displaying the draft is private is too much i think
20:09 <@vorlon078> um
20:09 <@p-y> it indicates the affected packages, and the versions
20:09 <@vorlon078> i guess we have some small variations of our view of priv sep here
20:10 <@vorlon078> in general i like the idea... more details could be talke about at a different time mazbe
20:10 <@vorlon078> for short term... i actuallz have no good idea
20:10 < hoffie> p-y: no, i mean, a security dev would mark the draft private and it would be hidden from any non-security member
20:11 <@p-y> vorlon078: I have: find the courage to draft some stuff :)
20:11 < hoffie> yeah i guess this topic could be postponed to some time else, maybe end of the meeting as it is unlikely that we find a short-term solution anyway
20:11 <@p-y> hoffie: ok
20:11 < hoffie> so i guess there are more important things to discuss now
20:11 <@vorlon078> p-y: ;) mainly lack of time here
20:11 <@vorlon078> let's postpone the topic then
20:11 <@p-y> vorlon078: I guess that's the same for every of us
20:12 <@vorlon078> i guess we have gotten at least some good ideas about a new tool
20:12 < hoffie> indeed
20:12 <@vorlon078> can we go on with the next topic?
20:12 <@p-y> yep
20:12 <@rbu> ++
20:13 <@vorlon078> GLSA related issues 
20:13 <@vorlon078> there are two points
20:13 <@vorlon078> related to changes in the glsa xml
20:13 <@vorlon078> first should implement the correct date format in glsas
20:13 <@vorlon078> we should...
20:14 <@vorlon078> rbu: could you give a status overview on that maybe
20:14 <@vorlon078> i don't think there is much holding us back there
20:15 <@rbu> yes. the status as follows
20:15 <@rbu> right now we ship glsas with a date that does not follow the DTD -- old glsas have a different date format
20:16 <@rbu> also, the revision should be in an attribute, not in the date as " : $rev"
20:16 <@rbu> we have a patch to glsamaker ready, and a script to convert all files in glsamaker, and in CVS
20:16 <@rbu> and that will also allow dates in the RSS feed finally
20:16 <@vorlon078> https://bugs.gentoo.org/show_bug.cgi?id=196681
20:16 <@vorlon078> for reference
20:17 <@rbu> what we do not have is an announcement of the change, and the patch to portage
20:17 <@rbu> this will "break" output in current portage versions, they will display the date as in the XML
20:17 <@rbu> so "January 1, 2008 : 1" would change to "2008-01-01"
20:17 <@rbu> and the revision ignored
20:17 <@vorlon078> is it just glsa-check or portage itself?
20:18 <@rbu> glsa-check
20:18 <@vorlon078> a patch for glsa-check was attached to the other bug iirc
20:18 <@rbu> but portage 2.2 has glsa parsing directly, so i guess that too
20:18 <@vorlon078> and it actually seemed just to be a cosmetic issue
20:19 <@vorlon078> rbu: that is what i was just wondering about too
20:19 <@rbu> vorlon078: right, and from my reading the patch is ok. but one would really need to test it beforehand
20:19 <@vorlon078> so the single hold up is portage
20:19 <@rbu> vorlon078: yes
20:19 <@vorlon078> then let's bug the portage/glsa-check team again
20:19 <@rbu> .. and no, considering the cosmetics. but still, people might have scripts parsing glsa-check's output
20:19 <@vorlon078> rbu: true
20:20 <@vorlon078> then let's push for the portage changes
20:20 <@vorlon078> so we can get it over with
20:20 <@rbu> anyone up to test the patch and bug the portage people?
20:21 <@rbu> we would also need to get that thing stable, maybe a little earlier than usual
20:21 <@vorlon078> and it should also be announce beforehand for people parsing glsa in scripts and other package managers
20:23 <@rbu> vorlon078: what bothers me a little is that neysx edited the dtd to add the <revised count=""> attribute
20:23 <@vorlon078> he did alreadz?
20:23 <@vorlon078> ah... the dtd
20:23 <@vorlon078> what bothers you about it?
20:24 <@rbu> vorlon078: yes... well, editing the dtd is not an issue. but i do not think we should be using that attribute, and at the same time we pay attention not to add a SLOT attribute without versioning
20:24 <@vorlon078> ?
20:25 <@vorlon078> why not that attribute?
20:25 <@rbu> in the end both are the same thing (from a format / package manager) perspective: i understood genone that *no* attribute should be added to the DTD without proper versioning
20:25 <@rbu> if that holds for SLOT attributes, it should also hold for COUNT attribute
20:25 <@vorlon078> that sounds right
20:26 <@vorlon078> so (joining this and the next topic) we do need a glsa version tag and that should be updated for every change in the dtd too
20:27 < hoffie> or start versioning the dtd maybe? the xml should contain the url of the dtd anyway? (i assume it already does)
20:28 <@rbu> hoffie: it does
20:28 <@rbu> vorlon078: i also think the XML should not contain the version inside, but we should use a new DTD, that has a version in the name
20:28 <@rbu> glsa-2.dtd
20:29 <@vorlon078> yeah
20:29 < hoffie> that's what i meant
20:29 <@vorlon078> well if genone/portage/neysx are alright with that, then we should go that route
20:29 <@rbu> when changing the format of dates, all our glsas will be the new DTD then
20:30 <@vorlon078> yeah
20:30 <@rbu> so the transition would be on at least 4 weeks delay due to announcing the change. so getting it ready soon would be good
20:31 <@rbu> as always :-)
20:31 <@vorlon078> ;-)
20:31 <@vorlon078> first step would be to ask about that kind of versioning of the dtd
20:31 <@vorlon078> and integration of the date/revision stuff into portage
20:32 <@rbu> maybe proposing a solution we favor would be helpful
20:32 <@vorlon078> yeah
20:32 <@rbu> then we can move to the next point, slot support. how would we want to do this?
20:32 <@rbu> do we want to do this?
20:33 <@vorlon078> i would sorry... connection issues... back again
20:34 <@p-y> yeah, that would avoid the usual "glsa-check says that foo-1.2-r14 is vulnerable but it's not" bugs
20:34 <@vorlon078> -i would
20:35 <@vorlon078> so we could say slot 1 >1.1 unaffected, slot 2 >2.3 unaffected etc
20:35 <@vorlon078> first requirement from the portage team before implementation was the versioning of the dtd
20:36 <@rbu> well, i guess we are beyond that
20:36 <@vorlon078> yeah
20:37 <@vorlon078> this should be worked out together with genone et al i guess
20:37 <@rbu> do we want to discuss specifics to the format now, or later?
20:37 <@vorlon078> and will probably take ..... well quite some time
20:37 <@p-y> rbu: later, probably
20:37 <@vorlon078> agreed
20:37 <@rbu> vorlon078: about the time. usually all it needs is follow-through.
20:37 <@vorlon078> so what is the next action from our side for those two issues
20:38 <@vorlon078> push portage team for the glsa date stuff
20:38 <@vorlon078> and test the patch
20:38 <@vorlon078> anything else?
20:39 <@rbu> here's how i see the next steps: decide how we would do slot support in the DTD, talk to neysx/docs team about getting -2.dtd ready, and then talk to genone about implementing it
20:39 <@rbu> i think we should do SLOT support and the date issue at the same time.. otherwise we have to do it twice
20:39 <@vorlon078> true
20:40 <@vorlon078> then let's start a discussion about the slot support via mail maybe
20:40 <@vorlon078> or the wiki
20:40  * vorlon078 uses the chance to remind everyone of the wiki we have... see link in glsamaker
20:41 < hoffie> it's non-public i guess?
20:41 <@vorlon078> hoffie: glsamaker account needed
20:42 < hoffie> mh, i guess i dont have mine anymore, ok ;)
20:42 <@vorlon078> nothing much of interest in there atm anyways ;)
20:42 <@vorlon078> so if nobody wants to add to this topic anymore then i suggest to take the discussion to mail and go on with the next topic
20:42 <@p-y> ++
20:43 <@p-y> ah... CVE ids :)
20:43 <@vorlon078> which takes us to specifying cve ids in bugyilla
20:43 <@vorlon078> y=z z=y
20:44 <@vorlon078> atm we have to places where we put the ids.. in the title and as aliases
20:44 <@vorlon078> which both works fine for the one cve per bug issues
20:44 <@p-y> yep
20:44 <@vorlon078> but we run into problems where one bug deals with multiple cve ids
20:44 <@p-y> usually i put the lowest id as alias, but that doesn't help much actually
20:45 <@vorlon078> in the title (CVE-2008-{1234,1235,1236,1237}) works just fine if  one uses searches like "ALL CVE-2008 1234" to find it
20:45 <@vorlon078> if there are multiple cves i don't put any of them as alias
20:46 <@p-y> imo we should add somehting about CVE in the vuln policy
20:46 <@vorlon078> rbu now has some issues with his notebook and should be right back
20:46 <@rbu> back -)(
20:46 <@p-y> heh
20:47 < hoffie> once again i'd have a suggestion which requires more than a little work, i guess... exposing the cve->bugid mapping from svn to the public using a small web tool, for example
20:47 <@vorlon078> p-y: yeah... i would like to specify a way now and document that in the coord guide
20:47 < hoffie> i.e. providing a small "search engine" specifically for cves
20:47 <@rbu> redhat does one bug per CVE, but i don't want to go down that mess
20:47 <@vorlon078> hoffie: kinda like debian does it... yeah
20:47 <@p-y> there's a cve bot already
20:47 <@vorlon078> rbu: yeah... too many bugs then
20:47 < hoffie> mh right
20:47 <@p-y> but a web tool could help
20:48 <@rbu> a web page *would* be helpful... but does anyone want to do that ? ;-)
20:48 <@p-y> rbu: espacially for mozilla bugs :D
20:48 <@vorlon078> as a side note... if we want to achieve cve compatibility, we need to have a way to link bugs/glsas/cve ids and make that searchable
20:49 < hoffie> rbu: you've got parsing code for those lists anyway, right (for !cve)?
20:49 < hoffie> then it should be *rather* easy to expose that as a small cgi script
20:49 <@p-y> vorlon078: maybe adding them in the glsa list at glsa.gentoo.org would be ok?
20:49 <@rbu> hoffie: kind of.... the way the bot works right now is really messy
20:49 <@p-y> then, ctrl+f in your browser ;)
20:50 <@vorlon078> p-y: i'm not sure that qualifies as searchable ,)
20:50 <@vorlon078> but having the cves listed there would be nice
20:50 <@p-y> at least that's better than nothing
20:50 <@vorlon078> but i think we have a lack of space on that page
20:51 <@vorlon078> and i believe it should also be possible to search for a certain cve and see that it does not affect us etc
20:51 <@vorlon078> s/possible/needed/
20:51 <@vorlon078> ah forget that
20:51 <@rbu> if you think we should employ the list in the SVN, which is the most complete (also features recent non-glsa bugs)... exposing that to the web is possible
20:51 < hoffie> so, what do we have? bug -> cve works (summary), bug -> glsa works (final comment), glsa -> cve works, glsa -> bugid? i dont think so, and cve -> bug is not accessible from web easily
20:51 <@rbu> and if we want to invest work, i think that would make the most sense
20:52 <@rbu> glsa-> bugid, is in the glsa
20:52 <@p-y> glsa already contains bugid, doesn't it?
20:52 <@p-y> ok :)
20:52 < hoffie> ok
20:52 < hoffie> so only cve -> bugid missing
20:52 <@vorlon078> hm
20:52 < hoffie> which would be implementable by using the list from svn as a source
20:52 <@p-y> !cve CVE-2008-2543
20:52 < rbubot> p-y: CVE-2008-2543 (The ooh323 channel driver in Asterisk Addons 1.2.x before 1.2.9 and ...)
20:52 < rbubot> p-y: * CVE-2008-2543 has bug 224949
20:53 < hoffie> s/missing/missing for non-irc/ ,9
20:53 < hoffie> ;)
20:53 <@p-y> :)
20:53 <@rbu> since i forked the tools from debian, the "security tracker" they run could almost handle our "database"
20:53 < hoffie> is it public as well?
20:53 <@rbu> yes, the code is public. but it is *huge*
20:53 <@vorlon078> rbu: yeah... i think we should look into implementing it that way maybe
20:53 <@p-y> it does the coffee too?
20:53 < hoffie> mh well, i'd rather have thought about a small cgi script
20:54 <@vorlon078> but we should also keep the cve ids in bug titles as we do it now and document that
20:54 < hoffie> yeah of course
20:54 <@rbu> the debian code is here http://svn.debian.org/wsvn/secure-testing/lib/python/?rev=0&sc=0
20:54 <@vorlon078> i am not sure about the alias
20:54 <@p-y> it's not possible to have multiple aliases for one bug?
20:55 <@p-y> one per cve i
20:55 <@rbu> p-y: nope
20:55 <@p-y> s/i/id
20:55 <@p-y> :/
20:55 <@rbu> and also, we have multiple bugs per CVE sometimes
20:55 <@rbu> we would need some kind of tracker then
20:56 <@rbu> tracker = tracker bug
20:56 <@vorlon078> yeah
20:57 <@rbu> hoffie: your interest in that tacker is rather passive? :-)
20:57 <@rbu> cve->bug tarcker
20:57 < hoffie> mh, i guess a mixture of the current system (sometimes handling multiple cves in one bug) and the redhat style (one bug per cve) would be messy as well. i.e. filing seperate bugs per cve but marking them as dups of the bug were all related cves are handled
20:58 < hoffie> well i could try to implement it :)
20:58 <@vorlon078> so we do want to have some kind of tracker site on the web for cve/bug/glsas
20:58 <@vorlon078> hoffie: hired
20:58 <@vorlon078> ;-)
20:59 < hoffie> well, for now i'd probably only want to implement cve->bug, as this is missing
20:59 < hoffie> we can then see if it's worth extending this to do all the other mappings as well
21:00 <@vorlon078> sounds good
21:00 <@rbu> hoffie: adding CVE->bug to that list could be done as well (by me), so that could be exported
21:00 <@vorlon078> we should also get more active with the tool in svn then
21:01 < hoffie> rbu: hu, this information is already in svn, isnt it?
21:01 < hoffie> that's what i was referring to
21:01 <@rbu> hoffie: not yet
21:01 < hoffie> 22:52:40 <@p-y> !cve CVE-2008-2543
21:01 < hoffie> 22:52:41 <rbubot> p-y: CVE-2008-2543 (The ooh323 channel driver in Asterisk Addons 1.2.x before 1.2.9 and ...)
21:01 < hoffie> 22:52:42 <rbubot> p-y: * CVE-2008-2543 has bug 224949
21:01 < hoffie> where does it come from then?
21:01 <@rbu> hoffie:  oh, that. yes
21:01 <@rbu> bug is, glsa not
21:01 < hoffie> ah, you meant glsa
21:02 <@vorlon078> should we start adding glsa ids to the list file too?
21:02 <@rbu> sorry.. man, yes
21:02 <@rbu> concentration--
21:02 < hoffie> yeah, either that or add a possibility to parse glsas and extract the bug ids
21:02 < hoffie> but i guess we can postpone that a bit, main priority is cve -> bug
21:02 <@rbu> vorlon078: we could script that easily
21:02 <@vorlon078> true
21:02 <@vorlon078> hoffie: would be great if you could come up with something there
21:03 <@vorlon078> which could easily be expanded later
21:03 <@vorlon078> passing 2h
21:04 <@rbu> MOVIN ON THEN
21:04 <@rbu> oops
21:04 <@vorlon078> lol
21:04 <@p-y> :D
21:04 <@vorlon078> ok
21:04 <@vorlon078> then we delegate the creation of a tool for this issue to hoffie ;)
21:04 <@vorlon078> and move on...
21:05 < hoffie> ok
21:05 <@vorlon078> rbu proposed two additions to the vuln policy
21:05 < hoffie> if you dont hear anything from me regarding this by the end of the week, poke me again :p
21:05 < hoffie> but i'll try to work on it tomorrow
21:05 <@vorlon078> we will delegate someone else to poke you then
21:05 < hoffie> :D
21:05 <@vorlon078> "Insecure creation of temporary files" and "SQL Injection"
21:06 <@vorlon078> both are not really defined in the policy atm
21:06 < hoffie> i'm really in favor of listing more common cases there (although my vote might not count here :p)
21:06 <@vorlon078> rbu proposed level 3 for that which would result in normal severity in the glsa
21:07 <@p-y> hmm, maybe 2 for SQL injection
21:07 <@vorlon078> 2: Remote passive compromise: remote execution of arbitrary code by enticing a user to visit a malicious server or using malicious data
21:07 <@vorlon078> 3: Global service compromise: denial of service, passwords or full database leaks...  	3  	normal
21:07 < hoffie> mhhh... i guess those things are often a case-by-case thing
21:08 <@p-y> yeah but SQL injection is still remote exec of SQL code
21:08 < hoffie> php limits queries w/ mysql_query to one query. so being able to inject data to a SELECT query really means that the attacker can "only" get information he isnt supposed to see
21:08 < hoffie> in case of an INSERT he can also manipulate the database
21:08 < hoffie> in case of other queries (functions or whatever) he might be able to execute arbitrary code
21:08 <@vorlon078> just as info... 2 always results in a glsa and has a target delay of 5 or 10 days
21:09 <@p-y> I know
21:09 <@vorlon078> 3 only results in glsa for A packages and gets a vote for B
21:09 <@vorlon078> keytoaster: still here?
21:09 < hoffie> so there seems to be a wide variety of different impacts, imo
21:09 <@vorlon078> do we agree on 3 for temp files?
21:09 <@p-y> yeah
21:10 <@keytoaster> vorlon078: yes, but a bit busy
21:10 < hoffie> mhhh
21:10 <@vorlon078> and mjf_ ?
21:10 < hoffie> in some cases, insecure temp file creation could be equal to local privilege escalation to root. think of overwriting /etc/shadow
21:10 < hoffie> or am i wrong here?
21:11 < hoffie> always depends on the concrete case of course...
21:11 <@vorlon078> hoffie: it can have serious consequences
21:11 <@p-y> hoffie, true, depends if the content is controllable by the attacker
21:11 <@vorlon078> so yeah... it is both a case by case thing
21:11 < hoffie> yep, i'd say this too
21:12 < hoffie> but i guess it'll still be a good idea to add this statement to the document
21:12 <@vorlon078> full db leak is 3 and data disclosure is 4... even those can have serious impact depending on the data
21:12 < hoffie> not to the list itself, but rather below it, i think
21:12 <@rbu> sorry for lagging.... as for insecure tempfile: if it allows code execution, we can still rate it 2
21:12 <@p-y> rbu: how?
21:12 <@rbu> or 1, if by root.
21:13 <@rbu> p-y: what do you mean?
21:13 <@vorlon078> and there is always the possibility to change the severity in the glsa even if not in full agreement with the policy... like has been done with the lates bind issue
21:13 <@p-y> how overwriting a file could allow code exec?
21:13 < hoffie> p-y: libs, /etc/shadow allowing root login, ...
21:13 <@p-y> in this case it's privilege escalation
21:14 <@vorlon078> yeah
21:14 <@rbu> p-y: well, if the attacker can control content and the file
21:14 <@rbu> p-y: that depends on who is *needed* to run the code. if it can (but not must) be run as root, it is not a privse?
21:14 <@rbu> privsep
21:14 <@vorlon078> actually the current policy kinda covers tempfile issues
21:14 <@vorlon078> just not explicitly
21:14 <@rbu> vorlon078: how so?
21:15 <@vorlon078> well... that case would be local priv escalation
21:15 <@vorlon078> hm... but in other cases it is not that clear it seems
21:15 <@vorlon078> bah... serious lack of concentration
21:15 <@rbu> vorlon078: by the same argument, any user-assisted code execution would be priv. escalation, because root could start the application
21:16 <@rbu> vorlon078: it would only be priv. esc. if root *needs to* (or usually does) run the application
21:16 <@vorlon078> alright
21:18 <@vorlon078> so actually it is quite hard to find a fixed value for both cases sql and tmp file
21:18 <@vorlon078> 3 would appear to be a good compromise though i think
21:19 <@vorlon078> if we do want to explicitely list it in the policz
21:19 <@vorlon078> s/policz/policy/
21:19 < hoffie> i'm certainly in favor of adding it to the document. i'm not sure if it should be added to the list. in any case i'd add a short explanation about the case-by-case thing below the table
21:19 <@vorlon078> that is something we could do
21:19 <@rbu> ++
21:20 <@vorlon078> input from jaervosz and Falco would be interesting too here i believe
21:20 <@vorlon078> who would like to draft a paragraph for that?
21:20  * rbu hides
21:20  * p-y follows rbu
21:20 <@vorlon078> rbu: great... thanks for stepping up and taking that task
21:20 < hoffie> haha
21:20 <@vorlon078> ah... two volunteers
21:21 <@vorlon078> ;)
21:21 < hoffie> does jeeves have some choose-a-random-person command? :p
21:21 <@vorlon078> lol
21:21 <@vorlon078> feature request for willikins
21:21 < hoffie> :D
21:21 <@vorlon078> rbu: could you do it?
21:22 < gontranz> .
21:22 < gontranz> oops
21:22 <@rbu> vorlon078: well, i would like to, but for fairness i had hoped we could split the load better :-)
21:23 <@rbu> next meeting i will keep a TODO counter in the /topic
21:23 <@vorlon078> hehe
21:23 < hoffie> i'm already at 1 and not even a member of the sec team :p
21:24 <@rbu> keytoaster: how do you feel about typing up those a few additions?
21:24 <@p-y> hey, we received a mail from a new recruit :)
21:24 <@vorlon078> just a short draft which could be reviewed
21:24 < hoffie> probably someone who listened to this meeting? :p
21:24 <@p-y> indeed
21:25 <@rbu> well, if no one else steps up in the aftermath, mark it TODO for me
21:25 <@vorlon078> ok
21:25 <@rbu> vorlon078: i hope you do sum up who needs to do what, otherwise i will die
21:25 <@vorlon078> we gotta do a summary anyways
21:25 < hoffie> yeah, some kind of summary would be cool
21:25 < hoffie> :)
21:26 <@keytoaster> rbu: i will decide that when i read the backlog :p
21:26 <@vorlon078> lol
21:26 <@vorlon078> ok
21:26 <@vorlon078> lets move on quickly
21:26 <@vorlon078> security support of games
21:26 <@vorlon078> no decision just short discussion
21:26 <@vorlon078> problem is we have many games with sec problems which end up being masked and stuff
21:27 <@vorlon078> and many never get fixed
21:27 <@rbu> http://rafb.net/p/R2cmJm95.html for a list
21:27 < hoffie> as long as they get masked and not removed, i think that's perfectly fine. if people want to use it, they'll have to explicitly agree to installing vulnerable software by putting it in package.unmask
21:27 <@p-y> ~arch seems the best way
21:27 <@vorlon078> we could treat them like every other package or declare them as non-supported
21:27 < hoffie> it's not that convenient, right, but security is still more important i think
21:28 <@vorlon078> p-y: that would be an idea... like with many webapps
21:28 <@vorlon078> although our goal should be to have secure software in the tree
21:28 <@rbu> ~arch, but no mask is no solution
21:28 <@rbu> i think both declaring it unsupported, and having it supported but masked is favorable over ~arch
21:29 < hoffie> yep
21:29 <@vorlon078> personally i don't like many masks either and ususally like security masked packages to get out of the tree
21:29 < hoffie> i'd favor handling it as any other package as i said.
21:29 <@vorlon078> i am not much in favour of calling a category unsupported when the packages are in arch
21:30 <@vorlon078> so i would prefer to have them masked
21:30 < hoffie> rbu: what exactly do you mean by "declaring it unspported"? i guess one would still file sec bugs and fix them asap if possible, just that there is no "guarantee" which enforces that, right?
21:30 <@vorlon078> and handled like other packages, just not removed from the tree as long as they are still maintained
21:30 < hoffie> yep..
21:31 <@vorlon078> any other opinions?
21:31 <@rbu> hoffie: the policy right now states that all packages should be supported (except some kernel sources), and if masked then removed or fixed shortly
21:32 < hoffie> [OT: concentration dropping... i guess meetings should be done more often in the future and be kept shorter]
21:32 <@rbu> if we want to *keep* some of them forever, we should add that to the policy as exceptions
21:32 <@vorlon078> we have not enforced the removal though
21:32 <@vorlon078> but i would prefer we do so more often
21:32 < hoffie> rbu: didnt know that (about having them removed at some time), but yeah, then i'd be in favor of adding such an exception for games
21:32 <@rbu> .. and web-apps.... the exception does not have to be for games explicitly.
21:33 <@vorlon078> hm
21:33 < hoffie> hm yeah, just thought about it, games are not really that special
21:33 < hoffie> it's more like if the software in question is still used heavily (which is often the case of games, but not necessarily)
21:33 <@vorlon078> ok
21:33 < hoffie> just look at php-4 as an example, we've kept it in p.mask for almost a year now as well
21:33 <@rbu> i would just like it so: Some applications are impossible or infeasable to support, so they might stay in package.mask"
21:34 < hoffie> (although there have been concrete dates for removal)
21:34 < hoffie> ++
21:34 <@vorlon078> i will look into the policy and see what could be changed or added
21:34 <@rbu> vorlon078: ok
21:34 <@vorlon078> and check what it says about removal etc
21:34 <@rbu> done with that then?
21:34 <@vorlon078> yep
21:34 <@vorlon078> woohoo
21:34 <@vorlon078> anything else???
21:34 <@rbu> p-y: you had topics
21:35 <@p-y> yeah
21:35 <@rbu> ohh.. one question to the general audience:
21:35 <@p-y> actually I noted CVE alias, but it was already dealt with :)
21:35 <@p-y> one last thing
21:35 <@p-y> removal of vulnerable pkg
21:35 <@rbu> p-y: you go first
21:35 <@p-y> some herds like web-apps do it, but others don't
21:35 <@p-y> and others have special policies
21:36 <@vorlon078> p-y: you mean vulnerable versions of fixed packages?
21:36 <@p-y> e.g gnome keep 2 stable versions
21:36 <@vorlon078> or masked packages
21:36 <@p-y> vorlon078: yep
21:36 <@rbu> p-y: others also do eventually, i guess web-app is just the ones leaving comments often
21:36 < hoffie> p-y: i think lots of devs dont even know about that and in many cases slacker arches are preventing it anyway
21:36 <@p-y> rbu: you sure of that?
21:36 <@vorlon078> p-y: officially we like the vuln versions to be removed but do not enforce it
21:36 <@p-y> and the "eventually" is already a problem for me
21:37 <@rbu> p-y: not entirely
21:37 <@p-y> no need to keep them any longer than necessary
21:37 <@p-y> ie when the fixed version is stabke
21:37 <@rbu> p-y: we could generate a list of all packages affected by a GLSA older than 4 weeks easily
21:37 <@vorlon078> rbu: that would be good
21:37 < hoffie> i dont think the problem is enforcing (i.e. maintainers who forget to do it), it's rather making them know about it in the first place
21:37 <@rbu> "easily" as in: it can be scripted.
21:37 <@vorlon078> someone had a script for stuff like that but i forgot who
21:37 <@rbu> but NO todo for me ths time ;-)
21:38 <@vorlon078> might have been jakub
21:38 < hoffie> i.e. adding a notice to the related bugs once stabilization is done
21:38 <@vorlon078> a script would be nice for this
21:38 <@vorlon078> and we should inform devs better about it
21:38 <@vorlon078> like a mail to -dev-announce
21:38 <@vorlon078> and include a comment when closing a bug
21:39 <@rbu> hoffie: adding it to the bug is a good idea. i plan for the new glsamaker to be able to change [stable] to [glsa] anyway, and it could leave that comment :-)
21:39 < hoffie> well, what about new devs? how should they know about it? it's not part of ebuild quiz or some document which every dev is supposed to read
21:39 < hoffie> so i'm really in favor of the comment-on-bug thing
21:39 <@vorlon078> hm
21:39 <@vorlon078> hoffie: agreed
21:40 <@rbu> we could agree on a comment, and then copy paste it
21:40 <@vorlon078> at some point we should also review quizzes and dev-manual for security related stuff maybe
21:40 <@rbu> about the script... p-y ?
21:40 <@p-y> hmm?
21:40 <@rbu> vorlon078: VERY good idea!
21:40 <@rbu> p-y: up to write that glsa "who is affected" thing?
21:40 < hoffie> vorlon078: maybe generate a "long-term todo list" along with the summary of this meeting? :)
21:41 <@p-y> err, don't know when I could find time to do that :/
21:41 <@vorlon078> hoffie: yep
21:41 <@p-y> but why not
21:41 <@vorlon078> also we could add stuff like that to the project page
21:41 <@rbu> vorlon078: if we have TODOs, which do not get assigned.. we could also list them on the recruitment page / blog
21:41 <@vorlon078> rbu: good idea
21:41 <@rbu> ok, i guess we are done with that question
21:42 <@vorlon078> so lets start adding comments to bugs about removal of vuln versions
21:42 <@vorlon078> could be something informal for now
21:42 <@vorlon078> just to get the word out
21:42 < hoffie> only problem is slacker arches i think..
21:42 <@rbu> hoffie: true
21:42 < hoffie> so security needs to keep track by bugmail, as vulnerable versions can often only be removed some time after the glsa (or changing to FIXED)
21:43 <@vorlon078> true
21:43 <@rbu> hoffie: none of the slacker arches actually removes themselves from the bug, so watching bugmail does not make sense
21:43 < hoffie> mhh
21:43 <@vorlon078> yeah... been a long time since i saw that happen
21:43 <@rbu> i think finding candidates by script is the easiest and most powerful approach
21:43 < hoffie> that sucks, but is really out of the scope of security
21:44 < hoffie> yep, sounds good
21:44 <@rbu> just needs some lines of bash/python/
21:44 <@rbu> and i guess we could actually advertise with that kind of task
21:44 <@vorlon078> yep
21:44 <@vorlon078> rbu: you had another topic?
21:44 <@rbu> uhh... well, kinda
21:45 <@rbu> just a question for opinions
21:45 <@rbu> debian marks security bumps in the *changelog* with a special keyword -- they use it for migration between their distributions
21:45 <@rbu> if we would do the same, we might end up having portage mark security updates in a special way
21:45 <@rbu> is that something we should go after, or not?
21:45 <@rbu> (i always have the craziest ideas, i know)
21:46 < hoffie> hmm, would certainly be cool, but how would you implement that?
21:46 <@p-y> rbu: maybe :)
21:46 < hoffie> ChangeLogs are free-form and i think they are not read at all by default (unless you use -l or whatever that option was)
21:46 <@vorlon078> i would like a consequent way to note sec bumps in the changelog since it is not always very clear atm
21:46 <@p-y> I don't know
21:46 <@rbu> hoffie:ever did "emerge -l"?
21:47 < hoffie> rbu: see contents of the parentheses :p
21:47 <@vorlon078> so i guess we would like it but could not require it
21:47 <@rbu> ohh.. ok, i should read all before typing
21:47 <@vorlon078> i'm already glad the changelog mostly contains "security" somehow so i get a hilight in #-commits
21:48 <@rbu> about the format, we could add a tag to the * lines, or so
21:48 < hoffie> well, i guess one could start making it a policy in the near future (like requiring the word "security" in those bump messages) and see about getting it parsed later
21:48 <@rbu> well, if i'm not the only one to like the idea, i'll just query genone sometime
21:49 <@vorlon078> rbu: i guess a proposal for such a keyword would be good
21:49 < hoffie> i certainly like the idea, i've got only concerns about the technical side of things
21:49 < hoffie> but maybe portage folks can help us here
21:49 <@vorlon078> then propose it and at some point later it could become policy
21:49 <@rbu> hoffie: ++
21:49 <@vorlon078> yep
21:50 <@rbu> well, we can have a meeting sometime soon and see about the outcome of most of what we discussed today
21:50 <@vorlon078> yeah
21:50 <@rbu> if we get 50% of it done, wow ;-)
21:50 < hoffie> yep, just wanted to re-raise this proposal :)
21:50 < hoffie> more frequent meetings, probably still on an as-needed basis
21:50 < hoffie> 3h of concentration are hard to manage
21:50 <@vorlon078> when more devs are back we also need to hold some kinda lead election again
21:50 <@vorlon078> and we do need to hold more (short) meetings
21:50 <@p-y> hoffie++
21:51 <@vorlon078> and personally i would like more stuff to be discussed via mail
21:51 <@rbu> yes, agreement to all of you (esp. election)
21:51 <@vorlon078> maybe even on gentoo-security@
21:51 <@vorlon078> which would make more of our work transparent
21:51 <@rbu> vorlon078: yes, list!
21:51 <@vorlon078> and could involve more people from outside
21:51 < hoffie> indeed
21:52 < hoffie> i'm certainly interested in helping out on certain things, but i dont want to be forced to be a member of the sec team. i guess there are more people feeling like that ;)
21:52 <@vorlon078> hoffie: yeah
21:52 <@vorlon078> good point
21:52 <@vorlon078> we need to be more open in some cases
21:53 <@p-y> ok, time for bed approaching here
21:53 <@vorlon078> talking about openness... i would like everyone to be reminded that bugs marked as CLASSIFIED should never be opened, or at least it needs serious discussion before they are
21:53 <@p-y> I'll try to think of that script for detecting vuln pkg
21:54 <@p-y> that'll be the occasion to boost my python skillz :)
21:54 <@vorlon078> p-y: might ask on -dev... i remember such a script existed
21:54 < hoffie> p-y: pff, your nick being "py" and not knowing python perfectly? :P
21:54 <@vorlon078> lol
21:54 <@p-y> yeah, I know :D
21:54 <@vorlon078> is there anything else to be discussed?
21:54 <@rbu> no from me
21:55 < hoffie> vorlon078: CLASSIFIED == CONFIDENTIAL/EMBARGOED? or is it sth different
21:55 <@p-y> not that I can think of
21:55 <@vorlon078> hoffie: no... see coord guide
21:55 < hoffie> ok
21:55 < aetius> none from me
21:55 <@vorlon078> classified shall stay closed forevere.... containing mails maybe or such
21:55 <@vorlon078> confidential can be opened at the agreed upon date
21:56 <@vorlon078> then let's consider this meeting closed
21:56 < hoffie> that's why i asked, as this is what i always saw ;)
21:56  * hoffie didnt notice aetius was there as well ;)
21:56 <@rbu> aetius: hahaha
21:56 <@vorlon078> i will upload the log to our proj/ space if nobody objects and send out a summary and stuff
21:56 <@vorlon078> but that might take a while
21:56 <@rbu> aetius: welcome, btw ;-)
21:56 < aetius> I wasn't really, just trying to catch up in spurts while working to fix our tools after bungie changed their site. :\
21:56 <@vorlon078> aetius: yeah... welcome ;)
21:57 <@rbu> bung... who?
21:57 < hoffie> vorlon078: do you have full logs? i.e. were you one of those problems without any connectivity/notebook problems? :p
--- Log closed Mon Jul 14 21:57:11 2008