2018-06-03 14:00:28 @ChrisADR !proj security 2018-06-03 14:00:29 willikins ChrisADR: (security@gentoo.org) a3li, ackle, blueknight, bman, chrisadr, creffett, k_f, pinkbyte, whissi, zlogene, zx2c4 2018-06-03 14:00:33 @ChrisADR meeting time? 2018-06-03 14:01:08 Irishluck83 there was a meeting 2018-06-03 14:01:12 * K_F here 2018-06-03 14:01:18 * ChrisADR here 2018-06-03 14:01:35 @Whissi uhm 2018-06-03 14:01:37 @Whissi Was it today? 2018-06-03 14:01:47 @K_F yup 2018-06-03 14:01:57 @K_F s/was/is/ 2018-06-03 14:02:15 @ChrisADR Irishluck83: yes, sorry I haven't sent you and sokan a proper invitation, very busy this week, if you have time now, you are more than welcomed :) 2018-06-03 14:02:33 Irishluck83 well i'm here so i can do the meeting 2018-06-03 14:02:38 @ChrisADR cool 2018-06-03 14:03:59 @ChrisADR domhnall: you too 2018-06-03 14:04:34 @Whissi But I am here. 2018-06-03 14:05:20 @ChrisADR ok, let's begin, b-man will catch up later I guess 2018-06-03 14:05:53 @ChrisADR first point in list was GLEP 14, deferred for next meeting 2018-06-03 14:05:56 @K_F sounds good .. I believe first agenda item is GLEP14, I'm hoping to get started on that this week as I have plenty of time up in the air 2018-06-03 14:06:10 @ChrisADR cool, sounds good 2018-06-03 14:06:34 @ChrisADR next topic, GLSAMaker use cases 2018-06-03 14:06:58 @ChrisADR those with access to the repo may have noticed that I added a document in the documentation folder 2018-06-03 14:07:23 @ChrisADR it is still a WIP, but I'd like to point a new change that is currently in (RFC) stage 2018-06-03 14:08:10 @ChrisADR I'd like to change GLSAMaker so that padawans have access to CVETool, but only to be able to list CVEs in NEW state and to report them with the current interface 2018-06-03 14:08:44 @ChrisADR thoughts? 2018-06-03 14:09:54 @Whissi Mh. 2018-06-03 14:10:14 Irishluck83 would that allow us to make the cve and put it in the whiteboard? 2018-06-03 14:10:28 @K_F might not be a bad idea, but haven't through it through fully. 2018-06-03 14:10:42 @ChrisADR that would allow padawans to see which CVEs are out there that we are not currently tracking 2018-06-03 14:10:56 @ChrisADR and if the apply to gentoo, to report them 2018-06-03 14:11:19 @Whissi Only for Padawans who passed first step and are also expected to write GLSA. I am against access for early Padawans to CVEtool just for reporting. 2018-06-03 14:11:26 Irishluck83 that would be helpful. 2018-06-03 14:12:00 @ChrisADR Whissi: right, we need to have a pre-filter, but the idea is once they have a good understanding about what we do, let them use our tools to automate the process 2018-06-03 14:12:04 Irishluck83 that sounds ok with me. I'm at that stage now anyway. It would help me more with bugs and helping the team 2018-06-03 14:12:34 @ChrisADR yes, mainly because scouting takes a lot of time, and produces not so much benefit for the team right now 2018-06-03 14:12:55 @Whissi When they have access to normal GLSAmaker, they can have access to CVEtool web interface, too 2018-06-03 14:13:12 @ChrisADR when I was a padawan CVETool was blocked, until full access 2018-06-03 14:13:31 @ChrisADR was granted to me 2018-06-03 14:14:08 @ChrisADR so the change would be to allow "padawan" users to see and use CVETool interface 2018-06-03 14:14:48 @ChrisADR but only the reporting or assign button, not NFU or Later yet 2018-06-03 14:14:51 Irishluck83 so apprentices and up 2018-06-03 14:15:29 @Whissi But only for Padawans with GLSAmaker access. Not for new people from day one. 2018-06-03 14:15:41 @ChrisADR Whissi: of course 2018-06-03 14:15:55 @K_F I'm actually unsure if adding too much granularity makes sense in that case, e.g marking things NFU to clean things out likely makes sense in the same process 2018-06-03 14:16:11 @K_F but indeed, only after training.. 2018-06-03 14:16:36 @ChrisADR K_F: granularity may not required, but at least a notification for other team members 2018-06-03 14:16:51 @ChrisADR so we can see if something is 'accidentally' marked as NFU 2018-06-03 14:18:06 @b-man Even if it is the CLI CVETool can assign it 2018-06-03 14:18:37 @ChrisADR I couldn't when I was padawan, but we'd have to take a look at the code and see that too 2018-06-03 14:19:11 domhnall ChrisADR: I'm here, continue while I read log for any missed content 2018-06-03 14:19:27 @ChrisADR so, do you consider it a idea worth of developing further? 2018-06-03 14:19:44 @ChrisADR with all the constraints listed above 2018-06-03 14:20:53 domhnall from what ChrisADR and Whissi are discussing, I'm in agreement. 2018-06-03 14:22:29 @K_F ChrisADR: likely mostly a matter of changing the access level granting cvetool access.. the monitoring can already be done using email filters 2018-06-03 14:22:57 @ChrisADR indeed, little change in implementation, but may be useful 2018-06-03 14:22:58 @K_F maybe learn from bugzilla and add some headers on the changes, e.g who makes them etc 2018-06-03 14:23:06 @Whissi Monitoring will be the problem. There's no notification or something when you set NFU 2018-06-03 14:23:31 @K_F right, but that can likely be added to email queue as well 2018-06-03 14:23:38 @ChrisADR it would be easier to just remove the button from the interface for 'padawan' memebers 2018-06-03 14:23:41 @K_F with appropriate headers, and possibly a way to shut it off.. 2018-06-03 14:24:10 @K_F meh, shouldn't hide things from UI if they have access under the hood, that should be consistent otherwise we'll just be confused 2018-06-03 14:24:15 @Whissi Yeah, hiding in UI would be fastest thing. 2018-06-03 14:24:44 @Whissi To implement something like that you would need 6+ hours... 2018-06-03 14:24:50 @Whissi And then you already know Ruby ;) 2018-06-03 14:24:56 @Whissi For us, it will take more time ;) 2018-06-03 14:24:59 @ChrisADR hahaha right 2018-06-03 14:25:13 @ChrisADR but I think it's worth the shot to try to find a implementation for this scenario 2018-06-03 14:25:35 @ChrisADR at least to have an extra couple of trusted eyes taking a look at the list 2018-06-03 14:26:08 @Whissi You suggestion to just hide the button for the beginning sounds practicable, yes. 2018-06-03 14:26:11 @Whissi +r 2018-06-03 14:26:38 @Whissi What I would like to investigate is how CLI access is restricted... 2018-06-03 14:27:02 @ChrisADR yes, I haven't take a look at that neither 2018-06-03 14:27:34 @ChrisADR shall we vote to move this from a RFC to a TODO stage? 2018-06-03 14:27:57 @ChrisADR with implementation details pending 2018-06-03 14:28:07 @Whissi Is RFC > Todo or < Todo? L) 2018-06-03 14:28:38 @ChrisADR mmm it'd be Request for Comment right now... so, < than TODO i guess 2018-06-03 14:28:54 @ChrisADR TODO should we something that we agree that we need, but we haven't implemented yet 2018-06-03 14:29:20 @Whissi OK. 2018-06-03 14:30:55 domhnall so, can we list the pending details before voting to avoid ambugiuty? 2018-06-03 14:31:11 domhnall blah, ambiguity 2018-06-03 14:31:22 @Whissi Would say we have to do a write up, i.e. update rfc, and then we can vote on that next time. 2018-06-03 14:31:46 @ChrisADR agree, sounds better and we then avoid ambiguity as domhnall says 2018-06-03 14:32:08 @ChrisADR ok, I'll work on that part of the document adding some constraints and we'll see for the next meeting, agree? 2018-06-03 14:32:18 @Whissi yup 2018-06-03 14:32:43 @ChrisADR K_F b-man extra comments? shall we move on? 2018-06-03 14:33:00 @K_F not on this topic, still got a few comments on glsamaker though :) 2018-06-03 14:33:00 @Whissi Maybe ping me/us before meeting so we can read before meeting in case we need to adjust something so that we have a final document when we meet so we can vote. 2018-06-03 14:33:27 @ChrisADR good, I'll keep that in mind for the next meeting then :) 2018-06-03 14:33:50 * b-man forgot today was a meeting 2018-06-03 14:34:03 @ChrisADR ok, last topic then :P 2018-06-03 14:34:26 @K_F for one thing, seems we need some infra access to update password / add new users, I haven't looked into it specifically but the htpasswd isn't stored in the glsamaker admin interface but directly on server, so we need to find a way to set access on that without infra access 2018-06-03 14:34:55 @ChrisADR mmm good point 2018-06-03 14:35:08 domhnall K_F: I agree, previous access should be revoked if not a padawan. 2018-06-03 14:35:24 @Whissi Why without infra access? 2018-06-03 14:35:42 @Whissi It's not like we have to update that very often. I.e. can't we ping infra like now? 2018-06-03 14:35:48 @K_F Whissi: security leads should have the possibility to do it without being member of infra 2018-06-03 14:36:06 @K_F Whissi: it is likely as easy as setting up a git repository though.. 2018-06-03 14:36:09 @ChrisADR since blueknight was infra too, he was able to do that 2018-06-03 14:36:29 @K_F with some sync mechanism 2018-06-03 14:36:46 @Whissi I don't think we need such a complexity. 2018-06-03 14:36:56 @Whissi But... if you like to have it, go on ;) 2018-06-03 14:37:17 @ChrisADR ok, we'll see that later then, now last topic 2018-06-03 14:37:32 @ChrisADR Policy definition of "supported" 2018-06-03 14:38:07 @ChrisADR since we have already dropped HPPA from the supported list, it may be a good time to redefine if "stable"=="supported" 2018-06-03 14:38:25 * b-man grabs popcorn 2018-06-03 14:39:59 @K_F since we wouldn't necessarily be consulted before something is marked stable, I don't like it as we don't necessarily have control of the situation.. also other way around, we'd lose possibility of dropping security support from lagging arches 2018-06-03 14:40:26 domhnall I agree K_F on this one 2018-06-03 14:41:21 @ChrisADR yes, we wouldn't be consulted, but maybe it'd be a good policy for AT teams to know that if they want an arch to be considered as "stable" they need to be sure that they'll respond in the proper times to sec issues 2018-06-03 14:41:48 @K_F we wouldn't know that.. 2018-06-03 14:41:57 @K_F and formally it is not a part of consideration for moving something to stable 2018-06-03 14:42:43 @b-man The proposals in the past were simply that stable profiles are security supported by default. 2018-06-03 14:42:48 @ChrisADR should we push to make it formally part of the considerations? 2018-06-03 14:42:56 @b-man within that stable profile only stable packages are truly supported 2018-06-03 14:43:35 @K_F ChrisADR: as I've said before, that would likely coincide with a GLEP:48 like for Security 2018-06-03 14:44:11 @b-man So, I think the first step and a reasonable proposal would be for security to drop the "security supported" terminology from s.g.o and docs. 2018-06-03 14:44:44 @b-man then we can work the other potential fixes such as a GLEP or what not to ensure profiles do not get marked stable without proper support. 2018-06-03 14:45:05 @K_F or we can keep security supported as it is and have the control to do as we want :) 2018-06-03 14:45:19 @b-man It is not really any control. 2018-06-03 14:45:35 @K_F it is 2018-06-03 14:45:40 @Whissi I agree with b-man. We don't have control. 2018-06-03 14:45:49 @b-man I can release a GLSA early? 2018-06-03 14:45:52 @K_F we control what is covered by the security project 2018-06-03 14:46:01 @b-man Which should be everything IMHO 2018-06-03 14:46:13 @Whissi b-man: Well, this has changed already. You can release after first arch has stabilized. 2018-06-03 14:46:13 @b-man ::gentoo 2018-06-03 14:46:43 @b-man Whissi: It was rhetorical in response to the we have control idea. 2018-06-03 14:46:46 @K_F wouldn't be everything in any case, we definitely need to stick to stable 2018-06-03 14:46:50 @ChrisADR yes, it should be everything... even ~ arches.. but sadly we don't have the manpower to do that neither 2018-06-03 14:46:51 domhnall order? 2018-06-03 14:46:52 @b-man Yes, stable only. 2018-06-03 14:47:18 @b-man but, we really do cover a lot of ~ already anyway 2018-06-03 14:47:33 @Whissi Sorry, I have a lot to say about stable & security supported... but I don't have the time for this today :( 2018-06-03 14:48:00 @K_F yeah, I don't really see any new arguments comming up in today's discussion :) 2018-06-03 14:48:05 @b-man Whissi: Out buying peanuts and orange juice? :-P 2018-06-03 14:48:08 @K_F but indeed, it is a broader scale discussion 2018-06-03 14:48:17 @b-man K_F: We should just put it to vote 2018-06-03 14:48:27 @Whissi b-man: :p 2018-06-03 14:48:36 @K_F b-man: depending on what we're voting on, it isn't our vote to begin with 2018-06-03 14:48:37 @ChrisADR I was thinking in a end user point of view... like a question in the AMA... a user should be certain that if he uses "stable" it is also security supported 2018-06-03 14:48:47 @K_F in particular if security acceptance is required for stable, it is a council matter 2018-06-03 14:49:05 @Whissi K_F: You are the only one who wants to keep status quo. So please come up with arguments why. 2018-06-03 14:49:17 @ChrisADR yes, indeed, but we need to see if the team, as a whole, wants to go to council presenting the idea 2018-06-03 14:49:20 @Whissi All the other wants to change stable includes security coverage. 2018-06-03 14:49:34 @Whissi You cannot have a stable arch if you cannot keep up with security stabilization 2018-06-03 14:49:51 @K_F there are two ways for that to happen, one is security doesn't have a say and just covers everything marked stable 2018-06-03 14:50:05 @K_F the other is if security want a role in the process a priori, that will require a glep:48 style for security 2018-06-03 14:50:15 @Whissi (and I would say it like Linus: It isn't about security... i.e. if you would only follow security stabilization but ignore all other stable requests for your architecture, your architecture shouldn't be stable at all... but... ) 2018-06-03 14:51:06 @ChrisADR ok, we then should prepare a GLPE:48 like document stating what should be considered to have a "stable" arch with security coverage and present that to council 2018-06-03 14:51:19 @b-man Step 1: we drop the separation of "security supported arches" and ensure it is understood that we support all stable profiles. 2018-06-03 14:51:25 @K_F ChrisADR: you'll find some early templates of that around already 2018-06-03 14:51:26 @b-man Step 2+: we go to council with a GLEP or whatever 2018-06-03 14:51:46 Irishluck83 need to go but i'll catch up later. 2018-06-03 14:52:20 @K_F https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security 2018-06-03 14:52:30 @ChrisADR ok, so far we all agree that this is a must have topic, maybe too long for just one meeting, right? 2018-06-03 14:53:02 @b-man ChrisADR: As Whissi mentioned, most are in agreement already. 2018-06-03 14:53:40 @b-man We go round and round about GLEP's and council stuff most of the time. 2018-06-03 14:54:16 @b-man Let's take some first steps within security... like vote on what we agree is the right way, then we can go do all the GLEPs and council stuff we want. 2018-06-03 14:54:32 @b-man but if we cannot agree and do anything internal than there is no point in pursuing GLEPs. 2018-06-03 14:54:47 @Whissi I think this is not special about security project. I have to look up GLEP for stable arches in general. If we haven't yet a document for Gentoo, we have to create one: 2018-06-03 14:54:53 @K_F what I'd like to see is a more complete proposal of how it'd look 2018-06-03 14:55:00 @Whissi Any arch which should be marked stable has to follow rules. 2018-06-03 14:55:09 @Whissi Like doing stabilization in time ;) 2018-06-03 14:55:17 @K_F you don't have that atm 2018-06-03 14:55:18 @Whissi If you cannot keep up, you will loose stable flag. 2018-06-03 14:55:20 @K_F so indeed 2018-06-03 14:55:24 @ChrisADR ok, what do you think about this 2018-06-03 14:55:32 domhnall no 2018-06-03 14:56:04 @K_F that is part of why I'd like to see a complete proposal, there are inconsistencies in what I've seen so far, except gentoo security being a taker of what to support from exogenuous sources 2018-06-03 14:56:17 @K_F you don't really need even a council decision to mark an arch stable today 2018-06-03 14:56:25 @ChrisADR I(or someone)'ll prepare an email stating what whissi said, that security project is concernd about the current status of "stable" arches, that they need to be able to keep security in the arch or they shouldn't be called "stable" 2018-06-03 14:56:52 @Whissi But prepare that for us, so we can work on this draft 2018-06-03 14:56:55 @Whissi before it goes public ;) 2018-06-03 14:56:57 @b-man ChrisADR: That is great, but we as a project cannot unanimously agree. 2018-06-03 14:57:08 @ChrisADR see how arch teams react, and in base of that feedback, prepare a GLEP and see the details about that? 2018-06-03 14:57:22 @K_F wrong way around if you ask me 2018-06-03 14:58:07 @b-man This is the what, 5th time this dicussion has come up? 2018-06-03 14:58:46 @K_F something like that :) 2018-06-03 14:58:58 @ChrisADR maybe because this has ambiguous scope between AT, security, and other teams? 2018-06-03 14:59:05 @K_F and I think we can even agree on the goal, but it requires proper preparation 2018-06-03 14:59:06 @b-man ChrisADR: Not really 2018-06-03 14:59:16 @b-man K_F: No, we haven't agreed on the goal. 2018-06-03 14:59:30 @b-man I am pretty sure it is as simple as... does a stable profile == security supported? 2018-06-03 14:59:41 @b-man K_F says no. Everyone else says yes. 2018-06-03 14:59:50 @K_F b-man: rights, it is as simple as that as long as security is a taker of stable 2018-06-03 15:00:05 <-- fekepp (~Thunderbi@87.140.192.248) ha salido (Ping timeout: 240 seconds) 2018-06-03 15:00:06 @K_F we don't have any impact of what is marked stable, or if slacking arches 2018-06-03 15:00:06 @ChrisADR yes b-man but is not as simple because right now we don't have power to decide if something is stable or not 2018-06-03 15:00:25 @ChrisADR and that's in AT scope, a bit... 2018-06-03 15:00:26 @b-man No, we don't nor do we have any power now 2018-06-03 15:00:38 @K_F now we say its not security supported, case closed 2018-06-03 15:00:50 @b-man This isn't making any sense 2018-06-03 15:00:53 @b-man It is a straw man 2018-06-03 15:01:17 @b-man and I can't believe I am even using the "straw man" crap 2018-06-03 15:01:38 @b-man We currently support all packages which have a stable marking 2018-06-03 15:02:12 @K_F not necessarily 2018-06-03 15:02:22 @b-man K_F: Please, tell me when we haven't... 2018-06-03 15:02:28 domhnall b-man: so that wont change after this meeting...agreed? 2018-06-03 15:02:51 @K_F one example would be a package that controls hardware/monitors hardware on ArchX and is only marked stable on that 2018-06-03 15:03:16 @b-man Yea, sure of course. 2018-06-03 15:03:18 @K_F I'd tend to agree that for more general purpose applications, as long as amd64 is added we're covering it anyways, but that isn't necessarily ultimately true for all packages 2018-06-03 15:03:42 @b-man Just because it isn't mathematically/empirically true doesn't make it wrong. 2018-06-03 15:04:10 @K_F it makes the statement wrong logically 2018-06-03 15:04:14 @b-man We are doing the usual Gentoo bullshit and coming up with "Big Bang Theory" like cases in order to avoid making a decision. 2018-06-03 15:05:07 @K_F but i propose someone write up a more detailed proposal and we can discuss that by email 2018-06-03 15:05:32 @b-man I think we all understand what the proposal is. 2018-06-03 15:05:55 @K_F I do believe that to do this correctly we indeed need more formal description of requirement to mark stable, and for security project to be an imput on that a GLEP:48-style proposal 2018-06-03 15:06:20 @b-man K_F: Sure, I don't disagree with a GLEP, but we should come to an agreement and take internal action first. 2018-06-03 15:06:46 @ChrisADR ok, what about this... 2018-06-03 15:06:55 @b-man I proposed to agree that we as a project support all stable profiles 2018-06-03 15:07:11 @b-man by doing that we remove all security supported lingo from the pages. 2018-06-03 15:07:13 @K_F that part we can do.. I don't like it personally, but that is possible 2018-06-03 15:07:26 @b-man send out a notice that we now support all stable arches 2018-06-03 15:07:47 @K_F but we need to be aware that we don't have any control of what is marked stable, so suddenly a developer can add risc-v and we have no prior notice 2018-06-03 15:07:47 @b-man then we draft a GLEP to present ot the council detailing the "rules of a stable arch" (e.g. if you suck you get dropped). 2018-06-03 15:08:07 @ChrisADR I consider it the wrong order b-man 2018-06-03 15:08:32 @b-man As I have said before, nothing will change if council does not do it. 2018-06-03 15:08:33 @ChrisADR If we'd have to vote right now... as Whissi said, ATs don't have a procedure to define something as 'stable' or markt it 2018-06-03 15:08:57 @b-man So, if all of that fails we can just go back and say sorry... your arch is no longer supported. 2018-06-03 15:09:01 @ChrisADR we need first to define what we expect to be considered before it is marked as stable 2018-06-03 15:09:07 @b-man but, I have confidence the council will see it our way. 2018-06-03 15:09:13 @ChrisADR that way we ensure that something is stable because it is security covered 2018-06-03 15:09:31 @b-man So, as a "show of good faith" we should take *some* action within the project first. 2018-06-03 15:10:16 @b-man K_F: Sure, that could happen, but highly doubtful. 2018-06-03 15:10:24 domhnall Why does this fail appealing to read GENTOO? 2018-06-03 15:10:27 @ChrisADR I consider that the show of good faith needs to be a formal proposal, worked by all of us, then presented to the community, and then to council if needed 2018-06-03 15:10:27 @b-man It would be a systematic process before that arch became stable 2018-06-03 15:10:42 @Whissi Don't treat security as an add-on. It should be _normal_ for stable to have security coverage. I really cannot think of any reason why you want something exposed as "stable" but give a shit about stabilization. 2018-06-03 15:11:05 @K_F right, but today it is an add-on, security isn't a special project 2018-06-03 15:11:13 domhnall right 2018-06-03 15:11:14 @b-man It doesn't need to be *special* 2018-06-03 15:11:16 @K_F I tend to agree we want to be one 2018-06-03 15:11:18 @Whissi It don't has to be a special for that 2018-06-03 15:11:28 domhnall heh 2018-06-03 15:11:37 @b-man Aside from the Gentooism of projects then sure it may be considered *special* 2018-06-03 15:11:45 @K_F Whissi: depends on the order of things, security supporting everything that is marked stable is possible 2018-06-03 15:11:55 @K_F but something doesn't need security coverate to become stable 2018-06-03 15:12:04 @K_F coverage* 2018-06-03 15:12:34 @b-man define something? an arch, a package? 2018-06-03 15:12:39 @K_F the first we can decide on as a project, the second requires something else 2018-06-03 15:13:09 @Whissi Well... I think I got your point but I think we can ignore this. It is important to have a rule for Gentoo itself what's need to be done to mark an architecture stable and when a stable flag will be removed. 2018-06-03 15:13:31 @Whissi s/need/needed/ 2018-06-03 15:13:34 @K_F right, but that requires a GLEP or at least a council vote on a properly written proposal 2018-06-03 15:13:42 @Whissi ACK. 2018-06-03 15:13:47 @b-man I think we have enough mechanisms in place (QA and Council) to ensure anything seriously worrisome (from a security perspective) is dealt with 2018-06-03 15:13:51 @Whissi (if we haven't something like that today) 2018-06-03 15:13:52 @K_F and likely a combination of both, 1) making Security a special project similar to QA 2018-06-03 15:14:05 @Whissi No. We don't need to be special for this. 2018-06-03 15:14:10 @Whissi Why do you want to combine this? 2018-06-03 15:14:11 @K_F 2) a council vote on policy to mark arches stable 2018-06-03 15:14:41 @K_F if Security support is required to mark an arch stable, we claim to be special 2018-06-03 15:14:52 @K_F even more so if input to drop an arch from stable 2018-06-03 15:15:01 @b-man K_F: Or, the council claims to be smartly deciding what we allow. Security should be one of those. 2018-06-03 15:15:20 @K_F b-man: technically you don't even need a council vote to mark an arch stable todday 2018-06-03 15:15:27 @b-man This is true. 2018-06-03 15:15:33 @b-man So, council should fix that. 2018-06-03 15:15:43 @Whissi Think about a simple GLEP saying: "You are a developer and you care for YOURARCH. Nice! If you want to mark YOURARCH stable, you have to tell anyone about your plans. From this moment, the whole community will start watching for X months to see if you can keep up with other architectures. Once you passed the test, YOURARCH will be marked as stable." Bum. 2018-06-03 15:15:50 @K_F b-man: its not really a problem as it is 2018-06-03 15:16:14 @b-man K_F: Sure it is, because we constantly see a flux of arches as stable/not stable 2018-06-03 15:16:25 @b-man but no one cares because we don't "promise" anything to our users. 2018-06-03 15:16:30 @K_F (of course, even talking about stable arches is incomplete, we need to consider the profiles too, but that is easier, we can just make it && dev profile) 2018-06-03 15:16:57 @Whissi Another paragraph: "Once you cannot keep up anymore, you will receive a strike. After 3 strikes, YOURARCH will be downgraded to exp again and you have to proof again for some time, that you can keep up, if you want to get back stable flag. 2018-06-03 15:17:13 @ChrisADR ok, I think we all ACK that a formal proposal needs to be written 2018-06-03 15:17:40 @b-man Sure, I agree a formal proposal needs to happen, but let's take some action internally for once first :) 2018-06-03 15:17:53 @ChrisADR that will define relevant aspects of Security project and some parameters that an arch needs to pass in order to be considered stable 2018-06-03 15:18:25 @ChrisADR so, are we all in the same page right now? 2018-06-03 15:18:35 @b-man and if our formal proposal implies that a stable arch == security supported then by our "good faith" actions we will show the council we *believe* it is important. 2018-06-03 15:18:35 @K_F ChrisADR: fwiw, those are likely parallel proposals, but something like that, yes 2018-06-03 15:19:03 @b-man *if* we believe security is important then we should act upon it. 2018-06-03 15:19:25 @ChrisADR ok, make it two separate proposals, but we all agree that those proposals need to be presented, right? 2018-06-03 15:19:46 Irishluck83 yes 2018-06-03 15:19:48 @K_F I think working on them internally is anyways useful to outline policy 2018-06-03 15:20:05 @b-man Not, "security is important, but we want to choose what is convenient to us" 2018-06-03 15:20:09 @K_F then we'll determine what needs external validation and not when we have a more complete proposal 2018-06-03 15:20:20 @b-man This is also the reason we need to take action and convince the council it is important. 2018-06-03 15:20:28 @b-man It should be baked-in... not an add-on 2018-06-03 15:21:10 @ChrisADR ok, what about this... K_F and me will work on the Security project structure as a document, b-man and Whissi, since you are involved with ATs in x64 and amd64, could you write some guidelines about what times, needs, constraints, and arch needs to accomplish to be considered 'stable'? 2018-06-03 15:21:12 @b-man and quite frankly, it would be nice to see the council discuss security on a regular basis 2018-06-03 15:21:40 @ChrisADR s/and arch/an arch/ 2018-06-03 15:22:04 @b-man Sure 2018-06-03 15:22:04 @K_F b-man: there isn't often a need for a council decision on it, that is only needed to set policy (as we're currently discussing, but that requires a proper proposal) 2018-06-03 15:22:24 @K_F otherwise it is the domain of Security 2018-06-03 15:22:24 @b-man K_F: Yes, via the proposal they will have to make a decision. 2018-06-03 15:22:46 @K_F well, strictly speaking not only that, if someone started Security II tomorrow they could do that 2018-06-03 15:23:15 @b-man Well then, I am going to fork the security project! 2018-06-03 15:23:28 @b-man LibreSecurity!!!!!! 2018-06-03 15:23:43 @b-man Who's coming with me? :-P 2018-06-03 15:23:55 * b-man is joking of course 2018-06-03 15:24:35 @ChrisADR ok so... both documents prepared internally... then presented to community in order to be presented to council for a final decition... agree? 2018-06-03 15:24:42 @b-man We are going to use Python instead of Ruby! 2018-06-03 15:24:54 @K_F ChrisADR: right.. 2018-06-03 15:25:10 @b-man and instead of padawans we will have Ninjas in training 2018-06-03 15:25:22 @b-man cuz ninjas are way cooler 2018-06-03 15:25:34 @ChrisADR Whissi b-man: agree? 2018-06-03 15:25:49 @Whissi On LibreSecurity? 2018-06-03 15:25:52 @b-man ChrisADR: On Ninjas? Yes :) 2018-06-03 15:25:53 Irishluck83 actually i did some ninjustus in college 2018-06-03 15:26:04 Irishluck83 ninjutsu 2018-06-03 15:26:12 @b-man I agree the documents, yes. 2018-06-03 15:26:16 @Whissi Well, b-man and I will create some guidelines, yes... 2018-06-03 15:26:19 @ChrisADR on preparing both documents (sec structure and arch stabilization constraints) to be presented formally to council as soon as possible 2018-06-03 15:26:32 @Whissi First we present it to security 2018-06-03 15:26:44 @ChrisADR sure 2018-06-03 15:26:46 @b-man Now, can we decide on stable arch == supported internally? 2018-06-03 15:26:58 @Whissi And before council, it will go to -dev ml to have some fun. Council is only final destination to vote after community discussed. 2018-06-03 15:26:58 @K_F right, first internal, then community discussion / RFC 2018-06-03 15:27:05 @b-man and get rid of the silly "security supported" list on the s.g.o? 2018-06-03 15:27:05 @ChrisADR I don't think we can given the current status of things 2018-06-03 15:27:37 @ChrisADR yes, following standard procedures of course 2018-06-03 15:27:47 @K_F well, we can, I'm not sure if we want to 2018-06-03 15:27:48 domhnall b-man: why? 2018-06-03 15:27:51 @b-man "Be the change you want to see in Gentoo" - Daniel Robbins 2018-06-03 15:28:38 domhnall Please, ChrisADR, keep the posted supported list. 2018-06-03 15:28:49 @b-man Ghandi and Daniel Robbins were friends. 2018-06-03 15:29:00 @ChrisADR I'd love to get rid of that part, but I don't see it as a wise decision right now, specially not having some guidelines about what 'stable' actually is 2018-06-03 15:29:11 @ChrisADR to begin with 2018-06-03 15:29:23 @b-man We don't *control* anything anyway 2018-06-03 15:29:36 @K_F we control what we call security supported 2018-06-03 15:29:50 @b-man so, the very *control* we think we have is just a way of saying "screw you user..." 2018-06-03 15:30:09 @b-man and it still leaves vulnerable ebuilds in the tree cuz arch X isn't caught up 2018-06-03 15:30:26 @b-man So, by pretending we have *control* we are just proving that we *don't* care. 2018-06-03 15:30:45 @K_F that won't change by us setting security supported = stable 2018-06-03 15:30:53 @b-man Nope, it won't. 2018-06-03 15:30:59 @b-man but it will show that we *do* care. 2018-06-03 15:31:06 @ChrisADR ok, it's clear that the current status is not great, and that if we change it right now it won't help neither 2018-06-03 15:31:24 @b-man and by taking action prior to telling the world we think we should do business a certain way means we believe it. 2018-06-03 15:31:30 @K_F at least now the user has a possibility of getting a warning, if support is dropped due to sluggishness etc 2018-06-03 15:31:41 @ChrisADR so, let's prepare those guidelines and present them, and show that we do care about security in general 2018-06-03 15:32:24 @ChrisADR ok let's finish that point with the documentation pending and move one 2018-06-03 15:32:32 @b-man Then lets at least take down "Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us." from s.g.o 2018-06-03 15:32:48 @b-man cuz that != true 2018-06-03 15:33:28 @ChrisADR well it is... that's why we are having this long discussion... 2018-06-03 15:33:51 @ChrisADR but moving on... anything else, or should I bang the gavel? 2018-06-03 15:34:07 @K_F one small thing, I noticed while linking on AMA ... 2018-06-03 15:34:15 @ChrisADR sure 2018-06-03 15:34:41 @K_F Update current members of https://wiki.gentoo.org/wiki/Project:Security/Affiliations <- we need to update this a bit with new members 2018-06-03 15:35:19 @K_F at least distros is wrong 2018-06-03 15:35:29 @ChrisADR I had never seen that document :P 2018-06-03 15:35:54 @ChrisADR can you take a look at that for us K_F ? 2018-06-03 15:36:11 @K_F yes, I added it to my TODO (but won't be next week..) 2018-06-03 15:36:28 @K_F reminds me, I need to set a devaway 2018-06-03 15:36:32 @ChrisADR well, it's not the most urgent thing we have right now 2018-06-03 15:36:35 @ChrisADR thanks :) 2018-06-03 15:37:23 @ChrisADR ok, something else? we are 37 mins over schedule 2018-06-03 15:37:45 @K_F nothing more from me 2018-06-03 15:38:24 @ChrisADR ohh before I forgot, please add those documents to the repo, same place as glsamaker-use_cases please 2018-06-03 15:38:48 @ChrisADR I mean, sec structure and arches constraints 2018-06-03 15:39:25 * ChrisADR bangs the gavel, thank you for your time today