* [gentoo-dev] Git, GPG Signing, and Manifests @ 2015-07-17 1:13 NP-Hardass 2015-07-17 1:25 ` Kent Fredric ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: NP-Hardass @ 2015-07-17 1:13 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Not sure if this has been covered in some of the rather long chains of late, but I was thinking about GPG signing, and how the proposed workflow requires every developer to sign their commits. Currently, it's advised that every manifest be signed. As far as I know, there are a number that are not. When a manifest is signed, the author is saving a state, and providing a means to check it has not changed. Additionally, I feel that a signature is a means of acknowledging that a package has been looked over, and that developer has stated that they approve of the existing state. I'm not sure if others agree with that sentiment, but if anyone does, my question is, how does the conversion process to git handle these packages, where the manifests are not signed. Is there an intention to blanket cover all packages when we switch to git? Will these packages be copied over directly and still maintain their unsigned manifest (I think this is unlikely as I read that there would be a switch to thin manifests, requiring regeneration)? If the community doesn't view the signature of the manifest as I just described, then a blanket signing would be fine. Would appreciate your thoughts either way, as I could be overthinking the issue :P - -- NP-Hardass -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJVqFalAAoJEBzZQR2yrxj7g3YP/3HkK57mPQp2xzcpwUlPHXkM NAXaxO9UBRp2fNFc78Ja//xa8OUL0IDhsjI69uw2QRFILkgOjLo5n91d+KHuXFBc y8BGJ9lkhYgyCy+uztYsKJwUnfINfURv/hFTKPemgO8FVhBHUqyP7Mbz9cck/92p M+Wh12SrMqbTVRAc9ev5aho5hX2WG9fI0ikmX9WqkXo6UuQbc02VD4FdpkYaDhp4 ZzdpwUUGexMgZHgUahLCYTi0WbCCenUFupxGVfYYN7xTz539zbtER2LepfN6vGTw H/mELsg5fU7GbB7LM7XhDyLBgXcwc3zg5L9bRdbWIEVH/YpOaL0ttSX6MLEc3g7/ 26aotDjVGNJYcCcM+/GLSv761/MV9FdDe/ZfQSsY51rd1Uv9MjKLnfZf4MjqZ5x6 Fj2Jj7HvdfLdC+MmVNMzXWpkGpyZHoCcy+aES+dBweX3Qhcow4vtj+IKUKRu7R7l toBWPe9vFNYdlb2ODphyD3lLyGcTElBOf/K6UBcv9lDrg0L5g4spOpMJ7PK1uCh5 nonkYAP+Rs4+hyWBlre9jqhH/SZFw7EioBVEXahiUvGExKgZHB33AzS74a+8AUqo knHec0KafArlnE0TS71ZaPhrzWZbMSxiynacZAtT20VrKLsbunRuvTGEmoNZawy4 FMPMLKTKFQkI/Ps2K7Oa =0QTd -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Git, GPG Signing, and Manifests 2015-07-17 1:13 [gentoo-dev] Git, GPG Signing, and Manifests NP-Hardass @ 2015-07-17 1:25 ` Kent Fredric 2015-07-17 3:13 ` NP-Hardass 2015-07-17 1:25 ` Brian Dolbec 2015-07-17 8:18 ` OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests) Kristian Fiskerstrand 2 siblings, 1 reply; 16+ messages in thread From: Kent Fredric @ 2015-07-17 1:25 UTC (permalink / raw To: gentoo-dev On 17 July 2015 at 13:13, NP-Hardass <NP-Hardass@gentoo.org> wrote: > Additionally, I feel that a signature is a means of acknowledging that > a package has been looked over, and that developer has stated that > they approve of the existing state That much is somewhat implied by a developer owning a commit. Because in git, single commits span multiple files. There's GIT_COMMITER and GIT_AUTHOR values in every commit. And a "Signature" is a digital proof that Joe Bloggs didn't forge a commit, label it "NP-Hardass" and push it on to some server pretending to be NP-Hardass. It might sound like a rubber stamping, but its no more rubber stamped than our current workflow where signature generation is automatic and having a signed manifest doesn't in fact mean it *has* been looked at, its only signing who touched it last. For NSA to break a Manifest, they'd need to update an entry and resign it, and then we could later work out who signed what manifests if we had any problem -- Kent KENTNL - https://metacpan.org/author/KENTNL ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Git, GPG Signing, and Manifests 2015-07-17 1:25 ` Kent Fredric @ 2015-07-17 3:13 ` NP-Hardass 0 siblings, 0 replies; 16+ messages in thread From: NP-Hardass @ 2015-07-17 3:13 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/16/2015 09:25 PM, Kent Fredric wrote: > On 17 July 2015 at 13:13, NP-Hardass <NP-Hardass@gentoo.org> > wrote: >> Additionally, I feel that a signature is a means of acknowledging >> that a package has been looked over, and that developer has >> stated that they approve of the existing state > > > That much is somewhat implied by a developer owning a commit. > Because in git, single commits span multiple files. > > There's GIT_COMMITER and GIT_AUTHOR values in every commit. > > And a "Signature" is a digital proof that Joe Bloggs didn't forge > a commit, label it "NP-Hardass" and push it on to some server > pretending to be NP-Hardass. > > It might sound like a rubber stamping, but its no more rubber > stamped than our current workflow where signature generation is > automatic and having a signed manifest doesn't in fact mean it > *has* been looked at, its only signing who touched it last. > > For NSA to break a Manifest, they'd need to update an entry and > resign it, and then we could later work out who signed what > manifests if we had any problem > Yeah, I understand that a signed manifest doesn't mean it's been looked at. My logic was that signing and keys is pretty prolific at this point, so a signed manifest implied the package has been touched (and hopefully looked at) by a dev more recently, and those that aren't signed probably haven't been touched in a longer amount of time. - -- NP-Hardass -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJVqHLQAAoJEBzZQR2yrxj7a7YQAIlHbIcNl2FVwNOGR5ERegc+ RlqmOheNx654aM02Hcd44asTuug9Zy6cJ5k/LSGJEiqupg6EaDS7jnQAfqu+k6Lg 6JSPnfD0qUr5nrwNDvhUEH5LfVNHsKqCN9XyWvdy3Z0l+vKnyoWVCrINrTMEGCAf IkVnuAXXzo83YnJwtcczxbXsLfMpvnJK12Au9sa0H75y01Vqxw6gWvQeEww/fUl4 7L3WQCiGJnW5tI7vMVhDq9vpYFaB+VIQekLge3nf5sx6PfDBS4XHqwnUHD/wnj+i nqvjMDuyVfbc4NkDh9gW9Nk994VGu/iFBgepwT54khcuYnIVGVnad1Br69yLosDU 5DGUff1UKCQDjl8Cv88yuCf8y7zTjema3Rg09T0XqsmBWuhacw2zqESplPdlYsNj NfDCpcpr71tCP7qhy6y05O58p/ZKQDTp66OeoCghEEiYN89jjIGqT5tdWenDXJ3a j+MewMSzampvy5LTg3T0rQvirlq9rC1EXxQ+NmqXkVw2EK64HzcjM+kVyevvYuCK 2wiqEA4MAodd1LcW2gCNJ/nQ765OQjtMasEb8H/W9DryayzDLICUc3QdENXB5dMb x7bS+Ft4TbE/xXyR28MhkYXHO50qeWzlLRjueS9bSdoEPbTfe62JNBv8GvyFFxS4 aYvU5QXAjHeXSECERZdU =tWk3 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Git, GPG Signing, and Manifests 2015-07-17 1:13 [gentoo-dev] Git, GPG Signing, and Manifests NP-Hardass 2015-07-17 1:25 ` Kent Fredric @ 2015-07-17 1:25 ` Brian Dolbec 2015-07-17 3:06 ` NP-Hardass 2015-07-17 8:18 ` OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests) Kristian Fiskerstrand 2 siblings, 1 reply; 16+ messages in thread From: Brian Dolbec @ 2015-07-17 1:25 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, 16 Jul 2015 21:13:09 -0400 NP-Hardass <NP-Hardass@gentoo.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Not sure if this has been covered in some of the rather long chains of > late, but I was thinking about GPG signing, and how the proposed > workflow requires every developer to sign their commits. Currently, > it's advised that every manifest be signed. As far as I know, there > are a number that are not. When a manifest is signed, the author is > saving a state, and providing a means to check it has not changed. > > Additionally, I feel that a signature is a means of acknowledging that > a package has been looked over, and that developer has stated that > they approve of the existing state. I'm not sure if others agree with > that sentiment, but if anyone does, my question is, how does the > conversion process to git handle these packages, where the manifests > are not signed. Is there an intention to blanket cover all packages > when we switch to git? Will these packages be copied over directly > and still maintain their unsigned manifest (I think this is unlikely > as I read that there would be a switch to thin manifests, requiring > regeneration)? If the community doesn't view the signature of the > manifest as I just described, then a blanket signing would be fine. > > Would appreciate your thoughts either way, as I could be overthinking > the issue :P > > - -- > NP-Hardass No, with the git working tree, we will switch to thin manifests and the entire commit will be signed. Not only that, but the push to the main server will also be signed (a push may contain commits signed by a different person that the person pushing). For the regular rsync tree, Full manifests will be regenerated as needed and signed by a common infra supplied gpg key. So for general users, it will be easy to verify without having all gentoo devs gpg keys. That will be different for users of the git tree. - -- Brian Dolbec <dolsen> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJVqFmVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YAbQQAIACEYKfijcCZDaNnTBZTrzx K47Nqx/0MRKKCF2LPTyMeiJ+RMAuGeuFFomNdxGxYAn+XxfP0PUefIXv7AJDwemV NUX60tvYXd2x6xnBoDp0AfPsEBewWW50pVMK5UI1tGHUh0Ba5fGA7fyuoi0SyW4/ lRl4RoejhBZw5JWrecv4aDSBWa18wyJ9hUmoF5/cboHZlOBPtsskb+IQjeq3M3Dw efn+cXJ90eR8QE4IO6y9wIuIZG0Dla4yD13XMzolPyBNfJh7qizWNryw4guVY5mf /2wD/M1Adbgf0CuM8SXL0JeoO063Pqs8WVIEBb5M0yY04eB3b7JpBi5mZvk2RS4y DVSd0MB+vK8WzSo/NrhYqqDJTY5ezYUnu8XW5GiLEk0eHMiP/Hh36cDU+eGfTVX9 vMYaYHS/15cN+8bhfs3SC7kLv7MdhG8Ye7UDyiWUrgbH19yzte8ExjyV3/oEoXOH 6Ng1OxGPozAhkwUB0hGNqWgWJ+n5FNYdTg3wtbPBeZmB/0sn7tkZRDy6aeg60Kfm ytGCJXHGynkKunaLQCzRZVQ3Ywq1sqOHwUnlcbTMpCoZwR7TJ59BCIZs3J8kG14Z B5DopEyfs8NEgNLXUd4thG7Pw7TXWxSXvo/m7+/vLuCmBfSNW8frF/5QADxNfnqR Va2Sp8HY8ZElj+ug3G7W =pfay -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Git, GPG Signing, and Manifests 2015-07-17 1:25 ` Brian Dolbec @ 2015-07-17 3:06 ` NP-Hardass 2015-07-17 4:42 ` Brian Dolbec 0 siblings, 1 reply; 16+ messages in thread From: NP-Hardass @ 2015-07-17 3:06 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/16/2015 09:25 PM, Brian Dolbec wrote: > On Thu, 16 Jul 2015 21:13:09 -0400 NP-Hardass > <NP-Hardass@gentoo.org> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > >> Not sure if this has been covered in some of the rather long >> chains of late, but I was thinking about GPG signing, and how the >> proposed workflow requires every developer to sign their commits. >> Currently, it's advised that every manifest be signed. As far as >> I know, there are a number that are not. When a manifest is >> signed, the author is saving a state, and providing a means to >> check it has not changed. > >> Additionally, I feel that a signature is a means of acknowledging >> that a package has been looked over, and that developer has >> stated that they approve of the existing state. I'm not sure if >> others agree with that sentiment, but if anyone does, my question >> is, how does the conversion process to git handle these packages, >> where the manifests are not signed. Is there an intention to >> blanket cover all packages when we switch to git? Will these >> packages be copied over directly and still maintain their >> unsigned manifest (I think this is unlikely as I read that there >> would be a switch to thin manifests, requiring regeneration)? If >> the community doesn't view the signature of the manifest as I >> just described, then a blanket signing would be fine. > >> Would appreciate your thoughts either way, as I could be >> overthinking the issue :P > >> - -- NP-Hardass > > > No, with the git working tree, we will switch to thin manifests and > the entire commit will be signed. Not only that, but the push to > the main server will also be signed (a push may contain commits > signed by a different person that the person pushing). > > For the regular rsync tree, Full manifests will be regenerated as > needed and signed by a common infra supplied gpg key. So for > general users, it will be easy to verify without having all gentoo > devs gpg keys. That will be different for users of the git tree. > > > Ah ha. so, with thin manifests, we as devs don't sign the manifest, me sign the commit. The infra key for the user facing tree makes sense. Thanks for filling me in. So, will infra be using that key to do the initial commit to the repo? Are there plans to the make the repo, w/ metadata and signed by infra, available to end users as a rsync alternative? And my apologies to all for the multiple messages. My cron plugin for my email client is wonking. - -- NP-Hardass -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJVqHEbAAoJEBzZQR2yrxj7jVMQALWoMkXzxapjYlBaGtOk5eyd XQQuWH6m4U+9DrzQRJEeaCivIJmzXHPAVU6Rd40gBGqlSTMoJKm2pIMkxGvDLLd7 zIwuPolamQhFM0vhkUOidfgBqvCbFJV5rFTKtIPXg28JivoY7omi4/oANd0V8L7A YRik152d2cFW+rdITLhgf3JNky99yOy4NR3SYB/dQY+E8D+5RaCXjy/EqjNqbsin To+/far3d5e2/Z7dDlfyuhYyG6dwbFl8vY7RN+eERH68GTqj2bjy2EL0T9FAVwWI O9i4T1sRIneYVfd3MEoLwkPHjhfDOmP/zLloFaqT9AUtiVlVf9vMy5dKXHva1OTe cmNicf66YBsSD2J6mMRHE4N7iTn8tpI5W7+WpXa2gyEeqWwDwbENxNU1IHlZ0Ys7 cHpfhkx63oWwvDQX3XKjl1fUjoVEoJ/6HhHNWboLaAxJ/XUcZCAGNEaF9NVtE0FN VUFmU7ZU1GLkk+MAKxpwdMqa9+LJ+Sr+4/NzF1ceE54yoq0ks+PfafyMybseOptK bKbiAQ4/GvDB3Tpw4S2QuqYZ3pT/enxYET3v8YxVPE6Hw79RYeaMtEEnm0Niy29k CHUT6T0Ul3IfS6LQZtEwC40Izs/usM+HH2XuYP3OfkBLgK8LUhEUcVNiC6B6frUD M6d04xGeSvDVMo9vBoYb =Fufx -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Git, GPG Signing, and Manifests 2015-07-17 3:06 ` NP-Hardass @ 2015-07-17 4:42 ` Brian Dolbec 2015-07-17 12:36 ` Rich Freeman 0 siblings, 1 reply; 16+ messages in thread From: Brian Dolbec @ 2015-07-17 4:42 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, 16 Jul 2015 23:06:03 -0400 NP-Hardass <NP-Hardass@gentoo.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 07/16/2015 09:25 PM, Brian Dolbec wrote: > > On Thu, 16 Jul 2015 21:13:09 -0400 NP-Hardass > > <NP-Hardass@gentoo.org> wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > > >> Not sure if this has been covered in some of the rather long > >> chains of late, but I was thinking about GPG signing, and how the > >> proposed workflow requires every developer to sign their commits. > >> Currently, it's advised that every manifest be signed. As far as > >> I know, there are a number that are not. When a manifest is > >> signed, the author is saving a state, and providing a means to > >> check it has not changed. > > > >> Additionally, I feel that a signature is a means of acknowledging > >> that a package has been looked over, and that developer has > >> stated that they approve of the existing state. I'm not sure if > >> others agree with that sentiment, but if anyone does, my question > >> is, how does the conversion process to git handle these packages, > >> where the manifests are not signed. Is there an intention to > >> blanket cover all packages when we switch to git? Will these > >> packages be copied over directly and still maintain their > >> unsigned manifest (I think this is unlikely as I read that there > >> would be a switch to thin manifests, requiring regeneration)? If > >> the community doesn't view the signature of the manifest as I > >> just described, then a blanket signing would be fine. > > > >> Would appreciate your thoughts either way, as I could be > >> overthinking the issue :P > > > >> - -- NP-Hardass > > > > > > No, with the git working tree, we will switch to thin manifests and > > the entire commit will be signed. Not only that, but the push to > > the main server will also be signed (a push may contain commits > > signed by a different person that the person pushing). > > > > For the regular rsync tree, Full manifests will be regenerated as > > needed and signed by a common infra supplied gpg key. So for > > general users, it will be easy to verify without having all gentoo > > devs gpg keys. That will be different for users of the git tree. > > > > > > > > Ah ha. so, with thin manifests, we as devs don't sign the manifest, me > sign the commit. > Yes, you sign all changes made by that commit. In CVS this was not possible, so the best workaround was a 2 stage commit, where the initial changes were committed, then repoman updated and signed the new Manifest and committed that. > The infra key for the user facing tree makes sense. Thanks for > filling me in. So, will infra be using that key to do the initial > commit to the repo? I don't know tbh, most are already signed, with the git migration, the strongly recommended commit signing will become MANDATORY. So, we are at 50 devs with valid gpg keys now, with 200 more gpg keys listed in LDAP that fail to meet the new spec. PLEASE fix them or create new keys... > > Are there plans to the make the repo, w/ metadata and signed by infra, > available to end users as a rsync alternative? > Yes, there will be an anonymous git mirror/server for general consumption. But I believe there again, a user using it will have to get the gentoo-devs seed file and install those keys in order to validate it for themselves. - -- Brian Dolbec <dolsen> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJVqIe1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7Y15QQAKl+8k3PJM6ZrToDqAH2o+Af 4O5FRAr48NVOL+AsA9/8pihiR0p7xZ0N35TJoCh3vkyfPj3sPfxvm3ZC46azVS7r HoLgRLYVEv8cZpZXBRi7tqi2XWSYxvGl2tqyF9N/k+Eur00s9zLOepgmxjmvDSjq J88qd/oi6KB0ufVGpl6HkcumPAY5uVw1yjJu5GO/UIWivkXdaHUAwNe2w0eE/TUv +8YmzkYhmKMAfOF3RFIxcjxtjh13hMrSWqAjxgMG+sH/4jWXi0PWRXNTU6fCTJXP oxKFyB/XyZObugOMrmDGXX4jnW5oJpj4P02xDyAbsQR/85EAygoxGEr1jvOXrPhN vX9XYrLaQ62Us6UM8bM8mv1W7gKn/NJSJoeoRpKDsAvUcJlUp4fcCUWc4F/AaE3a cDYM8uqDJcN571QlR07Rd28/TTX2BFfEclu/u9SznfMLeveET9CUa12LYiIKfKfx PnO301QRih0FqH/kvX9kAvpJWZeBmn8xdhZ4VyOeYNQFKuROiexswKTapHbuIJec eM1P0rZmh9AQfVaZhZJpKbvfRl6HyU6cTeHQJ9mvNzQV87MQuhmIyckJfCQONUZM SQJ95nlg69NJBLY5IHUYdC1A5k3neRhLvpErOFJZQzlVbAaFXfSPnuDKR/YiBbJ3 Benzg8eJp5Dpngyzr1Mz =4Hgt -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Git, GPG Signing, and Manifests 2015-07-17 4:42 ` Brian Dolbec @ 2015-07-17 12:36 ` Rich Freeman 2015-07-17 12:44 ` Alon Bar-Lev ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Rich Freeman @ 2015-07-17 12:36 UTC (permalink / raw To: gentoo-dev On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec <dolsen@gentoo.org> wrote: > > I don't know tbh, most are already signed, with the git migration, the > strongly recommended commit signing will become MANDATORY. > > So, we are at 50 devs with valid gpg keys now, with 200 more gpg keys > listed in LDAP that fail to meet the new spec. PLEASE fix them or > create new keys... How does somebody know whether their key meets the spec or not? I looked at the gentoo-keys website and didn't see any simple way to check. There was documentation on the gkeys utility for checking keys, but I ran into a few issues with this. First, it can't be installed on a stable system with mirrorselect. On a clean ~arch stage3 when trying to run "gkeys fetch-seed -C gentoo-devs" it outputs: Connector.connect_url(); Failed to retrieve the content from: https://api.gentoo.org/gentoo-keys/seeds/gentoo-devs.seeds Error was: Invalid header value 'Wed, 15 Jul 2015 17:50:17 GMT\n' After removing the files in /var/lib/gentoo/gkeys/seeds the fetch works. However, attempting to run "gkeys install-key -C gentoo-devs" results in: Found GKEY seeds: Traceback (most recent call last): File "/usr/lib/python-exec/python2.7/gkeys", line 50, in <module> success = main() File "/usr/lib64/python2.7/site-packages/gkeys/cli.py", line 63, in __call__ return self.run(args) File "/usr/lib64/python2.7/site-packages/gkeys/base.py", line 303, in run success, results = func(args) File "/usr/lib64/python2.7/site-packages/gkeys/actions.py", line 264, in installkey self.output(['', gkey], "\n Found GKEY seeds:") File "/usr/lib64/python2.7/site-packages/gkeys/base.py", line 323, in output_results print("\n".join([x.pretty_print for x in msg])) UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in position 1233: ordinal not in range(128) It might not hurt to publish the list of keys that fail checks. If that list is going to be used to block commits then obviously it needs to be updated very frequently. I do not know if there are any plans to block commits with signatures that do not conform to the GLEP. -- Rich ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Git, GPG Signing, and Manifests 2015-07-17 12:36 ` Rich Freeman @ 2015-07-17 12:44 ` Alon Bar-Lev 2015-07-17 12:50 ` Rich Freeman 2015-07-17 15:11 ` Brian Dolbec 2 siblings, 0 replies; 16+ messages in thread From: Alon Bar-Lev @ 2015-07-17 12:44 UTC (permalink / raw To: gentoo-dev On 17 July 2015 at 15:36, Rich Freeman <rich0@gentoo.org> wrote: > On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec <dolsen@gentoo.org> wrote: >> >> I don't know tbh, most are already signed, with the git migration, the >> strongly recommended commit signing will become MANDATORY. >> >> So, we are at 50 devs with valid gpg keys now, with 200 more gpg keys >> listed in LDAP that fail to meet the new spec. PLEASE fix them or >> create new keys... > > How does somebody know whether their key meets the spec or not? I > looked at the gentoo-keys website and didn't see any simple way to > check. > > There was documentation on the gkeys utility for checking keys, but I > ran into a few issues with this. First, it can't be installed on a > stable system with mirrorselect. The use of keys should be by counter signature, when pushing the counter signature service should check if signature is valid and dev key is valid using the internal ldap for example, and counter sign with its own key and add timestamp. Users should trust only the counter signature service key which is formal and should be valid for long time. This is yet another reason why it is best to not use signature within git but remain the signed manifest. When commit one can sign the manifest, send the manifest to the counter signature service and obtain a formal signed manifest to be committed into tree. Using signed manifest also reduce the merge conflict, survive rebase, enable code review without loosing original signer and will enable future migration to other technology. Regards, Alon ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Git, GPG Signing, and Manifests 2015-07-17 12:36 ` Rich Freeman 2015-07-17 12:44 ` Alon Bar-Lev @ 2015-07-17 12:50 ` Rich Freeman 2015-07-17 15:25 ` Brian Dolbec 2015-07-17 15:11 ` Brian Dolbec 2 siblings, 1 reply; 16+ messages in thread From: Rich Freeman @ 2015-07-17 12:50 UTC (permalink / raw To: gentoo-dev On Fri, Jul 17, 2015 at 8:36 AM, Rich Freeman <rich0@gentoo.org> wrote: > On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec <dolsen@gentoo.org> wrote: >> >> I don't know tbh, most are already signed, with the git migration, the >> strongly recommended commit signing will become MANDATORY. >> >> So, we are at 50 devs with valid gpg keys now, with 200 more gpg keys >> listed in LDAP that fail to meet the new spec. PLEASE fix them or >> create new keys... > > How does somebody know whether their key meets the spec or not? I > looked at the gentoo-keys website and didn't see any simple way to > check. > > There was documentation on the gkeys utility for checking keys, but I > ran into a few issues with this. > After waking up a bit more I configured a utf8 locale in my "clean stage3" and the errors went away, and I was able to verify that my key passed, with no encryption subkey (I don't intend to use this key for anything but gentoo main repository signing). Even so, it might not hurt to have a one-line way to check an arbitrary gpg key for conformity by ID. Otherwise we invite trial and error with devs uploading what they hope are compliant keys, fixing LDAP, waiting for seeds to be repopulated, then checking them. -- Rich ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Git, GPG Signing, and Manifests 2015-07-17 12:50 ` Rich Freeman @ 2015-07-17 15:25 ` Brian Dolbec 0 siblings, 0 replies; 16+ messages in thread From: Brian Dolbec @ 2015-07-17 15:25 UTC (permalink / raw To: gentoo-dev On Fri, 17 Jul 2015 08:50:43 -0400 Rich Freeman <rich0@gentoo.org> wrote: > On Fri, Jul 17, 2015 at 8:36 AM, Rich Freeman <rich0@gentoo.org> > wrote: > > On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec <dolsen@gentoo.org> > > wrote: > >> > >> I don't know tbh, most are already signed, with the git migration, > >> the strongly recommended commit signing will become MANDATORY. > >> > >> So, we are at 50 devs with valid gpg keys now, with 200 more gpg > >> keys listed in LDAP that fail to meet the new spec. PLEASE fix > >> them or create new keys... > > > > How does somebody know whether their key meets the spec or not? I > > looked at the gentoo-keys website and didn't see any simple way to > > check. > > > > There was documentation on the gkeys utility for checking keys, but > > I ran into a few issues with this. > > > > After waking up a bit more I configured a utf8 locale in my "clean > stage3" and the errors went away, and I was able to verify that my key > passed, with no encryption subkey (I don't intend to use this key for > anything but gentoo main repository signing). > > Even so, it might not hurt to have a one-line way to check an > arbitrary gpg key for conformity by ID. Otherwise we invite trial and > error with devs uploading what they hope are compliant keys, fixing > LDAP, waiting for seeds to be repopulated, then checking them. > One of the things I really wanted to get into gkeys is a way to add a users ~/.gnupg dir imported into the gkeys system, that will help in that reagrds and make it more of a one stop shop for common gpg tasks. Also, I will try to get at least the gkeys-gen target keydir added to gkeys visibility in the next release. Oh, forgot to mention. I will send the gkeys spec-check report to the gentoo-core list for a start. Perhaps some of the devs can help us get the wiki help pages completed when they fix their keys and know the steps. I'm sure both Kristian and myself would appreciate a little help with that while we are explaining how to fix the failures. One of the slowdowns in completing those pages is creating anomymous gpg keys output for the wiki examples. I do not want to use devs real keys as examples (which of course would be easiest). -- Brian Dolbec <dolsen> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Git, GPG Signing, and Manifests 2015-07-17 12:36 ` Rich Freeman 2015-07-17 12:44 ` Alon Bar-Lev 2015-07-17 12:50 ` Rich Freeman @ 2015-07-17 15:11 ` Brian Dolbec 2 siblings, 0 replies; 16+ messages in thread From: Brian Dolbec @ 2015-07-17 15:11 UTC (permalink / raw To: gentoo-dev On Fri, 17 Jul 2015 08:36:25 -0400 Rich Freeman <rich0@gentoo.org> wrote: > On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec <dolsen@gentoo.org> > wrote: > > > > I don't know tbh, most are already signed, with the git migration, > > the strongly recommended commit signing will become MANDATORY. > > > > So, we are at 50 devs with valid gpg keys now, with 200 more gpg > > keys listed in LDAP that fail to meet the new spec. PLEASE fix > > them or create new keys... > > How does somebody know whether their key meets the spec or not? I > looked at the gentoo-keys website and didn't see any simple way to > check. > > There was documentation on the gkeys utility for checking keys, but I > ran into a few issues with this. First, it can't be installed on a > stable system with mirrorselect. > > On a clean ~arch stage3 when trying to run "gkeys fetch-seed -C > gentoo-devs" it outputs: > Connector.connect_url(); Failed to retrieve the content from: > https://api.gentoo.org/gentoo-keys/seeds/gentoo-devs.seeds > Error was: Invalid header value 'Wed, 15 Jul 2015 17:50:17 GMT\n' > > > After removing the files in /var/lib/gentoo/gkeys/seeds the fetch > works. However, attempting to run "gkeys install-key -C gentoo-devs" > results in: > Found GKEY seeds: > Traceback (most recent call last): > File "/usr/lib/python-exec/python2.7/gkeys", line 50, in <module> > success = main() > File "/usr/lib64/python2.7/site-packages/gkeys/cli.py", line 63, in > __call__ return self.run(args) > File "/usr/lib64/python2.7/site-packages/gkeys/base.py", line 303, > in run success, results = func(args) > File "/usr/lib64/python2.7/site-packages/gkeys/actions.py", line > 264, in installkey > self.output(['', gkey], "\n Found GKEY seeds:") > File "/usr/lib64/python2.7/site-packages/gkeys/base.py", line 323, > in output_results > print("\n".join([x.pretty_print for x in msg])) > UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in > position 1233: ordinal not in range(128) > > Yes, the ssl-fetch issue is fixed with ssl-fetch-0.3 and it is now stabilized. So that conflict is fixed. > It might not hurt to publish the list of keys that fail checks. If > that list is going to be used to block commits then obviously it needs > to be updated very frequently. I do not know if there are any plans > to block commits with signatures that do not conform to the GLEP. > Yeah, I was thinking of putting up a gkeys spec-check report, but we were (unsuccessfully) trying to get more wiki pages help done on how to fix those issues reported. Before we did such a report. Also I need to make another release, currently gkeys-9999 and gkeys-gen-999 is the best option with the most fixes, best functionality. Hopefully I'll get those release this weekend. -- Brian Dolbec <dolsen> ^ permalink raw reply [flat|nested] 16+ messages in thread
* OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests) 2015-07-17 1:13 [gentoo-dev] Git, GPG Signing, and Manifests NP-Hardass 2015-07-17 1:25 ` Kent Fredric 2015-07-17 1:25 ` Brian Dolbec @ 2015-07-17 8:18 ` Kristian Fiskerstrand 2015-07-17 9:48 ` hasufell 2015-07-17 10:34 ` Verification of installed packages (was Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests)) Andrew Savchenko 2 siblings, 2 replies; 16+ messages in thread From: Kristian Fiskerstrand @ 2015-07-17 8:18 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/17/2015 03:13 AM, NP-Hardass wrote: > Additionally, I feel that a signature is a means of acknowledging > that a package has been looked over, and that developer has stated > that they approve of the existing state. I'm not sure if others > agree with that sentiment, I appreciate that you bring up this point. I would expect that part of that state is for the developer to verify the source distfile from upstream using OpenPGP / GnuPG as well, i.e not just rely on TOFU (trust on first use). This also means keeping a (locally) certified copy of the upstream distribution key that is reasonably verified by the developer. - -- Kristian Fiskerstrand Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVqLpCAAoJECULev7WN52FtmYH/3ySS/fM62KcRyxHrfDswNzA sL0lj43JxWAwCcPI46X8ag7nUBYwuo/x9E6IDQotAe1MoiV3vPGLIDugrCHIE0Ai AxVKhPwCXFDxtNwSKDIxiaupssLSt9uLB5rCMP+eJoFl3wiQb7rI4ly/qXE2DI6O U6sLABiq/7nmRSsCzakyNionknSU60HLo3V1o8/KdoyBfaup9FsHdFYMZmbn+w0T 0Rv2FJV6z0BsjmaOJQ4qCrOqtcNLnrUaXGdRm153LfAWoWiBMhM/mlOsDk73j4zw NtMSJpKbfIHsNrF8d9c6xrni5zlmaEjGoeQKSVJILEwO4ROnUKh2M1LwOiTkhzo= =bVWz -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests) 2015-07-17 8:18 ` OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests) Kristian Fiskerstrand @ 2015-07-17 9:48 ` hasufell 2015-07-17 9:56 ` Kristian Fiskerstrand 2015-07-17 10:34 ` Verification of installed packages (was Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests)) Andrew Savchenko 1 sibling, 1 reply; 16+ messages in thread From: hasufell @ 2015-07-17 9:48 UTC (permalink / raw To: gentoo-dev On 07/17/2015 10:18 AM, Kristian Fiskerstrand wrote: > On 07/17/2015 03:13 AM, NP-Hardass wrote: > >> Additionally, I feel that a signature is a means of acknowledging >> that a package has been looked over, and that developer has stated >> that they approve of the existing state. I'm not sure if others >> agree with that sentiment, > > I appreciate that you bring up this point. I would expect that part of > that state is for the developer to verify the source distfile from > upstream using OpenPGP / GnuPG as well, i.e not just rely on TOFU > (trust on first use). This also means keeping a (locally) certified > copy of the upstream distribution key that is reasonably verified by > the developer. > This really depends. In general, a signed commit can and should only say that the _patch_ comes from or was approved by a particular person. If it's a version bump on a single package, you can probably assume that he had a rough lookover. But you can't expect the same when e.g. the python herd has to do mass commits because of USE flag changes. That "approve of existing state" thing is rather implicit in a review workflow, where the package maintainer does the merge. We currently don't have any plans to enforce this globally, so signatures just say "this patch comes from...". ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests) 2015-07-17 9:48 ` hasufell @ 2015-07-17 9:56 ` Kristian Fiskerstrand 0 siblings, 0 replies; 16+ messages in thread From: Kristian Fiskerstrand @ 2015-07-17 9:56 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/17/2015 11:48 AM, hasufell wrote: > On 07/17/2015 10:18 AM, Kristian Fiskerstrand wrote: >> On 07/17/2015 03:13 AM, NP-Hardass wrote: >> >>> Additionally, I feel that a signature is a means of >>> acknowledging that a package has been looked over, and that >>> developer has stated that they approve of the existing state. >>> I'm not sure if others agree with that sentiment, >> >> I appreciate that you bring up this point. I would expect that >> part of that state is for the developer to verify the source >> distfile from upstream using OpenPGP / GnuPG as well, i.e not >> just rely on TOFU (trust on first use). This also means keeping a >> (locally) certified copy of the upstream distribution key that is >> reasonably verified by the developer. >> > > This really depends. In general, a signed commit can and should > only say that the _patch_ comes from or was approved by a > particular person. If it's a version bump on a single package, you > can probably assume that he had a rough lookover. But you can't > expect the same when e.g. the python herd has to do mass commits > because of USE flag changes. > I was referring to process during a version bump, the manifest entry for the distfile shouldn't be changed during a USE flag change, so in this case that verification would be brought along from the developer doing the bump. > That "approve of existing state" thing is rather implicit in a > review workflow, where the package maintainer does the merge. We > currently don't have any plans to enforce this globally, so > signatures just say "this patch comes from...". Not all do, as mentioned the push can be signed, e.g while an individual commit is signed by another (potentially a non-gentoo-dev). All I'm trying to say is really (and this isn't specific to the git workflow); Please take it as a reminder to verify upstream OpenPGP signatures when bumping packages, and please make an effort to maintain proper key management practices while doing so so you can do it properly. If we don't we have a case of purgamentum init, exit purgamentum (garbagin in, garbage out) - -- Kristian Fiskerstrand Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVqNEnAAoJECULev7WN52FohUIAIQrKGb7urSmzWFyIfF00FSr i+arpIMbClzyUf6fwulf22fkE0UjBykoodA6p67dxakgWOEpHkpoUW7Z3v8eyPu8 +UHzV67sNgoEnJW4PASyrOABMkpi5oHr2nGSq6oHwHG5oXnw9askEH8srThBTwNx Kflo4mzxSpbgIrbfawFERWPBTtwU1P1WLAVSKRz6GkPAKuY/ypjMeFJ2TSdPeapR TYLhgSUa/3gUOZx7OBJpYxqU2j7WOnGwxMsReJVnMykB4LOv7SRXzXSM+6r0Q+os bWv2wKUfOPwoOCMD+F0nIFZ/85T7wSiZxemM5T85+FFL6xl4hXgZr8GUwJU9iB4= =NylE -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Verification of installed packages (was Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests)) 2015-07-17 8:18 ` OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests) Kristian Fiskerstrand 2015-07-17 9:48 ` hasufell @ 2015-07-17 10:34 ` Andrew Savchenko 2015-07-17 10:43 ` Kent Fredric 1 sibling, 1 reply; 16+ messages in thread From: Andrew Savchenko @ 2015-07-17 10:34 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1844 bytes --] Hi, On Fri, 17 Jul 2015 10:18:14 +0200 Kristian Fiskerstrand wrote: > > Additionally, I feel that a signature is a means of acknowledging > > that a package has been looked over, and that developer has stated > > that they approve of the existing state. I'm not sure if others > > agree with that sentiment, > > I appreciate that you bring up this point. I would expect that part of > that state is for the developer to verify the source distfile from > upstream using OpenPGP / GnuPG as well, i.e not just rely on TOFU > (trust on first use). This also means keeping a (locally) certified > copy of the upstream distribution key that is reasonably verified by > the developer. Let me point another issue related to discussion above. It would be nice to have cryptographic verification of already installed packages. This will help in forensics and security audit of the systems, so that even without external snapshot of the system it will be possible to check for malicious changes of installed packages. Right now we have /var/db/pkg/$cat/$name/CONTENTS file with such data, but: 1. It uses md5 for file checksums. 2. It is not signed. So my proposal is: 1. Switch to more cryptographically secure hash (e.g. sha512 or whirlpool). 2. Add an optional feature to emerge (or even to PMS?) allowing user to provide a usable GPG key for signing packages CONTENTS files after its generation. In order for such key to be usable during emerge run, gpg-agent should be used; alternatively it may be allowed to sign already installed packages on a trusted system. 3. Of course backward compatibility with old CONTENTS format should be kept. This proposal is not my own whim: I have requests from users for such functionality which is quite wanted on production setups. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Verification of installed packages (was Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests)) 2015-07-17 10:34 ` Verification of installed packages (was Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests)) Andrew Savchenko @ 2015-07-17 10:43 ` Kent Fredric 0 siblings, 0 replies; 16+ messages in thread From: Kent Fredric @ 2015-07-17 10:43 UTC (permalink / raw To: gentoo-dev On 17 July 2015 at 22:34, Andrew Savchenko <bircoph@gentoo.org> wrote: > 2. Add an optional feature to emerge (or even to PMS?) allowing user > to provide a usable GPG key for signing packages CONTENTS files > after its generation. In order for such key to be usable during > emerge run, gpg-agent should be used; alternatively it may be > allowed to sign already installed packages on a trusted system. > 3. Of course backward compatibility with old CONTENTS format should > be kept. To keep things simple, I'd suggest storing the signature externally to the CONTENTS file. This would be more convenient for any tools that are trying to scrape the CONTENTS files with regex/grep not needing to first unwrap them. ( Not to mention trivial to determine which packages have signatures without needing to actually read the files ) Though, seeing we're going down this road, you could sign the whole vdb dir. -- Kent KENTNL - https://metacpan.org/author/KENTNL ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2015-07-17 15:25 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-07-17 1:13 [gentoo-dev] Git, GPG Signing, and Manifests NP-Hardass 2015-07-17 1:25 ` Kent Fredric 2015-07-17 3:13 ` NP-Hardass 2015-07-17 1:25 ` Brian Dolbec 2015-07-17 3:06 ` NP-Hardass 2015-07-17 4:42 ` Brian Dolbec 2015-07-17 12:36 ` Rich Freeman 2015-07-17 12:44 ` Alon Bar-Lev 2015-07-17 12:50 ` Rich Freeman 2015-07-17 15:25 ` Brian Dolbec 2015-07-17 15:11 ` Brian Dolbec 2015-07-17 8:18 ` OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests) Kristian Fiskerstrand 2015-07-17 9:48 ` hasufell 2015-07-17 9:56 ` Kristian Fiskerstrand 2015-07-17 10:34 ` Verification of installed packages (was Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests)) Andrew Savchenko 2015-07-17 10:43 ` Kent Fredric
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox