19:10:04 <ennael> #startmeeting 19:10:04 <Inigo_Montoya`> Meeting started Tue Apr 19 19:10:04 2011 UTC. The chair is ennael. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:10:04 <Inigo_Montoya`> Useful Commands: #action #agreed #help #info #idea #link #topic. 19:10:05 <erzulie> [ MeetBot - Debian Wiki ] 19:10:35 <ennael> ok this meeting is about launching secteam (or whatever the name) and be ready for final release 19:11:29 <Ruperto> helo 19:11:42 <ennael> stewb has joined and is ok to work on this with any other volunteer 19:11:56 <ennael> stewb: can you introduce yourself in a phew words ? 19:12:06 * Kharec is volunteer. 19:13:03 <stewb> hello everyone, I'm a former Mandriva developer and worked with vdanen on the mdv secteam for a couple fo years 19:13:47 <ennael> ok so we have some topics to review: 19:13:51 <stewb> ennael: I'm sorry, I'm getting called away for something unplanned :( 19:14:02 <ennael> stewb: outch so you cannot attend ? 19:14:20 <stewb> I sent and email to vdanen, and he brought me up to date on what's replaced vendor-sec 19:14:44 <stewb> yes, I have to go afk right now... 19:14:52 <ennael> ok :/ 19:15:33 <ennael> ok maybe we can still review some topics 19:15:47 <ennael> team, policy, needed bs 19:17:11 <boklm> ok 19:17:12 <mikala> needed bs ? 19:17:18 <spturtle> build system 19:17:26 <ennael> ok either we go on and people share or we go on by mail 19:17:33 <ennael> I do not intend to sleep here tonight :) 19:17:41 <boklm> what topic do we start ? 19:17:46 <ennael> ok 19:17:53 <misc> let's say team 19:18:04 <ennael> #topic build secteam team 19:18:07 <ennael> outch 19:18:13 <boklm> :) 19:18:15 <Kharec> :) 19:18:57 <ennael> o let speak about human beings 19:18:57 <misc> so first, i guess we need to define the team, ie what are the duties, etc 19:19:03 <ennael> yep 19:19:13 <ennael> human beings does not apply for pterjan 19:19:43 <ennael> misc: shall we define kind of profile to work in secteam 19:19:43 <Kharec> So define who want to be part of team? :) 19:19:56 <misc> ennael: well, why not 19:20:09 <misc> but stew explained what was needed on ml 19:20:54 <ennael> ok so we can include it if people are ok 19:21:48 <shikamaru> mmh one thing I don’t imagine is how many people are needed for it 19:22:11 <shikamaru> given that not everyone can work full time on this 19:22:24 <misc> https://www.mageia.org/pipermail/mageia-dev/20110415/003999.html 19:22:25 <erzulie> [ [Mageia-dev] Meeting for secteam start ] 19:22:34 <shikamaru> stew told us that at mandriva there were 2 people working full time on it 19:22:44 <pterjan> well I think it would be nice to have at least 5 people to start 19:22:46 <misc> yes, but they were the only one doing it 19:23:12 <pterjan> but the most important thing is to have 1 or 2 people to setup things initially 19:24:08 <shikamaru> ok 19:24:21 <misc> and to find a way to scale thing 19:24:35 <pterjan> first, listing the needs better (buildsystem target not uploading to mirrors and not listed on the interface, tracking tool) 19:24:51 <pterjan> so that people can then easily work on a single update 19:24:55 <misc> pterjan: testing is made for that, no ? 19:25:02 <shikamaru> mmh that part I don’t understand 19:25:13 <shikamaru> why should there be a separate BS ? 19:25:18 <pterjan> misc: except if sometimes it is not yet public 19:25:29 <misc> pterjan: how often does that happen ? 19:25:40 <pterjan> misc: well it happened very often in the past 19:25:53 <pterjan> much less without vendor sec I guess 19:26:22 <ennael> 21:14 < stewb> I sent and email to vdanen, and he brought me up to date on what's replaced vendor-sec 19:26:32 <pterjan> ah 19:26:35 <ennael> he will send an email about this 19:27:05 <misc> I think having to place such restriction will be detrimental to the growth of the team and increase sysadmin loads 19:27:17 <pterjan> misc: which restriction ? 19:27:48 <ennael> who spoke about restrictinon ? 19:28:03 <misc> pterjan: protecting bugzilla ( as there will be non public exploit ) ( if we use bugzilla ), having to use another separate BS , having to restrict the test to only some people 19:28:13 <pterjan> well 19:28:20 <boklm> for public vulnerabilities, I think we can use the same build system 19:28:24 <boklm> and bugzilla 19:28:25 <pterjan> protecting some bugs 19:28:32 <pterjan> until they get public 19:28:36 <boklm> and make an exception for private vulnerabilities 19:28:47 <pterjan> it should not be the default 19:28:58 <pterjan> and not really another buildsystem 19:28:59 <misc> protecting 10 vulns or 100 will have the same cost for us in term of workload 19:29:03 <ennael> we cannot make public what is private 19:29:21 <pterjan> misc: then should we wait until things become public to work on a fix ? 19:29:25 <boklm> discuss in a private mailing list private vulnerabilities 19:29:43 <boklm> build on our own machines while it is private 19:29:43 <pterjan> would be easier 19:29:45 <AndroUser2> security by darkness is not always the best 19:29:53 <pterjan> just get patches from other distro 19:29:58 <boklm> and submit to build system when we release the update 19:30:18 <pterjan> AndroUser2: when all distros agree to wait for a week before announcing the problem, we can not announce it before 19:30:23 <misc> pterjan: well, depend on the cost, since stuff are private, I do not really know how much vulns and how often they are disclosed before, what impact would it have in practice 19:30:26 <pterjan> AndroUser2: else they will no longer inform us 19:30:40 <pterjan> which cost ? 19:30:49 <pterjan> enabling private bugs on bugzilla ? 19:30:49 <ennael> misc: it's really not that much 19:30:58 <ennael> for what I remember in mdv 19:31:25 <pterjan> the bs thing is about having another youri config 19:31:31 <pterjan> I think 19:31:52 <pterjan> idon't know for svn actually 19:32:07 <misc> secteam didn't use svn until the last minute commit 19:32:27 <misc> using some decentralized stuff would solve this cleanly, but that's not doable for now :) 19:33:05 <ennael> we need a solution for 01/06 :) 19:33:34 <pterjan> allowing uploading a src.rpm to another iurt queue for people in a specific group? 19:33:43 <shikamaru> oh yeah yet another reason to use git :p 19:33:51 <pterjan> like a restricted scp to that directory 19:34:04 <pterjan> and then collecting things somewhere 19:34:06 <misc> I think the main issue is svn 19:34:27 <boklm> So using public svn, bugzilla, testing repositories for public vulnerabilities, and a private svn, private bugs, private BS for non-public vulnerabilities ? 19:34:40 <misc> who can access the private svn ? 19:34:56 <pterjan> people in the group + invited people :P 19:35:10 <misc> and how long will the access last ? 19:35:18 <boklm> until fix is released ? 19:35:20 <pterjan> until the update is pushed 19:35:41 <pterjan> maybe create some temporary git-svn and push and destroy at the end ? 19:35:58 <misc> could be 19:36:09 <shikamaru> yeah that could be nice 19:36:23 <AndroUser2> boklm, but what would be a non public vuln, since we use free sw all time 19:38:04 <pterjan> AndroUser2: free software authors and distro do not announce vuln before fixing it usually 19:38:17 <boklm> AndroUser2: some vulnerabilities are publicly announced, some other vulnerabilities are know only by a few people and announced only in private to people maintaining distribution to work on update before public announce 19:38:18 <misc> so do not announce after fixing :) 19:38:19 <pterjan> they announce to all distros the problem 19:38:27 <pterjan> and the date when it will be public 19:38:32 <pterjan> like a few days or a week 19:38:38 <shikamaru> so that means obfuscating the changelog as well ? 19:38:46 <pterjan> which changelog ? 19:38:47 <misc> shikamaru: nope 19:38:49 <shikamaru> like not announcing what you fix 19:38:57 <pterjan> just not distributing the fix :) 19:39:04 <boklm> shikamaru: update is not provided until it is public 19:39:05 <shikamaru> pterjan: the one you get when you issue rpm -q --changelog 19:39:13 <pterjan> shikamaru: the rpm is not distributed 19:39:16 <shikamaru> ah I see, sorry for the noise 19:39:31 <shikamaru> so you make the update locally, and you push it when it’s disclosed 19:39:38 <boklm> yes 19:39:38 <pterjan> yes 19:39:41 <misc> and who would test it ? 19:39:44 <pterjan> you 19:39:53 <pterjan> or the maintainer if you provide an explanation 19:40:02 <pterjan> or qa team ? 19:40:09 <misc> or a subset of the qa team ? 19:40:52 <boklm> maybe asking on qa list who has time to work on an update in coming days 19:41:20 <misc> except we cannot disclose what the update is about 19:41:29 <boklm> yes 19:41:37 <boklm> saying an unknown package will need some tests 19:41:42 <misc> and except we cannot distribute exploit 19:41:59 <pterjan> yes people who work on it have to agree to not communicate/redistribute 19:42:02 <boklm> distribute in private to that person, after they agreed to not distribute it 19:42:20 <misc> would it be ok with regard to non-disclosure ? 19:42:21 <pterjan> like when asking help from the maintainer 19:42:27 <AndroUser2> mmmm how do debiar or ubuntu deal with this? 19:42:47 <boklm> misc: I think that would be ok, unless there is a problem one day 19:42:53 <pterjan> https://launchpad.net/~ubuntu-security 19:42:54 <erzulie> [ Ubuntu Security Team in Launchpad ] 19:43:06 <pterjan> https://launchpad.net/~ubuntu-security/+mugshots 19:43:06 <erzulie> [ Member photos : "Ubuntu Security Team" team ] 19:43:14 <misc> boklm: well, what are the term ? 19:43:27 <misc> (again since this is private, we do not know what we have to agree :/ ) 19:43:57 <boklm> yes, I don't know exactly, so someone will need to check 19:44:12 <misc> @info check the condition for handling private exploit for bug 19:44:15 <misc> #info check the condition for handling private exploit for bug 19:44:23 <AndroUser2> need to go. please incude me on sec matters 19:44:32 <AndroUser2> im dlucio 19:45:02 <misc> #info check that bugzilla can handle private bug ( based on ldap if possible ) 19:45:58 <pterjan> http://oss-security.openwall.org/wiki/vendors 19:45:59 <erzulie> [ vendors [OSS-Security] ] 19:46:03 <pterjan> nice page 19:46:22 <pterjan> Debian bug tracker, Security issue tracker (public issues only) 19:46:30 <pterjan> they do not track private ones ? 19:47:02 <misc> maybe they don't 19:47:02 <boklm> "Security issues should be sent to security [at] debian [dot] org" 19:47:08 <pterjan> Use https://launchpad.net/ubuntu/+filebug to report Ubuntu bugs (private security bugs can be opened by checking the �This bug is a security vulnerability� box). 19:47:09 <erzulie> [ OpenID transaction in progress ] 19:47:13 <boklm> maybe they only track public one on they bug tracker 19:47:30 <boklm> and private one by email 19:47:46 <misc> or maybe they apply point 3 literaly : http://www.debian.org/social_contract 19:47:46 <erzulie> [ Debian Social Contract ] 19:47:53 <misc> who can check with debian people ? 19:49:22 <boklm> if no one else I can do it 19:49:39 <misc> #action boklm check with debian people for the way they handle security 19:50:30 <misc> I think , if we want to make sure the confidentiality of test can be ensured, we would need some vm to do that 19:50:48 <misc> as not all packagers will have access to all stable variation 19:50:54 <boklm> yes 19:51:26 <misc> #info requires testing vm to be avaliable 19:51:42 <misc> also, I guess we need some security contact 19:52:14 <misc> ( ie, someone to receive mail security@ , since this is the email used everywhere except for openbsd ) 19:52:41 <boklm> yes 19:53:07 <misc> question is "what is the goal of such alias" 19:53:20 <misc> warn for security regarding the product, the infrastructure ? 19:53:48 <boklm> for both yes 19:54:13 <misc> that's not the same people 19:54:15 <boklm> or for the infrastructure, maybe it should be sent to sysadmin 19:54:26 <misc> we could have 2 aliases 19:54:41 <misc> ( or maybe no one will ever warn us :) ) 19:54:48 <pterjan> well 19:54:49 <boklm> :) 19:55:05 <pterjan> I think security is enough and can contact admins 19:55:23 <pterjan> I expect them to have an opinion on the risk etc 19:55:29 <boklm> I think secteam is for security regarding the product (but can forward mails to sysadmin regarding infrastructure) 19:55:36 <misc> ok 19:55:59 <misc> #info security@ should be sent to the team in charge of security and should forward to sysadmin 19:56:15 <boklm> forward to sysadmin, if relevant for sysadmin 19:56:23 <misc> of course :) 19:57:35 <misc> so for public vuln, we treat them like any bugfix 19:57:54 <misc> ie, open bug on bugzilla, etc, etc 19:58:01 <pterjan> yes 19:58:28 <misc> for private vuln, we use bugzilla + private , we never declassify the bug ? 19:58:44 <pterjan> I wonder if there is a way that only secteam can close sec bugs ? 19:58:53 <pterjan> it becomes public when we upload 19:59:00 <pterjan> the only problem is exploits 19:59:10 <pterjan> if we attach them, they would become public 19:59:11 <misc> I do not think we should store them 19:59:14 <pterjan> ok 19:59:24 <misc> maybe removing them once they are not needed ? 19:59:33 <pterjan> yes 19:59:44 <boklm> maybe some people will copy paste exploit code inside messages 20:00:00 <pterjan> they should get punished 20:00:12 <pterjan> and the video uploaded somewhere 20:00:15 <boklm> :) 20:00:27 <misc> can we edit bugzilla message ? 20:00:39 <boklm> I'm not sure 20:01:05 <misc> ( besides touching to postgresql ) 20:01:11 <pterjan> http://www.bugzilla.org/features/#private 20:01:12 <erzulie> [ Features :: Bugzilla :: bugzilla.org ] 20:01:18 <pterjan> If you are in the "insider group," you can mark certain attachments and comments as private, and then they will be invisible to users who are not in the insider group. 20:01:32 <boklm> ok, so we can mark those comments as private 20:01:36 <spturtle> I think redhat uses bugzilla for private bugs as well 20:01:42 <misc> yes 20:02:13 <misc> but keeping a lots of exploit is IMHO asking for people to attack us to get them :/ 20:02:18 <pterjan> yes 20:02:41 <boklm> most of the exploits are supposed to be kept private ? 20:02:46 <misc> I dunno 20:02:57 <boklm> maybe we should check that 20:03:18 <misc> #action check if exploit need to be kept private or not 20:03:57 <spturtle> stewb was going to talk about this (replacement of vendor-sec which was secret) 20:04:04 <misc> yup 20:04:17 <misc> but the question is to know if this is used for coordination, or more 20:04:41 <boklm> and if exploits posted on this list are supposed to stay private even when vulnerability is public 20:05:24 <pterjan> I think releasing exploits too soon is bad as people will not update immediately 20:05:53 <spturtle> we'll have to wait for more info on this subject 20:06:12 <misc> on the other hand, most people who are able to use exploit do not really need them I guess 20:06:24 <misc> but it all depend on what we have to agree for vendor-sec 20:06:41 <misc> ( as a side note, it would be nice to document what is needed to get on the list too ) 20:06:57 <pterjan> well many script kiddies like to have the exploit ready :) 20:07:22 <pterjan> especially it if targets web app that you can locate easily with google 20:07:30 <misc> if the exploit allows to be root, yes 20:07:36 <misc> but that's one every 2/3 years 20:07:38 <spturtle> workload of security team depends on what packages are supported and how many releases, relevant now or do we leave that all for the security team to decide? 20:08:18 <pterjan> yes number of releases is important, but that's something to be decided by council I think 20:08:25 <misc> and by qateam 20:08:43 <misc> ( and also by what do we support in infra and mirrors ) 20:08:52 <pterjan> well sec and qa has to participate in the decision and then hire more :) 20:09:17 <misc> #action misc bring the issue for next council meeting 20:09:19 <stewb> sorry folks, I made an appt for tomorrow and they showed up today :/ 20:09:57 <misc> no problem 20:11:14 <ennael> stewb: so you have information about vendor-sec ? 20:11:28 <ennael> at least what may be in place of it 20:11:38 <stewb> yes, oss-security replaces vendor-sec 20:11:50 <boklm> and oss-security is public ? 20:11:53 <ennael> any specific thing to know about it ? 20:12:03 <stewb> vdanen told me to first get listed on their wiki, then make a request to join the list 20:12:16 <stewb> there may be some resistance, as we have no release history yet 20:12:30 <ennael> http://oss-security.openwall.org/wiki/ 20:12:31 <erzulie> [ welcome [OSS-Security] ] 20:12:32 <stewb> it's private, I believe 20:12:58 <stewb> they don't email to exploders, e.g security@, only people 20:13:18 <stewb> would be good to have "official" email addresses probably to subscribe 20:13:32 <misc> ie, official ? 20:13:45 <stewb> misc@mageia.org, etc 20:13:51 <misc> stewb: we do 20:13:56 <stewb> ah, ok 20:14:12 <misc> ( and personnaly, I would prefer to not use mine as clear text example for spam related reason, especially in meeting log ... ) 20:14:25 <stewb> sorry 20:14:49 <pterjan> I think we should start setting things up before contacting them 20:15:05 <misc> but if they refuse we will do that for nothing :) 20:15:11 <pterjan> well no 20:15:22 <stewb> well, we can still do updates, just won't have advanced notice 20:15:28 <pterjan> we can always be a bit later than others until we subscribe 20:15:40 <misc> yup 20:15:52 <spturtle> oss-security is a public list 20:15:59 <misc> but I think we should first ask what we would need on our side, and setup and then ask to subscribe 20:17:09 <misc> spturtle: indeed 20:17:50 <boklm> maybe there is a private one too 20:18:09 <pterjan> Public security issues only please. What you say here is public for the world to see - keep that in mind. Embargoed information is best disclosed to vendor-sec 20:18:12 <stewb> yes, I think I misunderstood vdnanen, and you ask to get on the private one 20:18:24 <stewb> http://article.gmane.org/gmane.comp.security.oss.general/4894 20:18:24 <erzulie> [ Gmane -- Mail To News And Back Again ] 20:18:30 <stewb> here was his request 20:19:31 <boklm> ok 20:19:33 <misc> #info thread about the replacement of vendor-sec http://thread.gmane.org/gmane.comp.security.oss.general/4650/focus=4894 20:19:33 <erzulie> [ Gmane Loom ] 20:19:50 <stewb> as I left about the time things moved to iurt, I'm a bit weak how things were managed the "new way" 20:19:51 <pterjan> > Initial members will have had to be a vendor-sec member (no exploders this 20:19:51 <pterjan> > time around). You must reply to this thread, in public (on oss-security). 20:19:51 <pterjan> > We want this to be very public, we have nothing to hide. You must have a 20:19:51 <pterjan> > public gpg key ID included in your reply. The new list will gpg encrypt all 20:19:51 <pterjan> > mail (it does accept plaintext messages though). 20:20:33 <pterjan> so yeah, will be hard to get there 20:20:53 <pterjan> but we can probably try when we are ready 20:21:07 <boklm> http://thread.gmane.org/gmane.comp.security.oss.general/4650/focus=4894 20:21:07 <erzulie> [ Gmane Loom ] 20:21:15 <boklm> It's clear that 20:21:15 <boklm> one of the membership requirements is now producing security updates. If 20:21:15 <boklm> you can show you're doing this, that's grounds for membership in my 20:21:16 <boklm> opinion. 20:21:32 <boklm> so that should be possible for us 20:21:39 <pterjan> we can probably ask "support" from few other people on the list 20:22:14 <misc> boklm: this also let us some time for setup everything fully 20:22:59 <misc> ie, we can first start by the team for regular update, and once this is working we can apply for that list 20:23:19 <boklm> yes, once we have a few updates released 20:23:29 <pterjan> yes 20:23:37 <boklm> we can send the update page to show we are releasing updates 20:23:39 <misc> they also request some gpg stuff 20:23:51 <pterjan> just the key of users 20:23:55 <pterjan> they encryp emails 20:24:30 <pterjan> you can not easily forward the message or see it on the server :) 20:24:41 <misc> also, the question is "who should apply to the list" 20:24:45 <misc> 1, 2 people ? 20:24:53 <stewb> at least 2 20:25:07 <stewb> not too many though 20:25:39 <misc> #info we should have 2 people for the vendor-sec replacement 20:26:29 <boklm> +at least ? 20:26:44 <misc> #undo 20:26:55 <misc> #info we should have at least 2 people for the vendor-sec replacement ( but not too many ) 20:27:50 <misc> also, not related to the list, we need to publish advisories , I guess 20:27:56 <boklm> yes 20:29:09 <pterjan> yes we should see with webteam 20:29:29 <misc> well, first, is this needed, what are the reuirement ? 20:29:59 <pterjan> providing some information like importance of the problem 20:30:11 <pterjan> and some explanations so that people know if they are affected 20:30:52 <misc> so who wish to present this to webteam ? 20:31:42 <pterjan> do we have "formal" ways for that ? like are we supposed to ask things on the ML ? 20:31:46 <pterjan> is irc enough ? 20:31:52 <stewb> database driven would be good 20:32:38 <misc> pterjan: I guess it is better to ask on the ml, and explain stuff to them, anse to question 20:32:53 <pterjan> k 20:33:08 <misc> I do not think they will formalise about that :) 20:33:56 <misc> #action ask to the webteam about publish advisories 20:37:03 <misc> ennael: so any others questions ? 20:37:24 <ennael> not for now for me 20:37:32 <ennael> we need a summary 20:37:40 <ennael> and write down all this 20:38:49 <ennael> also kind of planning until 01/06 20:39:06 <ennael> and maybe start to investigate about advisories on cauldron packages 20:39:24 <ennael> so that we can release with as less possible as sec alerts 20:39:31 <pterjan> yes we can start tracking 20:39:36 <ennael> we used to have a bug tracker for it 20:39:55 <misc> yup 20:40:16 <ennael> who can manage it? 20:40:23 <ennael> stewb: do you think you can do it ? 20:40:51 <pterjan> I may have some time next week, I'll be on vacation in paris 20:41:09 <pterjan> so if idon't get out to much I may be able to get some things done :) 20:41:21 <stewb> I can try, perhaps if someone else can monitor and push things too, when I get too busy 20:41:54 <stewb> perhaps just start with opening public bugs on public issues on our packages? 20:42:04 <misc> yup, of course, you should just ask to packager to update, not to build everything 20:42:14 <stewb> and maybe we can gel some sort of cooperation around that 20:42:19 <misc> ( as we all know how funny stuff can happen with "just a version upgrade" ) 20:42:28 <misc> stewb: yes, bug should be enough 20:42:35 <pterjan> first step is to see bugzilla config 20:42:43 <pterjan> like having a category 20:42:52 <ennael> dmorgan: around ? 20:43:02 * boklm can add category 20:43:03 <pterjan> and maybe some custom field for CVE 20:43:09 <ennael> boklm: oh ok 20:43:32 <misc> mhh, the bugzilla will have more custom field than non custom :) 20:43:48 <pterjan> maybe we can use alias for that :) 20:44:01 * pterjan does not know much about bugzilla 20:44:05 <boklm> alias ? 20:44:27 <stewb> do we use the whiteboard for anything? 20:44:41 <stewb> I was just looking at that on the LSB bz 20:44:52 <pterjan> boklm: I remember there was some sort of alias for bugs 20:45:01 <boklm> ah, I don't know 20:45:48 <pterjan> http://www.bugzilla.org/features/#custom-fields seems the most appropriate 20:45:49 <erzulie> [ Features :: Bugzilla :: bugzilla.org ] 20:46:07 <pterjan> like displaying CVE field for bugs in security category 20:46:53 <dmorgan> ennael: yes ? 20:47:05 <ennael> dmorgan: boklm is mastering finally :) 20:48:24 <boklm> redhat is using alias 20:48:29 <dmorgan> ennael: ok sorry i am on maven so i didn't read irc :) 20:48:35 <boklm> for instance on https://bugzilla.redhat.com/show_bug.cgi?id=446902 20:48:38 <erzulie> [ Bug 446902 - CVE-2008-2363 pan: heap overflow caused by large *.nzb files ] 20:48:42 <boklm> Aliases: CVE-2008-2363 20:49:06 <misc> pterjan: +1 for displaying only when needed 20:50:39 <boklm> ok for adding CVE custom field in security category 20:51:23 <misc> ( alos, maybe if we could only show srpm for rpm package , that would be nice ) 20:51:50 <boklm> ah yes 20:51:51 <misc> #action sysadmins add CVE field for the security category 20:52:11 <misc> #action sysadmins add security category 20:52:19 <pterjan> switch them :) 20:52:40 <misc> I think sysadmins will be able to do the ordering by themself 20:53:28 <misc> anything to add for the meeting ? 20:53:37 <boklm> maybe we need a security mailing list ? 20:53:54 <misc> what would be the topic ? 20:54:24 <boklm> to receive bugzilla emails 20:54:38 <misc> and who would be subscribed on it ? 20:54:46 <boklm> hmm, maybe that would be a problem for private bugs 20:54:53 <misc> yup too 20:55:24 <pterjan> do we have group based mail alias ? 20:55:51 <misc> yes 20:55:59 <misc> foo@group.mageia 20:56:05 <pterjan> ok 20:56:08 <misc> go to mga-foo members in ldpa 20:56:11 <misc> ldap 20:56:57 <boklm> who should be default asignee for Security bugs ? 20:57:45 <misc> mhhh 20:57:46 <pterjan> security@group.mageia.org ? 20:57:55 <misc> the email is not valid yes :) 20:58:09 <misc> but we can decide to create a team and place stew in it /o\ 20:58:15 <ennael> :) 20:58:22 <pterjan> :) 20:58:45 <misc> the question of "how is treated the secteam with regard to council, etc" is still open I guess 20:59:13 <misc> ( even if i guess we can treat it as a sub group of packagers, so no need to elect representant, etc ) 20:59:18 <pterjan> with due respect 21:00:27 <pterjan> (this can be decided later) 21:00:30 <misc> yup 21:00:45 <misc> so for default assignee, i guess we can use bug traiager for now 21:00:54 <misc> ie, all bug are public so far 21:00:59 <boklm> ok 21:01:01 <pterjan> yes 21:01:41 <misc> #nfo security bugs are assigned to bug triage team for now, as everything is public 21:01:45 <misc> #info security bugs are assigned to bug triage team for now, as everything is public 21:02:06 <boklm> Security component is created 21:02:26 <boklm> on product Mageia 21:02:52 <misc> boklm: (aside) could you post on sysadmin how to create componenent ( cause i would just psql, but I am maybe doing it wrong ) 21:03:10 <misc> ( of course, I can also read the manual /o\ ) 21:03:52 <boklm> misc: I don't know if you are set as admin yet (and if it would be possible to use ldap groups for this) 21:04:53 <misc> boklm: then we should open a bug for that :) 21:05:02 <boklm> yes 21:05:03 <misc> ( maybe using some ldap to db sync ) 21:06:58 <misc> ok so anything to add on the topic ? 21:07:59 <ennael> nope 21:08:19 <boklm> not for me 21:08:29 <pterjan> no 21:08:31 <misc> not for me ( but maybe because I have head spinning ) 21:09:38 <misc> ok I guess we can close ? 21:09:46 <boklm> yes 21:09:48 <ennael> ok 21:09:53 <ennael> #endmeeting