!proj council [20:00] (council@gentoo.org) dilfridge, k_f, leio, slyfox, ulm, whissi, williamh * K_F here let's start * Whissi here roll call :) * slyfox here here darth_dilfridge or dilfridge|mobile: *ping* [20:01] WilliamH: *ping* we have a quorum, but let's wait for a couple of minutes [20:02] two electricity glitches, might end up with desktop reboots randomly, but will be back quick in that case everyone ok with me chairing? yup * Whissi is fine with ulm chairing ulm: thanks for doing it :) would be good if everybody was present when we decide on the time [20:03] Constitute the new council [20:05] the previous council had its meetings on the second sunday of the month at 18:00 UTC [20:06] would this be ok, or any suggestions for another time? personally I preferred the 19:00 UTC we had before, but sunday generally works best i'm ok with 18:00 or 19:00 I'd appreciate 19:00 UTC during summer time in Europe. [20:07] K_F: 19:00 wfm too, but if we change it, we should wait for confirmation from dilfridge and WilliamH well.. we've had that for several seasons ahead.. so should work :) [20:08] I'm ok with anything from 16:00 to 19:00 UTC as start time on Sunday's ok, let's make it sunday 19:00 UTC then, pending ack from the absent members wfm next [20:09] Vote for continuing last council's workflow considering sending call for agenda items (2 weeks in advance), sending the agenda (1 week in advance) and have the meeting focussed, i.e., have major discussions on -project ML prior to the meeting everybody ok with that? yes.. I like the workflow was there some sort of convention to /me votes? yes.. votes should be separate channel [20:10] leio: yes Yes. But can we make sure that anything we should vote on must be present x days in its final state before meeting? the above really says it needs to be 1 week in advance but yes.. I agree we have been too lenient with a few points on that yeah, we should only vote on items on the agenda, and it should be sent in advance [20:11] i'm ok with the existing workflow quick vote on the above? * ulm yes * slyfox yes * leio yes * K_F yes [20:12] (I am more concerned about having everyone on the same page, that's why I asked for for "but make sure...") * Whissi yes 5 yes 0 no, motion passed Appoint chairmen for this term's meetings we used to do 2 in a row if possible [20:13] and yes, 12 isn't divisible by 2 :) *by 7 :) so, I could do August i can do september/october [20:14] I can do November/December I'd suggest to fill it up to december only, and do the rest when the absent members are there OK. [20:15] sure.. let OBOBjan7feb for me then sounds ok ehrmm... that was that latency I was talking about but that also works for me I've noted until December, and let's do the rest by e-mail we're not in a hurry there [20:16] anything else for this item? seems not [20:17] next, GLEPs https://archives.gentoo.org/gentoo-project/message/85a3eac64894ef534e6824c2b2cea93b mgorny: you have the floor GLEP 63 update first ok, so the latest version has had no negative feedback except for ... kumba? (sorry if i recall wrong) who only didn't read it all [20:18] i think it's the best compromise i've been able to come up with after all the reiterations I am sorry for not providing my feedback yet... but I have negative feedback: i'd like to see explicit approval from security@ "2. Signing subkey that is different from the primary key, and does not have any other capabilities enabled." [20:19] => I cannot approve this: There is no *technical* reason to ban keys where S and A capability is combined. slyfox: i'd like to have seen that request 3 weeks ago Whissi: well.. for ssh there likely isn't but it is bad practice and can be tricked into signing server provided data best practice != requirement. so its not bad for revealing private key data.. but it is bad practice in broader scope of things [20:20] Gentoo uses GPG only for commits. No need to enforce S and A split. Whissi: is there a reason to have S+A keys? it is if a dev is tricked into signing random blob by signing onto service y that is reused for commit ... [20:21] likelyhood is small.. but it is bad idea so best practice should be to avoid it removing dsa is likely less technical reason for though mgorny: My argument is, that there is no _requirement_ to enforce such a limitation. Whissi: there is no requirement ever to enforce any limitation [20:22] IIRC the current wording is already a compromise, it previously said there should be a dedicated gentoo signing subkey I fully agree that best practice is different sub keys... but for a policy, I think we need technical reasons if we enforce something. doesn't mean we should be allowing everything the general idea is that we want people to have separate S+A keys as two layers of security the technical reason is signature re-use if service provides signing text [20:23] i.e. that you need to *both* authenticate via SSH and sign your commits A capability is not limited to SSH and can be used for other services and protocols of which we don't know implementation details if you use the same subkey for both, the gain is lost when the subkey is compromised so user logging into site using it can be asked to signed random blob Whissi: is there any technical reason why anyone couldn't have separate keys with S and A caps? which can be used to compromise gentoo smartcards allow for it here [20:24] sorry just in time *** darth_dilfridge (~quassel@gentoo/developer/dilfridge) is now known as dilfridge dilfridge: read the backlog please, we decided to shift to 19:00 UTC wfm good separate S and A keys are better [20:25] so I'd at least strongly recommend it ulm: I am not aware of a specific reason why you would *need* S and A in one sub key... but my point is, that there's no reason to *enforce* a split and say "Nah, sorry... your key cannot be used with Gentoo because you combined S and A" [20:26] * WilliamH is here late there is .. the security considerations mentioned above so, are we ready to vote on it now? or back to the MLs and reconsider in the August meeting? (which will be in 14 days) I'm ready to vote do we enforce separate S and C ` i should point out that current GLEP is already insufficient and is blocking infra from enforcing extended security ? I haven't seen a compelling reason to remove the strict requirement, despite it maybe not having a technical reason to be required (to not have S+A) [20:27] Whissi: the GLEP was discussed at length dilfridge: yes No. Given that you cannot split down... if user can be tricked to signed on auth, user can be tricked to sign as well. my only concern is if 2 years + grace is sufficient for those people with primary keys in safe vaults -ed but seems like it is leio: #4 is also on my list as a general note i find docs lacking exact commands to execute to get a valid setup. i wonder if it's just me :) [20:28] its basics.. you really should know it as a dev I also find documentation lacking for gpg, but I don't know if that belongs in the glep. can't really update docs when you can't agree on a spec but plenty of docs around.. start with gnupg manual and GPH unless you want to write docs against the spec, or docs based on draft spec, or docs that are just plain wrong [20:29] mgorny: https://gitweb.gentoo.org/data/glep.git/commit/?h=glep63-updates&id=ea9b2428308bd428904a979d507245dd1d8c4d0f is the current version? Regarding "4. Expiration date on key and all subkeys set to no more than 900 days into the future." => There's no technical reason to ban primary key which is valid for >=3y. [20:30] as a general note, I dont like the trend lately where rewuiring certain common sense id out window and people rewuiesting policied for basic things, and the reduced requirementd of developers Setting an expiration date is best practice. But it is best practice for the life in web of trust which doesn't apply for Gentoo: In the web of trust I'll meet someone somewhere. Maybe just ONCE in my lifetime. Then it make sense to use the expiration date as something like a "dead man switch", i.e. if this person cannot proof access to key material every x years by updating expiration date, I know that this trust channel is dead and that I need to establish a new one. However, in Gentoo, someone with SSH access can add/remove keys all the time. We don't use expiration time and have no need for something like a "dead man switch" because we have undertakers which will ensure that non-active maintainers will be removed in time. [20:31] ulm: lacking one commit, just pushed the update s/maintainers/devs/ * WilliamH would rather not have a forced expiration on the primary key Whissi: the keys are used not only for gentoo [20:32] we assume people are using the same key for mails etc. do we really have to have this debate "how much can we water down things semi-safely?" ok, unless we send it back to the mailing list, we won't be able to update the glep during the meeting and wr likely want to use wot in futurr for new dev introductions etc It's kinda silly not to require something stricter than actually precisely needed people are using those practices outside gentoo, and that's why they should be good motion: accept the GLEP 63 updates in https://gitweb.gentoo.org/data/glep.git/commit/?h=glep63-updates&id=bf99712e1e5e9b68a70be1aa93669e2f7192501b [20:33] K_F: you need a better mobile irc client :P please vote * ulm yes * K_F yes [20:34] do those commits match what was sent to gentoo-dev as [PATCH v5 ...] + v5-amendment wrt uid? vote no if you think that it should go back to lists mgorny: Exactly, and because of 900d I'll get problems because my key is used somewhere else where it won't be automatically updated. Enforcing <3y for no reasons will add pain for no reason. leio: they should * slyfox yes Ermm, I am not just finished?! And you are starting a vote? * dilfridge yes Thanks for nothing. * Whissi NO leio: i.e. rendered version in https://dev.gentoo.org/~mgorny/tmp/glep-0063.html Whissi: by the workflow we just approved, the meeting should be focused [20:35] discussion really should be on ml to begin with major discussions on -project ML prior to the meeting * leio yes leio: yes, i've sent git patches from that repo WilliamH? [20:36] * WilliamH no that's 5 yes and 2 no motion passed [20:37] I don't mind expiration on my subkeys, but I would rather not put one on my primary key guys, this point was discussed at length for several weeks [20:38] next agenda item You can extend the date of that primary key at any time, for example when you extend it for the subkeys for which you don't mind it. dilfridge: yes maybe worth having F.A.Q. explaiing rationale and ways out of common problems [20:39] GLEP 77 "general resolution" that one has an official draft at https://www.gentoo.org/glep/glep-0077.html Can you put one on a primary that didn't have one before? * WilliamH doesn't want to make a third key WilliamH: yes, just like on subkey given the short terms of council to begin with I dont wee much reason for this WilliamH: but plz, after the meetig glep77; here it seems that the community at large didn't have any specific requests [20:40] (and yes, I miss my blackberry for typing) * Whissi votes YES on GLEP 77 there were a few concerns about large numbers but without any suggestions on what to change mgorny: the question is if we need such a thing [20:41] yes, that's one of the questions I'd be interested in a way to gauge the opinion of other developers in a better way than perhaps just a vocal minority lobbying and others not caring; this doesn't provide it, but could be worked on separately once needed, especially when the voting systems get extended to support more than a ranking schulze but well, it won't get in the way of any normal workflow, I think i think it's a good thing to have in general as it puts a formal way for electorate to enforce their wishes [20:42] leio: the developer opinion is a "bimodal distribution", i.e. different, disjunct groups... otherwise it couldnt be that both Whissi and me have a seat The existing way to enforce those wishes is to participate in the next elections accordingly. This is how this usually works let me put it like this right now, if some people disagree with Council, they express their opinion on mailing lists [20:43] The reason why I support GLEP77 is because I'm sick of noisy people claiming they speak for the majority without any proof of that they have no formal way of doing it, so they have to stay with anger and 'demonstrations' and how'd you call it even if they don't have any real support, they create negativity (and we don't have any way of gauging whether they do represent majority or not) [20:44] that will happen one way or other anyways its not going to be solved by rhis glep so give them a way to prove they have support of the majority, and shut up otherwise :P procedure like GLEP 77 means we say 'if you believe so, please use general resolution' so they either do it, and win, or they get proven 'community disagrees with you' I don't mind something like it, if appropriate safeguards are in place that don't end up with those carding to void a decision vote, others obviously don't worry about it and end up not voting, and then of course the void choice wins; I'm not sure 2:1 of who voted is enough to prevent such a situation, but it's something. they get their say in next vote that is <12 months away [20:45] K_F: last term was painful enough, 12 months can be very long *** rich0 (~quassel@gentoo/developer/rich0) has quit: Quit: rich0 its really not K_F: bad Council can do a lot of harm in 12 months so, looks like the council's opionion is split? should we just vote? [20:46] *opinion not saying it's something that will happen but i believe we owe people that * Whissi wants to vote yeah dont think there is more to discuss as such * K_F no I'm less worried about the "bad council" case since people did get elected +1 for voting let's vote motion: accept GLEP 77 * K_F no * slyfox yes * dilfridge yes [20:47] * Whissi yes * ulm abstains leio, WilliamH ^ leio: the glep had example numbers in it, sec [20:48] leio: 2:1 means at least ~50 devs voting yes yes, I looked at those; I'm just not sure percentages from who votes vs percentage from electorate count is ok though ultimately it means people need to be lobbied to care, then. [20:49] leio: that's why we combine both * leio yes WilliamH? * WilliamH yes motion passed with 5 yes votes, 1 no vote, one abstention [20:50] anything else for this item ? One concern I have: some reactionary devs not liking an upstream change and using this to force our devs to carry patches to do something a "Gentoo" way that is not supported upstream. do we assume that's enough or do we need a full dev vote to confirm? we'll do GLEPs 1 and 14 with the open bugs mgorny: I doubt that's needed since we only restrict powers of the council [20:51] dilfridge: i agree s/restrict/delegate/ if people disagree, they can use GR to void approving GR ;-) mgorny: no full dev vote, I would say but we can vote on that too :) [20:52] motion: have a full dev vote for approval of GLEP 77 * ulm no * dilfridge no * Whissi no * slyfox no [20:53] * K_F no leio: WilliamH: ^^ I haven't thought of these bureaucratic nuances, so * leio abstain anyway, 5 no votes so the motion cannot pass [20:54] * WilliamH no 6 no votes, 1 abstention let's move on Default locations for repositories, distfiles, and binpkgs https://archives.gentoo.org/gentoo-project/message/080ac812b76851f53230d88a66c0fd3b whee last message in dev was https://archives.gentoo.org/gentoo-dev/message/256c720b5e16b00304645cbacfc52413 i.e.: [20:55] /var/db/repos/gentoo /var/cache/distfiles /var/cache/binpkgs anyone wants to discuss it further here, or should we just vote on this one? [20:56] Can somebody explain why FHS uses singular (/var/log) and we use plural (repos, distfiles)? Whissi: hysterical raisins Whissi: huh? vote, we've had enough bikeshed i.e. it doesn't really matter, and there's no point in changing paths already in use for pl vs s Whissi: FHS uses plural too e.g. /media [20:57] The only thing I am unclear is /var/cache/distfiles vs /var/cache//distfiles... or /var/games I don't like the color of "db" vs "lib" and am not sure binpkgs are exactly reproducable to be suitable for cache. I'd be happy with /var/lib/repos/gentoo and the rest as mentioned above. vote on original first and then see if we need follow-up votes? [20:58] as a side question, how soon is our next meeting; second tuesday already? leio: Think about clients... I you are on a client using binhost, you will fetch packages from a binhost. This is the same location... and here, /var/cache makes sense. second sunday* *** rich0 (~quassel@gentoo/developer/rich0) has joined channel #gentoo-council *** ChanServ (ChanServ@services.) has changed mode for #gentoo-council to +v rich0 K_F: yes, let's vote on the proposal above * K_F yes * leio no and if it's rejected we can have separate votes on the single paths * ulm yes * dilfridge yes * slyfox yes * Whissi yes [20:59] WilliamH: ^^ one sec [21:00] * WilliamH yes i find it unusual that portage or releng team did not just pick some default path on their own. no spec should require using static path anyway. but if it takes concil to decide on a path then sure. [21:01] it's the usual gentoo problem I count 6 yes votes and 1 no vote Whissi: sure. that could happen, but there was too much bikeshed motion passed if anyone *but* the council makes a decision, someone else will start screaming. That's why we ended up with it. one day we'll have to sign up on bash updates... [21:02] dilfridge: we already do.. in EAPIs slyfox: it's only the default paths anyway right ulm: exactly :) I guess we should have the portage team make the announcement, once they've updated Well, it affects documentation so an official decision make sense in this case, not? oh, one more point name of the snapshot [21:03] curently it's portage-yyyymmdd or so gentoo-.... change it to gentoo-repo-yyyymmdd? wfmk sounds ok ulm++ i think infra was already planning on changing it to gentoo-YYYYMMDD, with fallback symlink +1 for gentoo-... no need for "-repo" suffix I think. mgorny++ both sound ok to me [21:04] gentoo is more than just the ebuild repository we already name it gentoo-YYYYMMDD for squashfs * WilliamH doesn't really care either way I hope they make sure sufficient testing of migration paths and such is conducted before committing... ok, quick vote on "gentoo-" please * slyfox yes [21:05] * Whissi yes K_F: the idea is to have - something that can be used for other repos as well (possibly including future official gentoo repos * K_F yes * leio yes * ulm yes * WilliamH yes * dilfridge yes [21:06] unanimous let's move on Explicit CoC agreement for members of special projects https://archives.gentoo.org/gentoo-project/message/fd06589b97e2d53162b23342f4dceec5 That's really unnecessary What does that mean? I would say anyone contributing or acting as member of the Gentoo community must agree on CoC. [21:07] Whissi++ CoC is the https://archives.gentoo.org/gentoo-project/message/fd06589b97e2d53162b23342f4dceec5 specifically, right? Whissi++ gentoo's CoC is very handwavy and informational. there is not much to agree to slyfox: yes, that's my url from above? gah, sorry [21:08] https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct slyfox: sadly you are right. slyfox: that's another topic for another time though. ok anyone who wants to in favour of the proposal? *speak just making sure vote does not mean much :) motion: a) Make explicit agreement with CoC mandatory for being part (i.e. also existing members) of Comrel, Infra, Recruiters and QA. [21:09] please vote * K_F no * ulm no * slyfox no * dilfridge abstain * WilliamH no * Whissi no * leio no [21:10] 6 no votes, 1 abstention motion doesn't pass I think we don't need to vote on b) In concordance with a) make explicit agreement an (unenforced) part of the first Council meeting. ulm++ Do we respond to those requests? [21:11] but of course, I fully agree with and support the CoC Whissi: it is in summary OK. next? next; [21:12] open bugs K_F: any progress on bug 637328? ulm: https://bugs.gentoo.org/637328 "GLEP 14 needs to be updated"; Documentation, GLEP Changes; IN_P; mgorny:security ulm: some, but not ready yet k bug 661504 https://bugs.gentoo.org/661504 "GLEP 1: Small update to reflect current practice"; Documentation, GLEP Changes; CONF; ulm:glep we've removed the requirement that glep must be discussed on gentoo forums [21:13] acknowledged good by decision of glep editors, so just for the record here ack, sounds good OK. I'll close the bug then but yes, each GLEP change should be mentioned like this in council meeting [21:14] bug 661058 ulm: https://bugs.gentoo.org/661058 "GLEP 63 updates @ Jul 2018"; Documentation, GLEP Changes; CONF; mgorny:glep bug 659894 ulm: https://bugs.gentoo.org/659894 "GLEP 77: Gentoo General Resolution"; Documentation, New GLEP submissions; CONF; mgorny:glep ^^ both discussed in previous items bug 642072 ulm: https://bugs.gentoo.org/642072 "Joint venture to deal with copyright issues"; Gentoo Council, unspecified; CONF; mgorny:council no progress since last meeting Open floor [21:15] anything for open floor? ulm: what was the state of last review of copyright glep? trustee election results just got out fyi seems it was a mis-send with encrypted files though [21:16] congrats to robbat2, antarus, bman, and prometheanfire K_F: better encrypted than with confirmation ids ;-) [21:17] mgorny++ hrhr mgorny: as I said, no progress on the copyright GLEP but I'll start working on it again now, with new council and trustees [21:18] ulm: yes, please try to get it for the meeting 1+ mo from now ;-) looks like there are no further items for open floor [21:19] i think that's the last big thing on my list Just a general comment... about the comment above wrt if someone else makes a decision besides us people scream.. In theory that's right, developers and teams can make their own decisions... [21:20] We can support decisions that developers make maybe, by deferring to the appropriate team if something gets put on our agenda. [21:21] yes that is true In other words, just vote to allow x team to make the decision. So that's another option maybe. [21:22] in terms of wording yes, in terms of workload no but I'm all for it dilfridge: ? What do you mean in terms of "workload" no well things still end up with the council that way just the next time maybe not [21:23] we have done so with qa from time to time yes That's all I had, just a general comment. [21:24] Whissi: i would like to ask you to reread the first paragraphs of your manifesto, https://archives.gentoo.org/gentoo-project/message/82745566f899431777b6fced00f27e4b mgorny: I think that doesn't belong here so, no further points? [21:25] * dilfridge wants to have dinner ulm: thanks for chairing * ulm bangs the virtual gavel :)