RFE: support PGP signatures for checking downloaded sources (xdg-app-builder). #435
Comments
|
From @cgwalters on December 20, 2015 15:28 |
|
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? |
|
From @cmacq2 on December 21, 2015 16:45 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). |
|
From @cmacq2 on December 21, 2015 16:54 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:
|
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). |
|
From @cmacq2 on December 21, 2015 21:59 Well thanks for putting that in proper context. All the more reason for supporting ... Let's consider the RFE duly ammended to hopefully include support for |
|
This issue needs to get some focus. I'm the maintainer of the RuneScape Flatpak and RuneScape often change the content of their .deb without changing the url, so the hashes don't match. In my case, PGP verification needs be possible to do for Arch Linux has already started doing this for their package, stopped verifying the checksum and moved over to verifying the PGP signature. |
|
How about NOT updating flathub to point to a new client until it can successfully be installed and continue to point to the existing working one until it is? Very little would need be done for a week or so v scrambling to deal with all the working clients that are disabled now and can't install the new ones? Old runescape clients still work, well at least until 2.2.9. That's when my reverting stopped working - so I can't guarantee it, but NOT updating the site until a new client is proven to actually install sure seems like the easiest solution to me. It's just a suggestion. |
|
@Limero what is the following script written in? Bash did not like the "(" starting line 9. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=runescape-launcher I should like to try it. |
|
We probably want to support this project if it becomes widely adopted: https://linuxfoundation.org/press-release/linux-foundation-announces-free-sigstore-signing-service-to-confirm-origin-and-authenticity-of-software/ |
This seems much more complicated (and much less secure due to its dependence on a central authority) than simply specifying the public key of the dependencies in the manifest. |
|
The problem with relying on simple keys is that many projects handle them quite loosely. It's not uncommon for changing signing key without a notice and without establishing chain of trust which may make whole effort close to security theater as there will be two options: trust blindly new key or not update. Examples: libseccomp, spotify. |
|
Extension to comment by @Erick555: nowadays git supports signing commits not just with GPG key but also SSH key. Latter are typically personal so it's more likely the signer is going to vary. The entire feature should take into account that there are now multiple ways to sign git tags. |
From @cmacq2 on December 19, 2015 23:10
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).
Copied from original issue: alexlarsson/xdg-app#95
The text was updated successfully, but these errors were encountered: