Michael, you make a very good point at https://blogs.gnome.org/mcatanzaro/2016/03/13/do-you-trust-this-package/
Our packaging guidelines really ought to mandate that *if* upstream publishes GPG or PKCS#7/CMS signatures of source tarballs, then the package *must* verify those signatures as part of %prep.
Do you want to put a draft together for approval by the packaging committee?
It might be nice to provide some RPM macros to make that easier for packagers.
I've had a go at doing this for OpenConnect, in http://pkgs.fedoraproject.org/cgit/rpms/openconnect.git/commit/?id=ca61de3f7...
It's a bit pointless there, since the tarballs tend to get uploaded to Fedora from the same workstation I sign them on, sometimes *before* they're uploaded to the FTP site. But it's still good practice, as you rightly point out.
On Mon, 2016-03-21 at 10:25 +0000, David Woodhouse wrote:
Michael, you make a very good point at https://blogs.gnome.org/mcatanzaro/2016/03/13/do-you-trust-this-packa ge/
Our packaging guidelines really ought to mandate that *if* upstream publishes GPG or PKCS#7/CMS signatures of source tarballs, then the package *must* verify those signatures as part of %prep.
Hi,
I agree this is a good idea. I actually did not consider that we could handle this in %prep.
Do you want to put a draft together for approval by the packaging committee?
Nope. Maybe somebody else will be interested in working on this. (I have no clue how to use GPG anyway. :)
It might be nice to provide some RPM macros to make that easier for packagers.
I agree.
I've had a go at doing this for OpenConnect, in http://pkgs.fedoraproject.org/cgit/rpms/openconnect.git/commit/?id=ca 61de3f77
It's a bit pointless there, since the tarballs tend to get uploaded to Fedora from the same workstation I sign them on, sometimes *before* they're uploaded to the FTP site. But it's still good practice, as you rightly point out.
Thanks,
Michael
On Mon, Mar 21, 2016 at 10:25:43AM +0000, David Woodhouse wrote:
It might be nice to provide some RPM macros to make that easier for packagers.
It is a simple one-liner if you use gpgv2: http://pkgs.fedoraproject.org/cgit/rpms/youtube-dl.git/tree/youtube-dl.spec#...
Thank you for raising awareness about this!
Kind regards Till
On Mon, 2016-03-21 at 18:02 +0100, Till Maas wrote:
It is a simple one-liner if you use gpgv2: http://pkgs.fedoraproject.org/cgit/rpms/youtube-dl.git/tree/youtube-dl.spec#...
That's better than my version; thanks. It also means there's probably not a lot of point in trying to simplify it with an RPM macro.
Might be nice if we could just use the ASCII-armoured key instead of having to generate the gpgkey-$KEYID.gpg keyring, but it's not the end of the world.
It turns out we've had a packaging draft since 2010: https://fedoraproject.org/wiki/PackagingDrafts:GPGSignatures
I've updated it and taken it over. I'm sure Matt will forgive me.
The original draft does raise an interesting question — do we need to put the upstream PGP key directly into the package git tree instead of the lookaside cache?
I suppose while the lookaside cache is still only using MD5(!) to validate what it downloads, the answer to that is an unequivocal 'yes'. Which means it would be even nicer to find a way to use the ASCII- armoured version of the key. Perhaps even if the check ends up being a two-stage process where we *make* a keyring and then use it with gpgv2? But really, the key is encoded in the signature already; can't we just specify the acceptable fingerprint on the gpgv2 command line? Is that a reasonable feature request for gpgv2?
The original draft also asks if we want the signature itself to be in the git tree. I don't really see the point, if the signing key is trusted.
https://fedorahosted.org/fpc/ticket/610
Might be nice to have rpmlint, when checking source URLs, also complain if a %{SOURCEx}.sig or %{SOURCEx}.asc file exists on the download site, and *isn't* also present as a source file in the spec?
On Tue, Mar 22, 2016 at 9:02 AM, David Woodhouse dwmw2@infradead.org wrote:
The original draft does raise an interesting question — do we need to put the upstream PGP key directly into the package git tree instead of the lookaside cache?
I suppose while the lookaside cache is still only using MD5(!) to validate what it downloads, the answer to that is an unequivocal 'yes'.
As an aside, I think Till has code written to make the lookaside use sha256. I'm not sure what the next steps are to get that rolled out though.
josh
On Tue, 2016-03-22 at 09:12 -0400, Josh Boyer wrote:
On Tue, Mar 22, 2016 at 9:02 AM, David Woodhouse <dwmw2@infradead.org
wrote:
The original draft does raise an interesting question — do we need to put the upstream PGP key directly into the package git tree instead of the lookaside cache?
I suppose while the lookaside cache is still only using MD5(!) to validate what it downloads, the answer to that is an unequivocal 'yes'.
As an aside, I think Till has code written to make the lookaside use sha256. I'm not sure what the next steps are to get that rolled out though.
Code-wise, everything is ready, both on the server-side and on the client-side.
The only thing needed now is to flip the switch from md5 to sha512.
But doing so would mandate an upgrade for every packager, since enforcing sha512 means older fedpkg versions still using md5 would get their uploads refused.
As a result, the Releng team collectively decided to hold off the move, and bundle it with other similarly breaking changes (new Koji certificates, for example)
All the details are here:
https://fedorahosted.org/rel-eng/ticket/5846
-- Mathieu
On Tue, Mar 22, 2016 at 1:30 PM, Till Maas opensource@till.name wrote:
On Tue, Mar 22, 2016 at 09:12:15AM -0400, Josh Boyer wrote:
As an aside, I think Till has code written to make the lookaside use sha256. I'm not sure what the next steps are to get that rolled out though.
Just for the record: Mathieu wrote the code/did the work for this.
Indeed. My apologies for misremembering who put in the effort here, Mathieu. And thanks!
josh
David Woodhouse dwmw2@infradead.org wrote:
On Mon, 2016-03-21 at 18:02 +0100, Till Maas wrote:
It is a simple one-liner if you use gpgv2: http://pkgs.fedoraproject.org/cgit/rpms/youtube-dl.git/tree/youtube-dl.spec#...
That's better than my version; thanks. It also means there's probably not a lot of point in trying to simplify it with an RPM macro.
Might be nice if we could just use the ASCII-armoured key instead of having to generate the gpgkey-$KEYID.gpg keyring, but it's not the end of the world.
[...]
Which means it would be even nicer to find a way to use the ASCII- armoured version of the key. Perhaps even if the check ends up being a two-stage process where we *make* a keyring and then use it with gpgv2?
Yes, if we're going to make this mandatory, then we should have a program or an RPM macro or some kind of code that can be run with a one-liner in the spec file, that recognizes the common file formats that are used to export or publish keys, and verifies the signature. We shouldn't require packagers to run obscure commands to convert keys into a special format before uploading them.
But really, the key is encoded in the signature already;
Is it really? An OpenPGP signature specifies which key it was made with, but I'm pretty sure it doesn't contain the key. In all of my experience with PGP and GPG there has always been an obvious difference between having a signature but not the key, and having a signature and a matching key.
An S/MIME signature, on the other hand, is said to contain the whole certificate chain.
Björn Persson
On Tue, Mar 22, 2016 at 01:02:40PM +0000, David Woodhouse wrote:
On Mon, 2016-03-21 at 18:02 +0100, Till Maas wrote:
It is a simple one-liner if you use gpgv2: http://pkgs.fedoraproject.org/cgit/rpms/youtube-dl.git/tree/youtube-dl.spec#...
That's better than my version; thanks. It also means there's probably not a lot of point in trying to simplify it with an RPM macro.
Might be nice if we could just use the ASCII-armoured key instead of having to generate the gpgkey-$KEYID.gpg keyring, but it's not the end of the world.
I already meant to file this feature request after discussing this with Werner Koch, so here it is and hopefully it will really be implemented: https://bugs.gnupg.org/gnupg/issue2290
The original draft does raise an interesting question — do we need to put the upstream PGP key directly into the package git tree instead of the lookaside cache?
IMHO this makes it easier to manage, since one can just use fedpkg new-sources for the new tarball and signature without making sure that the key stays in the sources file.
I suppose while the lookaside cache is still only using MD5(!) to validate what it downloads, the answer to that is an unequivocal 'yes'. Which means it would be even nicer to find a way to use the ASCII- armoured version of the key. Perhaps even if the check ends up being a two-stage process where we *make* a keyring and then use it with gpgv2? But really, the key is encoded in the signature already; can't we just specify the acceptable fingerprint on the gpgv2 command line? Is that a reasonable feature request for gpgv2?
The key itself is not part of the signature, only the short key id is an optional part of the signature. Btw. the keyring is just the de-armored GPG key, therefore an armored key can be de-armored with:
gpg --dearmor
But it also might make sense to first import the key and then export it in a minimised form with: gpg --export-options export-minimal --export $KEYID > $keyring
The original draft also asks if we want the signature itself to be in the git tree. I don't really see the point, if the signing key is trusted.
I agree with you here.
Kind regards Till
On Tue, 2016-03-22 at 18:29 +0100, Till Maas wrote:
I already meant to file this feature request after discussing this with Werner Koch, so here it is and hopefully it will really be implemented: https://bugs.gnupg.org/gnupg/issue2290
Excellent; thank you. And in the meantime it's possible just to
gpg2 --dearmor $KEY.asc gpgv2 --keyring $KEY.asc.gpg %{SOURCE1} ${SOURCE0}
The original draft does raise an interesting question — do we need to put the upstream PGP key directly into the package git tree instead of the lookaside cache?
IMHO this makes it easier to manage, since one can just use fedpkg new-sources for the new tarball and signature without making sure that the key stays in the sources file.
And less chance of the key being changed.
David Woodhouse wrote:
Our packaging guidelines really ought to mandate that *if* upstream publishes GPG or PKCS#7/CMS signatures of source tarballs, then the package *must* verify those signatures as part of %prep.
I suppose the point of this would be that others can see that the verification has been done, right?
Because technically, verifying a tarball that the packager uploaded, with a signature that the packager uploaded, against a key that the packager uploaded, that doesn't really add anything compared to the packager verifying the signature before they upload the tarball. The difference is that no one else can know whether the packager really did verify the signature, but encoding it in the spec shows publicly that the verification takes place.
That's a step in the right direction, and I support the proposal, but let's not fool ourselves into believing that this would prove that the code is genuine. The build system has no way of verifying that the key in the source package really is the upstream developer's key, especially not when it has no Internet access. If an attacker would trick a packager into downloading a malicious tarball with a corresponding key and signature, then the verification in %prep wouldn't catch that.
Björn Persson
On Tue, Mar 22, 2016 at 06:01:28PM +0100, Björn Persson wrote:
David Woodhouse wrote:
Our packaging guidelines really ought to mandate that *if* upstream publishes GPG or PKCS#7/CMS signatures of source tarballs, then the package *must* verify those signatures as part of %prep.
I suppose the point of this would be that others can see that the verification has been done, right?
It also makes it easier with (co)maintainers to establish a trust-on-first-use signature verification model. For example I added the GPG key for youtube-dl to the spec file and the co-maintainer or current maintainer just needs to update the tarball and the signature to be sure that only a trusted tarball will be used. Also it allows to easily verify the tarball using fedpkg prep or fedpkg local.
I guess it might even make the new hotness do scratch builds with verified tarballs, since iirc it updates both the tarball and the signature and then %prep makes sure that they are verified.
Kind regards Till
Till Maas wrote:
I guess it might even make the new hotness do scratch builds with verified tarballs, since iirc it updates both the tarball and the signature and then %prep makes sure that they are verified.
I suppose so, at least if the key is specified as only a filename. What will it do if a URL to the key is provided, and the key at that location has been modified? Will it replace the key with the modified one in the scratch build, or will it leave the key alone when there is no version number in the filename?
Björn Persson
On Tue, Mar 22, 2016 at 2:45 PM, Björn Persson <Bjorn@rombobjörn.se> wrote:
Till Maas wrote:
I guess it might even make the new hotness do scratch builds with verified tarballs, since iirc it updates both the tarball and the signature and then %prep makes sure that they are verified.
I suppose so, at least if the key is specified as only a filename. What will it do if a URL to the key is provided, and the key at that location has been modified? Will it replace the key with the modified one in the scratch build, or will it leave the key alone when there is no version number in the filename?
If Werner Koch is willing to make changes to benefit this type of use case, I don't suppose he could be persuaded to define a canonical, reasonably compact fingerprint format?
$ gpg --verify-by-fingerprint "gpg-ecdsa-nfakjwejfhasasfewiahcalkweec" filename filename.sig [optional path to keyring or whatever if not embedded in the sig]
would be quite handy.
256 bits of fingerprint would be sufficient for the forseeable future against anything except multiple-target quantum attacks. With signature schemes like ECDSA, simply encoding the literal public key would work fine, too.
<not-yet-relevant>Off the top of my head, a multiple-target quantum attack involves finding any of 2^t needles in a haystack of size 2^b, for a probability of 2^(t-b) that any given needle wins. Using a practical upper bound of t=128 and requiring that the adversary spend 2^128 effort on an attack gives t-b ~ 256 or b ~ 384 bits for security against Grover-style attacks.
Of course, trying to defend against that attack using 384-bit fingerprints over ECDSA keys is totally pointless. The world should seriously consider switching to SPHINCS or similar for software verification. </not-yet-relevant>
Björn Persson
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On Tue, 2016-03-22 at 22:45 +0100, Björn Persson wrote:
I suppose so, at least if the key is specified as only a filename. What will it do if a URL to the key is provided, and the key at that location has been modified? Will it replace the key with the modified one in the scratch build, …
That behaviour would be... suboptimal.
The key (or at least its fingerprint) should be committed directly to pkg git after being obtained through some trusted method — which depends on how upstream publishes it. For reference, I put a couple of examples into https://fedorahosted.org/fpc/ticket/610#comment:6
On Tue, Mar 22, 2016 at 10:45:59PM +0100, Björn Persson wrote:
I suppose so, at least if the key is specified as only a filename. What will it do if a URL to the key is provided, and the key at that location has been modified? Will it replace the key with the modified one in the scratch build, or will it leave the key alone when there is no version number in the filename?
At least spectool checks only whether a file with the intended name exists and skips downloading it, if it does. Therefore if the key is in the repo already, then it will not be downloaded. But I do not know what the new hotness is using to download source files.
Kind regards Till
On Tue, 2016-03-22 at 18:01 +0100, Björn Persson wrote:
Because technically, verifying a tarball that the packager uploaded, with a signature that the packager uploaded, against a key that the packager uploaded, that doesn't really add anything compared to the packager verifying the signature before they upload the tarball.
... every time.
You're right, it doesn't really add anything. But it's free, and it's a belt-and-braces system. Whatever might corrupt a tarball between the original download and the RPM build, the check in %prep would catch it.
Assuming the signing key isn't *also* compromised, of course. But there's a fairly large class of problems that *would* be caught. For almost no effort.
David Woodhouse wrote:
Our packaging guidelines really ought to mandate that *if* upstream publishes GPG or PKCS#7/CMS signatures of source tarballs, then the package *must* verify those signatures as part of %prep.
I just thought of something that shouldn't be forgotten: How would this affect the bootstrapping of a new architecture?
In https://fedoraproject.org/wiki/Architectures/AArch64/Bootstrap the gnupg2 package is listed in stage 3, where builds were done with RPMbuild. Bash (just to pick an example) is also listed in stage 3. Bash tarballs are signed, so verification would be required in bash.spec. This would move GPG and its dependencies to stage 2, stuff that must be built before RPMbuild can be used.
Is that acceptable? Should there be something that disables the verification during bootstrapping?
Björn Persson
On Thu, Mar 24, 2016 at 10:28:45AM +0100, Björn Persson wrote:
David Woodhouse wrote:
Our packaging guidelines really ought to mandate that *if* upstream publishes GPG or PKCS#7/CMS signatures of source tarballs, then the package *must* verify those signatures as part of %prep.
I just thought of something that shouldn't be forgotten: How would this affect the bootstrapping of a new architecture?
In https://fedoraproject.org/wiki/Architectures/AArch64/Bootstrap the gnupg2 package is listed in stage 3, where builds were done with RPMbuild. Bash (just to pick an example) is also listed in stage 3. Bash tarballs are signed, so verification would be required in bash.spec. This would move GPG and its dependencies to stage 2, stuff that must be built before RPMbuild can be used.
Is that acceptable? Should there be something that disables the verification during bootstrapping?
Put a link gpg → true in $PATH for the duration of stages 1-2?
Zbyszek
David Woodhouse wrote:
Our packaging guidelines really ought to mandate that *if* upstream publishes GPG or PKCS#7/CMS signatures of source tarballs, then the
^ and if the upstream tarball can legally be redistributed as is
package *must* verify those signatures as part of %prep.
If we need to repackage the tarball to remove patent-encumbered or otherwise illegal or non-redistributable files, we cannot do this.
Kevin Kofler
David Woodhouse wrote:
If we need to repackage the tarball to remove patent-encumbered or otherwise illegal or non-redistributable files, we cannot do this.
I think , we can. Because the check in %prep should make sure that you've got the real thing. It doesn't require that you have to package everything that makes up the source after extraction.
Ralf Senderek wrote:
I think , we can. Because the check in %prep should make sure that you've got the real thing. It doesn't require that you have to package everything that makes up the source after extraction. --
We can't. The upstream signatures are for the complete tarballs including the encumbered bits we cannot ship. We have to rebuild the tarball to remove the offending stuff, so there is no way the signature can possibly match.
Kevin Kofler
On 29 Mar 2016 18:08, "Ralf Senderek" fedora@senderek.ie wrote:
David Woodhouse wrote:
If we need to repackage the tarball to remove patent-encumbered or
otherwise
illegal or non-redistributable files, we cannot do this.
I think , we can. Because the check in %prep should make sure that you've
got the real thing.
It doesn't require that you have to package everything that makes up the
source after extraction.
The issue isn't the binary RPM but rather the SRPM which would need to include the signed tarball (and the lookaside cache for the sources of course) so that %prep works in koji.
It's fine as an optional thing but wouldn't work as mandatory one.
And of course with the packager uploading both the key and the archive to git with no net access in koji to verify the key I really don't see what this actually gives us beyond a heads up to a sleeper maintainer that he doesn't have an official tarball when built locally...
On Wed, Mar 30, 2016 at 07:01:53AM +0100, James Hogarth wrote:
And of course with the packager uploading both the key and the archive to git with no net access in koji to verify the key I really don't see what this actually gives us
The signature and key can be verified by anyone. The signature key usually changes only rarely, and dist-git history is immutable, so you easily can check that the key is the same one that has been used to signed previous releases by looking at git history, which is already useful by itself.
By expending a bit more effort, you can do a verification of the key once in some side channel (e.g. using the network or some local web-of-trust), and then only check that this key hasn't changed in dist-git. If the key ever changes, this is a reason for suspicion and a careful check.
beyond a heads up to a sleeper maintainer that he doesn't have an official tarball when built locally...
I don't think you can discount this. Most maintainers don't check the tarballs they download if they build fine, afaik. Checking the signatures in %prep would force a significant change to how we build srpms.
Zbyszek
On 30 Mar 2016 13:15, "Zbigniew Jędrzejewski-Szmek" zbyszek@in.waw.pl wrote:
On Wed, Mar 30, 2016 at 07:01:53AM +0100, James Hogarth wrote:
And of course with the packager uploading both the key and the archive
to
git with no net access in koji to verify the key I really don't see what this actually gives us
The signature and key can be verified by anyone. The signature key usually changes only rarely, and dist-git history is immutable, so you easily can check that the key is the same one that has been used to signed previous releases by looking at git history, which is already useful by itself.
By expending a bit more effort, you can do a verification of the key once in some side channel (e.g. using the network or some local
web-of-trust),
and then only check that this key hasn't changed in dist-git. If the key ever changes, this is a reason for suspicion and a careful check.
But by the same line of thinking you can just use grab the tarball yourself and compare to the sources in dist-git to verify upstream matches local (as the fedora-review tool does).
And from there you rapidly venture siren the same Web of Trust issues anyway.
beyond a heads up to a sleeper maintainer that he doesn't have an official tarball when built locally...
I don't think you can discount this. Most maintainers don't check the tarballs they download if they build fine, afaik. Checking the signatures in %prep would force a significant change to how we build srpms.
That perhaps is a valid case to an extent, but it really does seem reaching for the edge to find a reason for it.
Now don't think there's any harm in shipping the gpg key and doing a verification but I don't think it should be a mandatory guideline.
Have the guideline state "if the upstream provides a signed archive then this SHOULD be verified in %prep" rather than a must... Add the appropriate review entry to go with it and add a macro with standardised naming to make it convenient.
That would be much better than a MUST and would avoid FPC exceptions if there were reasons the tarball can't be distributed.
We trust our packagers to do a lot, we can trust them to add this to their packages if it helps them and for them to encourage it in their reviews if they find a signed archive provided upstream.
How many packages is this really going to affect anyway? Would be interesting if there was a convenient way to tell.
James Hogarth wrote:
We trust our packagers to do a lot, we can trust them to add this to their packages if it helps them and for them to encourage it in their reviews if they find a signed archive provided upstream.
IMHO, this is the main point. Checking signatures automatically in %prep only makes sense if you are sure you're using the correct public key. So the packager, who is supposed to work closely with upstream, MUST make sure that he has the correct public key form first-hand knowledge before he can include it in the spec file as %(SourceN) for %prep. This is as important as checking the source code for licensing files and it would be much more than the average Joe would do if he'd gonna check the source himself.
Sometimes the packager and upstream is even the same, so making sure the right public key is being used will be quite easy.
Having said the above, I also advocate a SHOULD instead of a MUST in the guidelines as providing a signature with the source tarball is voluntary for upstream and should be viewed as an additional means to maintain the integrity of the code that should be honoured in the spec file.
On Wed, Mar 30, 2016 at 02:26:59PM -0000, Ralf Senderek wrote: [snip the part I complete agree with]
Having said the above, I also advocate a SHOULD instead of a MUST in the guidelines as providing a signature with the source tarball is voluntary for upstream and should be viewed as an additional means to maintain the integrity of the code that should be honoured in the spec file.
What the upstream does is something that we cannot control, and we can only encourage the upstream to DTRT.
In fact signatures and license files are quite similar: our guidelines say that the license file MUST be installed if provided by upstream, and packagers SHOULD ask upstream to provide it if it is missing [1]. I think we should follow this pattern for signatures.
There will always be exceptions to the "MUST check if signed" rule: repacking the tarball is an obvious one. The guidelines should acknowledge this.
Zbyszek
On Wed, Mar 30, 2016 at 02:44:44PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Mar 30, 2016 at 02:26:59PM -0000, Ralf Senderek wrote: [snip the part I complete agree with]
Having said the above, I also advocate a SHOULD instead of a MUST in the guidelines as providing a signature with the source tarball is voluntary for upstream and should be viewed as an additional means to maintain the integrity of the code that should be honoured in the spec file.
What the upstream does is something that we cannot control, and we can only encourage the upstream to DTRT.
In fact signatures and license files are quite similar: our guidelines say that the license file MUST be installed if provided by upstream, and packagers SHOULD ask upstream to provide it if it is missing [1]. I think we should follow this pattern for signatures.
There will always be exceptions to the "MUST check if signed" rule: repacking the tarball is an obvious one. The guidelines should acknowledge this.
Zbyszek
[1] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text
On 30 March 2016 at 15:45, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Mar 30, 2016 at 02:44:44PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Mar 30, 2016 at 02:26:59PM -0000, Ralf Senderek wrote: [snip the part I complete agree with]
Having said the above, I also advocate a SHOULD instead of a MUST in the guidelines as providing a signature with the source tarball is voluntary for upstream and should be viewed as an additional means to maintain the integrity of the code that should be honoured in the spec file.
What the upstream does is something that we cannot control, and we can only encourage the upstream to DTRT.
In fact signatures and license files are quite similar: our guidelines say that the license file MUST be installed if provided by upstream, and packagers SHOULD ask upstream to provide it if it is missing [1]. I think we should follow this pattern for signatures.
There will always be exceptions to the "MUST check if signed" rule: repacking the tarball is an obvious one. The guidelines should acknowledge this.
Zbyszek
[1] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text --
Granted on LICENSE but that is about providing providence on the open source nature and demonstrating permission to distribute.
Given the legalities surrounding that and the potential damage to Fedora (and possibly Red Hat) for non-free items being distributed that's a somewhat different situation to verifying that the tarball in the lookaside cache is the same as that which an original upstream provided.
For this reason (alongside the others about repack) I really do think that should signature verification be added to the guidelines the best way to handle that would be:
"If the upstream provides a signed archive this SHOULD be verified in %prep prior to unpacking"
Start off with that - if we find that the use of this starts growing (again how many packages in the archive actually have signed tarballs right now?) then this can always be modified in the future to a MUST if it becomes apparent that it has saved us somewhere. I'm really reluctant to add another thing that needs to go to FPC for an exception though (which would be the case with a MUST) just after we've come to an agreement on the bundling side of things having *removed* exception requirements for that.
On Wed, Mar 30, 2016 at 04:31:14PM +0100, James Hogarth wrote:
On 30 March 2016 at 15:45, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Mar 30, 2016 at 02:44:44PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Mar 30, 2016 at 02:26:59PM -0000, Ralf Senderek wrote: [snip the part I complete agree with]
Having said the above, I also advocate a SHOULD instead of a MUST in the guidelines as providing a signature with the source tarball is voluntary for upstream and should be viewed as an additional means to maintain the integrity of the code that should be honoured in the spec file.
What the upstream does is something that we cannot control, and we can only encourage the upstream to DTRT.
In fact signatures and license files are quite similar: our guidelines say that the license file MUST be installed if provided by upstream, and packagers SHOULD ask upstream to provide it if it is missing [1]. I think we should follow this pattern for signatures.
There will always be exceptions to the "MUST check if signed" rule: repacking the tarball is an obvious one. The guidelines should acknowledge this.
Zbyszek
[1] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text --
Granted on LICENSE but that is about providing providence on the open source nature and demonstrating permission to distribute.
Given the legalities surrounding that and the potential damage to Fedora (and possibly Red Hat) for non-free items being distributed that's a somewhat different situation to verifying that the tarball in the lookaside cache is the same as that which an original upstream provided.
For this reason (alongside the others about repack) I really do think that should signature verification be added to the guidelines the best way to handle that would be:
"If the upstream provides a signed archive this SHOULD be verified in %prep prior to unpacking"
Start off with that - if we find that the use of this starts growing (again how many packages in the archive actually have signed tarballs right now?) then this can always be modified in the future to a MUST if it becomes apparent that it has saved us somewhere. I'm really reluctant to add another thing that needs to go to FPC for an exception though (which would be the case with a MUST) just after we've come to an agreement on the bundling side of things having *removed* exception requirements for that.
I don't think we'd know if "it saved us somewhere". More likely we can encounter a situation where "it would have saved us if we had it". But I'd rather not wait for a successful attack.
In what scenario do you expect an FPC exception to be required? Either the upstream provides a signature and it's good to check it, or the signature is missing altogether / known to be impossible to check for some reason (repacked tarball, missing public key, etc) and then the rule obviously does not apply. In that situation I'd expect an explanation in a comment and/or a check in the repacking script.
Zbyszek
On Wed, Mar 30, 2016 at 02:26:59PM -0000, Ralf Senderek wrote: [snip the part I complete agree with]
...
In fact signatures and license files are quite similar: our guidelines say that the license file MUST be installed if provided by upstream, and packagers SHOULD ask upstream to provide it if it is missing [1]. I think we should follow this pattern for signatures.
I think MUST or SHOULD should be decided in light of the threat model.
If upstream signs the source code, what are they trying to prevent? Most likely they don't want anyone else to be able to produce updated source code that looks legitimate.
Now, what if there is a new updated source code without a matching signature on the upstream website? Upstream clearly does not want this code to go into Fedora. What, if there is a new updated source code with a matching signature and a new key?
At that point the packager has got some work to do, because it's not clear what that means. a) if the new key is signed by the old code signing key, prepare a new keyring and go ahead. b) if the new key is self-signed because upstream has had an incident in which the sole control over the old key's private key may have been lost, then an attacker could create a new key that looks legitimate to the packager like a). A packager cannot tell a) from b) if he does not make close contact to upstream about the new key. No automation is possible here.
In case of an incident where the private key may be compromized, upstream is required to build the trust into the new key from the ground up.
As these cases can be quite complicated and would need some serious actions on behalf of the packager I think at the moment everything speaks in favour or SHOULD, because we don't have a bullet-proof procedure everyone can follow. But that's only my 2c.
On Wed, Mar 30, 2016 at 04:19:49PM -0000, Ralf Senderek wrote:
In case of an incident where the private key may be compromized, upstream is required to build the trust into the new key from the ground up.
As these cases can be quite complicated and would need some serious actions on behalf of the packager I think at the moment everything speaks in favour or SHOULD, because we don't have a bullet-proof procedure everyone can follow.
Exactly. The maintainer has to *decide* if she trusts the new signing key (either by reaching out to the authors through some side channel, or inspecting the code, or extending the web-of-trust). Alternatively, if the new tarball is not signed, the maintainer has to decide if she trusts the explanation for the lack of signature. Either way, this has to be done *before* the updated version is built. And then we're back to the old situation: there's either a (newly) trusted signature, and it MUST checked in %prep, or there's no signature for valid reasons, or the new tarball is rejected and not built.
The alternative of SHOULD would mean that the maintainer is not sure if the new tarball can be trusted but goes ahead anyway. In that situation I'd prefer she waits until it *can* be verified.
Zbyszek
With my upstream hat on, I'm all for a MUST, because it's the only way that upstream can control what goes into Fedora. Without checking signatures or tarball hashes, it's too easy to end up with questionable code.
But the MUST has some implications:
1) The packager's trust-building activities into the public key are by no means optional. 2) Patches, that are applied to the signed (and checked) source must also be signed by the packager and checked in %prep.
From an ordinary Fedora user's point of view modifications of the trusted source code should also be properly attributed to the one who modified. If upstream signs its code it is for the purpose to better distinguish original and patched code. So in order to add accountability, patches must be signed as well.
3) While the new tarball can be a URL, the public key ring cannot be allowed to be downloaded, it must be produced by the packager and added as a file to the SOURCE directory.
We have to ensure the equivalent to "certificate pinning" in browsers here, so that a (possibly MITMed) false source tarball can be checke with a key that has been sitting in the GIT for a long time, and not just been downloaded alongside the false tarball.
Zbigniew Jędrzejewski-Szmek wrote:
The alternative of SHOULD would mean that the maintainer is not sure if the new tarball can be trusted but goes ahead anyway. In that situation I'd prefer she waits until it *can* be verified.
Zbyszek
You're right, its not easy to come up with a valid excuse not to check the signature, when upstream clearly wants to use it, and highlights this fact on their website. I'm just not sure how many packagers would get into trouble if the signature check becomes a requirement for the package to go ahead.
On Thu, Mar 31, 2016 at 01:39:17PM -0000, Ralf Senderek wrote:
But the MUST has some implications:
- The packager's trust-building activities into the public key are by no
means optional.
Yes, the whole exercise would be pointless otherwise.
- Patches, that are applied to the signed (and checked) source must also be
signed by the packager and checked in %prep.
No, that would be just a waste of time.
We trust dist-git contents. The patches are stored in dist-git, so they are already trusted (in the sense that we know that the patch is what the maintainer committed), so signing them brings has no benefit. (The maintainer should check the patch before committing it, of course).
From an ordinary Fedora user's point of view modifications of the trusted source code should also be properly attributed to the one who modified. If upstream signs its code it is for the purpose to better distinguish original and patched code. So in order to add accountability, patches must be signed as well.
I don't buy that reasoning. You sign stuff to prevent silent modification (because of malice or corruption), and not to track changes, we have better mechanisms for that.
If you want to see who changed what, look at the spec file. In particular, note that "sed in %prep" is just as effective in changing stuff as a patch, so it makes no sense to just sign the patches in dist-git, you'd have to sign the whole dist-git contents.
- While the new tarball can be a URL, the public key ring cannot be allowed
to be downloaded, it must be produced by the packager and added as a file to the SOURCE directory.
Yes.
Zbyszek
Zbigniew Jędrzejewski-Szmek wrote:
I don't buy that reasoning. You sign stuff to prevent silent modification (because of malice or corruption), and not to track changes, we have better mechanisms for that.
Signing is much more than an integrity proof for which hash values would suffice.The fact that some upstream sign their code (in particular when the code is security critical) means that they're willing to take responsifility for the code in the form "they signed it off". It is sometimes very easy to ruin a secure system by modifying it (with a patch or some code in the spec file doesn't matter). That's why I thought it might make sense for the packager to take responsibility for his modifications by signing them.
The changelog don't really reflect the modifications in enough detail.
On Thu, Mar 31, 2016 at 02:39:41PM -0000, Ralf Senderek wrote:
Zbigniew Jędrzejewski-Szmek wrote:
I don't buy that reasoning. You sign stuff to prevent silent modification (because of malice or corruption), and not to track changes, we have better mechanisms for that.
Signing is much more than an integrity proof for which hash values would suffice.The fact that some upstream sign their code (in particular when the code is security critical) means that they're willing to take responsifility for the code in the form "they signed it off". It is sometimes very easy to ruin a secure system by modifying it (with a patch or some code in the spec file doesn't matter). That's why I thought it might make sense for the packager to take responsibility for his modifications by signing them.
Packagers already take responsibility for their modifications by committing under their name. We have a mechanism of secure transmission of dist-git changes (using ssh), so we don't need GPG signatures to trust what we download from dist-git.
We could go a step further, and require gpg signatures for commits to dist-git. This could serve as an additional verification step that maintainer credentials have not been compromised. But that's another discussion, and I'm not sure that gpg signatures would be the best way. Maybe two factor auth for dist-git would be better. We already have that in place, and we could talk about making it mandatory, at least for some important packages. That subject is orthogonal to current discussion though.
The changelog don't really reflect the modifications in enough detail.
Yes, changelogs are a terse overview. Use 'git log -p' for the details. But the signature doesn't reflect the modifications at all (apart from a hash of the final version), so I don't see the relevance.
Zbyszek
On Wed, 2016-03-30 at 12:14 +0000, Zbigniew Jędrzejewski-Szmek wrote:
I don't think you can discount this. Most maintainers don't check the tarballs they download if they build fine, afaik. Checking the signatures in %prep would force a significant change to how we build srpms.
Yeah, if this isn't automated SOMEHOW, I'm not going to do it, because I don't understand how to use GPG. I doubt I'm unusual in this regard....
Michael Catanzaro writes:
Yeah, if this isn't automated SOMEHOW, I'm not going to do it, because I don't understand how to use GPG. I doubt I'm unusual in this regard....
It cannot be automated, because it relies on using the correct public key, which always has to be checked manually by the packager (including the use of gpg).
On Wed, 2016-03-30 at 15:57 +0000, Ralf Senderek wrote:
It cannot be automated, because it relies on using the correct public key, which always has to be checked manually by the packager (including the use of gpg).
I mean, after the packager manually configures signature checking the first time, then it can and should work automatically for package updates until the public key changes.
Michael
On Wed, Mar 30, 2016 at 11:38:28AM -0500, Michael Catanzaro wrote:
On Wed, 2016-03-30 at 15:57 +0000, Ralf Senderek wrote:
It cannot be automated, because it relies on using the correct public key, which always has to be checked manually by the packager (including the use of gpg).
I mean, after the packager manually configures signature checking the first time, then it can and should work automatically for package updates until the public key changes.
The way I understand the planned implementation, the keyring would be added as Source2, the signature as Source1, and in %prep a single-line-macro would be used to verify Source0 with Source1 using Source2. I.e., the manual step would be adding of the keyring as Source2 and checking it at that time.
Zbyszek
-
Andrew Lutomirski -
Björn Persson -
David Woodhouse -
James Hogarth -
Josh Boyer -
Kevin Kofler -
Mathieu Bridon -
Michael Catanzaro -
Ralf Senderek -
Till Maas -
Zbigniew Jędrzejewski-Szmek