diff options
| -rw-r--r-- | sec-meeting-2018-06-03-log | 346 |
1 files changed, 346 insertions, 0 deletions
diff --git a/sec-meeting-2018-06-03-log b/sec-meeting-2018-06-03-log new file mode 100644 index 0000000..cdd32a5 --- /dev/null +++ b/sec-meeting-2018-06-03-log @@ -0,0 +1,346 @@ +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 |