1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
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
|