#3 Verify downloaded files using gpgv2
Merged by tibbs. Opened by zbyszek.
zbyszek/spectool master  into  master

Download 3.patch
no initial comment

This tries to DTRT by default: if signatures are listed in sources, it'll try to verify files after downloading or when explicitly requested. It makes an educated guess at which files are signatures and which is the keyring.

Probably various corner cases are not covered. It should be easy enough to add support for more signature conventions later.

$ ~/python/spectool/spectool -g
Source0: https://yt-dl.org/downloads/2016.03.06/youtube-dl-2016.03.06.tar.gz → ./youtube-dl-2016.03.06.tar.gz
Source1: ./youtube-dl-2016.03.06.tar.gz.sig already exists
Source2: gpgkey-7D33D762FD6C35130481347FDB4B54CBA4826A18.gpg cannot be downloaded
Source3: youtube-dl.conf cannot be downloaded
No signature for ./youtube-dl.conf
./youtube-dl-2016.03.06.tar.gz has a good signature

$ echo "blah" >> ./youtube-dl-2016.03.06.tar.gz
$ ~/python/spectool/spectool -g
Source0: ./youtube-dl-2016.03.06.tar.gz already exists
Source1: ./youtube-dl-2016.03.06.tar.gz.sig already exists
Source2: gpgkey-7D33D762FD6C35130481347FDB4B54CBA4826A18.gpg cannot be downloaded
Source3: youtube-dl.conf cannot be downloaded
gpgv: Signature made Sun 06 Mar 2016 04:11:54 AM EST using RSA key ID A4826A18
gpgv: BAD signature from "Philipp Hagemeister phihag@phihag.de"

Error: signature verification failed for ./youtube-dl-2016.03.06.tar.gz!
Return code 1

This makes sense to me, and I'll merge it shortly. Since you're doing far more work on this than I am at this point, I went ahead and added you to the repo proper.

If you could, write a bit of documentation for the heuristics you use for finding keys and signatures, because I would like to implement the same thing in Lua code for use in RPM macros (since there have been requests for that kind of thing).

checking signatures in a specfile macro, so it would be good if they directly in rpm macros

Pull-Request has been merged by tibbs

Thanks.

Maybe the docs should be inline in the code and converted into some html format using sphinx? I think this would be relatively little work with a high chance of staying up-to-date over time.

I sent an email reply via email but it doesn't appear to have made it.

I know essentially zero about generating docs from python source in the
manner you describe, but it seems like a good idea.

I sent an email reply via email but it doesn't appear to have made it.
Yeah, I didn't get anything afaict.

I know essentially zero about generating docs from python source in the
manner you describe, but it seems like a good idea.

I started adding sphinx docs, but it seems overkill in this case. I extended the --help output and README.rst. If we create a rpm file, help2man can be used to generate a decent man page.

I pushed the changes to the main repo.

BTW, I don't really understand this comment in is_keyring:

Sometimes .gpg extension is also used for keyrings, so if we don't
find a .kbx file, we should look for an extraneous .gpg file.

Is that just a TODO item? I understood .gpg files to be more common, and the the discussion around verifying upstream signatures that I've seen hasn't really mentioned .kbx files. Does it suffice to just check for both, or do you call gpg differently depending on what you found?

No, that describes the implementation. I was trying to be smart: if .kbx is found, then that is the keyring. Otherwise, look at the .gpg files, if one of them does not look like a signature for another file (based on name matching), that that is the keyring. Otherwise bail.

Later I learned that the kernel signes the uncompressed tarball. I'll implement that too, it should be fairly easy.

Hmm, OK, it just seems weird to see that comment there while the actual check for .gpg is in is_signature.

Also, in the examples I've seen, both the key and the signature are .asc files, which makes for additional fun. I guess I really need to see more examples.

If you find anything interesting, just paste the name of the package here.

Metadata