[gentoo-dev] Git, GPG Signing, and Manifests

[gentoo-dev] Git, GPG Signing, and Manifests

[NP-Hardass]

-----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-----

Re: [gentoo-dev] Git, GPG Signing, and Manifests

[Kent Fredric]

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

Re: [gentoo-dev] Git, GPG Signing, and Manifests

[Brian Dolbec]

-----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-----

Re: [gentoo-dev] Git, GPG Signing, and Manifests

[NP-Hardass]

-----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-----

Re: [gentoo-dev] Git, GPG Signing, and Manifests

[NP-Hardass]

-----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-----

Re: [gentoo-dev] Git, GPG Signing, and Manifests

[Brian Dolbec]

-----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-----

OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests)

[Kristian Fiskerstrand]

-----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-----

Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests)

[hasufell]

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...".

Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests)

[Kristian Fiskerstrand]

-----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-----

Verification of installed packages (was Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests))

[Andrew Savchenko]

[-- 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 --]

Re: Verification of installed packages (was Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests))

[Kent Fredric]

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

Re: [gentoo-dev] Git, GPG Signing, and Manifests

[Rich Freeman]

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

Re: [gentoo-dev] Git, GPG Signing, and Manifests

[Alon Bar-Lev]

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

Re: [gentoo-dev] Git, GPG Signing, and Manifests

[Rich Freeman]

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

Re: [gentoo-dev] Git, GPG Signing, and Manifests

[Brian Dolbec]

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>

Re: [gentoo-dev] Git, GPG Signing, and Manifests

[Brian Dolbec]

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>