diff options
author | John Helmert III <ajak@gentoo.org> | 2022-03-21 15:54:55 -0500 |
---|---|---|
committer | John Helmert III <ajak@gentoo.org> | 2022-03-21 15:54:55 -0500 |
commit | c6ab7e754aa05029c069bef6096cbd5632aa4969 (patch) | |
tree | a844f4eb004fa7e09d51e0815dc1c26eecd5c19b /meetings | |
parent | Added sec-meeting-2018-09-02-log (diff) | |
download | security-c6ab7e754aa05029c069bef6096cbd5632aa4969.tar.gz security-c6ab7e754aa05029c069bef6096cbd5632aa4969.tar.bz2 security-c6ab7e754aa05029c069bef6096cbd5632aa4969.zip |
The new files come from:
https://web.archive.org/web/20141222060728if_/http://www.gentoo.org/proj/en/security/meeting-logs/gentoo-security-meeting-2010-09-01-summary.txt
https://web.archive.org/web/20141222054453if_/http://www.gentoo.org/proj/en/security/meeting-logs/gentoo-security-meeting-2010-09-01.txt
https://web.archive.org/web/20141222060730if_/http://www.gentoo.org/proj/en/security/meeting-logs/20080714-log.txt
https://web.archive.org/web/20141222060734if_/http://www.gentoo.org/proj/en/security/meeting-logs/20080714-summary.txt
Signed-off-by: John Helmert III <ajak@gentoo.org>
Diffstat (limited to 'meetings')
-rw-r--r-- | meetings/logs/20080714-log.txt | 798 | ||||
-rw-r--r-- | meetings/logs/20080714-summary.txt | 156 | ||||
-rw-r--r-- | meetings/logs/gentoo-security-meeting-2010-09-01-summary.txt | 112 | ||||
-rw-r--r-- | meetings/logs/gentoo-security-meeting-2010-09-01.txt | 917 |
4 files changed, 1983 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 diff --git a/meetings/logs/20080714-summary.txt b/meetings/logs/20080714-summary.txt new file mode 100644 index 0000000..caaf726 --- /dev/null +++ b/meetings/logs/20080714-summary.txt @@ -0,0 +1,156 @@ +Gentoo Security Project Meeting 2008-07-14 +****************************************** + +Agenda +------ + +1) Project status + * Short overview of the current status of the Gentoo Security Project +2) Recruitment + * What can be done to improve the current situation? +3) Delays in bug resolution/GLSA publication + * Where are the delays located and what can be done about them? +4) GLSA related issues + 4.1) New date format in GLSAs + 4.2) Slot support +5) Handling of CVE identifiers in bugs + * Define a way/ways to specify CVE ids in bugs (title/alias/...). + * Documentation is needed on how to search for CVE ids. + * CVE Compatibility +6) Possible changes to the Vulnerability Policy + 6.1) Insecure creation of temporary files + 6.2) SQL Injection +7) Security support for games + * Should games be fully security-supported or be handled in a different + way than other packages? +8) Any other topic + + +Summary +------- + +ad 1) Project status + - The auditing as well as the kernel security subproject are dead at the + moment. The kernel project should be revived when possible and auditing + could be revived when somebody steps up who is interested in it. Dead + projects should be removed from the project page and/or marked as + inactive. (Discussion of kernel security was postponed at this point.) + - The project is currently suffering a lack of new recruits/... . + +ad 2) Recruitment + - After the cleaning of the list of padawans [1] only one person was left + there and one was willing to come back. Many recruits became inactive only + a short while after they joined. + - It was proposed to give scouts the editbugs priv on bugzilla, so they can + also edit bugs which have not been filed by themselves. Since it is + currently not possible to restrict that privilege to a certain product, a + mentor should look after the edits of his assigned padawan. The privilege + should be given after about of 1 to 2 weeks of active work as a scout. + Infra will have to be contacted about the possibilities to give out + editbugs privilege. + - rbu and mjf will work on new documentation for padawans. + - vorlon will prepare a blog post or an article to invite more people to + help out in the project. + +ad 3) Delays in bug resolution/GLSA publication + - The statistics [2], although possibly not a 100% accurate, show that + currently not even 50% of bugs are closed within the target delays given + by the vulnerability policy [3]. The main delay currently appears to be in + the drafting and reviewing of GLSAs. + - More recruits would help in this area, but the access to the drafting tool + (GLSAMaker) can currently not be given out too early, since it also + contains drafts for embargoed issues. This leads to many recruits leaving + before they even gain access to GLSAMaker. To make earlier contribution of + drafts easier, a new tool is needed. After some discussion about such new + tools, the topic was postponed as no short-term solution is available at + the moment. + +ad 4) GLSA related issues + 4.1) New date format in GLSAs + - The date format currently used in GLSAs is incorrect and the revision + number should not be included in the date, but in an attribute. + - A patch for GLSAMaker as well as a script to convert all current GLSA + files in GLSAMaker and CVS are available. + - A patch for glsa-check has been attached in bugzilla. Possible impacts + of the change to portage need to be determined. + - The change should be announced before it goes live. + 4.2) Slot support + - As a first step towards slot support in GLSAs, portage team requires a + versioning of the DTD/GLSAs. + - The discussion of details of slot support was postponed. A decision is + needed on how to change the DTD to allow for slot support, which then + should be brought up with neysx/docs team to prepare a new DTD version. + Then then the implementation should be discussed with the portage team. + + - It was decided that all changes to the DTD should require versioning and + that such versioning should not be included as a new attribute in the XML + but as a new name for the DTD (glsa.dtd, glsa-2.dtd, ...). + - The change of the date format and the introduction of slot support in the + DTD should occur at the same time. + +ad 5) Handling of CVE identifiers in bugs + - Currently the CVE id of an issue is added to the summary of a bug and + as an alias for the bug. Multiple CVE ids for a single bug are entered in + the summary as e.g. (CVE-2008-{1234,1235,1236,1237}) which makes it + possible to use "CVE-2008 1234" as a search term to find the relevant bug. + Multiple ids in the alias field are not possible and a single bug per CVE + did not appear to be feasible. The method of putting CVE ids in bugs + should be added to the documentation. + - To achieve CVE compatibility at one point, a link needs to be made between + bugs, GLSAs and CVE ids, which needs to be searchable. + - As it is currently not easily possible to find the bug to a certain CVE + id, hoffie will work on a web based tool to allow such a search based on + the data available in SVN [4]. + +ad 6) Possible changes to the Vulnerability Policy + 6.1) Insecure creation of temporary files + 6.2) SQL Injection + + - After a discussion of possible impacts and severity levels for those + vulnerabilities, it was decided not to add a fixed level for these, but to + add a note to the vulnerability policy to explain the possible levels and + the need to determine them case by case. rbu will work on such a note if + nobody else steps up to do so. + +ad 7) Security support for games + - As currently many games are package masked for security reasons [5] and don't + get fixed, a discussion was raised on how to handle vulnerabilities in + games in general. + - Since it was neither wanted to declare games as unsupported by the security + team nor to keep them all marked as ~arch, it would be best to treat games + as other packages, but not to push for removal after masking. This might + need a change in the policies. + - vorlon will look into needed additions or changes to the vulnerability + policy and/or the GLSA coordinators guide. + +ad 8) Any other topic + - It is wanted that vulnerable versions of packages be removed from the + tree when fixed versions are available and stable. Devs should be + informed about this by comments left in the bugs. Also py will try to come + up with a script to identify such packages in the tree. + + - In general the dev manual and quizzes should be reviewed for security + related topics. + + - It would be desirable to have a keyword for security related commits in + the Changelog files. The technical side of this should be discussed with + the portage team. + + - Lead elections will be held at a later time, since several devs are + currently unavailable. + + - Shorter meetings should be held more frequently and mail, especially the + gentoo-security@g.o mailing list, should be used more often. This would + also make the work more transparent and could get more people involved. + + - It was noted again that nobody should open bugs marked as "CLASSIFIED" to + the public, as they might contain private emails for example and only bugs + marked "CONFIDENTIAL" should be opened after the agreed upon time. + + + +[1] <http://www.gentoo.org/security/en/padawans.xml> +[2] <http://dev.gentoo.org/~vorlon/security/stats.xml> +[3] <http://www.gentoo.org/security/en/vulnerability-policy.xml> +[4] <https://overlays.gentoo.org/proj/security/browser/data/CVE/list> +[5] <http://tinyurl.com/66qaq8> diff --git a/meetings/logs/gentoo-security-meeting-2010-09-01-summary.txt b/meetings/logs/gentoo-security-meeting-2010-09-01-summary.txt new file mode 100644 index 0000000..b148bdb --- /dev/null +++ b/meetings/logs/gentoo-security-meeting-2010-09-01-summary.txt @@ -0,0 +1,112 @@ +Security Project Meeting 2010-09-01 +=================================== + +Roll call +--------- + here: + Alex Legler (a3li) + Tony Vroon (chainsaw), padawan + Stefan Behte (craig) + Raphaël Marichez (falco), joined later on during the meeting + Sune Kloppenborg Jeppesen (jaervosz) + Tobias Heinlein (keytoaster) + Pierre-Yves Rofes (py) + Robert Buchholz (rbu) + Robin H. Johnson (robbat2), infrastructure representative + Tim Sammut (underling), padawan + Matthias Geerdsen (vorlon) + missing: + Kurt Lieber (klieber) + Ned Ludd (solar) + + +1. Project status +----------------- +The Gentoo Security team is functional, but running on low flame. There is a +huge backlog (a huge amount of open bugs and GLSAs that still need to be sent) +and due to a small amount of active members not all bugs are filed/handled in a +timely manner and bigger packages (Firefox, Java, etc.) are not easy to draft +GLSAs for for various reasons. + +Some members feel that drafting GLSAs with the old GLSAMaker is a huge PITA. + +Not all recruitment requests by both developers and non-developers have been +handled as well as we want them to, due to limited time and resources. + + +2. Lead election +---------------- +It has been decided that the Gentoo security team's leads are there to do +administrative stuff (like distributing permissions e.g. on Bugzilla), to +ensure progress, to cast deciding votes, and to act as the point of contact for +encrypted mails. + +Robert, Matthias, and Stefan have either opted out of being nominated or not +accepted their nomination due to time issues. Alex and Tobias have been +nominated. + +The team has decided unanimously to continue having two leads, and that those be +Alex and Tobias. + + +3. Population of several mail aliases, bugzilla groups etc. +----------------------------------------------------------- +The following groups/aliases had to be cleaned and updated in order to ensure +that no outdated entries still exist. + + +3.1 CERT mails +It has been decided that all team members who attended the meeting will receive +the CERT mails. Matthias will put a list together and send it to the security +alias before informing CERT. + + +3.2 vendor-sec alias +Due to respect for the group, the team decided to have only a limited number of +people subscribed. As such, everyone has been removed from the alias and only +Alex, Tobias, and Stefan have been put on it. The team agreed to further +evaluate subscribing active members at the next meeting. + + +3.3 "securitymail" group on dev.gentoo.org +The team decided that only the new leads will be allowed to edit mail aliases. + + +3.3 "security" mail alias and "security" group on Bugzilla +The team agreed that every "full" team member should be on/in these. The leads +will have the power to edit them. + + +4. Handling of the current GLSA and bug queues and how to avoid such situations in the future +--------------------------------------------------------------------------------------------- +The new GLSAMaker will ease the team's work in huge parts and its development is +currently of utmost importance. Alex and Tobias have given a summary on the new +GLSAMaker: It's in a near-usable state, the goal is to have our information +integrated better, it will replace the old CVE tracker, it's way easier to +draft minor issues, and permission groups allow for non-team members and new +recruits to help with drafting. + +Alex and Tobias will see to getting a usable beta version of GLSAMaker2 deployed +until Oct 1, 2010, while the rest of the team will try to get some GLSAs out +with the old one. + +The team agreed to send "mini-GLSAs" for minor issues, that is a usual GLSA +with shorter description and impact texts, like we did a few months ago. + + +5. Any other topic +------------------ +In order to be more open to users, Matthias will draft an announcement +explaining our current situation. + +Alex will arrange for a wiki to document todo lists and miscellaneous stuff. + +The team will hold meetings more frequently, every 2 or 3 months has been +suggested. The next meeting will be around mid-October to vote on this and also +to check the progress of GLSAMaker2. + +There is no further need for the position of the infrastructure liasion and it +has been removed. Robin suggested to bug either him or Ned. + +Tobias will merge documentation files from devspaces into our project pages. + diff --git a/meetings/logs/gentoo-security-meeting-2010-09-01.txt b/meetings/logs/gentoo-security-meeting-2010-09-01.txt new file mode 100644 index 0000000..71277eb --- /dev/null +++ b/meetings/logs/gentoo-security-meeting-2010-09-01.txt @@ -0,0 +1,917 @@ +[2010/09/01 20:29:30] @ Log started by gen2 +[2010/09/01 20:29:30] @ Joined channel #gentoo-security +[2010/09/01 20:29:30] @ Topic is "Project Meeting 2010-09-01 18:30 UTC in here | This channel is only for coordinating vulnerabilities and GLSA releases. For an end-user support channel, see #gentoo | http://security.gentoo.org | New recruits: http://www.gentoo.org/security/en/padawans.xml" +[2010/09/01 20:29:30] @ Topic set by vorlon078!~vorlon@gentoo/developer/vorlon on Mon Aug 30 22:16:23 +0200 2010 +[2010/09/01 20:29:30] @ Mode +cntz by kornbluth.freenode.net +[2010/09/01 20:29:38] <vorlon078> bye _Craig_ :P +[2010/09/01 20:29:39] <a3li> three loggers now +[2010/09/01 20:29:41] <a3li> at leat +[2010/09/01 20:29:42] <a3li> *least +[2010/09/01 20:29:52] <_Craig_> I'm against data retention! +[2010/09/01 20:29:53] <p-y> that should be enough :) +[2010/09/01 20:30:01] * _Craig_ logs, too +[2010/09/01 20:30:02] <keytoaster> hi +[2010/09/01 20:30:12] <vorlon078> hi everyone +[2010/09/01 20:30:12] * a3li deletes _Craig_ +[2010/09/01 20:30:27] <vorlon078> since it's time now... could we have a short roll call +[2010/09/01 20:30:30] * vorlon078 is here +[2010/09/01 20:30:30] <Chainsaw> Do we have an agenda? +[2010/09/01 20:30:42] * Chainsaw is present(ly awaiting an agenda link!) +[2010/09/01 20:30:44] <a3li> http://archives.gentoo.org/gentoo-security/msg_69f93c889d9aaeeb3a13d679f1abde8c.xml +[2010/09/01 20:31:12] <underling> I am here, hey folks. +[2010/09/01 20:31:18] <vorlon078> http://dev.gentoo.org/~vorlon/security/meeting-20100901.xml +[2010/09/01 20:31:27] <a3li> underling: great +[2010/09/01 20:31:44] * rbu here +[2010/09/01 20:31:46] * jaervosz is here too +[2010/09/01 20:31:54] <vorlon078> Falco: ping +[2010/09/01 20:31:55] <a3li> if there's anyone who doesn't know underling yet. he's that very active @cisco.com dude who files bugs in bugzilla :) +[2010/09/01 20:31:58] * p-y is here +[2010/09/01 20:33:25] <vorlon078> _Craig_ keytoaster solar: meeting ping +[2010/09/01 20:33:31] <_Craig_> yo +[2010/09/01 20:33:57] <keytoaster> yo +[2010/09/01 20:34:15] <vorlon078> great +[2010/09/01 20:34:30] <vorlon078> so we are more or less complete I guess and ready to start +[2010/09/01 20:35:41] <vorlon078> well +[2010/09/01 20:35:53] <_Craig_> 1) project status +[2010/09/01 20:35:54] <vorlon078> nobody added anything to the proposed agenda +[2010/09/01 20:36:12] <vorlon078> so we should just start and add anything that still comes up to point 5 +[2010/09/01 20:36:33] <vorlon078> could someone give a short overview of where we stand right now +[2010/09/01 20:36:49] <vorlon078> besides the existance of an enormous backlog +[2010/09/01 20:37:12] <_Craig_> Current status from my point of view: we file bugs, but we're slow sometimes. Sometimes we miss bugs. +[2010/09/01 20:37:25] <_Craig_> Things like firefox and browsers generally are a huge PITA +[2010/09/01 20:37:49] <_Craig_> lots of bugs, hard to trace, no one really likes doing that kind of work +[2010/09/01 20:38:11] <Chainsaw> The Mozilla trademark issues don't help. +[2010/09/01 20:38:37] <_Craig_> and there are times when no one files anything, because we're busy, e.g. with studies +[2010/09/01 20:38:44] <p-y> or real life +[2010/09/01 20:38:46] <vorlon078> yeah +[2010/09/01 20:39:04] <_Craig_> as the team is rather small, it can quickly happen that no one does anything for a week on critical bugs. +[2010/09/01 20:39:07] <vorlon078> so the problem is not just drafting/reviewing but also filing bugs in time +[2010/09/01 20:39:17] <p-y> what about the new glsamaker? +[2010/09/01 20:39:31] <_Craig_> IMHO, yes. High-priority gets attention, but lower ones not always. +[2010/09/01 20:39:32] <a3li> p-y: maybe we talk about that later on +[2010/09/01 20:39:35] <p-y> ok +[2010/09/01 20:39:58] <rbu> _Craig_: but that's alright then. use the time you have as wise as you can. :-) +[2010/09/01 20:40:00] <a3li> in terms of bugs we usually do the easy stuff first. but we're already running at capacity while dealing with the easy stuff. +[2010/09/01 20:40:05] <a3li> so the hard things don't get done. +[2010/09/01 20:40:20] <_Craig_> (like the gazillion of browser bugs) +[2010/09/01 20:40:25] <a3li> on a larger scale, we're scratching on the surface of the amount of bugs and advisories we need to send +[2010/09/01 20:40:33] <vorlon078> yeah +[2010/09/01 20:40:37] <rbu> what is easy vs. hard? firefox, etc.. i heard. what else? +[2010/09/01 20:40:50] <_Craig_> webkit +[2010/09/01 20:40:50] <a3li> and with the current active (not on the list) team, we're not getting the numbers lower, we're rather growing further apart from 0 open bugs +[2010/09/01 20:40:51] <p-y> php, java... +[2010/09/01 20:41:21] <rbu> ok.. so large packages are not easy. because they have so many issues? +[2010/09/01 20:41:35] <a3li> it's the quantity as well as the list of affected packages +[2010/09/01 20:41:36] <vorlon078> sidenote: I would like to add team membership to topic 4 +[2010/09/01 20:42:07] <a3li> rbu: as in 1 CVE affects xulrunner, firefox, thunderbird, seamonkey and several versions of these +[2010/09/01 20:42:12] <a3li> and that >100 times +[2010/09/01 20:42:20] <_Craig_> or sometimes not all bugs get fixed, so we cannot send the glsa yet. +[2010/09/01 20:42:27] <keytoaster> rbu: not only because of many issues, but also because some issues are fixed in one version, some in another only, some in both +[2010/09/01 20:42:43] <a3li> and more importantly, bugs that are not readily researched are completely left aside. +[2010/09/01 20:42:49] <p-y> and seometimes it's hard to know whether it's fixed or not +[2010/09/01 20:43:17] <keytoaster> ok, so our job sucks because most upstreams suck :) +[2010/09/01 20:43:24] <p-y> heh +[2010/09/01 20:43:37] <rbu> are we gathering problems first, and discussing solutions later, or do we do both in parallel? +[2010/09/01 20:43:42] <vorlon078> so in summary we are very low on active ressources and have some more trouble with the usual troublesome packages +[2010/09/01 20:43:55] <rbu> keytoaster: i guess because upstream sucks, our job exists +[2010/09/01 20:44:23] <vorlon078> according the the very short agenda I proposed this is the short status overview and we look at solutions later ;) +[2010/09/01 20:44:41] <rbu> vorlon078: full ack +[2010/09/01 20:44:58] <rbu> what's the status besides bug reporting? +[2010/09/01 20:45:34] <a3li> it's the same wrt GLSA sending and CVE tracking. +[2010/09/01 20:45:46] <keytoaster> a huge backlog with drafting, because noone wants to draft with the old glsamaker anymore +[2010/09/01 20:45:55] <keytoaster> i personally am waiting till the new one is ready +[2010/09/01 20:46:15] <a3li> all-in-all I'd say we're functional, but running on low flame. +[2010/09/01 20:46:19] <Chainsaw> I must admit, I was shown the glsamaker and it made me lose the will to live. +[2010/09/01 20:46:43] <p-y> Chainsaw: the interface, or the backlog? +[2010/09/01 20:46:52] <keytoaster> both probably +[2010/09/01 20:46:53] <Chainsaw> p-y: Both. They combine. +[2010/09/01 20:47:36] <vorlon078> so actually it seems we have the problems we always had, just a even worse this time +[2010/09/01 20:47:39] <keytoaster> we have some new functions in the new glsamaker to quickly draft all those old, low severity issues within minutes +[2010/09/01 20:47:48] <keytoaster> that would decrease the backlog partly +[2010/09/01 20:48:19] <Chainsaw> Could we adopt a rule that we kick out any advisory that is no longer relevant because newer software has already been stabled for another GLSA? +[2010/09/01 20:48:33] <vorlon078> are there any status related questions left? else we should discuss the possible backlog soluions later on +[2010/09/01 20:48:33] <Chainsaw> (This kept happening for Asterisk) +[2010/09/01 20:48:42] <a3li> vorlon078: yes. I think that is due to the reason that we're basically three active people plus one trainee +[2010/09/01 20:48:52] <keytoaster> Chainsaw: people might still be running the vulnerable software +[2010/09/01 20:49:01] <keytoaster> oh, for another GLSA +[2010/09/01 20:49:04] <keytoaster> hrm.. +[2010/09/01 20:49:15] <keytoaster> well, that's just corner cases i guess +[2010/09/01 20:50:00] <vorlon078> then I believe we should get on to topic 2 +[2010/09/01 20:50:06] <keytoaster> yes. +[2010/09/01 20:50:07] <vorlon078> if nobody objects +[2010/09/01 20:50:24] <rbu> one question still +[2010/09/01 20:50:34] <rbu> what about new recruits, team maintenance? +[2010/09/01 20:50:45] <rbu> what is the status there +[2010/09/01 20:51:01] <a3li> I started working with Chainsaw, but I've sent him to the council where his works is just as needed. +[2010/09/01 20:51:01] <keytoaster> we had a few requests from different people, both devs and non-devs +[2010/09/01 20:51:20] <keytoaster> those non-devs never returned because we just didn't have enough time to train them +[2010/09/01 20:51:28] <keytoaster> (apart from underling :) +[2010/09/01 20:51:36] <a3li> underling is doing a good job with filing bugs, I shall introduce him to the magic of drafting soon +[2010/09/01 20:51:43] <rbu> good +[2010/09/01 20:51:46] <vorlon078> yeah +[2010/09/01 20:51:58] <_Craig_> keytoaster: chiiph got trained a bit too, but stopped filing. +[2010/09/01 20:51:58] <rbu> underling: sounds great what you do, i saw some bugmail +[2010/09/01 20:52:05] <rbu> porps +[2010/09/01 20:52:09] <keytoaster> _Craig_: yes, that's my fault too +[2010/09/01 20:52:18] <underling> rbu: thanks, I am looking forward to "magic" +[2010/09/01 20:52:25] <keytoaster> i'll ask him again when the new glsamaker is done +[2010/09/01 20:52:46] <a3li> keytoaster: it'll be never done, just v1.0 :p +[2010/09/01 20:52:51] <rbu> vorlon078: feel free to go to #2 then from my side +[2010/09/01 20:52:52] <chiiph> keytoaster: well... not really... I'm with my hands full with other things apart from gentoo atm... +[2010/09/01 20:52:54] <keytoaster> yeah yeah +[2010/09/01 20:53:01] <keytoaster> chiiph: oh, ok then :( +[2010/09/01 20:53:01] <vorlon078> ok +[2010/09/01 20:53:09] <vorlon078> then lets get to topic 2 +[2010/09/01 20:53:15] <chiiph> keytoaster: but don't count me out just yet... +[2010/09/01 20:53:25] <vorlon078> lead election, simply because it is supposed to happen every year +[2010/09/01 20:54:05] <keytoaster> i for one don't think we even need leads +[2010/09/01 20:54:16] <Chainsaw> keytoaster: Someone has to cast the deciding voice. +[2010/09/01 20:54:20] <vorlon078> it has always been more or less a formality for us +[2010/09/01 20:54:25] <rbu> keytoaster: hah.. you're not serious? +[2010/09/01 20:54:27] <Chainsaw> keytoaster: Running things by committee will turn you into Debian. +[2010/09/01 20:54:37] <a3li> no swearing please :) +[2010/09/01 20:54:38] <keytoaster> ok, then what have our leads done in the last two years? +[2010/09/01 20:54:39] <vorlon078> and in rare cases decisions have to be made +[2010/09/01 20:54:43] <p-y> keytoaster: at least for the CERT mails +[2010/09/01 20:54:45] <keytoaster> i don't recall there has been any decision +[2010/09/01 20:54:48] <p-y> and that kind of stuff +[2010/09/01 20:55:29] <Chainsaw> keytoaster: The best managers are the ones you don't see (micro!)managing stuff all the time. +[2010/09/01 20:55:44] <jaervosz> back then leads just meant taking in the lead in doing the hard work and ensuring some progress +[2010/09/01 20:55:45] <p-y> keytoaster: not that much, I have to admit :( +[2010/09/01 20:55:57] <vorlon078> well there used to be administrative stuff like rights for bugzie, v-sec etc. +[2010/09/01 20:56:00] <keytoaster> p-y: it wasn't meant to be an insult +[2010/09/01 20:56:04] <p-y> I know +[2010/09/01 20:56:08] <p-y> but still +[2010/09/01 20:56:10] <keytoaster> more like there simply was no need for them +[2010/09/01 20:56:17] <vorlon078> leads were the points of contact for cert and encrypted mail etc +[2010/09/01 20:56:35] <rbu> Chainsaw: we don't need micro management. but we also need someone who understands the state of the group, and keeps them together +[2010/09/01 20:56:42] <keytoaster> vorlon078: ok, that's about it +[2010/09/01 20:56:49] <a3li> rbu: ++ +[2010/09/01 20:56:54] <rbu> i do not feel i can currently do that, so i'd be happy if new (old) faces could step up +[2010/09/01 20:57:02] <rbu> old=known +[2010/09/01 20:57:16] <vorlon078> lol +[2010/09/01 20:57:26] <vorlon078> anyway +[2010/09/01 20:57:37] <vorlon078> is there anyone willing and able to do it? +[2010/09/01 20:57:38] <a3li> well if you want a newish face, I'd be happy to help out +[2010/09/01 20:57:46] <keytoaster> me too +[2010/09/01 20:57:51] * Chainsaw votes for a3li +[2010/09/01 20:57:57] <keytoaster> simply because we're the few active people +[2010/09/01 20:57:58] * _Craig_ points at a3li, too +[2010/09/01 20:58:29] <rbu> just don't do it like py and me did.. afer the vote, disappear! +[2010/09/01 20:58:34] <vorlon078> I would have said me too, but since I can't guarantee a fixed amount of dedicated time yet, that would not be the best choice +[2010/09/01 20:58:41] <p-y> rbu++ +[2010/09/01 20:59:15] <rbu> ok.. anyone else who wants to be nominated? +[2010/09/01 20:59:29] <vorlon078> Chainsaw and a3li so far +[2010/09/01 20:59:33] <keytoaster> i would nominate craig on top of that +[2010/09/01 20:59:40] <_Craig_> Oo +[2010/09/01 20:59:41] <Chainsaw> vorlon078: What? No. keytoaster & a3li. +[2010/09/01 20:59:44] <a3li> vorlon078: you mean keytoaster and me :) +[2010/09/01 20:59:51] <vorlon078> oops type and tab completions, sorry +[2010/09/01 21:00:03] <Chainsaw> The sound herd pulled that trick last time. +[2010/09/01 21:00:06] <vorlon078> so keytoaster and a3li with _Craig_ on top +[2010/09/01 21:00:12] * Chainsaw is not falling for that again +[2010/09/01 21:00:13] <a3li> erm *cough* +[2010/09/01 21:01:15] <a3li> so anyone else? +[2010/09/01 21:01:56] <rbu> ETIMEOUT +[2010/09/01 21:02:01] * Chainsaw points at a3li +[2010/09/01 21:02:11] <vorlon078> _Craig_: want to be nominated? +[2010/09/01 21:02:56] <rbu> do we have one or two votes per team member? +[2010/09/01 21:03:09] <vorlon078> next question... how many leads +[2010/09/01 21:03:11] <_Craig_> uhm, I'd prefer being a full dev before leading anything +[2010/09/01 21:03:14] <a3li> we did some combined vote last time +[2010/09/01 21:03:18] <vorlon078> we used to have 2 and had 3 for some time too +[2010/09/01 21:03:29] <_Craig_> let's have 2 votes +[2010/09/01 21:03:41] <_Craig_> should we vote on that? ;) +[2010/09/01 21:03:55] * keytoaster votes for 2 votes +[2010/09/01 21:04:00] <vorlon078> arghhhhh +[2010/09/01 21:04:06] * p-y seconds keytoaster +[2010/09/01 21:04:15] <rbu> _Craig_: you do not have to be an ebuild dev to be a team lead +[2010/09/01 21:04:23] <vorlon078> rbu: ++ +[2010/09/01 21:05:13] <rbu> _Craig_: in fact, it may even help you keep focus not to be distracted by latest release of $software +[2010/09/01 21:05:33] <vorlon078> so if we simply have 2 or 3 nominees we could vote for all en bloc +[2010/09/01 21:06:11] <vorlon078> if nobody objects to that, or give votes and take the 2? with the highest amount of votes +[2010/09/01 21:06:12] <_Craig_> rbu: I know that, but still. I'm know I'm just too busy right now and for the next months. +[2010/09/01 21:06:40] <_Craig_> So, next time. ;) +[2010/09/01 21:07:34] <rbu> _Craig_: too bad.. but i appreciate your anticipation +[2010/09/01 21:07:35] <vorlon078> ok +[2010/09/01 21:07:40] <vorlon078> yeah +[2010/09/01 21:08:01] <_Craig_> so, two votes. +[2010/09/01 21:08:04] <vorlon078> then if nobody objects I say we simply vote on accepting the two nominees +[2010/09/01 21:08:12] <rbu> vorlon078: ++ +[2010/09/01 21:08:13] <a3li> yes. one vote +[2010/09/01 21:08:17] <p-y> yep +[2010/09/01 21:08:20] <_Craig_> okok +[2010/09/01 21:08:24] <rbu> i want a3li and keytoaster as leads +[2010/09/01 21:08:31] <a3li> _Craig_: what would happen if one would be not accepted? :) +[2010/09/01 21:08:32] <_Craig_> me, too. +[2010/09/01 21:08:44] <vorlon078> I vote for a3li and keytoaster as well +[2010/09/01 21:08:49] <p-y> me too +[2010/09/01 21:08:55] <jaervosz> me too:) +[2010/09/01 21:09:02] <_Craig_> a3li: damocles sword will hit someone. +[2010/09/01 21:09:06] <keytoaster> so can a3li and me vote for ourselves? +[2010/09/01 21:09:11] <Chainsaw> I confirm, a3li as primary, keytoaster as secondary. +[2010/09/01 21:09:13] <vorlon078> sure you can +[2010/09/01 21:09:46] <rbu> you should! or do you not trust yourselves? +[2010/09/01 21:09:56] <keytoaster> ok, i vote for a3li and me :) +[2010/09/01 21:10:13] <a3li> I vote against not being team lead together with keytoaster +[2010/09/01 21:10:23] <vorlon078> then so it will be +[2010/09/01 21:10:23] <keytoaster> shit, now we're screwed +[2010/09/01 21:10:33] <keytoaster> oh wait, "against not" +[2010/09/01 21:10:39] <a3li> haha +[2010/09/01 21:10:44] <keytoaster> you got me there :( +[2010/09/01 21:11:00] <_Craig_> haha +[2010/09/01 21:11:00] <vorlon078> i count many votes for and none against a3li and keytoaster as the new team leads +[2010/09/01 21:11:13] <rbu> congrats +[2010/09/01 21:11:17] <Chainsaw> vorlon078: "Unanimous" is shorter. +[2010/09/01 21:11:19] <a3li> well I want to thank our two predecessors. especially rbu for always replying to my enquiries about the content of the CERT emails I couldn't read :) +[2010/09/01 21:11:38] <keytoaster> ++ +[2010/09/01 21:11:39] <vorlon078> congrats a3li and keytoaster +[2010/09/01 21:11:50] <vorlon078> in case you accept the voting of course +[2010/09/01 21:11:52] <vorlon078> ;-) +[2010/09/01 21:11:56] <rbu> first action duty as new leads: buy old leads beer +[2010/09/01 21:12:01] <p-y> ++ +[2010/09/01 21:12:16] <a3li> rbu: sure, if you show up here :) +[2010/09/01 21:12:20] <vorlon078> and two bear for the leads before the old leads +[2010/09/01 21:12:22] <_Craig_> rbu: ...if they show up and file bugs :P +[2010/09/01 21:12:26] <vorlon078> beer even +[2010/09/01 21:12:29] <keytoaster> bear +[2010/09/01 21:12:32] <a3li> vorlon078: here, have a pedobear +[2010/09/01 21:12:33] <keytoaster> sec, gonna shoot some +[2010/09/01 21:12:46] <vorlon078> yeah just keep hitting +[2010/09/01 21:12:58] <vorlon078> :-P +[2010/09/01 21:13:00] <vorlon078> ok +[2010/09/01 21:13:04] <a3li> agenda++; +[2010/09/01 21:13:09] <vorlon078> if there are no objections again, then lets go on +[2010/09/01 21:13:21] <vorlon078> # Population of several mail aliases, bugzilla groups etc. +[2010/09/01 21:13:56] <vorlon078> we need to go through the v-sec alias to see, cert mails and bugzilla security group +[2010/09/01 21:13:58] <keytoaster> what is meant by that exactly? +[2010/09/01 21:14:01] <vorlon078> -to see +[2010/09/01 21:14:24] <vorlon078> who is supposed to be receiving cert mails at the moment +[2010/09/01 21:14:34] <vorlon078> who should be on v-sec, which is pretty crowded right now +[2010/09/01 21:14:50] <a3li> To: Matthias Geerdsen <vorlon@gentoo.org>, Raphael Marichez <falco@gentoo.org>, Pierre-Yves Rofes <py@gentoo.org>, Robert Buchholz <rbu@gentoo.org> +[2010/09/01 21:14:51] <vorlon078> and who should be on the bugzilla group for security bugs and be able to set that membership +[2010/09/01 21:14:54] <a3li> Cc: Gentoo Security Team <security@gentoo.org>, CERT Coordination Center <cert@cert.org> +[2010/09/01 21:14:57] <a3li> that is CERT as-is +[2010/09/01 21:15:02] <keytoaster> ok, cert: is it policy by them that only the leads (or only 2?) people may receive the mails? +[2010/09/01 21:15:16] <_Craig_> who should be on the bugzilla group for security bugs and be able to set that membership << leads. +[2010/09/01 21:15:19] <vorlon078> keytoaster: no, I made the contact a few years ago +[2010/09/01 21:15:32] <keytoaster> any reason against having everyone receive them? +[2010/09/01 21:15:32] <vorlon078> and there should be no such policy from cert side +[2010/09/01 21:15:47] <_Craig_> who should be on v-sec << seniors (+1 years active in the security team) +[2010/09/01 21:15:59] <keytoaster> i mean, the entire team deals with confidential stuff, not receiving the cert mails won't make a difference wrt trustworthyness +[2010/09/01 21:16:02] <a3li> maybe let's focus on one list +[2010/09/01 21:16:04] <a3li> so CERT forst +[2010/09/01 21:16:05] <a3li> *first +[2010/09/01 21:16:10] <vorlon078> a3li: ++ +[2010/09/01 21:16:17] <a3li> the problem with CERT is that they GPG sign +[2010/09/01 21:16:23] <a3li> so we cannot just update the list of recievers +[2010/09/01 21:16:27] <vorlon078> exactly +[2010/09/01 21:16:49] <vorlon078> a few more people would be good, so that we avoid forwarding in cleartext +[2010/09/01 21:17:32] <vorlon078> who actually would like to get the mails directly from cert? +[2010/09/01 21:17:35] <keytoaster> a few more on top of the ones that already receive them? +[2010/09/01 21:17:38] <p-y> at least the new leads should +[2010/09/01 21:17:54] <vorlon078> sorry for my sucky grammar and spelling today, pretty tired +[2010/09/01 21:18:01] <vorlon078> p-y: agreed +[2010/09/01 21:18:38] <rbu> craig and chainsaw could alse see them. i see no point in leaving them out +[2010/09/01 21:18:50] <keytoaster> rbu++ +[2010/09/01 21:18:53] <keytoaster> that's my point +[2010/09/01 21:18:55] <rbu> i'd rather exclude myself from that list if they object to sending to 8 people +[2010/09/01 21:19:26] <vorlon078> then let's ask the other way around, is there anyone who does not want to get the cert mails +[2010/09/01 21:20:17] <vorlon078> then I would just ask them to add everyone who is attending this meeting and a member of the security project +[2010/09/01 21:20:20] <keytoaster> hrm, perhaps we should start by talking about who "the team" is. there are some people on the project page that have a) been inactive for years and b) not shown up to the meeting +[2010/09/01 21:20:33] <keytoaster> cool, we have the same thoughts there :) +[2010/09/01 21:20:55] <vorlon078> then let me add ...at the end of this meeting +[2010/09/01 21:21:01] <vorlon078> is that alright for everyone +[2010/09/01 21:21:07] <rbu> vorlon078: ++ +[2010/09/01 21:21:09] <_Craig_> yo +[2010/09/01 21:21:10] <p-y> yep +[2010/09/01 21:21:17] <vorlon078> i will put a list together and send it on the security alias before sending to cert +[2010/09/01 21:21:19] <keytoaster> yup +[2010/09/01 21:21:27] <keytoaster> good +[2010/09/01 21:21:36] <a3li> wasn't that the job of the leads? :) +[2010/09/01 21:21:40] <a3li> vorlon078: ^ +[2010/09/01 21:22:24] <vorlon078> well job of old leads is to get people on the cert list +[2010/09/01 21:22:32] <vorlon078> :) +[2010/09/01 21:22:41] <a3li> well. if you want to do it, do it. +[2010/09/01 21:22:44] <rbu> job of the lead is making sure things get done. not necessarily doing them ;-) +[2010/09/01 21:23:00] <a3li> okay, so no pointing at tobias and me for not doing our job then :) +[2010/09/01 21:23:21] <jaervosz> rbu: exactly +[2010/09/01 21:23:26] <vorlon078> I simply said I would do it, since I am a known contact for cert +[2010/09/01 21:23:31] <vorlon078> anyway +[2010/09/01 21:23:34] <vorlon078> lets get on +[2010/09/01 21:23:37] <vorlon078> v-sec alias +[2010/09/01 21:23:42] <a3li> vendor-sec : rbu,py,falco,jaervosz,vorlon,a3li +[2010/09/01 21:23:51] <rbu> get me off +[2010/09/01 21:23:55] <vorlon078> ah, I thought there were more +[2010/09/01 21:24:01] <a3li> I'd like at least keytoaster to be there as well +[2010/09/01 21:24:08] <rbu> there should be 2-4 active people on there +[2010/09/01 21:24:11] <a3li> and falco off before anyone else +[2010/09/01 21:24:12] <vorlon078> if you don't mind I would like to stay on the alias +[2010/09/01 21:24:18] <keytoaster> and _Craig_ on, if he wants +[2010/09/01 21:24:19] <vorlon078> planning to be more active anyway +[2010/09/01 21:24:33] <keytoaster> vorlon078: good +[2010/09/01 21:24:50] <vorlon078> if it is a problem for anyone, I don +[2010/09/01 21:24:56] <vorlon078> 't mind if you want to get me off the list +[2010/09/01 21:24:57] <_Craig_> vendorsec: me too, if possible. +[2010/09/01 21:25:02] <jaervosz> i'm hoping to be more active as well, but can be removed if needed +[2010/09/01 21:25:10] <a3li> a3li,keytoaster,vorlon,X +[2010/09/01 21:25:10] <p-y> jaervosz++ +[2010/09/01 21:25:37] <vorlon078> then I would say current alias -falco +craig +[2010/09/01 21:25:47] <_Craig_> :) +[2010/09/01 21:26:31] <vorlon078> any objections? +[2010/09/01 21:26:33] <p-y> and keytoaster? +[2010/09/01 21:26:38] <a3li> yeah +[2010/09/01 21:26:39] <keytoaster> oh, right +[2010/09/01 21:26:40] <vorlon078> ah yeah of course +[2010/09/01 21:26:43] <keytoaster> p-y: good catch +[2010/09/01 21:26:47] <p-y> heh :) +[2010/09/01 21:27:00] <a3li> so rbu says max 4 people +[2010/09/01 21:27:03] <a3li> we're at 6 already +[2010/09/01 21:27:09] <a3li> with keytoaster and craig 7 +[2010/09/01 21:27:13] <vorlon078> rbu,py,jaervosz,vorlon,a3li,keytoaster,craig +[2010/09/01 21:27:15] <a3li> (and falco removed) +[2010/09/01 21:27:19] <keytoaster> is that rbu's opinion or policy vendor-sec-wise? +[2010/09/01 21:27:35] <vorlon078> v-sec would like to keep it low at least +[2010/09/01 21:27:48] <vorlon078> i don't know the original deal +[2010/09/01 21:28:47] <rbu> i think hardly any distro has so many people on the list. i don't think there's a policy, i rather feel that with the "state" of the list (you know what i mean) there should really be a limited number of people on there +[2010/09/01 21:28:59] <keytoaster> vorlon078: well, they can assume that we'd leak it otherwise anyway :) +[2010/09/01 21:29:10] <vorlon078> rbu is right though +[2010/09/01 21:29:49] <jaervosz> yeah rbu is right +[2010/09/01 21:30:02] @ robbat2|na joined channel #gentoo-security +[2010/09/01 21:30:06] <jaervosz> at least just remove me and let the proven active ppl on the alias +[2010/09/01 21:30:15] <rbu> just as a sidenote.. i'm currently considering whether i can put any time into gentoo security anymore or not. and if i want to do more, there's plenty work outside of vendor sec +[2010/09/01 21:30:16] <robbat2|na> solar, you want to be sec team infra contact? +[2010/09/01 21:30:31] <jaervosz> if devs go awol for some time just replace them with active devs +[2010/09/01 21:30:56] <a3li> rbu: :( but thanks for being specific +[2010/09/01 21:31:13] <robbat2|na> re infra contact, what all do you need from me? how's the new glsamaker that a3li was working on?\ +[2010/09/01 21:31:22] <a3li> robbat2|na: later on the agenda +[2010/09/01 21:31:39] <p-y> robbat2|na: we're in the middle of a meeting +[2010/09/01 21:31:44] <a3li> robbat2|na: and I think there's a special group for editing the security aliases. keytoaster and I would like access as new team leads +[2010/09/01 21:31:47] <keytoaster> my fault, i ordered him here :) +[2010/09/01 21:31:55] <robbat2|na> keytoaster asked me here re infra contact +[2010/09/01 21:32:07] <rbu> robbat2|na: i guess the main question is.. who is klieber? is there a point in having him as infra liaison? +[2010/09/01 21:32:14] <keytoaster> robbat2|na: lol +[2010/09/01 21:32:17] <keytoaster> err +[2010/09/01 21:32:19] <keytoaster> rbu: lol +[2010/09/01 21:32:26] <vorlon078> heh +[2010/09/01 21:32:30] <robbat2|na> klieber's still nominally infra, but hasn't been seen in ages, and potentially retirable +[2010/09/01 21:32:49] <vorlon078> klieber was also one of the founders of the sec team if i remember right +[2010/09/01 21:32:49] <robbat2|na> that's why I was asking what you need out of an infra liaison +[2010/09/01 21:32:55] <vorlon078> but i haven't seen him for years +[2010/09/01 21:33:05] <robbat2|na> as if he hasn't been around, and you haven't need anything from him, does the position even need to exist? +[2010/09/01 21:33:20] <keytoaster> i don't think so +[2010/09/01 21:33:23] <vorlon078> robbat2|na: I don't believe that job is well defined +[2010/09/01 21:33:30] <robbat2|na> if it does, what do you need from the person? +[2010/09/01 21:33:40] <rbu> i think we just cc'ed you and solar anyway if infra needs to act on a confidential bug +[2010/09/01 21:33:46] <keytoaster> we basically just need him for shell access ont he glsamaker box +[2010/09/01 21:33:56] <vorlon078> we used to cc someone from infra on confidential bugs relevant for infra +[2010/09/01 21:34:22] <vorlon078> keytoaster: leads used to have shell on the current infra box +[2010/09/01 21:34:29] <robbat2|na> just drop the position, and CC me/solar +[2010/09/01 21:34:34] <vorlon078> robbat2|na: agreed +[2010/09/01 21:34:37] <robbat2|na> other infra needs are pretty stock +[2010/09/01 21:34:48] <keytoaster> ok, agreed +[2010/09/01 21:35:43] <robbat2|na> i'll lurk here now, for the new glsamaker stuff later +[2010/09/01 21:35:43] <a3li> good. +[2010/09/01 21:35:49] <a3li> okay. +[2010/09/01 21:35:50] <vorlon078> if there are no objections we will then do as robbat2|na just proposed +[2010/09/01 21:35:53] <robbat2|na> ping if you need me +[2010/09/01 21:36:03] <vorlon078> thanks robbat2|na +[2010/09/01 21:36:07] <a3li> vorlon078: ack +[2010/09/01 21:36:08] <vorlon078> then lets get back to v-sec +[2010/09/01 21:36:12] <keytoaster> good +[2010/09/01 21:36:50] <vorlon078> we proposed "rbu,py,jaervosz,vorlon,a3li,keytoaster,craig" but that was too many +[2010/09/01 21:37:03] <keytoaster> so let's divide that into two groups: 1) people that we want to have there for sure, and 2) people who can still be on there if allowed +[2010/09/01 21:37:22] <a3li> I think on there for sure would be keytoaster, vorlon and me +[2010/09/01 21:37:26] * jaervosz is 2 unfortunately +[2010/09/01 21:37:36] <vorlon078> and do we actually want to discuss the names on that alias publicly? +[2010/09/01 21:37:46] <a3li> it's publically visible for any dev +[2010/09/01 21:37:47] <jaervosz> vorlon078: we already kind of did that.... +[2010/09/01 21:37:56] <vorlon078> i know ;-) +[2010/09/01 21:37:58] <rbu> vorlon078: lol... too late +[2010/09/01 21:38:03] <vorlon078> i am for transparency anyways +[2010/09/01 21:38:03] <jaervosz> vorlon078: so unless you want to recruit a completely new team... +[2010/09/01 21:38:10] <a3li> we just rename +[2010/09/01 21:38:13] @ a3li is now known as a4li +[2010/09/01 21:38:14] <a4li> see? +[2010/09/01 21:38:16] <vorlon078> cool +[2010/09/01 21:38:17] <p-y> lol +[2010/09/01 21:38:22] <jaervosz> lol +[2010/09/01 21:38:37] <vorlon078> for security reasons the team's nicknames have to be changed weekly +[2010/09/01 21:38:45] <a4li> oh my, hopefully that's a long long +[2010/09/01 21:38:47] <vorlon078> sorry for the interruption +[2010/09/01 21:38:50] <a4li> or else I'll overflow soon :( +[2010/09/01 21:38:50] <rbu> 1) a3li,keytoaster,craig +[2010/09/01 21:39:11] <vorlon078> yep +[2010/09/01 21:39:24] <a4li> I think we should be able to allow 2 people from the 2) group +[2010/09/01 21:39:36] <a4li> or we could assign those later +[2010/09/01 21:39:50] <a4li> let's say in X months, after you've all had a chance to see how much time you can spend with gentoo sec +[2010/09/01 21:40:26] @ a4li is now known as a3li +[2010/09/01 21:40:27] <rbu> or "when you made the glsa backlog half its size" +[2010/09/01 21:40:38] <_Craig_> we can still try getting everyone in. +[2010/09/01 21:40:41] <a3li> I think sending that mozilla GLSA should be even enough :) +[2010/09/01 21:40:43] <p-y> a3li: that sounds reasonable +[2010/09/01 21:41:39] <jaervosz> a3li: sounds reasonable +[2010/09/01 21:41:55] <rbu> _Craig_: it's really not a question of getting people in. we administrate who is in and who is out. it's rather a question of ... let's say respect (?) to the group +[2010/09/01 21:42:14] <vorlon078> besides +[2010/09/01 21:42:25] <vorlon078> v-sec likes people on the list to be active members +[2010/09/01 21:42:31] <vorlon078> on the list tha tis +[2010/09/01 21:42:57] <vorlon078> ok +[2010/09/01 21:43:33] <vorlon078> so for now we put a3li keytoaster and _Craig_ +[2010/09/01 21:44:10] <vorlon078> btw, it would be good to inform v-sec of changes on the alias, others do that too +[2010/09/01 21:44:18] <a3li> yes. +[2010/09/01 21:44:29] <a3li> I'd say let's talk about the other spots around christmas? +[2010/09/01 21:44:34] <a3li> three months should be reasonable +[2010/09/01 21:44:48] <vorlon078> a3li: I wanted to talk about a date for the next meeting in the end anyways +[2010/09/01 21:44:51] <vorlon078> and regular meetings +[2010/09/01 21:45:21] <vorlon078> are there any objections to the above change for the vendor-sec alias? +[2010/09/01 21:45:27] <a3li> no +[2010/09/01 21:45:29] <keytoaster> no +[2010/09/01 21:45:45] <jaervosz> no +[2010/09/01 21:46:21] <vorlon078> alright +[2010/09/01 21:46:43] <keytoaster> btw, is anyone gonna write a meeting summary? +[2010/09/01 21:46:49] <keytoaster> if no, i'd do that +[2010/09/01 21:46:59] <vorlon078> keytoaster: good, then you do it ;-) +[2010/09/01 21:47:02] <vorlon078> otherwise i would have +[2010/09/01 21:47:10] <Chainsaw> No objections. +[2010/09/01 21:47:21] <keytoaster> ok +[2010/09/01 21:47:38] <a3li> I'll do the v-s notification and alias changing +[2010/09/01 21:47:42] <Chainsaw> I'm happy with how I'm kept in the loop on everything; I realise I'm not the most active person for security right now. +[2010/09/01 21:47:43] <vorlon078> a3li: keytoaster then I would say go ahead and ask infra to change the alias +[2010/09/01 21:47:54] <keytoaster> vorlon078: i think we can change the alias ourselves +[2010/09/01 21:48:01] <keytoaster> err, the alias +[2010/09/01 21:48:04] <Chainsaw> If it's relevant to my interests I trust someone will forward it to me :) +[2010/09/01 21:48:05] <keytoaster> sorry, i was thinking bugzilla +[2010/09/01 21:48:13] <a3li> robbat2|na: can you add keytoaster and me to the securitymail group on pecker? +[2010/09/01 21:48:32] <vorlon078> a3li: thats not enough, at least it used not to be +[2010/09/01 21:48:51] <a3li> maybe robbat2|na can make it be enough? :) +[2010/09/01 21:48:51] <keytoaster> well, we can edit the alias file then :) +[2010/09/01 21:49:00] <vorlon078> argh +[2010/09/01 21:49:27] <vorlon078> vendor-sec can only be edited by infra afaict/afaik +[2010/09/01 21:49:33] <robbat2|na> ok, you should be able to edit all aliases in /var/mail/alias/security/ now (after you cycle login to get new groups) +[2010/09/01 21:49:33] <vorlon078> that is not the worst thing i guess +[2010/09/01 21:49:41] <robbat2|na> i can move vendor-sec alias if you want? +[2010/09/01 21:50:01] <a3li> robbat2|na: please do +[2010/09/01 21:50:14] <robbat2|na> done +[2010/09/01 21:50:14] @ Ford_Prefect joined channel #gentoo-security +[2010/09/01 21:50:20] <a3li> gracias +[2010/09/01 21:50:41] <vorlon078> securitymail group currently consists of: solar,vorlon,falco,py,rbu,keytoaster,a3li +[2010/09/01 21:51:52] <p-y> we should add _Craig_ +[2010/09/01 21:52:24] <a3li> I think leads is enough +[2010/09/01 21:52:33] <a3li> as the group basically reads like a lead history +[2010/09/01 21:53:04] <vorlon078> a3li: it used to be leads, we actually introduced editing the alias ourselves back at that time +[2010/09/01 21:53:05] <_Craig_> agreed. +[2010/09/01 21:53:22] <rbu> why not remove old leads then? +[2010/09/01 21:53:24] <vorlon078> and it does not make sense to restrict the v-sec exploder when we all can change it +[2010/09/01 21:53:30] <rbu> only make it keytoaster,a3li +[2010/09/01 21:53:32] <keytoaster> vorlon078++ +[2010/09/01 21:53:44] <vorlon078> and to add a little history to that +[2010/09/01 21:54:04] <vorlon078> it was quite hard for gentoo to get on vendor-sec in the first place +[2010/09/01 21:54:21] <vorlon078> that is a reason why the alias was under strict control +[2010/09/01 21:54:56] <vorlon078> since vendor-sec is a lot about trust, we should keep that in mind +[2010/09/01 21:55:06] <a3li> okay +[2010/09/01 21:55:19] <keytoaster> good +[2010/09/01 21:55:27] <jaervosz> vorlon078: reading mail is one thing, having ssh login to the mail server is another +[2010/09/01 21:55:34] <a3li> robbat2|na: please drop everyone besides keytoaster and me from securitymail +[2010/09/01 21:55:38] <a3li> jaervosz: it's dev.gentoo.org :) +[2010/09/01 21:56:03] <jaervosz> a3li: some of us get our mail forwarded to other boxes +[2010/09/01 21:56:07] <vorlon078> a mail server where every dev has shell access would be a topic in itself i guess +[2010/09/01 21:56:16] <vorlon078> anyways +[2010/09/01 21:56:21] <a3li> anyways! +[2010/09/01 21:56:22] <vorlon078> let's move on +[2010/09/01 21:56:25] <vorlon078> bugzie +[2010/09/01 21:56:41] <a3li> 21:17:47 < idl0r> a3li, craig, falco, jaervosz, keytoaster, py, rbu, vapier, vorlon +[2010/09/01 21:56:58] <vorlon078> members of the security group +[2010/09/01 21:57:01] <robbat2|na> a3li, done +[2010/09/01 21:57:04] <a3li> see above +[2010/09/01 21:57:06] <a3li> robbat2|na: thanks +[2010/09/01 21:57:22] <robbat2|na> i can make a new group for that one file if that would help too +[2010/09/01 21:57:35] <a3li> I think we're good now +[2010/09/01 21:57:48] <a3li> the alias isn't any less confidential as v-s +[2010/09/01 21:57:55] <a3li> security@ being the 'alias' +[2010/09/01 21:58:13] <robbat2|na> ok +[2010/09/01 21:58:17] <a3li> bugzilla: we can keep things the way they are imo. +[2010/09/01 21:58:32] <rbu> re security group. i think everyone on the alias should be in the group, and that is everyone in the team ? +[2010/09/01 21:58:39] <a3li> ack +[2010/09/01 21:58:45] <a3li> more or less +[2010/09/01 21:58:57] <rbu> more or less? +[2010/09/01 21:59:02] <a3li> security : klieber,jaervosz,vorlon,vapier,falco,solar,py,keytoaster,rbu,a3li,asym,craig +[2010/09/01 21:59:05] <a3li> that's the alias +[2010/09/01 21:59:10] <vorlon078> asym? +[2010/09/01 21:59:15] <jaervosz> yeah asym? +[2010/09/01 21:59:20] <keytoaster> lol +[2010/09/01 21:59:21] <a3li> he did kernel-check with rbu in 2009 +[2010/09/01 21:59:25] <rbu> he was doing kernel security, but is being retired nw +[2010/09/01 21:59:25] <a3li> already being retired +[2010/09/01 21:59:32] <vorlon078> then remove him +[2010/09/01 21:59:35] <vorlon078> klieber too? +[2010/09/01 21:59:37] <_Craig_> it's not through yet +[2010/09/01 21:59:44] <_Craig_> he was given the usual 14 days +[2010/09/01 21:59:52] <vorlon078> and this weird craig guy +[2010/09/01 22:00:00] <vorlon078> :-P +[2010/09/01 22:00:29] <rbu> "who is in the team" is another question. but i think there should be no "more or less", but the stuff should be in sync +[2010/09/01 22:00:38] <vorlon078> agreed +[2010/09/01 22:00:42] <keytoaster> yup, right +[2010/09/01 22:00:49] <jaervosz> rbu: the team is the security alias as i see it +[2010/09/01 22:00:50] <vorlon078> there used to be the powers.xml which described who can do what +[2010/09/01 22:00:57] <Chainsaw> I'm happy to just be AMD64 liaison, yes :) +[2010/09/01 22:01:03] <jaervosz> + padawans et al +[2010/09/01 22:01:28] <vorlon078> padawans have not been on the security alias +[2010/09/01 22:01:30] <rbu> vorlon078: i think chainsaw is in the team, no? +[2010/09/01 22:01:42] <a3li> he's a padawan technically +[2010/09/01 22:01:48] <rbu> oh man +[2010/09/01 22:01:53] <p-y> vorlon078: you mean http://dev.gentoo.org/~falco/powers.html ? +[2010/09/01 22:01:54] <a3li> but now hired to the council +[2010/09/01 22:01:55] <keytoaster> huge mess here +[2010/09/01 22:02:06] <rbu> Chainsaw: get your butt up and join, man! :-) +[2010/09/01 22:02:14] <vorlon078> p-y: yes +[2010/09/01 22:02:20] <vorlon078> that was made by koon way back +[2010/09/01 22:02:21] <keytoaster> p-y: whoa, we'll have to move that into our project space +[2010/09/01 22:02:27] <p-y> indeed +[2010/09/01 22:02:28] <keytoaster> i can do that if you want +[2010/09/01 22:02:34] <vorlon078> make it so +[2010/09/01 22:02:37] <Chainsaw> rbu: With my current workload, it wouldn't be fair. A colleague of mine has left, and I'm doing the job of about 3 or 4 people right now. +[2010/09/01 22:03:08] <vorlon078> brb +[2010/09/01 22:03:10] <a3li> okay as for security@ right now +[2010/09/01 22:03:15] <a3li> I'll remove klieber and asym +[2010/09/01 22:03:16] <rbu> Chainsaw: sucks. sorry. well, hope you get more help@work soon then +[2010/09/01 22:03:25] <keytoaster> ok, vorlon078 is brb, me too +[2010/09/01 22:03:29] <keytoaster> 5-10 minutes +[2010/09/01 22:03:30] <keytoaster> sorry +[2010/09/01 22:03:32] <p-y> there's probably other interesting stuff to merge in ~falco +[2010/09/01 22:03:49] <Chainsaw> rbu: There's budget for an assistant next year. +[2010/09/01 22:03:58] <Chainsaw> rbu: I will be looking for a Gentoo developer with commit privs. +[2010/09/01 22:04:19] <rbu> not too hard to find in this channel i guess +[2010/09/01 22:04:23] <vorlon078> back +[2010/09/01 22:04:44] <vorlon078> a3li: ack wrt security@ +[2010/09/01 22:04:50] <a3li> mhm being Chainsaw's PFY would mean access to those nice salt and vinegar crisps they have in GB +[2010/09/01 22:04:59] <a3li> okay +[2010/09/01 22:05:30] <Chainsaw> Yes, and living in the cathedral city of Peterborough :) +[2010/09/01 22:05:42] <vorlon078> we could make a short break for keytoaster and start with team membership afterwards +[2010/09/01 22:05:45] <a3li> as long as it has a pub +[2010/09/01 22:06:24] <vorlon078> then we should speed things up a little +[2010/09/01 22:06:28] <Chainsaw> a3li: Many pubs, yes :) +[2010/09/01 22:07:07] <a3li> okay, short break, let's go on at :15 +[2010/09/01 22:07:26] <vorlon078> yes +[2010/09/01 22:07:30] <Chainsaw> I would actually like to go home at some point. +[2010/09/01 22:07:30] <p-y> the part 4 is probably the biggest and most interesting +[2010/09/01 22:07:39] <Chainsaw> It is 9pm and I'm sitting at my work desk. +[2010/09/01 22:08:08] <a3li> Chainsaw: feel free to leave, there will be no more voting I guess. we'll have a log and you can always ask questions later +[2010/09/01 22:08:22] <Chainsaw> Okay, thanks :) +[2010/09/01 22:09:09] @ Quit: Chainsaw: Remote host closed the connection +[2010/09/01 22:09:45] <keytoaster> back +[2010/09/01 22:11:49] <_Craig_> let's go on +[2010/09/01 22:15:08] <_Craig_> hullo? +[2010/09/01 22:15:21] <a3li> now is :15 +[2010/09/01 22:15:23] <a3li> everyone back? :) +[2010/09/01 22:15:23] * jaervosz is still here for a bit more +[2010/09/01 22:15:26] <vorlon078> yep +[2010/09/01 22:15:31] <vorlon078> let's move on +[2010/09/01 22:15:33] <p-y> ok +[2010/09/01 22:15:34] <a3li> okay so let's speeeeeed up +[2010/09/01 22:16:05] <vorlon078> so we sorted out the security alias I believe +[2010/09/01 22:16:22] <a3li> yes +[2010/09/01 22:16:33] <vorlon078> if there is nothing more about bugzilla et al, we could go on to team membership +[2010/09/01 22:16:39] <keytoaster> yes +[2010/09/01 22:16:44] <a3li> bugzilla is fine. defined to be == team +[2010/09/01 22:16:47] @ Quit: Ford_Prefect: Ping timeout: 240 seconds +[2010/09/01 22:16:54] <a3li> now, let's talk about who the team is +[2010/09/01 22:17:03] <keytoaster> actually +[2010/09/01 22:17:11] <keytoaster> who is able to add people to the bugzie group? +[2010/09/01 22:17:14] <vorlon078> there is still the +[2010/09/01 22:17:18] <vorlon078> exactly +[2010/09/01 22:17:29] <a3li> should be the leads as well, right? +[2010/09/01 22:17:34] <vorlon078> there is a group who can do that +[2010/09/01 22:17:43] <keytoaster> i don't think there is a group +[2010/09/01 22:17:45] <vorlon078> I am currently still in it I beleieve +[2010/09/01 22:17:49] <vorlon078> a bugzie group +[2010/09/01 22:17:49] <keytoaster> people just get the bit set to be able to set it +[2010/09/01 22:17:52] <vorlon078> whatever you call it +[2010/09/01 22:17:54] <vorlon078> yes +[2010/09/01 22:18:42] <keytoaster> actually i can change that bit +[2010/09/01 22:18:46] <a3li> so. bottom line: team leads should have that flag? +[2010/09/01 22:18:47] <keytoaster> because i'm a recruiter +[2010/09/01 22:18:55] <a3li> if yes, I'll talk to idl0r later and have things sorted. +[2010/09/01 22:19:01] <keytoaster> but i don't seem to find a way to see who already has it +[2010/09/01 22:19:13] <vorlon078> a3li: that was the idea behind it at that time +[2010/09/01 22:19:20] <a3li> okay. I'll get it done later. +[2010/09/01 22:19:26] <a3li> next agenda item? +[2010/09/01 22:19:27] <keytoaster> ok, cool. +[2010/09/01 22:20:06] <p-y> 4) handling of the current GLSA and bug queues and how to avoid such situations in the future +[2010/09/01 22:20:31] <jaervosz> bedtime here have to get up at 5 am in the morning. However with my new job i should be available during normal working hours to help out, i'll try pinging again in here in the morning +[2010/09/01 22:20:51] <vorlon078> good night jaervosz and hope to see you around again here +[2010/09/01 22:20:52] <a3li> yes, that's the most important bit. we need to get everyone working again. +[2010/09/01 22:20:58] <a3li> so thanks jaervosz, see you! +[2010/09/01 22:21:16] <keytoaster> ok, good night +[2010/09/01 22:21:27] <jaervosz> see you tomorrow and we'll do something about that terrible backlog +[2010/09/01 22:21:35] <a3li> that's the spirit! +[2010/09/01 22:22:03] <vorlon078> since it was brought up earlier that the new glsamaker might help cleaning the current queue, could someone shed some light on that +[2010/09/01 22:22:08] <vorlon078> shortly +[2010/09/01 22:22:28] <a3li> okay. we started writing a new glsamaker as you all know +[2010/09/01 22:22:33] <vorlon078> like eta and how it can help +[2010/09/01 22:22:36] <a3li> it's in a near-usable state +[2010/09/01 22:22:50] <a3li> the goal is to have our information integrated better +[2010/09/01 22:22:53] <Falco> vorlon078: pong +[2010/09/01 22:22:53] <keytoaster> that is combined with the idea of "mini glsas": we have boilerplates for description that just says "xxx is affected. please review the CVEs referenced below for details." +[2010/09/01 22:23:01] <Falco> hey, some activity here +[2010/09/01 22:23:07] <_Craig_> a3li: what kind of problems are there to solve? +[2010/09/01 22:23:09] <p-y> I like the idea of mini-glsas +[2010/09/01 22:23:12] <a3li> Falco: nice of you to show up. +[2010/09/01 22:23:14] <rbu> Falco: team meeting +[2010/09/01 22:23:22] <Falco> was at work ^^ +[2010/09/01 22:23:23] <keytoaster> p-y: me too +[2010/09/01 22:23:30] <_Craig_> keytoaster: ++ +[2010/09/01 22:23:34] <keytoaster> vorlon078: we did a bunch of those a few months ago +[2010/09/01 22:23:36] <p-y> Hey Falco! +[2010/09/01 22:23:37] <Falco> and in holidays, before +[2010/09/01 22:23:39] <Falco> hey p-y ! +[2010/09/01 22:23:45] <Falco> long time we haven't got a drink +[2010/09/01 22:23:46] <keytoaster> that actually went pretty fast and decreased the backlog +[2010/09/01 22:23:53] <p-y> Falco: yep +[2010/09/01 22:23:54] <vorlon078> Falco: hi +[2010/09/01 22:23:54] <keytoaster> and with the new glsamaker it's *very* easy to draft those +[2010/09/01 22:24:07] <vorlon078> keytoaster: I think we should do something like that for a while again +[2010/09/01 22:24:09] <a3li> _Craig_: the problem we are trying to solve is, that drafting an advisory isn't efficient and just not fun +[2010/09/01 22:24:21] <keytoaster> and let me claim that about 50% of the current backlog is just minor issues +[2010/09/01 22:24:27] <a3li> _Craig_: you have to get information from many sources and manually combine them +[2010/09/01 22:24:29] <vorlon078> well +[2010/09/01 22:24:29] <Falco> hi everyone, vorlon078 , keytoaster , a3li and jaervosz !! +[2010/09/01 22:24:34] <a3li> hi. +[2010/09/01 22:24:51] <p-y> vorlon078: not only for a while, IHMO +[2010/09/01 22:24:52] <vorlon078> at this point in the agend i see two slightly different subjects +[2010/09/01 22:25:18] <vorlon078> first: how to get rid of the very old things needing a glsa +[2010/09/01 22:25:29] <vorlon078> second: how to ease things up in the future +[2010/09/01 22:25:44] <vorlon078> for the second part a better tool is part of the solution i would say +[2010/09/01 22:25:52] <keytoaster> it both boils down to motivating people and getting the new glsamaker done :) +[2010/09/01 22:26:14] <vorlon078> the currently full backlog of old stuff is demotivating +[2010/09/01 22:26:22] <keytoaster> oh btw +[2010/09/01 22:26:22] <a3li> yes. +[2010/09/01 22:26:27] <vorlon078> it would help to find a quick and easy way to get rid of that +[2010/09/01 22:26:30] <p-y> maybe it's a good occasion to review the vulnerability policy +[2010/09/01 22:26:32] <keytoaster> at the moment we don't give glsamaker access to everyone +[2010/09/01 22:26:37] <keytoaster> because it holds confidential information +[2010/09/01 22:26:50] <p-y> and send glsa only for really serious issues +[2010/09/01 22:26:56] <keytoaster> the new tool will have permission groups, so we can give new interested people access way earlier +[2010/09/01 22:27:06] <vorlon078> p-y: i don't consider that a good idea +[2010/09/01 22:27:34] <a3li> I'd rather like to send a less detailed GLSA for those B3 things +[2010/09/01 22:27:40] <vorlon078> a3li: agreed +[2010/09/01 22:27:41] <keytoaster> p-y: we could send mini GLSAs instead. just fill out affeced, unaffected versions, use the boilerplates for the rest, done. +[2010/09/01 22:27:44] <a3li> i.e. what other distros do, copy the CVE text +[2010/09/01 22:27:45] <rbu> when is it "good enough" to use? i think that's the key to everything. not be perfect, but have it running and doing 80% of the job +[2010/09/01 22:27:48] <keytoaster> a3li++ +[2010/09/01 22:27:50] <keytoaster> yes, indeed +[2010/09/01 22:27:56] <a3li> rbu: within the year. +[2010/09/01 22:28:04] <vorlon078> a3li: thanks for that info +[2010/09/01 22:28:15] <_Craig_> <@a3li> I'd rather like to send a less detailed GLSA for those B3 things <<< ++ +[2010/09/01 22:28:17] <vorlon078> then we need to find a way with the current tools to get rid of the large queue +[2010/09/01 22:28:28] * _Craig_ wants mini-glsas, too. +[2010/09/01 22:28:35] <keytoaster> rbu: to replace the old tool: drafting is completely done. we need to create the txt advisory, xml advisory, and sending mails +[2010/09/01 22:28:36] <vorlon078> then let us define mini-glsa +[2010/09/01 22:29:03] <p-y> vorlon078: I say that because in the past, we used to send glsas for "minor" issues (DoS) on minor packages, and we were the only distro doing so, other fixed them silently +[2010/09/01 22:29:04] <keytoaster> rbu: actually i've sorted stuff on the redmine tracker +[2010/09/01 22:29:19] <p-y> that's a waste of energy IMO +[2010/09/01 22:29:37] <a3li> p-y: the thing is when there's a B2 bug coming later. what do you do with the DoS then? +[2010/09/01 22:29:43] <p-y> especially given the manpower shortage +[2010/09/01 22:29:48] <a3li> p-y: just discard it and not include in the advisory? +[2010/09/01 22:29:59] <keytoaster> vorlon078: like http://www.gentoo.org/security/en/glsa/glsa-201006-14.xml +[2010/09/01 22:30:14] <keytoaster> oh wait, that's actually still a pretty long one +[2010/09/01 22:30:30] <vorlon078> p-y: for such things i would propose to draft the changes to the policy, send to security@ and discuss it there +[2010/09/01 22:30:36] <vorlon078> or even better +[2010/09/01 22:30:37] <vorlon078> the gentoo-security list +[2010/09/01 22:30:38] <keytoaster> vorlon078: http://www.gentoo.org/security/en/glsa/glsa-201006-05.xml +[2010/09/01 22:31:04] <keytoaster> basically just a very short description and impact +[2010/09/01 22:31:44] <vorlon078> keytoaster: ok, thanks +[2010/09/01 22:32:05] <Falco> very good ! (that the new glsamaker tool will have permission groups) : because only very few glsas are actually confidential +[2010/09/01 22:32:08] <a3li> the new glsamaker could help there by filling in the background, getting the CVEs from the bug +[2010/09/01 22:33:06] <vorlon078> so what is the easiest way for us to deal with the old waiting drafts +[2010/09/01 22:33:21] <a3li> what we could do is a GLSA fest(tm) +[2010/09/01 22:33:25] <vorlon078> should we do mini-glsas like those examples in the current glsamaker? +[2010/09/01 22:33:30] <a3li> as many people as possible ddraft GLSAs together +[2010/09/01 22:33:31] <vorlon078> or is there another way? +[2010/09/01 22:33:39] <a3li> make that mini glsas. +[2010/09/01 22:33:43] <keytoaster> ++ +[2010/09/01 22:33:44] <a3li> and after 5 hours they're sent +[2010/09/01 22:33:50] <a3li> but that needs at least 4-5 people +[2010/09/01 22:34:07] <a3li> same would be needed for bugs, btw +[2010/09/01 22:34:14] <vorlon078> a3li: yeah +[2010/09/01 22:34:15] <keytoaster> although i'd wait for the new tool +[2010/09/01 22:34:23] <keytoaster> i'm not motivated to do anything with the old one +[2010/09/01 22:34:26] <vorlon078> but I think it would be nice to clean up glsamaker queue first +[2010/09/01 22:34:37] <keytoaster> basically i start, look at the tool, and lose interest again +[2010/09/01 22:34:42] <vorlon078> actually, i don't think waiting is a good option right now +[2010/09/01 22:34:52] <vorlon078> it will just grow +[2010/09/01 22:35:19] <vorlon078> and there is currently know exact time frame for the new tool +[2010/09/01 22:35:26] <vorlon078> s/know/no +[2010/09/01 22:35:49] <vorlon078> I would be willing to do some old stuff in the old tool +[2010/09/01 22:35:53] <a3li> how about we'll have something that will allow us end-to-end drafting by Oct 1 +[2010/09/01 22:35:54] <vorlon078> lets say next week +[2010/09/01 22:35:55] <rbu> ++ we can't wait until the end of the year and pile up +[2010/09/01 22:36:07] <keytoaster> a3li: define end-to-end +[2010/09/01 22:36:09] <rbu> well ... we can. but it we should make that public at least +[2010/09/01 22:36:12] <Falco> there's also another possibility +[2010/09/01 22:36:13] <a3li> bug comes in to email goes out +[2010/09/01 22:36:22] <keytoaster> yes, cool +[2010/09/01 22:36:32] <keytoaster> that shouldn't take too long +[2010/09/01 22:36:33] <a3li> that would mainly require people motivating keytoaster and me to finish things :) +[2010/09/01 22:36:42] <rbu> DO IT +[2010/09/01 22:36:44] <vorlon078> that would be a great thing +[2010/09/01 22:36:45] <rbu> enough? +[2010/09/01 22:36:45] <keytoaster> a3li: you'll have to do the xml part, i can do the txt erb and mail stuff +[2010/09/01 22:36:50] <a3li> rbu: does it involve beer? +[2010/09/01 22:36:58] <vorlon078> but should not stop us from already doing some stuff with the old tool +[2010/09/01 22:37:07] <a3li> so maybe we can separate the effor then +[2010/09/01 22:37:11] <rbu> yes. you get one crate of beer and one club mate *each* +[2010/09/01 22:37:12] <Falco> perhaps we can commit mini .xml files to portage, before writing the full text and sending the official mail +[2010/09/01 22:37:17] <rbu> paid by gentoo e.v. +[2010/09/01 22:37:24] <a3li> keytoaster and I focus on glsamaker 2 +[2010/09/01 22:37:27] <a3li> the rest does our day-job +[2010/09/01 22:37:31] <keytoaster> vorlon078: perhaps you need to see the new tool in action to see what it's capable of? :D +[2010/09/01 22:37:59] <_Craig_> <@a3li> rbu: does it involve beer? <<< finish glsamaker, receive beer at 27c3. +[2010/09/01 22:38:01] <p-y> Falco: if we do that, we all know that the full text will never be written +[2010/09/01 22:38:02] <_Craig_> ;) +[2010/09/01 22:38:17] <Falco> p-y: possible, indeed +[2010/09/01 22:38:25] <vorlon078> oh and one important thing +[2010/09/01 22:38:32] <Falco> but glsa-check would be up-to-date +[2010/09/01 22:38:38] <vorlon078> with all the trouble we had and have, we should be more open about it +[2010/09/01 22:38:49] <vorlon078> and tell the users not to expect glsas in these situaions +[2010/09/01 22:38:49] <rbu> ++ +[2010/09/01 22:38:57] <vorlon078> i feel rather bad about the way we handled it +[2010/09/01 22:39:41] <p-y> me too, but anyway, users emerging world on a regular basis should be ok +[2010/09/01 22:39:49] <vorlon078> yeah those should +[2010/09/01 22:40:10] <vorlon078> but there might be users and even larger environments that don't work that way +[2010/09/01 22:40:43] <keytoaster> vorlon078: i'll add a notice at the top of the project page +[2010/09/01 22:40:45] <vorlon078> that's why i would like to see glsas go out again or an explanation why not and how to keep track of security fixes +[2010/09/01 22:40:48] <keytoaster> refering to the meeting log/summary +[2010/09/01 22:41:16] <a3li> of course the goal is to get the GLSA process going again +[2010/09/01 22:41:45] <vorlon078> if we don't restart sending stuff again soon, i would propose to send an explanation out to -announce +[2010/09/01 22:41:51] <p-y> agreed +[2010/09/01 22:41:56] <a3li> well we have to simply +[2010/09/01 22:42:02] <vorlon078> yes +[2010/09/01 22:42:05] <p-y> even if we do, actually +[2010/09/01 22:42:47] <Falco> ok +[2010/09/01 22:43:03] <vorlon078> so we should write something up on the current security situation in gentoo and make it public? +[2010/09/01 22:43:13] <vorlon078> no matter how we go on next month +[2010/09/01 22:43:13] <rbu> y +[2010/09/01 22:43:17] <vorlon078> ack +[2010/09/01 22:43:18] <keytoaster> yes +[2010/09/01 22:43:19] <p-y> yep +[2010/09/01 22:43:24] <a3li> but please don't make to too dramatic +[2010/09/01 22:43:30] <a3li> *it +[2010/09/01 22:43:31] <_Craig_> oh no...bad news +[2010/09/01 22:43:35] <_Craig_> I already see it on heise... +[2010/09/01 22:43:43] <keytoaster> right +[2010/09/01 22:43:56] <vorlon078> I can try to think of a first draft +[2010/09/01 22:44:01] <keytoaster> and if it will be on heise, your line will be as well :P +[2010/09/01 22:44:23] <_Craig_> We're doomed. +[2010/09/01 22:44:28] <a3li> kay. +[2010/09/01 22:44:36] <vorlon078> alright +[2010/09/01 22:44:37] <keytoaster> ok, good +[2010/09/01 22:44:39] <keytoaster> next point then +[2010/09/01 22:44:44] <vorlon078> umm wait +[2010/09/01 22:45:04] <vorlon078> i can try and draft something next week +[2010/09/01 22:45:12] <vorlon078> or is there anyone else who wants to with more time +[2010/09/01 22:45:18] <keytoaster> nope +[2010/09/01 22:45:29] <a3li> next week is fine imo +[2010/09/01 22:45:41] <vorlon078> btw +[2010/09/01 22:45:57] <vorlon078> is there any team we should have it checked by? +[2010/09/01 22:46:09] <rbu> like pr? +[2010/09/01 22:46:14] <rbu> not that i know of +[2010/09/01 22:46:31] <vorlon078> same here +[2010/09/01 22:46:48] <vorlon078> ok +[2010/09/01 22:46:50] <vorlon078> then lets go on +[2010/09/01 22:47:04] <vorlon078> I"ll draft and send to security@g.o for review +[2010/09/01 22:47:18] <keytoaster> ok +[2010/09/01 22:48:11] <vorlon078> so for the current queue +[2010/09/01 22:48:19] <keytoaster> ok, 5. is "Any other topic" +[2010/09/01 22:48:19] <vorlon078> a tool by oct 1 +[2010/09/01 22:48:25] <keytoaster> oh, sorry +[2010/09/01 22:48:36] <vorlon078> and who ever wants to send mini-glsas with the current tool can go on +[2010/09/01 22:48:38] <vorlon078> right? +[2010/09/01 22:48:49] <keytoaster> yes +[2010/09/01 22:49:01] <vorlon078> just for the record (and the summary) +[2010/09/01 22:49:02] <vorlon078> ok +[2010/09/01 22:49:10] <vorlon078> then any other topics? +[2010/09/01 22:49:16] <keytoaster> none from me +[2010/09/01 22:49:39] <a3li> well if you don't want any further info about glsamaker2.. +[2010/09/01 22:50:00] <keytoaster> it seems you want to tell us info :) +[2010/09/01 22:50:07] <vorlon078> 5.1 further info about glsamaker2 +[2010/09/01 22:50:17] <vorlon078> there you go ;) +[2010/09/01 22:50:21] <p-y> does it make coffee? :) +[2010/09/01 22:50:22] <a3li> I thought it was included in 4. +[2010/09/01 22:50:27] <a3li> p-y: no it's not emacs! +[2010/09/01 22:50:32] <p-y> oh :( +[2010/09/01 22:50:51] <a3li> so I already talked about the idea +[2010/09/01 22:50:56] <a3li> integrate all info +[2010/09/01 22:51:03] <a3li> that also means, it'll be the new CVE tracker. +[2010/09/01 22:51:18] <keytoaster> ++ +[2010/09/01 22:51:30] <rbu> is there a live demo / staging server? +[2010/09/01 22:51:49] <a3li> I could update my trunk demo again +[2010/09/01 22:51:51] <p-y> yep, i'd like to see it too +[2010/09/01 22:51:58] <vorlon078> that would be great +[2010/09/01 22:52:09] <keytoaster> http://vandium.net/~keytoaster/glsamaker2-comments.ogv +[2010/09/01 22:52:10] <a3li> or get things rolling with infra (robbat2|na *prod*) +[2010/09/01 22:52:13] <keytoaster> that shows some comment action +[2010/09/01 22:52:17] <keytoaster> (nothing about the cve tracker) +[2010/09/01 22:52:21] <a3li> hot comment action! +[2010/09/01 22:52:24] <a3li> that's the drafting part +[2010/09/01 22:52:55] <a3li> http://stingray.a3li.info/~alex/cvetool-1.png and http://stingray.a3li.info/~alex/cvetool-2.png are shots of the CVE tracker +[2010/09/01 22:53:40] <robbat2|na> a3li, on phone, one moment +[2010/09/01 22:53:51] <a3li> robbat2|na: fix overlays first, yeah +[2010/09/01 22:54:33] <p-y> you guys really did an awesome job, thanks +[2010/09/01 22:55:22] <rbu> sweet +[2010/09/01 22:55:33] <rbu> the images alone make me want to work again! +[2010/09/01 22:55:39] <a3li> yes, it has 3G +[2010/09/01 22:55:40] <p-y> yeah, me too +[2010/09/01 22:55:41] <a3li> and the wifis +[2010/09/01 22:55:52] <a3li> and it doesn't crash if you enter >A instead of >5 +[2010/09/01 22:55:52] <a3li> :P +[2010/09/01 22:55:53] <rbu> get it running NOW +[2010/09/01 22:56:03] <a3li> see the url in the title bar +[2010/09/01 22:56:05] <a3li> :> +[2010/09/01 22:56:57] <rbu> localhorst? +[2010/09/01 22:57:01] <a3li> lolcathost +[2010/09/01 22:57:12] <p-y> local toast? +[2010/09/01 22:57:24] <vorlon078> port 3000 is bad +[2010/09/01 22:57:31] <vorlon078> just wanted to add something too ;) +[2010/09/01 22:57:42] <a3li> we should have it on port 0 +[2010/09/01 22:57:47] <vorlon078> yeah +[2010/09/01 22:58:09] <vorlon078> sounds like we already passed the end of the meeting btw +[2010/09/01 22:58:17] <a3li> likely. +[2010/09/01 22:58:20] <vorlon078> oh and it should be yellow +[2010/09/01 22:58:22] <a3li> I hope we get back in the saddle +[2010/09/01 22:58:39] <vorlon078> is there anything anyone wants to add about glsamaker2? +[2010/09/01 22:58:50] <keytoaster> nope +[2010/09/01 22:58:56] <a3li> we'll get you a demo running +[2010/09/01 22:59:06] <vorlon078> that would really be great +[2010/09/01 22:59:11] <a3li> then we need testing and of course take suggestions +[2010/09/01 22:59:17] <a3li> beta rollout by october +[2010/09/01 22:59:29] <a3li> working 1.0 version rollout within the year +[2010/09/01 22:59:39] <keytoaster> what's within the year? +[2010/09/01 22:59:45] <keytoaster> in 2010 or within 12 months from now on? +[2010/09/01 22:59:53] <a3li> 2010! +[2010/09/01 22:59:58] <keytoaster> whoa +[2010/09/01 23:00:01] <keytoaster> you're optimistic :) +[2010/09/01 23:00:04] <a3li> er? +[2010/09/01 23:00:04] <vorlon078> i think it would be nice to have a current todo list for the team and who is 'responsible' for which task +[2010/09/01 23:00:11] <a3li> it won't be the final version +[2010/09/01 23:00:21] <keytoaster> floss is never final +[2010/09/01 23:00:28] <keytoaster> vorlon078: we have a redmine +[2010/09/01 23:00:34] <rbu> well.. glsamaker1 is final +[2010/09/01 23:00:34] <keytoaster> oh, you mean in general for security +[2010/09/01 23:00:50] <vorlon078> yeah for security +[2010/09/01 23:01:01] <a3li> we can get a wiki again somewhere +[2010/09/01 23:01:06] <vorlon078> a3li: good point +[2010/09/01 23:01:14] <keytoaster> *sigh* +[2010/09/01 23:01:18] <keytoaster> not another wiki discussion +[2010/09/01 23:01:27] <keytoaster> but yes, go for it +[2010/09/01 23:01:32] <vorlon078> well, for the task list an .xml in proj is fine +[2010/09/01 23:01:32] <a3li> yes. let's have a cvs and check in guidexml files +[2010/09/01 23:01:33] <keytoaster> i'll kill the first guy who objects +[2010/09/01 23:01:58] <vorlon078> hmpf +[2010/09/01 23:02:12] * _Craig_ AFK: pizzapizza. BBL. +[2010/09/01 23:02:12] <a3li> okay. I think we're really done now +[2010/09/01 23:02:14] <keytoaster> vorlon078: you didn't get the joke probably :) +[2010/09/01 23:02:22] <vorlon078> keytoaster: no not at first +[2010/09/01 23:02:41] <vorlon078> and actually i simply want a list and a place to keep such stuff +[2010/09/01 23:02:50] <vorlon078> i did use our dokuwiki installation btw +[2010/09/01 23:02:58] <a3li> we'll arrange for something +[2010/09/01 23:03:12] <vorlon078> one last thing at the end of each meeting +[2010/09/01 23:03:32] <vorlon078> i would like to hold meetings way more often but shorter +[2010/09/01 23:03:40] <keytoaster> ++ +[2010/09/01 23:03:43] <vorlon078> way more often means more than every two years +[2010/09/01 23:04:02] <keytoaster> every three months? +[2010/09/01 23:04:02] <rbu> thanks vorlon078 for moderating and calling in the meeting +[2010/09/01 23:04:14] <rbu> and thanks to everyone who picked up tasks +[2010/09/01 23:04:23] <a3li> thanks to rbu for the mate +[2010/09/01 23:04:24] <keytoaster> thanks rbu for attending +[2010/09/01 23:04:24] <vorlon078> every two or three would be really good i think +[2010/09/01 23:04:28] <vorlon078> rbu: thanks +[2010/09/01 23:04:59] <vorlon078> what aboud mid october for october for the next one since we wanted to make changes then +[2010/09/01 23:05:05] <vorlon078> argh +[2010/09/01 23:05:37] <vorlon078> i would have said nov/dec, but oct might be nice in case we do have a tool to change things again +[2010/09/01 23:05:46] <keytoaster> fine with me +[2010/09/01 23:05:52] <rbu> good +[2010/09/01 23:05:59] <p-y> ok for me +[2010/09/01 23:06:01] <a3li> kk +[2010/09/01 23:06:05] <vorlon078> oh wait +[2010/09/01 23:06:10] <vorlon078> im on vacation then +[2010/09/01 23:06:11] <vorlon078> lol +[2010/09/01 23:06:17] <p-y> I have to go, gn8 all +[2010/09/01 23:06:20] <a3li> n8 +[2010/09/01 23:06:25] <keytoaster> p-y: good night, and thanks +[2010/09/01 23:06:26] <vorlon078> alright +[2010/09/01 23:06:29] <vorlon078> good night +[2010/09/01 23:06:32] <rbu> nite +[2010/09/01 23:06:53] <vorlon078> i'll write a reminder for myself for an october meeting then +[2010/09/01 23:07:22] <vorlon078> thanks for attending everyone :) +[2010/09/01 23:07:29] <a3li> monstermeeting +[2010/09/01 23:07:32] <keytoaster> thanks vorlon078 for doing this :) +[2010/09/01 23:07:34] <a3li> thanks +[2010/09/01 23:08:03] @ keytoaster set topic "Last project meeting: 2010-09-01 18:30 UTC; Logs and summary available soon | This channel is only for coordinating vulnerabilities and GLSA releases. For an end-user support channel, see #gentoo | http://security.gentoo.org | New recruits: http://www.gentoo.org/security/en/padawans.xml" +[2010/09/01 23:08:29] <a3li> that topic is not so god +[2010/09/01 23:08:31] <a3li> *good +[2010/09/01 23:08:42] <a3li> sounds like that was our last meeting ever :) +[2010/09/01 23:08:52] <keytoaster> *sigh* +[2010/09/01 23:09:02] @ keytoaster set topic "Previous project meeting: 2010-09-01 18:30 UTC; Logs and summary available soon | This channel is only for coordinating vulnerabilities and GLSA releases. For an end-user support channel, see #gentoo | http://security.gentoo.org | New recruits: http://www.gentoo.org/security/en/padawans.xml" +[2010/09/01 23:10:46] <vorlon078> log stopped here btw +[2010/09/01 23:10:56] <a3li> %part +[2010/09/01 23:10:56] @ Left channel #gentoo-security () |