path: root/sec-meeting-2018-06-03-log

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