1 |
dilfridge 15/01/29 19:59:07 |
2 |
|
3 |
Added: 20150113.txt |
4 |
Log: |
5 |
Add meeting log |
6 |
|
7 |
Revision Changes Path |
8 |
1.1 xml/htdocs/proj/en/council/meeting-logs/20150113.txt |
9 |
|
10 |
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20150113.txt?rev=1.1&view=markup |
11 |
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20150113.txt?rev=1.1&content-type=text/plain |
12 |
|
13 |
Index: 20150113.txt |
14 |
=================================================================== |
15 |
[20:02:02] <dilfridge> shall we start? |
16 |
[20:02:02] <-> ulm_ heißt jetzt ulm |
17 |
[20:02:18] <dilfridge> 1. Roll call (5 minutes) |
18 |
[20:02:20] -*- dilfridge here |
19 |
[20:02:24] <radhermit> here |
20 |
[20:02:30] -*- rich0 here |
21 |
[20:02:35] <dberkholz|mob> Here |
22 |
[20:02:44] -*- WilliamH here |
23 |
[20:03:12] <dilfridge> ulm, blueness? |
24 |
[20:03:24] <blueness> here |
25 |
[20:03:34] <ulm> just in time for the meeting I am having connection issues :( |
26 |
[20:03:36] -*- ulm here |
27 |
[20:03:43] <dilfridge> ok everyone's here! |
28 |
[20:04:03] <dilfridge> 2. Discussion of GLEP39, "lame projects" / "lame project leads" (10 minutes) http://thread.gmane.org/gmane.linux.gentoo.project/4169/focus=4170 |
29 |
[20:04:11] <dilfridge> rich0: your moment |
30 |
[20:04:32] <rich0> Was that one mine? |
31 |
[20:04:35] <radhermit> lame -> unresponsive I assume |
32 |
[20:04:43] <dilfridge> err sorry |
33 |
[20:04:49] <dilfridge> blueness: your moment :) |
34 |
[20:05:02] <blueness> well |
35 |
[20:05:02] -*- rich0 breathes a sign of relief |
36 |
[20:05:32] <blueness> there was a lot of chatter on the list, but basically i wanted to see what the council thinks we ought to do with lame team leads |
37 |
[20:06:07] <blueness> in particular toolchain. it doesn't have a project page, i'm not sure whos lead, i think its vapier, but vapier isnt' very responsive |
38 |
[20:06:29] <blueness> so i want to help with toolchains, but can't interact with its organization |
39 |
[20:06:32] <WilliamH> blueness: if it doesn't have a project page it isn't really a project? |
40 |
[20:06:39] <dilfridge> in this particular case it's even more complicated since it's no project (no page)... |
41 |
[20:06:43] <blueness> no idea, it *is* a herd |
42 |
[20:06:49] <WilliamH> blueness: I've seen toolchain as more a subproject of base-system. |
43 |
[20:06:51] <dilfridge> and glep39 only talks about projects... |
44 |
[20:07:08] <blueness> WilliamH, is it? |
45 |
[20:07:15] <rich0> All of these issues are related. |
46 |
[20:07:30] <WilliamH> Well, it is more like just a group of maintainers. |
47 |
[20:07:36] <rich0> We have lots of loose associations of packages and devs with varying levels of formality, and varying levels of leadership/etc. |
48 |
[20:07:37] <WilliamH> udev-bugs is similar. |
49 |
[20:07:44] <blueness> glep 39 isn't so much about laying down the law as expectations |
50 |
[20:08:02] <rich0> I'll agree with that. I think there needs to be flexibility. |
51 |
[20:08:14] <rich0> Also, I think that to some degree devs need to "be bold" in Wikipedia terms. |
52 |
[20:08:28] <rich0> ie not wait around forever for an email response that will probably never come |
53 |
[20:08:44] <WilliamH> rich0: I can agree with that... I have personally been cautious about that myself in ways, but you are right. |
54 |
[20:08:48] <blueness> rich0, i think some boldness is needed too, but its really hard when you are naturally a "team player' not that i like that erm |
55 |
[20:08:51] <blueness> term |
56 |
[20:09:17] <dilfridge> the base system project page states that the base system project kinda maintains the toolchain, though it does not list toolchain as one of its herds |
57 |
[20:09:23] <blueness> classic bug to illustrated the issue -> https://bugs.gentoo.org/show_bug.cgi?id=516988 |
58 |
[20:09:23] <radhermit> what exactly are you wanting to do here? rework/redo the toolchain eclass and need feedback? |
59 |
[20:09:43] <-- dberkholz|mob (~AndChat19@gentoo/developer/dberkholz) hat das Netzwerk verlassen (Disconnected by services) |
60 |
[20:10:23] <blueness> radhermit, no just get some toolchain stuff done, eg the next one is shooting for gcc 4.9.2 stabilizatoin |
61 |
[20:10:40] --> dberkholz|mob (~AndChat19@gentoo/developer/dberkholz) hat #gentoo-council betreten |
62 |
[20:10:48] <radhermit> so there really hasn't ever been a leader coordinating such things in recent history |
63 |
[20:10:50] <WilliamH> blueness: imo if no one responds in a reasonable amount of time add yourself and go for it. |
64 |
[20:11:05] <radhermit> just the main gcc maintainer at the time |
65 |
[20:11:06] <rich0> Agree with the solution to the immediate problem. |
66 |
[20:11:21] <WilliamH> radhermit: yes, it was mostly the gcc maintainer. |
67 |
[20:11:21] <rich0> I think the real question is does this need fixing, and can it be fixed? |
68 |
[20:11:39] <blueness> radhermit, in part just filling in the nitty griddy stuff with rhill being gone |
69 |
[20:11:39] <WilliamH> rich0: I'm not sure there is anything to fix here. |
70 |
[20:11:56] <rich0> IMO I think our options are limited. If somebody doesn't want to actually step up and be a charismatic leader / etc, then at most we can just put barriers in the way of people who don't want to do that. |
71 |
[20:12:01] <blueness> the toolchain eclass is there too, but i don't want to focuse on that |
72 |
[20:12:09] <radhermit> basically someone needs to step up, and we can't really do anything as a council to effectively make that happen |
73 |
[20:12:12] <dilfridge> that is a different porblem |
74 |
[20:12:37] <dilfridge> the biggest problem is "trying to join a team, but there is noone who responds" |
75 |
[20:12:45] <blueness> radhermit, i'm okay with coordinating it, but vapier is the technical wizard here |
76 |
[20:12:52] <WilliamH> blueness: I say go for it; no one is stopping you from adding yourself. |
77 |
[20:12:55] <rich0> yup, I don't think not having any toolchain team is better than having one with a non-responsive lead |
78 |
[20:13:13] -*- dilfridge has some doubts about the wizard level since the botched dependency fixes |
79 |
[20:14:01] <blueness> okay, so zorry and i spoke about this in pm and we'd like to start coordinating toolchain |
80 |
[20:14:24] <blueness> so maybe i'll get a page up as a subproject of base system |
81 |
[20:14:31] <radhermit> sounds fine to me |
82 |
[20:14:31] <dilfridge> sounds good |
83 |
[20:14:38] <WilliamH> blueness: nothing is stopping you from formalizing it into a project. |
84 |
[20:14:44] <blueness> and then at least there'll be some point-of-contact |
85 |
[20:15:14] <WilliamH> blueness: it doesn't have to be a subproject of base-system even imo that's up to you. |
86 |
[20:15:22] <blueness> to be honest, i didn't care so much about games team or other teams being disorganized, but its worrisome when toolchain is this way |
87 |
[20:15:37] <dilfridge> yes, but it's a repetitive problem |
88 |
[20:15:52] <blueness> okay, i don't think we need a motion here or anything, i just wanted to bounce this off the council for feedback |
89 |
[20:16:05] <rich0> toolchain, portage at times, sometimes infra. There are a lot of overworked/understaffed/etc projects that are fairly core to the distro |
90 |
[20:16:06] <dilfridge> maybe we should come up with a general idea how to solve it |
91 |
[20:16:11] <radhermit> I think teams are disorganized in general, with organization being the rarity here |
92 |
[20:16:16] <blueness> zorry and i had a similar situation with hardened back in the day when gengor + solar were fading away |
93 |
[20:16:47] <rich0> To some extent it might reflect an attitude that these things are mature and don't need a lot of improvement |
94 |
[20:16:48] <dilfridge> scarabeus seems to be missing in action, so office is only me right now... |
95 |
[20:17:06] <ulm> isn't it straight forward? apply to join the project/team, and if there is no reply from project members for some time then you just add yourself |
96 |
[20:17:11] <blueness> radhermit, if you see vapier in real life, just let him know what i'm up to. and reassure him we (zorry and i) are only shooting for conservative commits |
97 |
[20:17:28] <radhermit> sure, might see him tonight |
98 |
[20:17:29] <dilfridge> ulm: that is exactly what I'd suggest to put somewhere in writing. |
99 |
[20:18:04] <ulm> lead MIA can be handled in a similar way |
100 |
[20:18:08] <radhermit> that's exactly what I've always done... other people are just too hesitant I guess :P |
101 |
[20:18:13] <WilliamH> As someone told me, the lead of a project doesn't have to be the technical wizzard. The lead just coordinates the project. |
102 |
[20:18:13] <rich0> Agree. In general if the previous team is unresponsive, just step up and make a new one, etc. |
103 |
[20:18:33] <rich0> WilliamH++ |
104 |
[20:18:46] <radhermit> really the technical wizard types should probably be doing work, not coordinating stuff |
105 |
[20:19:21] <blueness> works for me |
106 |
[20:19:26] <rich0> Agree. We don't want people who are outright disruptive, but if somebody wants to quietly do their own thing and it is making Gentoo better, then we should get out of their way. |
107 |
[20:19:32] <dilfridge> do we need / want a resolution? |
108 |
[20:19:55] <blueness> dilfridge, i don't think we need a motion here |
109 |
[20:20:06] <dilfridge> fine with me |
110 |
[20:20:08] -*- WilliamH agrees with blueness |
111 |
[20:20:10] <dilfridge> anyone else? |
112 |
[20:20:11] <rich0> I think we should try to send out a general mesage though. It isn't about rules. |
113 |
[20:20:20] <radhermit> "Ask if you can add yourself... after X amount of time with no response, add yourself." |
114 |
[20:20:23] <radhermit> something like that |
115 |
[20:20:26] <blueness> toolchain is important and i want to make sure the council is okay with trying to re-organize it |
116 |
[20:20:28] <rich0> radhermit: ++ |
117 |
[20:20:35] <WilliamH> s/x/a reasonable/ |
118 |
[20:20:52] <rich0> And they can always escalate to council if there is conflict. However, if it is person vs wall of silence, the person can just assume the answer is yes. |
119 |
[20:21:01] <blueness> radhermit, i almost always agree with that statement, but i'm not so sure when it comes to the more demanding stuff |
120 |
[20:21:08] <dberkholz|mob> +1 on that (self-adding w no response) |
121 |
[20:21:19] <blueness> eg. i'm not sure if non-response about binutils should mean anyone gets to add binutils! |
122 |
[20:21:26] <dberkholz|mob> Making that explicit if it's not yet would be a good thing |
123 |
[20:21:30] <radhermit> blueness: if some random person starts breaking important stuff they'll get noticed ;) |
124 |
[20:21:36] <blueness> true! |
125 |
[20:21:40] <radhermit> and things will become less silent |
126 |
[20:21:45] <blueness> yes yes |
127 |
[20:21:47] <dilfridge> and qa wakes up |
128 |
[20:21:49] <dilfridge> :) |
129 |
[20:22:00] <blueness> actually the way i usually add toolchain stuff is keyword masked |
130 |
[20:22:01] <rich0> radhermit: agree, right now I think we're erring on the side of too little risk, and not enough is getting done |
131 |
[20:22:10] <blueness> so it can't break stuff right away |
132 |
[20:22:19] <rich0> If things start breaking then we can deal with that problem |
133 |
[20:22:21] <blueness> but its there for testing |
134 |
[20:22:37] <dilfridge> ok I think we're all basically of the same opinion. |
135 |
[20:22:50] <dilfridge> any completely different statements? if not, ... |
136 |
[20:23:11] <blueness> good, so expect some toolchain stuff to be comeing from me and zorry, eg stabilization of gcc-4.9 etc |
137 |
[20:23:21] <radhermit> sounds excellent |
138 |
[20:23:36] <dilfridge> Next topic... |
139 |
[20:23:36] <dilfridge> 3. Policy for long-term package masks (10 minutes) http://thread.gmane.org/gmane.linux.gentoo.project/4169/focus=4198 |
140 |
[20:24:04] <WilliamH> Really what I was wanting was to get some folks to step up and update them or fix things. |
141 |
[20:24:05] <dilfridge> dunno how much we need to talk there |
142 |
[20:24:18] <WilliamH> and that is happening. |
143 |
[20:24:31] <dberkholz> i would kinda prefer to see them move to overlays if they're gonna be long-term |
144 |
[20:24:48] <radhermit> some issues relate to games that have bundled libs I'm assuming, kind of hard to fix that |
145 |
[20:24:48] <dberkholz> and use p.mask for breakage |
146 |
[20:24:49] -*- WilliamH tends to agree with dberkholz to be honest |
147 |
[20:25:09] <ulm> as long as a package is actively maintained, I don't have a problem with long-term masks |
148 |
[20:25:31] <blueness> ulm, there is one example of where that might make sense |
149 |
[20:25:32] <ulm> but we should avoid broken and unmaintained stuff sitting in the tree for years |
150 |
[20:25:42] <WilliamH> is taviso still around ? |
151 |
[20:25:44] <blueness> paxtest is a package which is *intentionally* broken |
152 |
[20:25:47] <dilfridge> as long as there is a good description what the mask is for, I don't mind either (why? impact? duration?) |
153 |
[20:25:51] <radhermit> taviso isn't around |
154 |
[20:25:53] -*- WilliamH points to the very bottom of p.mask |
155 |
[20:26:20] <radhermit> works on google security stuff atm iirc |
156 |
[20:26:37] <WilliamH> radhermit: is he still an active gentoo maintainer? |
157 |
[20:26:42] <dilfridge> in general masked packages are better gone, but there are valid reasons to keep them around |
158 |
[20:26:45] <ulm> WilliamH: nethack? that was discussed on lists |
159 |
[20:26:55] <ulm> broken by games policy |
160 |
[20:27:11] <WilliamH> no |
161 |
[20:27:12] <WilliamH> sorry |
162 |
[20:27:16] <radhermit> WilliamH: he's not even a dev afaik |
163 |
[20:27:17] <dberkholz> is he even an active gentoo dev? i don't think so |
164 |
[20:27:20] <radhermit> retired him |
165 |
[20:27:26] <WilliamH> bug 44351 |
166 |
[20:27:27] <dilfridge> # <klieber@g.o> (01 Apr 2004) |
167 |
[20:27:28] <dilfridge> yeah |
168 |
[20:27:29] <willikins> WilliamH: https://bugs.gentoo.org/44351 "games-fps/unreal engine vulnerability"; Gentoo Security, Vulnerabilities; VERI, CANT; carlo:security |
169 |
[20:28:07] <WilliamH> masked for 11 years now? |
170 |
[20:28:20] <dilfridge> actually I wonder if this still runs |
171 |
[20:28:26] <ulm> in addition these are cdrom installs, so nobody can check status |
172 |
[20:28:49] <mgorny> is unreal free these days? |
173 |
[20:28:56] <rich0> that was on the lists |
174 |
[20:28:56] <ulm> such stuff should be removed, or moved to an overlay |
175 |
[20:28:56] <rich0> yes |
176 |
[20:29:10] -*- WilliamH agrees with ulm |
177 |
[20:29:12] <rich0> I'm not convinced that games with issues like this can't be in the tree |
178 |
[20:29:20] <blueness> i agree with ulm above, the key point is whteher its being actively maintained, not the masking |
179 |
[20:29:21] <rich0> However, I think that should only be if they're maintained |
180 |
[20:29:35] <rich0> if they're maintainer-wanted and nobody can even tell if they work, then I'm fine with treecleaning |
181 |
[20:30:05] <rich0> Anything that isn't open-source should be treecleaned if not maintained - nobody can even vouch for whether it works |
182 |
[20:30:16] <WilliamH> Is "This is a fun game so I think it should be kept" valid? |
183 |
[20:30:24] <ulm> rich0: +1 |
184 |
[20:30:27] <ulm> it's a different story if there's a maintainer who can confirm that it still works |
185 |
[20:30:44] <WilliamH> ;-) |
186 |
[20:30:53] <a3li> just to be clear: something that works but puts users at risk is "maintained" by your definition? |
187 |
[20:30:59] <dilfridge> WilliamH: imho not if there's a big security problem with it |
188 |
[20:31:00] <rich0> a3li: yes |
189 |
[20:31:10] <rich0> I'm fine with it being masked and in the tree. |
190 |
[20:31:14] <rich0> Let the user make the choice |
191 |
[20:31:19] <radhermit> solution: try last-riting stuff you want to remove and see who cares ;) |
192 |
[20:31:38] <WilliamH> radhermit: I did, that's why we are talking about it. |
193 |
[20:31:44] <rich0> I'm more concerned with it being unmaintained and untestable than it being insecure |
194 |
[20:31:56] <dilfridge> a3li: what's the official security steam statement about keeping security-problematic packages in the tree masked? |
195 |
[20:32:01] <rich0> security is a continuum, with risk up to to the user |
196 |
[20:32:23] <a3li> dilfridge: practice has been to remove known vulnerable packages for years (n>5); only keep if needed for good reasons |
197 |
[20:32:24] <dilfridge> a3li: (or how is it handled now, mostly?) |
198 |
[20:32:29] <blueness> what about a package that simulates security risks as part of a test suite? |
199 |
[20:32:35] <WilliamH> When I've had security bugs on packages I maintain I've been asked to remove vulmerable versions after the fixed one is stable. |
200 |
[20:32:47] <dilfridge> blueness: that doesnt count imho, but it needs to be documented. |
201 |
[20:32:50] <a3li> dilfridge: and statement: keep that policy. |
202 |
[20:32:51] <rich0> WilliamH: sure, if there is a non-vulnerable version |
203 |
[20:32:55] <blueness> dilfridge, it is |
204 |
[20:33:04] <rich0> What if latest version is insecure, and this is unlikely to change? |
205 |
[20:33:24] <blueness> paxtest intentionlly tries to execute code in the stack, bss, data etc to see if the pax kernel catches the problem |
206 |
[20:33:27] <dilfridge> kick, kill, move to overlay |
207 |
[20:33:29] <WilliamH> rich0: I disagree with you wrt keeping vulnerable software in the tree (qa hat firmly on) |
208 |
[20:33:30] <dilfridge> ?! |
209 |
[20:33:31] <ulm> rich0: remove, unless there are good reasons for keeping it |
210 |
[20:34:01] <rich0> WilliamH: you're allowed to disagree, but I'm not changing my mind |
211 |
[20:34:19] <dilfridge> ok |
212 |
[20:34:20] <rich0> ulm: the good reason for keeping it is that it is useful |
213 |
[20:34:36] -*- WilliamH disagrees |
214 |
[20:35:10] <blueness> security depends on context, so let the user decide |
215 |
[20:35:11] <rich0> WilliamH: everything you use has a security vulnerability. They're just unknown at present. |
216 |
[20:35:22] <ulm> on the list, there was the example of sys-block/afacli which depends on a package with security issues, but there is no alternative |
217 |
[20:35:40] <dilfridge> "fun game" is in my opinion not a good reason |
218 |
[20:35:52] -*- WilliamH agrees with dilfridge |
219 |
[20:35:54] <rich0> what is the alternative to unreal? |
220 |
[20:35:58] <ulm> so if it was removed, users would still install it from elsewhere |
221 |
[20:36:16] <rich0> ulm: agree |
222 |
[20:36:22] <WilliamH> rich0: we aren't saying you can't use it, just that it belongs outside the main tree |
223 |
[20:36:25] <dilfridge> ulm: true but not our problem, since we're not providing it |
224 |
[20:36:29] <rich0> We're not making anything more secure. We're just forcing everybody to stick things in overlays |
225 |
[20:36:55] <WilliamH> rich0: we are cleaning up the main tree |
226 |
[20:36:56] <rich0> WilliamH: you prefer an overlay with no security warnings to an in-tree package with them? |
227 |
[20:37:07] <rich0> Why even have a main tree? |
228 |
[20:37:14] <radhermit> imo, if we ever move to a more multi-repo centric approach then moving to repos makes sense, currently we're not really pushing that so it doesn't imo |
229 |
[20:37:58] <dilfridge> rich0: but we're providing a maintainership / security / ... "guarantee" for the main tree, and for nothing else |
230 |
[20:38:22] <rich0> dilfridge: we're not breaking that guarantee |
231 |
[20:38:27] <rich0> We clearly disclose that the package is vulnerable |
232 |
[20:38:35] <rich0> Which is more info than users would get otherwise |
233 |
[20:39:20] <dilfridge> ok |
234 |
[20:39:26] <blueness> we have control over the tree and so can assure quality there, but not with repos, so be careful about moving stuff to repos |
235 |
[20:39:37] <dilfridge> this is not really going anywhere, we have different opinions |
236 |
[20:39:48] <WilliamH> Should we vote on whether packages with security vulnerabilities shoulb be removed from the tree if there are no fixed versions? |
237 |
[20:39:52] <dilfridge> I'd propose a vote: |
238 |
[20:40:33] <dilfridge> "may packages with security vulnerabilities remain in tree package-masked for indefinite time?" |
239 |
[20:40:48] -*- WilliamH votes no |
240 |
[20:40:51] -*- dilfridge no |
241 |
[20:40:55] <rich0> I suggest rewording |
242 |
[20:40:58] <radhermit> "assuming there are no replacements for them and they have maintainers" |
243 |
[20:41:06] <radhermit> tack that on |
244 |
[20:41:09] <dilfridge> ok, that is good |
245 |
[20:41:10] <blueness> *active* maintainers |
246 |
[20:41:16] <rich0> "May maintained packages with security vulnerabilities remain in tree package-masked for indefinite time?" |
247 |
[20:41:29] <dilfridge> "may packages with security vulnerabilities remain in tree package-masked for indefinite time, assuming there are no replacements for them and they have active maintainers?" |
248 |
[20:41:46] -*- dilfridge votes still no |
249 |
[20:41:51] -*- ulm votes yes |
250 |
[20:41:54] -*- blueness yes |
251 |
[20:41:55] <radhermit> yes |
252 |
[20:42:11] <WilliamH> Assuming above, yes. |
253 |
[20:42:42] <dilfridge> dberkholz: rich0? |
254 |
[20:42:47] <WilliamH> Now my question to the council is, is "games" an active maintainer? I would assume no. |
255 |
[20:42:55] <rich0> or radhermit's suggestion |
256 |
[20:43:02] <rich0> dilfridge: what? |
257 |
[20:43:08] <rich0> lag |
258 |
[20:43:12] -*- rich0 yes |
259 |
[20:43:58] <WilliamH> Actually, one more thing. |
260 |
[20:44:01] <dilfridge> WilliamH: given that I see activity by Mr_Bones updating EAPIs, I would say yes. |
261 |
[20:44:41] <WilliamH> looking again at the mask I cited, |
262 |
[20:44:55] <WilliamH> the mask was put there by kleiber and has never been touched. |
263 |
[20:45:03] <radhermit> WilliamH: plenty of the games are probably rotting and could be last-rited if Mr_Bones or whoever doesn't step up say they're still maintained |
264 |
[20:45:10] <WilliamH> so from that pov, kleiber did the masking. |
265 |
[20:45:23] <radhermit> I'm sure he doesn't care about every single game some random dev has added with "games" as the herd and then retired after a few years |
266 |
[20:45:42] <WilliamH> radhermit: right. |
267 |
[20:45:55] <blueness> when we're done voting, can we have a followup on the resolution |
268 |
[20:46:05] <WilliamH> He hasn't stepped up wrt the last rites I posted. |
269 |
[20:46:06] <dberkholz> i'd vote no |
270 |
[20:46:13] <blueness> i think we should add a few comments if we email this decision out |
271 |
[20:46:14] <dberkholz> overlays are fine |
272 |
[20:46:27] <dberkholz> (bad connectivity in here, sorry) |
273 |
[20:46:37] <radhermit> WilliamH: so CC games/him and wipe them later? |
274 |
[20:46:42] <WilliamH> I would add a qualification... |
275 |
[20:47:26] <WilliamH> radhermit: why cc games? it was put on g-d-a and dev |
276 |
[20:47:32] <dilfridge> ok that means 2x no, 5x yes, motion passed |
277 |
[20:47:47] <radhermit> WilliamH: I dunno, you were sounding hesitant |
278 |
[20:48:04] <blueness> dilfridge, okay now that we have a yes vote, i think we should also strongly recommend the maintainer communicate the issue to the user |
279 |
[20:48:16] <dilfridge> yes |
280 |
[20:48:18] <WilliamH> But I think we should be able to push the maintainer to get a fixed version in the tree and remove the old ones. |
281 |
[20:48:26] <blueness> say in a pkg_postint say |
282 |
[20:48:39] <blueness> there should be some mitigation of the risk |
283 |
[20:48:53] <radhermit> how much stronger can you get than a mask stating the vulnerability? |
284 |
[20:48:55] <blueness> eg. if you want to play nethack, do it in a sandbox |
285 |
[20:48:58] <WilliamH> blueness: if you do that with pkg_postinst it doesn't belong in p.mask. |
286 |
[20:49:19] <blueness> sorry your right |
287 |
[20:49:23] <WilliamH> p.mask is not permanent. |
288 |
[20:49:24] <blueness> it does say pmasked |
289 |
[20:49:33] <blueness> but then we should have the info in the pmask comment |
290 |
[20:49:43] <radhermit> if/when people unmask stuff, they should know what they're getting into |
291 |
[20:49:44] <blueness> s/info/warning/ |
292 |
[20:49:57] <radhermit> yes, as long as there's info |
293 |
[20:50:01] <WilliamH> If we are going to allow security vulnerable packages to stay in the tree they don't belong in p.mask, use postinst msgs |
294 |
[20:50:22] <dilfridge> isn't that exactly what the mask message is for? |
295 |
[20:50:25] <radhermit> yes |
296 |
[20:50:28] <WilliamH> p.mask is for things that can be fixed. |
297 |
[20:50:29] <blueness> radhermit, i'm good, it just slipped my mind that p.mask has that comment when you try to emerge |
298 |
[20:51:00] <radhermit> p.mask is for masking things, full stop |
299 |
[20:51:10] <WilliamH> I was always taught that p.mask is never permanent. |
300 |
[20:51:41] <dilfridge> ok |
301 |
[20:51:53] <dilfridge> do we want to make another vote / motion? |
302 |
[20:52:08] <creffett|irssi> just to chime in as a security type: which makes more sense, a big warning that says "security issues, unmask at your own risk" or an easily-ignored postinst? |
303 |
[20:52:09] <blueness> dilfridge, for the warning? |
304 |
[20:52:41] <dilfridge> "the security issue must be documented in the mask message, with bug number" |
305 |
[20:52:48] <radhermit> sounds fine |
306 |
[20:52:56] -*- blueness yes |
307 |
[20:53:05] -*- rich0 yes |
308 |
[20:53:07] -*- dilfridge yes |
309 |
[20:53:13] -*- radhermit yes |
310 |
[20:53:39] -*- ulm yes |
311 |
[20:53:41] <dberkholz> of course.. |
312 |
[20:53:54] <dilfridge> k |
313 |
[20:54:00] <dilfridge> anything else to say here? |
314 |
[20:54:31] <dilfridge> seems not |
315 |
[20:54:32] <WilliamH> I se this as an abuse of p.mask to be honest. |
316 |
[20:54:39] <blueness> (ab)use |
317 |
[20:55:27] <dilfridge> 4. Open bugs with council involvement (5 minutes) |
318 |
[20:55:27] <radhermit> and I wish all games released source code after X number of years |
319 |
[20:55:28] <blueness> WilliamH, it really does depend if this just becomes an easy way around trying to fix something or a last resort |
320 |
[20:55:39] <WilliamH> http://devmanual.gentoo.org/profiles/package.mask/index.html |
321 |
[20:56:27] <dilfridge> blueness: indeed. so let's start lastriting ancient stuff and see what happens. |
322 |
[20:56:30] <dilfridge> anyway |
323 |
[20:56:32] <dilfridge> 4. Open bugs with council involvement (5 minutes) |
324 |
[20:56:38] <dilfridge> bug 523828 |
325 |
[20:56:40] <willikins> dilfridge: https://bugs.gentoo.org/523828 "GLEP 42 update: Unify gentoo-news repo and rsync structure"; Doc Other, GLEP Changes; CONF; mgorny:glep |
326 |
[20:56:49] <dilfridge> any news here? |
327 |
[20:57:19] <WilliamH> dilfridge: I agree with you, let's start getting rid of ancient stuff. |
328 |
[20:57:40] <dilfridge> since we decided about it last time, maybe we should just un-cc council and leave the execution to, well, some able executioners? |
329 |
[20:57:58] <ulm> someone should update that glep |
330 |
[20:58:22] <dilfridge> the generation code is more critical |
331 |
[20:58:42] <ulm> it's a trivial change |
332 |
[20:59:02] <dilfridge> yes but someone needs to do it. wink, wink, wink... |
333 |
[20:59:27] <ulm> the proponent? :) |
334 |
[20:59:34] <dilfridge> ok seems nothing to do here. |
335 |
[20:59:44] <dilfridge> bug 503382 |
336 |
[20:59:49] <willikins> dilfridge: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council |
337 |
[20:59:59] <dilfridge> well, nothing to do here either. just move along please. |
338 |
[21:00:15] <dilfridge> 5. Open floor |
339 |
[21:00:18] <dilfridge> anyone? |
340 |
[21:00:40] <WilliamH> Well, I'll just comment. |
341 |
[21:00:55] <WilliamH> Today's debate is a good example of why devs find it hard to be bold and do things. |
342 |
[21:01:05] <WilliamH> *sigh* |
343 |
[21:02:12] <blueness> i'm not sure bold/courage is the right issue, its more respect |
344 |
[21:02:20] <blueness> and coordinating with other devs |
345 |
[21:02:32] <radhermit> about masks? I still don't see what the issue is about removing ones if no one cares enough to respond for certain pkgs. |
346 |
[21:03:02] <radhermit> that's what last rites are partially for, questioning maintainership |
347 |
[21:03:21] <WilliamH> I need to go through the thread again, but I believe I saw someone say that "x is a fun game, so this should be kept in the tree regardless of the risk" a couple of times. |
348 |
[21:03:49] <rich0> WilliamH: if it were maintained I'd agree with them |
349 |
[21:03:51] <radhermit> if they didn't want to step up and maintain it... too bad I'd say |
350 |
[21:03:53] <dilfridge> WilliamH: noone prevents you from starting last rites, and if "someone" doesnt volunteer to maintain it, then "someone" doesn't really count |
351 |
[21:03:58] <WilliamH> I also saw one that was "Now there is a new version of x that is gpl'd, but we should keep both." |
352 |
[21:04:06] <rich0> dilfridge: ++ |
353 |
[21:04:26] <rich0> WilliamH: might be worth exploring the reasoning behind such a statement in the latter example |
354 |
[21:04:41] <rich0> In general though I'm more about informing users than making choices for them |
355 |
[21:05:02] --> keytoaster (~tobias@gentoo/developer/keytoaster) hat #gentoo-council betreten |
356 |
[21:05:06] <rich0> Stuff that is just broken or which we can't be sure if it is broken or not, that is a different story. There is no value to having ebuilds in the tree that don't even build |
357 |
[21:05:13] <dilfridge> ++ |
358 |
[21:05:21] <dberkholz> are you arguing that insecure software isn't broken? |
359 |
[21:05:26] <WilliamH> The justification was pretty weak, just like the argument we had a while back about keeping module-init-utils. |
360 |
[21:05:48] -*- WilliamH thinks insecure software is dangerously broken |
361 |
[21:06:01] <radhermit> insecure software that you aren't able to fix but have to use is broken in a special way :) |
362 |
[21:06:26] <dilfridge> and with these words, it's about time... I dont think this further discussion is going anywhere. |
363 |
[21:06:37] <dilfridge> new arguments next month please. |
364 |
[21:06:46] <WilliamH> What about the "gentoo is about choice" argument? |
365 |
[21:06:47] -*- dilfridge bangs the gavel |
366 |
[21:07:01] <dilfridge> session closed |