Re: [gentoo-dev] crypto@ packages up for grabs
On 08.01.2020 22:16, Mikle Kolyada wrote: > These are up for grabs due to the crypto@ project being disbanded. Going over the list once more, I'll also take > app-crypt/nasty > dev-libs/npth -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] crypto@ packages up for grabs
On 08.01.2020 22:16, Mikle Kolyada wrote: > These are up for grabs due to the crypto@ project being disbanded. > > app-eselect/eselect-pinentry I'll take this as well. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] crypto@ packages up for grabs
On 09.01.2020 09:09, Lars Wendler wrote: > On Thu, 9 Jan 2020 00:16:13 +0300 Mikle Kolyada wrote: > >> These are up for grabs due to the crypto@ project being disbanded. >> ... > > I've taken these… but I'd appreciate it if someone wants to > co-maintain them with me. I can join on >> app-crypt/gpgme >> dev-libs/libassuan >> dev-libs/libgpg-error >> dev-libs/libksba -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] News Item: Desktop profile switching USE default to elogind
On 28.10.2019 13:36, Brian Evans wrote: > On 10/27/2019 10:19 PM, Andreas Sturmlechner wrote: >> Rebuild all affected consumers and remove sys-auth/consolekit: >> >> # emerge --ask --changed-use --deep world missing set operator in line above as well >> # emerge --unmerge consolekit -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: News item about interoperability restrictions of >=net-p2p/syncthing-1.2.0
On 7/15/19 1:39 PM, Marek Szuba wrote: > 2019-07-18-syncthing-update-incompatibility.en.txt > > Title: Syncthing 1.2.0 and newer do not interoperate with 0.14.45 and older > Author: Marek Szuba > Posted: 2019-07-18 > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: net-p2p/syncthing > > Starting with version 1.2.0, Syncthing always uses large, variable-sized, > blocks to index and transfer files larger than 256 MiB [1]. Syncthing > version 0.14.45 and older will initially appear to accept files scanned > with large blocks, but will later panic during some internal file > operations. Do NOT enable large blocks in clusters with devices still > on v0.14.45 or older, Should we be more specific as to how not to enable it here? is it a USE-flag? does it require a package mask for newer versions if it is always used for the newer ones? Also cluster immediately made me think of server<>client relationship and this only affecting server side, which probably doesn't fit well with syncthing, but admittedly I don't use it so not familiar with the nomenclature. > e.g. Debian Stretch servers using official packages. > > [1] https://docs.syncthing.net/advanced/folder-uselargeblocks.html -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo on Discord
On 4/30/19 7:32 PM, Matthew Thode wrote: > One thing that may help is to have multiple levels of control defined. Indeed, this distinction is interesting. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo on Discord
On 4/30/19 7:24 PM, Michał Górny wrote: >>> I've contacted the author and the author refused to change it. >>> The claim is that 'PR team runs it', '8 Gentoo developers have admin >>> rights', 'i.e. it is sanctioned by the project itself'. I was suggested >>> that if it's not official, we should close it instead. >> If that is how it is perceived I'd be in favor of outright closing it at >> least >> > I suppose the problem boils down to 'perceived by whom'. I'd say a reasonable person, which the author of the article doesn't sound like, but the article doesn't provide sufficient information for third parties to judge per se. I guess a more interesting question is why communication is increasingly fragmented across multiple chat systems; it reminds me of https://xkcd.com/1810/ -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo on Discord
On 4/30/19 7:17 PM, Alec Warner wrote: > On Mon, Apr 29, 2019 at 4:34 PM Dirkjan Ochtman wrote: > >> In this article on chat services used for OSS: >> >> https://catfox.life/2019/04/28/keeping-libre-software-accessible-to-all/ >> >> I was surprised to see a mention of Gentoo as a project that uses "Discord >> as an official method of communication". When I searched, I indeed found >> https://discordapp.com/invite/gentoo. However, I'd never before heard we >> were using Discord (and didn't find any mentions of Discord on the -dev or >> -project mailing lists). >> >> Is this indeed an official venue? It's not listed on >> https://gentoo.org/support/ (which does mention IRC). >> > I'm trying to understand why it matters. Lets assume we decide it is, or is > not. What would you expect the project to do differently? > > I feel like the whole thread is trying to debate something that doesn't > really matter, so I'm trying to grasp why we are having this conversation. > > -A > > It matters if things are perceived as official Gentoo and causing a negative reputation as in the article in this thread. One some level that actually goes to trademark infringement that should be of interest to the foundation, but the issue is broader than that. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo on Discord
On 4/30/19 7:18 PM, Michał Górny wrote: > On Mon, 2019-04-29 at 22:34 +0200, Dirkjan Ochtman wrote: >> In this article on chat services used for OSS: >> >> https://catfox.life/2019/04/28/keeping-libre-software-accessible-to-all/ >> >> I was surprised to see a mention of Gentoo as a project that uses "Discord >> as an official method of communication". When I searched, I indeed found >> https://discordapp.com/invite/gentoo. However, I'd never before heard we >> were using Discord (and didn't find any mentions of Discord on the -dev or >> -project mailing lists). >> >> Is this indeed an official venue? It's not listed on >> https://gentoo.org/support/ (which does mention IRC). >> > I've contacted the author and the author refused to change it. > The claim is that 'PR team runs it', '8 Gentoo developers have admin > rights', 'i.e. it is sanctioned by the project itself'. I was suggested > that if it's not official, we should close it instead. If that is how it is perceived I'd be in favor of outright closing it at least -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo on Discord
On 4/30/19 6:55 PM, Mart Raudsepp wrote: > Probably what it is - social media under PR admin. Do you > consider facebook as official communication medium too? No, Facebook is definitely not an official communication medium. However you might argue that a given Facebook Page is official if it is controlled by Gentoo. But this is where you get into semantic discussions. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo on Discord
On 4/30/19 6:04 PM, Kristian Fiskerstrand wrote: > On 4/30/19 9:05 AM, Cynede wrote: >> Right, alike reddit, twitter, facebook and other PR channels. It's >> "official" because it's controlled by PR Gentoo team, > > No, that does not make anything official. Official would mean a place we > would place an announcement ourselves and mostly comes down to our > website and the announce mailing list. > > Basically; What is considered an official communication channel should > be analogous to SEC Regulation Fair Disclosure (FD). > > Now, that Gentoo developers in some way have anything to do with other > channels is a good thing, but its not an official communication channel > for Gentoo. > Ok, the above was a bit too compromised. The official communication channels within the project of course also includes the ways the developers are expected to work together; i.e also bugzilla and the various required mailing lists. Whether IRC is official communication channel is more of an interesting discussion; as it is not a required medium for developers, but it is definitely close due to the amount of work that is being done over it. but from a PR perspective the official communication channels are the website and mailing list announcements (that for us acts as press releases) -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo on Discord
On 4/30/19 9:05 AM, Cynede wrote: > Right, alike reddit, twitter, facebook and other PR channels. It's > "official" because it's controlled by PR Gentoo team, No, that does not make anything official. Official would mean a place we would place an announcement ourselves and mostly comes down to our website and the announce mailing list. Basically; What is considered an official communication channel should be analogous to SEC Regulation Fair Disclosure (FD). Now, that Gentoo developers in some way have anything to do with other channels is a good thing, but its not an official communication channel for Gentoo. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On 4/26/19 12:52 AM, Rich Freeman wrote: > gpg is the same. Yes, the concepts are great once you understand them > (though the smartcard standard is needlessly limited). The actual > command line interface is just painful to use if you're doing more > than just encrypting/signing something. If you want to use something > other than your default key you pass --default-key, which seems odd, > since you don't really want to change your default, and there isn't > any way to pass a "non-default" key. I get having a default key > option in a config file, since that is what it describes. And then > there is all the interactivity, which makes sense to have as an > option, but not without a command line override. I mean, the FTP > interactive console also makes sense but there is a reason everybody > uses curl/wget/etc, and not FTP+expect. default-key is exactly for config file, for other operations you use -u/--local-user -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On 4/26/19 12:26 AM, Rich Freeman wrote: > I mean, I'd expect any Gentoo dev to be able to figure out how to use > git as well, but git also has a terrible command line interface, Not really, it is quite intuitive once you understand the basics. > > Personally I think we ought to make it easier to just use the > Nitrokeys we spent all this money on in a more secure manner than just > leaving primary keys lying around on hard drives, The decisions involved are disjunct here, but leaving around on hard-drives is generally a bad idea irrespective of any nitrokey, and certainly something expected not to happen from a Gentoo Dev to begin with (for primary key material at least) -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On 4/25/19 10:48 PM, Rich Freeman wrote: > I think a big problem is that gpg is sorely lacking in command line > commands/options for key management. Almost anything having to do > with key management involves a back-and-forth console interaction. Yes and no.. One issue is it depends on context, which differs, for generating a new TPK everything is easy to document, but from there things gets curious for how to adjust existing key material. The main issue is security can't be solved technically, it is ultimately requires social interaction and proper procedures / policy (if you haven't seen the movie Crimson Tide, now is the time to do so, it is the only movie I'm aware of that is singularly about proper security procedure) E.g --quick-add-key can be easily used to generate a new signing subkey from a default generated key, but why not just do an addkey in interactive mode? Quite frankly I'd expect a Gentoo Developer to be able to manage the gpg interface. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] util-linux build time increase?
On 2/28/19 10:16 AM, Joshua Kinard wrote:
> Is /usr/local/bin/emerge_time.sh a custom script of yours, or is it
> available somewhere else? I usually use genlop to measure merge times, but
> that package has a lengthy set of perl dependencies that I don't want to
> pull into the catalyst seed chroots I am building/updating.
Its just a a quick way to propagate this wrapper on multiple computers;
# cat /usr/local/bin/emerge_time.sh
#!/bin/bash
if [[ $# < 1 ]]; then
echo "Usage: ${0} ";
exit;
fi
qlop -tHvg "$1"
--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] util-linux build time increase?
On 2/21/19 1:29 PM, Guilherme Amadio wrote: > On Thu, Feb 21, 2019 at 04:36:24AM -0500, Joshua Kinard wrote: >> Does anyone have an idea why util-linux's build time would go up >> significantly from 2.32.x to 2.33.x? It may be a MIPS thing, as my x86_64 >> box shows no discernible change in build times between the same versions. >> Can any other archs check w/ genlop to see if they see a large jump in build >> time? >> At least on a couple of my amd64 there isn't any noticeable slowdown. similar to your own observations. E.g this laptop (Linux ares 4.9.155-gentoo-kf0 #1 SMP Sun Feb 10 17:01:51 CET 2019 x86_64 Intel(R) Xeon(R) CPU E3-1535M v5 @ 2.90GHz GenuineIntel GNU/Linux) says # /usr/local/bin/emerge_time.sh sys-apps/util-linux util-linux-2.28.2: Thu Feb 9 18:52:32 2017: 1 minute, 9 seconds util-linux-2.28.2: Thu Feb 9 19:56:31 2017: 1 minute, 37 seconds util-linux-2.28.2: Fri Apr 21 20:05:52 2017: 35 seconds util-linux-2.30.2: Thu Nov 23 18:59:23 2017: 55 seconds util-linux-2.30.2: Mon Dec 4 22:08:07 2017: 38 seconds util-linux-2.30.2: Wed Jan 10 20:44:39 2018: 44 seconds util-linux-2.30.2-r1: Mon Mar 12 19:20:06 2018: 46 seconds util-linux-2.32-r4: Sun Jul 15 15:51:21 2018: 50 seconds util-linux-2.33-r1: Sun Jan 6 20:53:29 2019: 46 seconds util-linux-2.33-r1: Thu Feb 21 22:16:25 2019: 53 seconds -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] AUTHORS file for portage repository
On 11/27/18 9:07 PM, William Hubbs wrote: > All, > I just picked a random msg to reply to on the thread. > > Here is the updated AUTHORS file I would like to commit. > > William Lets put it on agenda for next council meeting and let the discussion go until then. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 11:35 PM, Chí-Thanh Christopher Nguyễn wrote: > > I fully understand why in the general case this is considered undesirable. > > But in very specific cases it can make sense to err on the side of > caution, and the rigid -Werror policy gets in the way. This is what the > initial message by bircoph suggested. I would argue that this depends on the upstream; some upstreams doesn't know the downstream implications of this and are slow at responding at issues. Others are very clear about it and this is the desired behavior; and they actually fix it quickly when reported. There is a difference here, and on some level that is up to maintainer privilege to evaluate the difference. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 11:31 PM, Rich Freeman wrote: > For more critical packages (like the example of zfs) whether it > compiles and installs isn't 1/10th as important as whether it eats my > data... exactly -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 11:21 PM, Kristian Fiskerstrand wrote: > On 9/10/18 11:19 PM, Chí-Thanh Christopher Nguyễn wrote: >> It is indeed an insurmountable task to write code that is warning-free >> from the beginning across architectures, compiler versions, etc. But >> that is not the goal anyway. It is examining the situation and taking >> appropriate action, and then applying a change to no longer cause that >> particular warning (or make it non-fatal if the warning is bogus/harmless). > > sure, but for upstreams that make this an explicit goal, do we really > want to apply additional downstream pataches with the additional > complexity that carries for build system (autotools re-generation that > might make it unsupported upstream etc) ? > in all fairness, for one of my upstream packages, SKS, we make -Werror part of non-release versions but remove it for releases. But there are certain crypto related packages where you want the ensure it is properly handle altogether, in particular where RNG is concerned as there isn't really a proper way to test for it afterwards.. for other packages the test suite is of great importance.. if the tests are proper there isn't a great need, but sadly packages today doesn't really come with proper test suits -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 11:19 PM, Chí-Thanh Christopher Nguyễn wrote: > It is indeed an insurmountable task to write code that is warning-free > from the beginning across architectures, compiler versions, etc. But > that is not the goal anyway. It is examining the situation and taking > appropriate action, and then applying a change to no longer cause that > particular warning (or make it non-fatal if the warning is bogus/harmless). sure, but for upstreams that make this an explicit goal, do we really want to apply additional downstream pataches with the additional complexity that carries for build system (autotools re-generation that might make it unsupported upstream etc) ? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 11:04 PM, Kristian Fiskerstrand wrote: > On 9/10/18 11:01 PM, Mike Gilbert wrote: > >> It's quite a bit harder for a user to remove -Werror from the build >> system, assuming they can even interpret the error output. >> > > Sure, but at some point it matters whether this is a leaf package or > something that is a core dependency. > > That it wasn't caught before being stabilized on several arches was > indeed bad, but that likely says more about our stabilization procedures > than the quality of the underlying package's upstream choices. > What I'm saying here is mostly that more tinderboxing is a good thing to capture all kinds of issues, and for upstreams being responsive Gentoo is a good way of providing valuable input. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 11:01 PM, Mike Gilbert wrote: > It's quite a bit harder for a user to remove -Werror from the build > system, assuming they can even interpret the error output. > Sure, but at some point it matters whether this is a leaf package or something that is a core dependency. That it wasn't caught before being stabilized on several arches was indeed bad, but that likely says more about our stabilization procedures than the quality of the underlying package's upstream choices. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 10:56 PM, Kristian Fiskerstrand wrote: > On 9/10/18 10:51 PM, Matt Turner wrote: >> Consider again the bug that started this. The maintainer had not built >> this configuration. None of the arch teams had built this >> configuration until I did for the last architecture Cc'd. The patch >> committed doesn't change anything installed on the system, if not for >> Werror preventing the code from building. > > one way to look at it though, is that it is a valuable upstream > contribution that this configuration produces the error, so Gentoo is > contributing to upstream development because of it. > Adding to this, that arch testing for stabilization didn't catch this might say more about our stabilization procedures than the quality of the upstream package (that in this case routinely includes patches to fix these issues). And they are mostly cought in testing (~arch) -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 10:51 PM, Matt Turner wrote: > Consider again the bug that started this. The maintainer had not built > this configuration. None of the arch teams had built this > configuration until I did for the last architecture Cc'd. The patch > committed doesn't change anything installed on the system, if not for > Werror preventing the code from building. one way to look at it though, is that it is a valuable upstream contribution that this configuration produces the error, so Gentoo is contributing to upstream development because of it. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test
On 08/21/2018 10:06 PM, Juippisi . wrote: > On Tue, Aug 21, 2018 at 3:57 PM, Davide Pesavento wrote: > >> >> Wait, are you saying that I can set USE=-test while FEATURES=test is >> enabled? Is that a valid combination? >> > > It's really annoying if you try to make some conditional stuff apply using > "if use test;" because it doesn't work with FEATURES="test". > if it doesn't work with FEATURES="test" but is othervise verified it might be a case for a RESTRICT=test instead? That said, you'll find RESTRICT="!test? ( test )" in plenty of ebuilds, disabling the test phase if the use flag is unset altogether. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: What means bup?
On 07/18/2018 02:10 PM, Alexis Ballier wrote: > I often find myself in the > need to use/invent some abbreviation in order to fit the limit. > Considering this is an error, this sends the message that short is > preferred over clear. Or that the summary should be concise and a longer proper description can be written in the body of the commit message instead. Potentially mixed in with multiple commits for different logical changes etc etc. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On 07/18/2018 11:55 AM, Ulrich Mueller wrote: > I therefore suggest the following scheme: The full scheme looks good to me -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree
On 07/09/2018 11:14 PM, William Hubbs wrote: >> Though I do prefer /var/lib or /var/cache over /var/db, simply because >> /var/lib is actually in FHS. > Agreed, /var/db I guess is a Gentoo invention of some kind? well, for a gentoo-based PMS that might not be a bad thing.. but I'd say cache is out of the question, whether it is /var/lib or /var/db doesn't matter too much to me, but it needs to be announced properly ahead of time to adjust LVM2 volumes etc etc if impacting existing systems... I'd mostly argue any such change should only affect new systems -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
On 07/09/2018 10:40 AM, Michał Górny wrote: > Therefore, I'd like to start enforcing (at the level of the hook > verifying signatures) that all commits made to gentoo.git (and other > repositories requiring dev signatures) are made using @gentoo.org e-mail > address (for committer field). Sounds like a good thing, go for it! -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News Item: Portage rsync hardlink support
On 07/08/2018 11:59 PM, Zac Medico wrote: >> It used to make a special statement for a new stable Portage and >> strongly recommended that it be emerged first. It should probably do the >> same for openpgp-keys-gentoo-release. > Sure, but it this case we have a chicken-and-egg problem, because I > needed the latest openpgp-keys-gentoo-release installed but in order to > do that I had to sync, but then verification failed because I didn't > have the latest openpgp-keys-gentoo-release. We're hopefully attributing that to a startup problem. Obviously as we go along we need to have proper key rollover procedures so this should never happen including backup keys. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
Re: [gentoo-dev] News Item: Portage rsync hardlink support
On 07/08/2018 08:10 PM, Rich Freeman wrote: > Again, the current portage support for git verification doesn't check > any developer keys. right, so why would it be material for a news item improving the status quo for those synching using the official rsync method? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News Item: Portage rsync hardlink support
On 07/08/2018 07:34 PM, Rich Freeman wrote: > The patch is to do the verification before > checking it out so that if it fails the tree is left in a > last-known-good state (at least as seen by tools at the filesystem > level - the fetched bad commits would still be visible to git). there is still a very different key management issue discussed. If a developers credentials are removed from Gentoo LDAP for some reason it will be stopped from pushing new commits immediately, but the third party verification can be valid up until that point and after since the developer might not have published a revocation certificate. the git sync method will need a way to distinguish this for end-users, but the proper rsync synchronization will be able to trust the data at the point we say it is OK. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v4 00/14] GLEP 63 update
On 07/07/2018 03:11 PM, Michał Górny wrote: >>> 1. SHA2-series output digest (SHA1 digests internally permitted), >>>256bit or more:: >>>personal-digest-preferences SHA256 >> Is the config line still needed with current GnuPG versions? > I'll let others answer that. In any case, the point itself (requiring > SHA-2 digest) makes sense. The RiseUp standard requires all self- > signatures to be SHA-2, and I was planning on verifying that as well. > no, SHA256 in this context is already default, and it doesn't impact cert-algo that you seem to go on about. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News Item: Portage rsync hardlink support
On 07/08/2018 08:53 AM, Michał Górny wrote: > Is safe git syncing implemented already? If not, maybe finish it first and > cover both with a single news item. Git is going to be more efficient here, > so people may want to learn they have an alternative. Why complicate things, and increase wait for something that benefits most users, just to give alternatives to a few using non-default sync mechanism. Securing git distribution is a whole different ballpark. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News Item: Portage rsync hardlink support
On 07/08/2018 08:08 AM, Zac Medico wrote: > For example, if signature verification fails during a > sync operation, the new hardlink behavior will preserve the previous > state of the repository. This seems like a nice improvement, thank you for implementing it and making it the new default. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On 07/06/2018 01:34 PM, Ulrich Mueller wrote: > Note that the revocation certificate is still listed under > recommendations only, so devs need not create one. Making this a > requirement would be a real improvement, IMHO. From a Gentoo perspective, we can "revoke" it by deleting it from LDAP and as such block access to push etc, so it actually is more important for other aspects of the ecosystem than for us. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On 07/05/2018 05:37 PM, Marc Schiffbauer wrote: > I have my primary key offline only, so renewing/editing it is a much > more time consuming matter than if I had my primary key always with me > which I consider a bad idea because you do not need to. But is it sufficiently time-consuming / difficult that it is a problem to do it once a year? What do you do when certifying/signing other's UIDs? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v3 08/12] glep-0063: Allow ECC curve 25519 keys
On 07/06/2018 07:49 AM, Ulrich Mueller wrote: >>>>>> On Thu, 5 Jul 2018, Jonas Stein wrote: > >>> b. RSA, >=2048 bits (OpenPGP v4 key format or later only) >>> >>> + c. ECC curve 25519 >>> + >>> 4. Key expiry: 5 years maximum >>> 5. Upload your key to the SKS keyserver rotation before usage! > >> I think we should ensure first that everything works fine with ECC. >> Last time I checked, ECC was a nightmare. > >> Some SKS server could not handle ECC... and so on. > > IIRC, it has also been pointed out that ECC is not part of the OpenPGP > standard (yet)? > Right, the NIST curves prime curves are defined in RFC6637 but Curve25519/EdDSA is only implemented in GnuPG and part of the draft rfc4880bis (WG isn't currently active, so not expected a v5 any time soon). ECC is also only implemented in gnupg >=2.1 , so as mentioned earlier, gnupg 1.4 (which is still maintained and often used for smaller footprint or backwards compat to v3 keys) will not be able to use it. > Maybe we should better omit it. It shouldn't be too complicated for > developers to add a dedicated RSA signing key for Gentoo if necessary > (especially, since someone using ECC could be considered an advanced > GnuPG user). If the primary key is ECC, clients not supporting it won't be able to use the key material even if the signing subkey is RSA. > > Ulrich > -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys
On 07/05/2018 01:22 AM, Kristian Fiskerstrand wrote: > that said, I'm not aware of any curves defined with a lower security > margin than this for OpenPGP in general. The known curves in the > ecosystem are known in the ecosystem being the union of rfc4880bis draft and rfc6637 -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys
On 07/05/2018 01:07 AM, Joshua Kinard wrote: >> @@ -64,6 +66,8 @@ not be used to commit. >> >> b. RSA, >=2048 bits (OpenPGP v4 key format or later only) >> >> + c. ECC, curve 25519 >> + >> 3. Key expiry: 5 years maximum >> >> 4. Upload your key to the SKS keyserver rotation before usage! >> > Add a minimum key size here for ECC. They have different bit sizes than > classic DSA/RSA keys. A quick read indicates that a 224-bit ECC key is > roughly > equivalent to a 112-bit symmetric key, which is what a 2048-bit RSA key is > equivalent to, so the logical minimum for ECC looks like 'nistp256'. The > maximum is 521-bits on ECC (nistp521). > > Also move the mention of Ed25519 keys to their own bullet and clarify that > they > don't allow for a key length, as I think that's hardcoded in some capacity. following the comma-style of the rest of the document, the ECC part should likely be read as curve25519 being the only acceptable curve, which is 256 bits (roughtly 128 bit shannon entropy equivalent) that said, I'm not aware of any curves defined with a lower security margin than this for OpenPGP in general. The known curves in the ecosystem are let oid_to_psize oid = let psize = match oid with | "\x2b\x81\x04\x00\x23" -> 521(* nistp521 *) | "\x2b\x81\x04\x00\x22" -> 384(* nistp384 *) | "\x2a\x86\x48\xce\x3d\x03\x01\x07" -> 256(* nistp256 *) | "\x2b\x24\x03\x03\x02\x08\x01\x01\x07" -> 256(* brainpoolP256r1 *) | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0b" -> 384(* brainpoolP384r1 *) | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0d" -> 512(* brainpoolP512r1 *) | "\x2b\x81\x04\x00\x0a" -> 256(* secp256k1 *) | "\x2b\x06\x01\x04\x01\xda\x47\x0f\x01" -> 256(* Ed25519 *) | _ -> failwith "Unknown OID" -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
On 07/04/2018 11:43 PM, Kristian Fiskerstrand wrote: > On 07/04/2018 11:28 PM, Michał Górny wrote: >> W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller >> napisał: >>>>>>>> On Wed, 04 Jul 2018, Michał Górny wrote: >>>>b. Signing subkey: 1 year maximum >>>> 5. Key expiration date renewed at least 2 weeks before the previous >>>>expiration date. >>> >>> This is crappy as a scheme, since it will make it impossible to keep >>> the expiration date at a constant month and date. >>> >> >> Nobody forces you to prolong it for exactly the same amount, exactly two >> weeks before expiration. The only point made here is to give services >> time to sync rather than the common combo of renewing key once it >> already expired. >> >> Especially, if you follow the recommended scheme below you can easily >> get periodic expiration dates. >> > > As I understand ulm's concern, the issue is with the max 1 year in > combination with this, e.g it effectively prohibits extended a subkey > expiring 2018-12-31 to 2019-12-31 two weeks before, since that exceeds > one year maximum > fwiw, this can be mitigated by allowing e.g 1.25 years / 15 months instead of one year. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
On 07/04/2018 11:28 PM, Michał Górny wrote: > W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller > napisał: >>>>>>> On Wed, 04 Jul 2018, Michał Górny wrote: >>>b. Signing subkey: 1 year maximum >>> 5. Key expiration date renewed at least 2 weeks before the previous >>>expiration date. >> >> This is crappy as a scheme, since it will make it impossible to keep >> the expiration date at a constant month and date. >> > > Nobody forces you to prolong it for exactly the same amount, exactly two > weeks before expiration. The only point made here is to give services > time to sync rather than the common combo of renewing key once it > already expired. > > Especially, if you follow the recommended scheme below you can easily > get periodic expiration dates. > As I understand ulm's concern, the issue is with the max 1 year in combination with this, e.g it effectively prohibits extended a subkey expiring 2018-12-31 to 2019-12-31 two weeks before, since that exceeds one year maximum -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs
On 07/04/2018 12:59 PM, Michał Górny wrote: > > Or maybe even make a separate point about having a separate signing > subkey? > Right, that is likely also easier to understand. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs
On 07/04/2018 12:54 PM, Michał Górny wrote: > W dniu śro, 04.07.2018 o godzinie 12∶35 +0200, użytkownik Kristian > Fiskerstrand napisał: >> On 07/04/2018 12:23 PM, Michał Górny wrote: >>> -2. Root key and signing subkey of EITHER: >>> +2. Root key and a dedicated signing subkey, both of EITHER: >> >> "dedicated" here might be misread to be gentoo-specific, which doesn't >> really make much sense. > > What alternative do you suggest? We really want to make clear that we > require a separate subkey, and that subkey is not marked for encryption. > "signing subkey" already implies as much though, but maybe write it out more "Both the primary key and the signing subkey needs to be of EITHER;" -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs
On 07/04/2018 12:23 PM, Michał Górny wrote: > -2. Root key and signing subkey of EITHER: > +2. Root key and a dedicated signing subkey, both of EITHER: "dedicated" here might be misread to be gentoo-specific, which doesn't really make much sense. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
On 07/04/2018 11:09 AM, Michał Górny wrote: > I honestly don't think Gentoo is the distribution where we let people > stay with obsolete versions for 'smaller footprint'. 1.4 isn't obsolete, it is still maintained as separate branch upstream. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
On 07/04/2018 10:42 AM, Michał Górny wrote: > 1. I suppose the ECC/cv25519 packets won't change in incompatible manner > at this point. It being implemented in gnupg-2-2 is a good indication it won't be allowed to change at this point > > 2. Hardware incompatibility issues are not really relevant to us but to > the person using the key. It is relevant to us to the extent of discussion for hardware token for devs > > 3. Developer keys are mostly for internal use, while the majority of > users verify only the infra signatures, so I don't think we have to be > that concerned about interoperability of the algos, provided that it > works for infra purposes. This depends on the discussion of rsync vs git, if you expect end-users to verify git commits from developers directly you require them to use the 2.2 branch, whereby some server users prefer 1.4 for its smaller footprint etc. If we conclude that the git repo is internal and not to be exposed to end-users per se, but distribution happens in curated git or rsync I agree it is not an issue. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
On 07/04/2018 09:54 AM, Michał Górny wrote: >> We also keep gnupg 1.4 in tree that does not, and will not, support ecc. > Well, we have developers using ECC (Curve 25519, to be specific). > I don't really know enough about this to judge but we either need to > allow at least this, or convince those devs to change to RSA. incidentally curve25519 is the one I'm thinking of that isn't standardized, although it is part of current draft version of rfc4880bis (but WG is stalled so no update expected any time soon there). NIST/brainpool are included in RFC6637, but we wouldn't want to accept them for various reasons. There are good reasons these are not provided in the regular interface of gnupg, but requires --expert -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
On 07/04/2018 09:22 AM, Michał Górny wrote: > + c. ECC Likely should not blanket accept ECC for various reasons. For one thing the curves we likely would want to accept are not standardized, so you have interoperability issues. The hardware situation is improving somewhat on these, so that is less of a concern now than back in the day. But there aren't really very strong arguments in favor of ecc, and in the case of quantum computation there less protection offered from ecc due to smaller key sizes. We also keep gnupg 1.4 in tree that does not, and will not, support ecc. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?
I would expect as much. But my primary argument would be key management related, it is simply impossible to present a raw copy of our repo to end-users and have them verify each commit Original message From: William Hubbs Date: 7/3/18 17:39 (GMT+01:00) To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync? On Tue, Jul 03, 2018 at 08:32:55AM -0700, Brian Dolbec wrote: > On Tue, 3 Jul 2018 10:22:35 -0500 > William Hubbs wrote: > > > All, > > > > Mostly because of the recent "trustless infrastructure" thread, I am > > wondering why we are still distributing the portage tree primarily > > via rsync instead of git? > > > > Can someone educate me on that, and is it worth considering moving > > away from rsync distribution? > > > > Thanks, > > > > William > > > > because: > > 1) it is still the most bandwidth economical means of distributing the > tree Even more so than http or https? Thanks, William
Re: [gentoo-dev] Trustless Infrastructure
On 07/02/2018 10:16 PM, Michał Górny wrote: > W dniu pon, 02.07.2018 o godzinie 17∶36 +0200, użytkownik Jason A. > Donenfeld napisał: >> Hey guys, >> >> While our infrastructure team has some nice technical competence, the >> recent disaster and ongoing embarrassing aftermath has made ever more >> urgent the need to have end-to-end signatures between developers and >> users. While the infrastructure team seems fairly impressive at >> deploying services and keeping the house running smoothly, I'd rather >> we don't place additional burden on them to do everything they're >> doing securely. Specifically, I'd like to ensure that 100% of Gentoo's >> infrastructure can be hacked, yet not backdoor a single witting user >> of the portage tree. Right now, as it stands, rsync distributes >> signatures to users that are derived from some >> infrastructure-controlled keys, not from the developers themselves. >> >> Proposal: >> - Sign every file in the portage tree so that it has a corresponding >> .asc. Repoman will need support for this. >> - Ensure the naming scheme of portage files is sufficiently strict, so >> that renaming or re-parenting signed files doesn't result in RCE. [*] >> - Distribute said .asc files with rsync per usual. >> > > Another problem: how do you prevent attacks based on removing files? > For example, let's say a MITM that removes new version of some packages > and related GLSAs in order to force the user to stay at vulnerable > version. > right, just to point out, this is already covered in the metamanifest signing scheme, but wouldn't be in a separate file signing mechanism. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Trustless Infrastructure
On 07/02/2018 07:47 PM, Hanno Böck wrote: > I don't want to say this is unworkable. But these are challenges and > imho fixing them all is really, I'll say it, it is unworkable, you need a trusted party doing verification of developers at point in time, then sign it with release engineering keys for distribution to end-users. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Trustless Infrastructure
On 07/02/2018 08:08 PM, Jason A. Donenfeld wrote: > On Mon, Jul 2, 2018 at 7:57 PM Rich Freeman wrote: >> This only helps you if a dev you don't trust is compromised. If a dev >> you trust is compromised, they can modify anything in the tree and >> you're hosed. > Yes indeed. This is more or less what we're aiming for. Putting the > trust in developers. The goal is for infra not to be the weak link in > this, as it currently is. > >> Sure, I'd prefer to not extract git signatures and just distribute via >> git purely without any rsync. > Yea, I personally don't really care much for rsync either. I've just > kind of been assuming this is a requirement of any gentoo solution. > But maybe this whole thing should take another dimension, and we > should instead talk about sunsetting rsync, and moving to a model of: > 1) git fetch, 2) git verify, 3) git checkout? There still might be > problems with "untrusting" devs, as I wrote above, but perhaps there's > room to grow within the git framework, by manually filtering commits > during checkout, or even by imposing ebuild directory signature-based > ACLs that I think you were hinting at before. So, sure, if you want to > call for an abolition of rsync, maybe I'd follow you in that direction > instead of the one here I'm proposing. > > picking a semi-random post to respond to, but the key management you're introducing with such a proposal is just silly. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-project] Gentoo-dev whitelisting
On 05/13/2018 08:57 PM, Alec Warner wrote: > [2] The whitelist is not yet live, but I wanted to give folks an > opportunity to populate the whitelist before enabling it; so have at it. People have had the necessary time for a long time already, so I don't see a wait as being required. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Mailing list moderation and community openness
On 03/22/2018 12:38 PM, Rich Freeman wrote: > On Thu, Mar 22, 2018 at 4:30 AM, Alexander Berntsen <berna...@gentoo.org> > wrote: >> On 22/03/18 07:31, Benda Xu wrote: >>> We might be able to require GPG signed email to make a post. >> Almost definitely. >> >> But before bikeshedding that, it would be advisable to find out whether >> it would be a good idea in the first place. Unless you want only >> prospective developers to be able to contribute to the ML (maybe you do >> want that?), it seems like a poor idea to unnecessarily exclude anyone >> who doesn't care (nor want to care) about OpenPGP. > > That, and getting yourself whitelisted by a dev is gong to be a lower > barrier than having to meet one in-person to have a key signed. That > is unless devs just start signing keys for people they've never met > (which honestly doesn't really bother me much as I don't put much > faith in the WoT anyway), in which case it turns into a whitelist that > only comrel can un-whitelist since I don't think you can revoke a > signature. The one issuing the signature can also revoke it (see revsig in --edit-key). That said, I'd rather focus on our own devs having WoT and requiring it to become a developer long before we require it to be part of a mailing list. If anything the technical complexity of verifying it doesn't make much sense to me vs a simple whitelist. > > Plus signing emails is a pain if you don't use an MUA that has this > feature, and the web-based ones which do aren't very good. > -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Mailing list moderation and community openness
On 03/22/2018 12:56 AM, Chí-Thanh Christopher Nguyễn wrote: > Rich Freeman schrieb: > >> Actually, I think it is more of a technical constraint. It is >> basically impossible to blacklist somebody on a mailing list, since >> all they need to do is roll up a new email address. >> >> I can think of various arguments for whitelisting or not whitelisting, >> but it seems silly to blacklist. > > And how often did it actually happen that blacklisting was evaded on -dev > mailing list? we are aware of at least one case of evasion like this within the relatively near past, but it is more a matter of principle as we don't know if there are sock-puppets etc around. The main things is really, the bar for whiltelisting is very low, you just need a current dev to vouch for you, which is similiar to editbugs and the #-dev channel on IRC. Most discussion should anyways happen on -project ML, whereby the -dev ML is technical in nature. So there isn't any real restriction being imposed here. Most contributions should happen via patches on b.g.o -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Mailing list moderation and community openness
On 03/22/2018 12:56 AM, Chí-Thanh Christopher Nguyễn wrote: > Michael Palimaka schrieb: >> I see that in bug #650964[1] Council is pushing forward again with >> implementing user whitelisting on this mailing list (ie. anyone that is >> not "approved" will have their mail rejected). >> >> Could someone please explain how this doesn't directly contradict the >> core tenets of an open and inclusive community? > > (I do not intend to single out your post, just replying to the thread in > general here) > > I would like to ask people to stay respectful in their disagreement towards > the Council and their decision here. You might not agree with the decision, > but the Council is an elected body and was given these powers by the > developer community which they represent. Also I have no doubt that Council > members who voted for -dev moderation are aware of the counter arguments and > honestly expect a net positive effect from this. > > If you dislike mailing list moderation, campaign and/or vote in the next > period for candidates who want to reverse this decision. +1 for this, and also note that the whitelisting approach allows for those opposing to start a project for -dev ML moderation that is similar to editbugs and proxy maintenance as we currently have in the project. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Mailing list moderation and community openness
On 03/22/2018 12:56 AM, Chí-Thanh Christopher Nguyễn wrote: > Kristian Fiskerstrand schrieb: > >> Switching to mailman might have some good merits on its own, but as I >> understand it it isn't necessary for the proposal at hand, that can be >> solved using access control lists in mlmmj-process? > > I would advise caution that Council better not try to micro-manage Infra here. By all means, infra should do what they think is right, but this particular decision doesn't force infra to switch mailing list infrastructure. If they believe there are reasons to do so, by all means, but the decision doesn't result in On 03/20/2018 04:28 PM, Matthew Thode wrote: > There are still some issues with it infra side (archiving will still > have to use the old system) and moving mailing lists is going to be fun, > but them the breaks. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Mailing list moderation and community openness
On 03/20/2018 04:28 PM, Matthew Thode wrote: > On 18-03-20 23:17:52, Michael Palimaka wrote: >> I see that in bug #650964[1] Council is pushing forward again with >> implementing user whitelisting on this mailing list (ie. anyone that is >> not "approved" will have their mail rejected). >> >> Could someone please explain how this doesn't directly contradict the >> core tenets of an open and inclusive community? >> >> 1: https://bugs.gentoo.org/650964 >> > While I personally do no agree with mailing list moderation infra has > been tasked with moving forward on it. In that vein, this is what we > are proposing. > > Install and configure mailman3/hyperkitty/postorius once they all > support python3. Specifically we wish to use docker-mailman for this so > we can easilly redeploy this on diferent machines as needed. > > mailman3 gives us two good things, it has support for moderation (for > better or worse) and it handles senders using dmarc. > > There are still some issues with it infra side (archiving will still > have to use the old system) and moving mailing lists is going to be fun, > but them the breaks. Switching to mailman might have some good merits on its own, but as I understand it it isn't necessary for the proposal at hand, that can be solved using access control lists in mlmmj-process? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Mailing list moderation and community openness
On 03/20/2018 01:17 PM, Michael Palimaka wrote: > I see that in bug #650964[1] Council is pushing forward again with > implementing user whitelisting on this mailing list (ie. anyone that is > not "approved" will have their mail rejected). > > Could someone please explain how this doesn't directly contradict the > core tenets of an open and inclusive community? > > 1: https://bugs.gentoo.org/650964 > The correct place to have pointed this out would have been during the previous ML discussions, and in particular ahead of either of the two council meetings on the matter where it was clearly put on the agenda. The bug in question is just a technical matter of implementing a final decision. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On 01/09/2018 10:20 PM, Andreas K. Huettel wrote: > During the last Gentoo council meeting, the decision was made to implement > changes to the gentoo-dev mailing list [1]. > > These changes affect only the gentoo-dev mailing list, and will come into > effect on 23 January 2018. > > * Subscribing to the list and receiving list mail remains as it is now. > * Posting to the list will only be possible to Gentoo developers and > whitelisted additional participants. > * Whitelisting requires that one developer vouches for you. We intend this > to be as unbureaucratic as possible. > * Obviously, repeated off-topic posting as well as behaviour against the > Code of Conduct [2] will lead to revocation of the posting permission. > > If, as a non-developer, you want to participate in a discussion on > gentoo-dev, > - either reply directly to the author of a list mail and ask him/her to > forward your message, > - or ask any Gentoo developer of your choice to get you whitelisted. > > If, as a developer, you want to have someone whitelisted, please comment on > bug 644070 [3]. Similar to Bugzilla editbugs permission, if you are vouching > for a contributor you are expected to keep an eye on their activity. > > [1] https://projects.gentoo.org/council/meeting-logs/20171210-summary.txt > [2] https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct > [3] https://bugs.gentoo.org/644070 (alias g-dev-whitelist) > This was not put in effect on 23 January 2018, however I have now requested infra to put it in place in [bug 650964]. Users wishing posting permissions are encouraged to find a mentor and register in [bug 644070] References: [bug 650964] https://bugs.gentoo.org/650964 [bug 644070] https://bugs.gentoo.org/644070 -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Lastrite: app-crypt/monkeysign
On 02/13/2018 11:47 AM, Michael Palimaka wrote: > On 02/12/2018 08:59 AM, Kristian Fiskerstrand wrote: >> # Kristian Fiskerstrand <k...@gentoo.org> (11 Feb 2018) >> # Lastrite: app-crypt/monkeysign . Please use caff from >> # app-crypt/signing-party instead. Removal in 30 days. >> # Bug: #647352 >> app-crypt/monkeysign >> > > What's the reason for the removal? > Very little upstream activity and not expected to be anything happening with it soon, and some breakages etc that should be fixed for it to be used. I'm not using it, and rather dropping it than putting it in the ever-growing pile of maintainer needed. Feel free to take it if you want it though. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Lastrite: app-crypt/monkeysign
# Kristian Fiskerstrand <k...@gentoo.org> (11 Feb 2018) # Lastrite: app-crypt/monkeysign . Please use caff from # app-crypt/signing-party instead. Removal in 30 days. # Bug: #647352 app-crypt/monkeysign -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
eclass committ message verbosity (Was: Re: [gentoo-dev] [PATCH] bzr.eclass: Add --overwrite-tags option to pull command.)
On 02/06/2018 03:36 PM, Ulrich Mueller wrote: >>>>>> On Tue, 6 Feb 2018, Kristian Fiskerstrand wrote: >> More generally though, should we start requiring more verbose commit >> messages for eclasses to make it easier to trace changes in our git >> repo directly without reaching out to bugs? At least including >> summaries of the respective bugs as a short description? > > In the concrete example, the bug's summary is "bzr.eclass might need > to use bzr pull's --overwrite-tags flag" which is not much different > from the git commit message. Right, this specific commit likely has little more to gain given the summary line. But could easily benefit from some text in body still :) But I generally think we can benefit from some more verbosity in our commit messages, in particular for eclasses. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] bzr.eclass: Add --overwrite-tags option to pull command.
On 02/06/2018 02:57 PM, Ulrich Müller wrote: > Fixes: https://bugs.gentoo.org/446422 Bug or Closes, Fixes would be referencing a commit-id c.f GLEP 66. More generally though, should we start requiring more verbose commit messages for eclasses to make it easier to trace changes in our git repo directly without reaching out to bugs? At least including summaries of the respective bugs as a short description? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] use.desc: Correct/clarify SSL/TLS-related flags
On 01/31/2018 12:22 AM, Ulrich Mueller wrote: >> gnome-keyring - Enable support for storing passwords via gnome-keyring >> gnuplot - Enable support for gnuplot (data and function plotting) >> -gnutls - Add support for net-libs/gnutls (TLS 1.0 and SSL 3.0 support) >> +gnutls - Prefer net-libs/gnutls as SSL/TLS provider (requires USE=ssl if >> present) > NACK. This seems to imply that USE="-ssl gnutls" is not a valid > configuration? What if the user prefers gnutls and therefore has > globally enabled the gnutls flag, but -ssl for a single package? > > How about "(needs USE=ssl to take effect)" instead? > as I understand it ssl is intended as a generic use flag, of which gnutls can be one of the providers. In the case of of app-crypt/gnupg there are only two possible providers, gnutls, and ntbtls, of which only one is available in tree, so gnutls is the only one, so the only one relevant for Gentoo is gnutls, hence no use flag for it, either TLS is enabled, or it is not. in this scenario I don't see why "ssl -gnutls" would not be a valid configuration as long as ssl is a generic use flag as it is presented to be. It doesn't mean never install gnutls, but just not preferring it in cases where there are other providers of ssl/tls, that the global description already indicate. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] use.desc: Correct/clarify SSL/TLS-related flags
On 01/30/2018 11:11 PM, Michał Górny wrote: > Correct the description of SSL/TLS-related flags to match their modern > use. USE=ssl is a feature flag that enables support for SSL/TLS, > while USE=gnutls and USE=libressl are implementation toggling flags. > > Unify the descriptions a bit. Make sure to mention both SSL and TLS > to avoid confusion. Inform about the necessity of enabling USE=ssl > in both implementation flags, and replace 'might' with 'if present'. > +1 / Reviewed-By -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [News item review] Portage rsync tree verification
On 01/25/2018 11:04 AM, Michał Górny wrote: > Hi, > Thanks for your work on this! > This one would be committed once new sys-apps/portage release is > wrapped up and hits ~arch. > > --- Title: Portage rsync tree verification Author: Michał Górny > <mgo...@gentoo.org> Posted: 2018-01-xx Revision: 1 News-Item-Format: > 2.0 Display-If-Installed: > Starting with sys-apps/portage-2.3.22, Portage enables strong > cryptographic verification of the Gentoo rsync tree by default. This > aims to prevent malicious third parties from altering the contents of > the ebuild repository received by our users. Just for sake of it, would remove "strong" here, as it is a description and not PR document. Should we be consistent with referencing, so e.g the Gentoo ebuild repository as distributed through rsync, or something? Atm we seem to be using different terms all of the place, so should try to harmonize a bit. > > The verification is implemented using app-portage/gemato. Currently, ... "implemented in", as opposed to "using"? its implemented using various cryptographic primitives, but gemato is the implementation itself of sorts. > the whole repository is verified after syncing. On systems with slow > hard drives, this could take around 2 minutes. If you wish to > disable it, you can disable the 'rsync-verify' flag on USE flag? > sys-apps/portage or set 'sync-rsync-verify-metamanifest = no' in your > repos.conf. > > Please note that the verification currently does not prevent Portage > from using the repository after syncing. If 'emerge --sync' fails, do > not install any packages and retry syncing. In case of prolonged or > frequent verification failures, please make sure to report a bug > including the failing mirror addresses (found in emerge.log). > > The verification uses keys provided by the app-crypt/gentoo-keys > package. The keys are refreshed from the keyserver before every use > in order to check for revocation. The post-sync verification ensures > that the key package is verified itself. However, manua > verification is required before the first use. Maybe some wording around binary keyring? e.g the verification uses information from the binary keyring provided by app-crypt/gentoo-keys? In particular the reference to "key package" might be misread (and the keyring consists of multiple public keyblocks, that includes much more information than the cryptographic keys per se) > > On new Gentoo installations including portage-2.3.22, the stage3s? > verification of the keys will be covered by verifying the > installation media and repository snapshot signatures. On existing > installations, you need to manually compare the primary key > fingerprint (reported by gemato on every sync) against the official > Gentoo keys [1]. An example gemato output is: > > INFO:root:Valid OpenPGP signature found: INFO:root:- primary key: > 1234567890ABCDEF1234567890ABCDEF12345678 INFO:root:- subkey: > FEDCBA0987654321FEDCBA0987654321FEDCBA09 > > The primary key printed must match 'Gentoo Portage Snapshot Signing > Key' on the site. Please make sure to also check the certificate > used for the secure connection to the site! > > [1]:https://www.gentoo.org/downloads/signatures/ --- > -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change
On 01/16/2018 03:45 PM, Aaron W. Swenson wrote: > Given the situation, we have a choice: Remove GnuCash altogether, or > press ahead with recommending a version upstream considers unstable. Or 3, discuss with upstream to see if they can release an updated version as stable branch. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change
On 01/16/2018 03:07 PM, Róbert Čerňanský wrote: > I think generated reports are typical use of webkit in GnuCash. Are > attack vectors so severe also in this case? Yes, as it would hinder upgrade / keep the vulnerable libraries on the system that can possibly be used by other packages. That said, I agree with the overall premise of discussion, and stability guarantees for the stable keywords, have anyone been in contact with upstream and discussed the issue of getting a stable release branch not based on the old webkit? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change
On 01/10/2018 07:31 PM, Aaron W. Swenson wrote: > Display-If-Installed: >=app-office/gnucash-2.7.0 And we might want to display it before users actually upgrades if it is for backing up an auto migrated change? Since it doesn't require user changes I'm not entirely sure news item is correct approach, seems like an elog could satisfy this -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change
On 01/10/2018 07:31 PM, Aaron W. Swenson wrote: > It is imperative that you back up any files or databases that GnuCash > uses in case you run into an issue with 2.7+ and want or need to revert > back to 2.6. This seems to imply that upgrading from 2.6 to 2.7+ does not require any changes / auto-upgrades schema, maybe it should be stated explicitly early on? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue
On 01/10/2018 02:19 AM, Michael Orlitzky wrote: > On 01/09/2018 07:07 PM, William Hubbs wrote >> >> However, I'm not sure how to deal with the hard link issue in a way that >> will not break service scripts. >> > > Systemd mitigates this by enabling the fs.protected_hardlinks sysctl by > default, but they have the liberty of requiring a relatively new Linux so does gentoo-sources since discussion in https://bugs.gentoo.org/540006#c19 > > (I didn't realize at the time that the OpenRC fix still contained a race > condition.) This was mentioned already in https://bugs.gentoo.org/540006#c15 -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Deleting old news items
On 01/06/2018 11:11 PM, Anders Thomson wrote: > Thanks. Which of the requirements requires transport to be in a > particular manner? I see implications on pm, but nothing on > transport. tl;dr; the PM knows which packages are installed on the specific system, a specific feed does not (although that doesn't exclude the possibility of getting feed of all messages, which is already part of git repository) -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deleting old news items
On 01/05/2018 11:47 PM, Kristian Fiskerstrand wrote: > On 01/05/2018 11:40 PM, Alec Warner wrote: >>> I might sound like a broken CD here, but why define the expiration as >>> part of the news format instead of specifying it in the package manager >>> as a user defined variable? Various use cases requires different >>> treatment, so leaving it up to user seems more relevant to me, and we >>> could allow information to be presented as part of stages to give a hint >>> for what dates to look for? >>> >> The short answer is I haven't seen any real use cases for it and even if we >> were to spec it out and add it, I don't think it would be used by more than >> 10 people. To me that is an incentive to avoid complicating the software >> spec. > > From my point of view it requires less specification, as it doesn't > require a policy for how to set the expiration date, but allowing some > flexibility on the part of the user base. > > There are rather big differences e.g between a server upgrade pattern > and a desktop system, how would you account for that in the expire date? > in particular for non security relevant upgrades, e.g profile changes? > > Lets take another real-life example; I have two machines A and B. A is one a stage3 install from before switching from 13.0. to 17.0 and B is on the latter. As a developer, how would you specify expiration for switch between profiles? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deleting old news items
On 01/05/2018 11:40 PM, Alec Warner wrote: >> I might sound like a broken CD here, but why define the expiration as >> part of the news format instead of specifying it in the package manager >> as a user defined variable? Various use cases requires different >> treatment, so leaving it up to user seems more relevant to me, and we >> could allow information to be presented as part of stages to give a hint >> for what dates to look for? >> > The short answer is I haven't seen any real use cases for it and even if we > were to spec it out and add it, I don't think it would be used by more than > 10 people. To me that is an incentive to avoid complicating the software > spec. From my point of view it requires less specification, as it doesn't require a policy for how to set the expiration date, but allowing some flexibility on the part of the user base. There are rather big differences e.g between a server upgrade pattern and a desktop system, how would you account for that in the expire date? in particular for non security relevant upgrades, e.g profile changes? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deleting old news items
On 01/05/2018 10:28 PM, Aaron W. Swenson wrote: > On 2018-01-05 15:16, William Hubbs wrote: >> If we have a default expiration, it should be one year after the date >> posted to go along with our current policy of not supporting things that >> are older than a year. >> >> William > > I thought it was three years. > > At any rate, I think a year is too short. > > How about 18 months? > I might sound like a broken CD here, but why define the expiration as part of the news format instead of specifying it in the package manager as a user defined variable? Various use cases requires different treatment, so leaving it up to user seems more relevant to me, and we could allow information to be presented as part of stages to give a hint for what dates to look for? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deleting old news items
On 01/03/2018 03:13 PM, Kristian Fiskerstrand wrote: > On 01/03/2018 02:45 PM, Ciaran McCreesh wrote: >> On Wed, 3 Jan 2018 12:23:33 +0100 >> Kristian Fiskerstrand <k...@gentoo.org> wrote: >>> Do we necessarily need to do even that? A package manager could have a >>> feature to mask based on other heuristics without changing the format, >>> e.g all messages from before X, presumably with a switch to show >> Package manglers having to use heuristics when explicit information >> could easily be provided by developers but isn't is the source of at >> least 27.4% of Gentoo's problems. > > I'd say it is easier to have flexibility for user to decide than a > developer trying to estimate the value of the information for setting an > expiration date, as that is context dependent. > That said, I'd prefer either option over deleting news items, deleting info shouldn't be necessary to begin with, it'd be more interesting to have an "active" boolean or something, but still keep the info (but I'd still say a PM filter based on date is better) -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deleting old news items
On 01/03/2018 02:45 PM, Ciaran McCreesh wrote: > On Wed, 3 Jan 2018 12:23:33 +0100 > Kristian Fiskerstrand <k...@gentoo.org> wrote: >> Do we necessarily need to do even that? A package manager could have a >> feature to mask based on other heuristics without changing the format, >> e.g all messages from before X, presumably with a switch to show > Package manglers having to use heuristics when explicit information > could easily be provided by developers but isn't is the source of at > least 27.4% of Gentoo's problems. I'd say it is easier to have flexibility for user to decide than a developer trying to estimate the value of the information for setting an expiration date, as that is context dependent. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deleting old news items
On 01/03/2018 12:07 PM, Ulrich Mueller wrote: >>>>>> On Tue, 2 Jan 2018, Alec Warner wrote: > >> Problem: >> New stages have numerous news items listed that are likely not >> relevant, but are shown due to limitations in the filtering in NEWS >> items. E.g. on a recent stage3: > >> [...] > > We could add an "Expires:" header to the news item format, and the > package manager (or eselect news) could mask old items based on it. Do we necessarily need to do even that? A package manager could have a feature to mask based on other heuristics without changing the format, e.g all messages from before X, presumably with a switch to show older. I'm thinking along the lines of only show those published within last 12 months by default, configurable by make.conf variable. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] AMD64 Arch Testers needed urgently
On 12/14/2017 01:01 PM, Rich Freeman wrote: > In the beginning the system would be opt-in. Then once we have > confidence that it is working well the flag could potentially be made > opt-out. The only place I imagine this being a good idea is for the kernel, given the strict no break of userland policy (but even they fail from time to time). For rest of the applications, even if we add tools to help automate part of the stabilization, I'd very much oppose it being automated without being initiated / acked by the maintainer. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] AMD64 Arch Testers needed urgently
On 12/14/2017 09:21 PM, R0b0t1 wrote: > It seems like lagging stability is due to a lack of resources. I do > not know a single person who would be able to run only stable > packages. I run stable only on most of my systems. > They seem to move too slowly, and people switch to unstable > packages because they contain bugfixes and sometimes new features. slow isn't necessarily a problem, as long as security fixes are handled. There is some balancing for large performance gains, but most existing systems are scaled based on the current estimates so it would only be relevant for the up sizing of the server park for growth needs etc. > > Could the criteria for stability be reconsidered? Mixed systems might why would it? > not be supported, but save for cases of ABI/API breakage (which can > happen when transitioning from stable->stable) I do not know why the > packages would not play well with each other. I am sure there are > examples where things have blown up, but it seems like expecting that > to be the case isn't helping. There are plenty of cases where this fails in miserable ways, so thats not a good idea (not to mention the dependency hell from it). That said, you can have a stable chroot, or just use a VM for testing etc. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On 12/06/2017 12:22 AM, William L. Thomson Jr. wrote: > Sorry and no more from me. I just feel given how I am portrayed, > spoken of, action taken against, etc. I must clarify some things for the > public record. Which even despite all my actions being in public. > People still assume because research and thinking for yourself takes > time. Time I do not expect anyone to expend. One of the primary issues recently is that you keep bringing up old matters in a way that is a criticism of Gentoo overall, in various channels. We've heard it already, and to keep bringing it up doesn't add additional value to the discussion. So again, please reduce the volume of such posts. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On 12/05/2017 11:41 PM, Kristian Fiskerstrand wrote: > On 12/05/2017 11:37 PM, Rich Freeman wrote: >> Honestly, I'm not really a big fan of even on-topic posts from people >> who have caused a lot of harm to others in private. I'm not sure >> which is the lesser evil but do we really want a community where we >> tolerate absolutely any kind of abuse of other members? > > We do not, but that presumes actual abuse has been demonstrated. > "spamming the mailing list", where the posts are regarding Gentoo, isn't > automatically abuse because some people are uncomfortable about the > information being presented, or they disagree with it. > This whole email thread is actually one of the examples of where split lists is a bad thing, the original message was cross-posted between gentoo-project and gentoo-dev with a reply-to for gentoo-dev. Resulting in split discussions across the lists. The overall discussion should've been in -project to begin with. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On 12/05/2017 11:37 PM, Rich Freeman wrote: > Honestly, I'm not really a big fan of even on-topic posts from people > who have caused a lot of harm to others in private. I'm not sure > which is the lesser evil but do we really want a community where we > tolerate absolutely any kind of abuse of other members? We do not, but that presumes actual abuse has been demonstrated. "spamming the mailing list", where the posts are regarding Gentoo, isn't automatically abuse because some people are uncomfortable about the information being presented, or they disagree with it. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On 12/05/2017 11:25 PM, Rich Freeman wrote: > On Tue, Dec 5, 2017 at 5:19 PM, Kristian Fiskerstrand <k...@gentoo.org> wrote: >> On 12/05/2017 11:12 PM, Rich Freeman wrote: >>> On Tue, Dec 5, 2017 at 4:16 PM, Daniel Campbell <z...@gentoo.org> wrote: >>>> I think the plan to split mailing lists serves as a way to insulate >>>> developers from the effects of their decisions. Anyone with an >>>> incongenial tone will have their voice bit revoked and their mail will >>>> be dropped or rejected. >>> And what would you do when somebody repeatedly sexually harasses other >>> members of the community in private after being told to stop, and then >>> acts as if they're the victim on the public mailing lists? >> >> This doesn't seem relevant to the matter of splitting the lists, and >> would certainly be a matter for comrel. >> > > What do you do when they keep posting manifestos or whatever on the > lists every few months, or generally stirring up the community about > how unjustly they're being treated? When the appeal is to popular > opinion, instead of the defined process for handling these appeals? > > Ultimately it isn't that hard to convince newcomers that Gentoo is > full of backstabbing when you let people allege that and have the last > word whenever it fancies them to do so. > > The point of prior restraint is so that our mailing lists don't turn > into the most negative PR imaginable. > The difference would be that you, in your first example, can demonstrate some actual abuse. In the latter case you're talking about differences of opinions of how things are run, which quickly turns into censorship. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On 12/05/2017 11:12 PM, Rich Freeman wrote: > On Tue, Dec 5, 2017 at 4:16 PM, Daniel Campbell <z...@gentoo.org> wrote: >> I think the plan to split mailing lists serves as a way to insulate >> developers from the effects of their decisions. Anyone with an >> incongenial tone will have their voice bit revoked and their mail will >> be dropped or rejected. > And what would you do when somebody repeatedly sexually harasses other > members of the community in private after being told to stop, and then > acts as if they're the victim on the public mailing lists? This doesn't seem relevant to the matter of splitting the lists, and would certainly be a matter for comrel. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists
On 12/04/2017 10:36 PM, William L. Thomson Jr. wrote: > Sorry last one, directed to Alec, but all should read. I hope you really mean that, we've all heard you complaining about this too many times already. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: RFC v2: news item for the 17.0 profiles
On 10/10/2017 09:16 PM, Andreas K. Huettel wrote: > emerge -e world we should use "@world" for sets to be consistent with recommendations to users here. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Manifest2 hashes, take n+1-th
On 10/20/2017 03:05 PM, Michael Orlitzky wrote: > Every WiFi network on the planet essentially became Starbucks overnight > on Sunday->Monday, so in my opinion we shouldn't bet against immediate > and catastrophic failure of anything, no matter how well-tested. Post Hoc ergo Propter Hoc -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Manifest2 hashes, take n+1-th
On 10/20/2017 11:10 AM, Dirkjan Ochtman wrote: > > I support Hanno's suggestion of doing just SHA512, but would be > interested in hearing opinions from others who have apparent > security/crypto experience. Maybe the Security project can weigh the > suggestions as well? > The whole discussion is moot so long as we don't have OpenPGP signed gentoo repository in rsync. SHA2-512 is generally quicker than sha256 on 64 bit architectures, but considerably slower for some architectures. Introducing a non-optimized keccak on top of it will have a significant negative performance impact for these arches without much security gain. if we still want two separate hashes, the choice of sha2 and sha3 compination is a good one given they are based on separate constructs. But IMHO we should start where things matter and complete an implementation for OpenPGP signatures of MetaManifests in Portage. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan
On 09/11/2017 07:29 PM, Michael Orlitzky wrote: > I generally agree with you that wiki markup is terrible and that a text > editor and a git repo is The Right Way to do things (with Jekyll or > whatever to push it to the web). But in my experience, crappy and easy > is a better way to get people to contribute. I generally agree with this as well, but I don't like that we're shifting back and forth as much as we do, which is a further hindrance. At some point we just need to decide on something and go with it, whether that is Wiki, RST or LaTeX.. The accessibility issues of wiki review and editing is a reasonable argument, but we probably don't want to rush a change again. Maybe we should start by defining a set of criteria / RFP for how we would like the GLEP process to be and the format required? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow
On 09/08/2017 11:19 PM, Rich Freeman wrote: > FYI - if anybody does want to make any comments on the proposed > devmanual changes to implement the new tags please comment at: > > https://github.com/gentoo/devmanual.gentoo.org/pull/72 > > For that matter, if you want to even know what the proposed changes > are you should also visit the link. This violates the gentoo social contract, please keep the discussion on the mailing list -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula
On 08/15/2017 02:21 PM, Rich Freeman wrote: > For example, could you say that a client-only install that still > installs the X11 components is "minimal?" Its somewhat context dependent, for an X application this doesn't necessarily constitute additional dependencies for the system (think desktop profile), whereby an application that is primarily used on servers suddenly needing some graphics processing dragging it in is likely wrong. That said, the use flag description isn't more detailed than "minimal - Install a very minimal build (disables, for example, plugins, fonts, most drivers, non-critical features)", so I'd say it is appropriate -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula
On 08/15/2017 11:33 AM, tom...@gentoo.org wrote: > Quoting Kristian Fiskerstrand (2017-08-15 10:37:39) >> On 08/15/2017 12:29 AM, Rich Freeman wrote: >>> On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny <mgo...@gentoo.org> wrote: >>>> On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote: >>>>> * 'bacula-clientonly' becomes 'clientonly' >>>> This is still negative logic in disguise. clientonly = noserver. >> >> Can the "minimum"-use flag be utilized here? >> > Sounds reasonable and is worth thinking about. At least we could define the > meaning of "minimum" here in metadata.xml. > > But, looking through portage there seems to be no "minimum" use flag anymore. > Seems it got dropped for some reasons. > typo; "minimal"... -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula
On 08/15/2017 12:29 AM, Rich Freeman wrote: > On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny <mgo...@gentoo.org> wrote: >> On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote: >>> * 'bacula-clientonly' becomes 'clientonly' >> This is still negative logic in disguise. clientonly = noserver. Can the "minimum"-use flag be utilized here? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation
On 08/08/2017 08:10 PM, William L. Thomson Jr. wrote: >> I'm not sure explicitly about environment files, but it's an option to >> emerge. For instance, I've added this to my EMERGE_DEFAULT_OPTS to >> ensure none of the following are built: >> >> --buildpkg-exclude "virtual/* sys-kernel/*-sources dev-perl/* >> perl-core/*" > Something like this would NOT be desirable. It would have to be done on > every system. It would have to be set on every binhost, not every client system.. that said, I prefer env approach as it is easier to track changes properly in a CVS -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation
On 08/08/2017 07:23 PM, William L. Thomson Jr. wrote: > Can you think of any? I cannot see any operator wanting a binary of a > binary, or a package of sources. When they already have a sources - The machine you're installing it on might not have internet access so you want to have the files stored in a single location for wrapping it up. - You might want an audit trail of installed packages, so using the binary files on specific media ensures same copy is installed everywhere - You might be applying local patches through /etc/portage/patches that are distributed to all clients On 08/08/2017 07:23 PM, William L. Thomson Jr. wrote: >> it can already be controlled through env files. > I was thinking it might, but having used them to skip other hooks. I > was thinking they could not be used as such for binary packages. Have > you confirmed such is possible? Could you provide a link or example? > Thanks! try something like: /etc/portage/env/nobin: FEATURES="-buildpkg" /etc/portage/package.env/nobin: sys-kernel/gentoo-sources nobin -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
