This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 1093712 - Verify upstream source signatures by spectool
Verify upstream source signatures by spectool
Status: NEW
Product: Fedora
Classification: Fedora
Component: rpmdevtools (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-05-02 08:46 EDT by Petr Pisar
Modified: 2016-04-05 09:25 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Petr Pisar 2014-05-02 08:46:04 EDT
I have a humble feature request: Various upstreams sign their software releases. It would be nice if spectool(1) was able to verify the signatures. Verifying upstream signatures would make Fedora more trustworthy. I can see few obstacles preventing from implementing this enhancement easily:

(1) Spec files does not list URLs for the signatures.

spectool could try to download ${SOURCE}.{sig,asc} files blindly or guess from the URL (e.g. archives distributed by CPAN has signatures in a specific directory-level files).

Or spec files could start to list the signature files as an ordinary source and spectool would pair the signed archive to the signature file automatically.

Or spec language could provide new tag for the signatures.

(2) The integrity of the signing key.

Like signatures, there is place for signing key in spec files now. One could create a new spec tag for that, or one could leave the key management for the user and his GPG key ring.

Alternatively, one could create a new configuration file like rpmlint supports ./.rpmlint files.

(3) spectool code is not friendly for such change.

I read the spectool code and although it's not impossible, it's not easy to agument the code with such a new feature. Are even rpmdevtool maintainers willing to accept this feature, or do they think this is out of scope spectool or rpmdevtools.
Comment 1 Jason Tibbitts 2015-10-07 19:05:16 EDT
I just started rewriting spectool in python because I kept running into various issues.  I don't know if it would be accepted upstream or in the Fedora package, or if I'll just rename it and ship a separate utility, but I'll take a look at your suggestions.

It seems quite reasonable that such signature files would simply be listed as additional Source:s; it doesn't hurt to have them along with the package.  But even just a comment after each Source: line would be workable.

I also have no problem with attempting to find .sig and .asc or trying to guess the location from the URL though it would be good to have more examples than just Perl.

It would also be nice if you could illustrate exactly how one would check these signatures.  I know very little about gpg or the python interfaces to it.
Comment 2 Petr Pisar 2015-10-08 02:21:23 EDT
I don't know nothing about GnuPG's binding for python. So I cannot help you with it.

In general, there is gnupg executable and gpgme library. Either of them can be used to to verify a signature. The input is a file and its signature. The result is whether the signature matches and whether the signing key is trusted/valid.

There are two obstacles: You need corresponding public key and you should be pretty sure the key is owned by the genuine person. GPGME can handle both obstacles automatically by downloading keys from key servers and by traversing web of trust of these keys.

Unfortunately not all the keys are published on every key server and there are usually not enough key signatures for establishing path in the web of trust.

Either you can leave solution to the user and his GnuPG's configuration, or you can try to compensate it somehow (GnuPG can have multiple separate configuration like rpm database has its own).

I think the only viable compensation method is to implement some kind of trust-on-fist-use and warn-on-change. Something like rpm does now:

If you create a new Fedora package, you mark the public key signing the sources as trusted for the package. Then when packager rebases the package, there are two cases: Either the new sources were signed with the same key, then the verification succeeds, this is the ideal case. Or the new sources were signed with another key, then you should stop and ask user for confirmation if this is expected. If user affirms, you can continue as with a new package. If user declines, then something is terribly wrong, probably the sources were tampered.

Then there could be some optimizations like all sources published on CPAN are signed with one key, so it would be great share the one key for all the sources coming from CPAN. The same probably applies for other language specific repositories.

Basically the use case is to give packager some assurance that when calling "spectool -g PACKAGE.spec", the downloaded sources can be trusted.
Comment 3 Jason Tibbitts 2015-10-08 02:40:41 EDT
There's a python3-pygpgme package available, so I suppose basic verification of signatures isn't much more difficult than actually finding and downloading them.  However, it sounds like some of this goes a bit beyond a quick hack to spectool and instead requires some infrastructure for safely storing the trusted keys somewhere.  If the trusted keys can't just be stored in the SCM then I'm afraid it's kind of beyond the scope of what I'm trying to accomplish at the moment.  But let me finish up the basic functionality and then we'll see what we can come up with.
Comment 4 Zbigniew Jędrzejewski-Szmek 2016-04-03 13:54:36 EDT
This has been discussed a lot on the fedora-devel [1]. I think we should simply store the key in dist-git. When the maintainer downloads the key for the first time, or if the key that the tarball is signed with ever changes, they should do manual verification.

[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2TBK4LLNRH73QJQSXWFPCQYHGTSJ3C7P/]

Support in spectool could look like this:
Source0: http://some.where/tarball
Source1: http://some.where/tarball.gpg
Source2: http://some.other.place.or.even.non-url.path/keyring.gpg

When spectool is asked to verify, it would:
1. Look over the file list and if SourceY has a filename that corresponds to SourceX but with a known signature extension appended, it would use this as the signature.

2. The source to use as keyring would either have to be specified manually (by number), or we'd expect some pattern (e.g. gpgkey-*.gpg?).

After downloading sources, spectool would silently perform verification, and raise ruckus if the signature doesn't match.
Comment 5 Zbigniew Jędrzejewski-Szmek 2016-04-03 15:45:06 EDT
https://pagure.io/spectool/pull-request/3
Comment 6 Petr Pisar 2016-04-04 04:38:48 EDT
Great. Just be ware some signature files does not match signed files. That's the case of the Linux.
Comment 7 Ville Skyttä 2016-04-04 04:51:48 EDT
The situation with spectool is a bit unclear at the moment. There is rpmspectool which is shipped with Fedora, the one in pagure which your PR is against is to my knowledge not shipped anywhere at the moment, and the one in rpmdevtools is deprecated and hopefully cleanly replaced at some point by some of the new rewrites.

I thought I'd mention this because I was not aware that the pagure one is alive (at least some PRs seem to be getting merged) because I hadn't heard of it in a while, and some others might be in the same situation. But then again that's just my understanding of things. I do not want to endorse any of the new implementations another, but I would be happy if a compatible, maintained replacement emerged and was shipped in Fedora so that I could drop the old spectool in rpmdevtools.

Some more discussion and background is in bug 1279723.
Comment 8 Zbigniew Jędrzejewski-Szmek 2016-04-04 08:54:37 EDT
(In reply to Petr Pisar from comment #6)
> Great. Just be ware some signature files does not match signed files. That's
> the case of the Linux.

Do you mean that the signature is invalid, or just that the signature is not used to verify another Source? In the first case, the maintainer shouldn't put the signatures in Sources, in the second case, no issue.

(In reply to Ville Skyttä from comment #7)
> The situation with spectool is a bit unclear at the moment. There is
> rpmspectool which is shipped with Fedora, the one in pagure which your PR is
> against is to my knowledge not shipped anywhere at the moment, and the one
> in rpmdevtools is deprecated and hopefully cleanly replaced at some point by
> some of the new rewrites.

Yeah, I hacked on the pagure spectool because it's much simpler (just one file). 

The code in both projects is rather similar. There's just one obvious way to do some things in python and that helps. But there are also some differences. I think we really should have a CLI interface that is backwards compatible with old spectool. This is the only way to replace spectool without wreaking havoc on peoples' finger memory and scripts.

The interface that spectool has, while not beautiful, is not particularly bad. It just suffers from the "I can't decide if I want dashes in option names" problem. The way to deal with that is IMHO to pick a consistent version (I'd prefer --get-files, --list-files, etc) and document only that, but accept both (--get-files, --getfiles, --gf, --list-files, --listfiles, --lf).
Comment 9 Jason Tibbitts 2016-04-04 14:53:23 EDT
Just so everyone knows, I kind of gave up on my spectool rewrite because it kind of got stepped on by the other one and I didn't se much point in continuing.  I didn't see the need to delete the project, though, and eventually Zbigniew seems to have decided that he liked it.   Now that it's getting additional work and it doesn't appear that the other rewrite was even intended to replace the perl one in rpmdevtools, I think it would be good to start thinking again about switching to this one.

I did take pains to duplicate the arguments of the original, even though that ended up being by far the most painful part of the code.  For me that's the best reason to continue with this one over the other one, though of course it could probably gain a compatible interface if someone wanted to write one.
Comment 10 Petr Pisar 2016-04-05 03:47:20 EDT
(In reply to Zbigniew Jędrzejewski-Szmek from comment #8)
> (In reply to Petr Pisar from comment #6)
> > Great. Just be ware some signature files does not match signed files. That's
> > the case of the Linux.
> 
> Do you mean that the signature is invalid, or just that the signature is not
> used to verify another Source? In the first case, the maintainer shouldn't
> put the signatures in Sources, in the second case, no issue.
> 
There is linux-4.5.tar.sign with the signature and linux-4.5.tar.xz with the sources. The signature is computed from uncompressed archive.
Comment 11 Zbigniew Jędrzejewski-Szmek 2016-04-05 08:51:13 EDT
Ah, OK, no I understand. When you said "That's the case of the Linux" I thought you were making a general statement about the ecosystem, but you mean the linux tarball in particular ;) 

> There is linux-4.5.tar.sign with the signature and linux-4.5.tar.xz with the
> sources. The signature is computed from uncompressed archive.

Current rewritten spectool doesn't support that case. It'd wouldn't know what the signature signs, so it'd simply ignore the signature.

It should be easy enough to add support for this. I'm not sure if it's worth the trouble though: why would you sign the uncompressed tarball? That's rather inconvenient for uses and makes verification much slower than it has to be.
Comment 12 Petr Pisar 2016-04-05 09:25:30 EDT
Originally, gzipped and bzipped archives where signed. When LZMA came, Linus decided to sign uncompressed archive instead, so that new compression methods can be introduced or removed while having one signature only.

Note You need to log in before you can comment on or make changes to this bug.