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.
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.
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.
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.
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.
https://pagure.io/spectool/pull-request/3
Great. Just be ware some signature files does not match signed files. That's the case of the Linux.
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.
(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).
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.
(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.
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.
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.