diff options
Diffstat (limited to 'meetings/logs/20080714-log.txt')
| -rw-r--r-- | meetings/logs/20080714-log.txt | 798 |
1 files changed, 798 insertions, 0 deletions
diff --git a/meetings/logs/20080714-log.txt b/meetings/logs/20080714-log.txt new file mode 100644 index 0000000..b342c69 --- /dev/null +++ b/meetings/logs/20080714-log.txt @@ -0,0 +1,798 @@ +--- 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 |