RFE: support PGP signatures for checking downloaded sources (xdg-app-builder).

[cmacq2]

Judging by a cursory overview of the docs there is no support for verifying integrity of downloaded sources beyond a simple SHA256 checksum in xdg-app-builder.

It would arguably be better (more robust) if the integrity of the sources could be verified by checking a PGP signature against a known key. As it stands, essentially the builder has zero protection against a compromised repository/download server (and this has happened: think vsftpd, kernel.org).

Beyond that, it simplifies things for the user of xdg-app-builder because as long as a PGP key remains valid they can trivially upgrade without having to check & update to the new SHA256 sums manually -- since an equivalent up-to-date checksum would, of course, be embedded in the PGP signature itself. So only the trusted keys of upstream need to be known, and the machinery takes care of all the rest.

Event better, still: modern GIT allows you to sign commits with PGP signatures as well, so for the smoothest experience the builder would ideally be able to verify the signature of a GIT commit also. This can help guard you better against a compromised repository because it authenticates the GIT history itself. Essentially a signed GIT commit is a statement from upstream that they trust their current GIT history/state up until and including the particular commit to be 'verified', otherwise the only guarantee is that the GIT history is internally consistent which is not necessarily equivalent to 'tamper free'.

That way the consumer (builder) could declare the a GIT tag as their dependency (i.e. a particular release) and the builder could give fairly strong guarantees that the the sources being used in the project actually match with what was intended.

By adopting support for checking sources against PGP signatures, xdg-app-builder can offer a stronger protection against compromised sources to its users.

By adopting support for checking authenticity of signed GIT commits, xdg-app-builder can offer some gentle encouragement and reward for upstreams to make their release process/source control practices the best they can be, which will ultimately benefit the consumers of their code (i.e. users of xdg-app-builder).

[cgwalters]

See also https://github.com/cgwalters/git-evtag

[alexlarsson]

First of all, i don't think a sha256 checksum (which is mandated for all remote archives in builder) is weak. It is actually stronger than e.g. any git signatures, which rely on sha1 for the git objects. So, if you use archives, I think we should handle a compromised download server.

However, I agree that a gpg signature would be both easier to use (less work to update versions) and make it possible to secure remote git repos, which we currently don't allow.

This seems pretty easy to implement for git, but how would it work for tarballs? Is there some standard mechanism for distributing signed tarballs? Signature on the side, with a known suffix? Is someone doing this?

[cmacq2]

Just a point of terminology: GIT commit IDs/checksums are SHA1. SHA1 is cryptographically broken but still valid for checksumming purposes (just as MD5 is still valid). SHA256 sum is better than SHA1 because it's harder to find collisions, but neither checksum goes beyond a guarantee of consistency to offer any guarantee of authenticity.

A signed GIT commit attaches a PGP signature to the commit. So that signature is a strong as the cryptographic strength of the underlying PGP key material. Generally (i.e assuming an upstream that doesn't do things like uploading their private key to github for convenience...), it can be considered stronger than the SHA256 checksum because you don't get just the benefits of consistency checking from the checksum but also authenticity guarantees from the PGP scheme.

So an attacker/malicious repository would have to break both PGP (to forge the signature) and SHA1 (to rewrite the GIT repository to be internally consistent so as not to trip GIT's consistency checking defenses).

[cmacq2]

As for how to implement this for tarballs: a detached PGP signature is probably the way to go. See c.f. machinectl man page documentation on pull-* and verify options. The machinectl implements a scheme for signing containers in raw disk image and tarball formats by rewriting the URL of the image itself to construct one for the detached PGP signature.

http://www.freedesktop.org/software/systemd/man/machinectl.html#pull-tar%20URL%20%5BNAME%5D

Basically, just adopt a convention (and possibly permit users to override it with JSON config to patch up servers/upstreams that don't implement this) and ask/prod/encourage upstreams to upload a detached PGP signature along with their source tarball.

So for example:

1. The tarball is: https://www.acme.com/releases/project/source-version.tar.gz
2. Rewrite URL, strip suffix, substitute 'fixed' elements in the path name:
3. The signature is e.g. https://www.acme.com/releases/project/source-version-sha256.pgp

[alexlarsson]

So that signature is a strong as the cryptographic strength of the underlying PGP key material

This is not true. A git commit is a small file with commiter, commit message, some metadata and the sha1 checksum of the root directory object. The root directory object is a small file with filenames, file types and permissions plus the sha1 checksum of the subdir/file object, and so on until you reach the sha1 of the file content. If you can break sha1 you can replace the content at any place in this hierarchy without invalidating the signature on the toplevel commit object.

In fact, this is the reason for git evtag, which instead does a deep sha512 (instead of shallow sha1) checksum of the commit and signs that.

Thats really an uninteresting technicality though. Anything is better than nothing (although git-evtag would be best).

[cmacq2]

Well thanks for putting that in proper context. All the more reason for supporting evtag, too!

... Let's consider the RFE duly ammended to hopefully include support for evtag as well?

[alexlarsson]

This issue was moved to flatpak/flatpak#16