README.rst

spectool

This is a rewrite of spectool in Python (3.3+).

The initial goal is for it to be completely compatible with the Perl version, including having identical non-debug non-help output.

Further goals are to use the Python rpm and curl bindings to avoid shelling out to curl and rpm, and to eventually handle more advanced situations like automatically generating git checkouts and validating signatures.

Source URL and destination file name

By default spectool uses the component of the URL (anything after the last slash) as the destination file name. It is often desirable to specify a custom destination file name. This is possible by appending a pseudo fragment identifier that includes a slash.

Examples:

https://example.net/path/to/file.tar.gz → file.tar.gz
https://example.net/path/to/file.tar.gz#/project-file.tar.gz → project-file.tar.gz

In particular this works for github/gitlab/bitbucket archive URLs:

Source0:  https://github.com/OWNER/PROJECT/archive/GIT-TAG.tar.gz#/PROJECT-VERSION.tar.gz
Source1:  https://gitlab.com/OWNER/NAME/repository/archive.tar.gz?ref=GIT-TAG#/NAME-VERSION.tar.gz
Source2:  https://bitbucket.org/OWNER/NAME/get/GIT-TAG.tar.gz#/NAME-VERSION.tar.gz

Common usage

If the specfile is not specified, and current directory contains just one specfile, that specfile will be used by default.

When invoked without arguments:

$ spectool

all Sources and Patches specified in the specfile will be listed.

To download all Sources and Patches:

$ spectool -g

Signatures will be verified if they are listed among the Sources.

Signature verification

spectool currently uses gpgv2 to verify signatures. Currently only detached signatures are supported.

The following algorithm is used:

  1. For all Sources, if the destination file name ends in .gpg or .sig, it is considered a signature.
  2. For all Sources and Patches, it is checked if a matching signature is specified. The name of the signature file must be the same but with .gpg or .sig appended.
  3. If a signature file is specified, the Source or Patch is checked.
  4. Signatures are checked against a keyring which must be specified in a file. It can be specified using --keyring=N, in which case SourceN is used as the keyring, or --keyring=FILE, in which case FILE is used as the keyring. If the keyring is not specified explicitly, if there's just one Source with .kbx extension, it will be used as the keyring, and otherwise, if there's a Source with the .gpg extension that does match not another Source or Patch as specified in point 2., it will be used as the keyring. If the --keyring option is not used and the keyring cannot be guessed, verification fails.
  5. Verification is performed automatically after download, and also when --verify option is specified.

Example (based on the youtube-dl package):

Source0:        https://yt-dl.org/downloads/2016.03.06/youtube-dl-2016.03.06.tar.gz
Source1:        https://yt-dl.org/downloads/2016.03.06/youtube-dl-2016.03.06.tar.gz.sig
Source2:        gpgkey-7D33D762FD6C35130481347FDB4B54CBA4826A18.gpg

In this case Source2 is used as the keyring, Source1 as the signature, and Source0 is the file that is verified.