GNOME Bugzilla – Bug 645565
Please add digital signatures to tarballs
Last modified: 2013-11-21 19:21:06 UTC
This was discussed on d-d-l:
> OTOH I’d really appreciate to see digital signatures along with the
We don't have signatures, so I'd like (need) loads of detail:
1. What guarantee is expected?
e.g. 100% trust it was uploaded by the maintainer vs 'comes from
random person who has the ability to upload things @ GNOME'
2. How to handle digital signatures securely?
e.g. is there is a breakin, having someone steal the private key
would be really bad, as signatures imply trust.
3. How to expire, announce new versions, get the initial trust, etc?
... basically how is the infrastructure bit handled at Debian/ some
(In reply to comment #0)
> We don't have signatures, so I'd like (need) loads of detail:
> 1. What guarantee is expected?
> e.g. 100% trust it was uploaded by the maintainer vs 'comes from
> random person who has the ability to upload things @ GNOME'
Authenticating maintainers is the problem of the GNOME sysadmins, it doesn’t affect users. Using GPG for authentication will give you more traceability, and a bit more security since people are usually more cautious with their GPG keys than they are with their SSH ones.
The real issue at hand is protecting users against Man-In-The-Middle attacks, so this has to be done on the archive side.
> 2. How to handle digital signatures securely?
> e.g. is there is a breakin, having someone steal the private key
> would be really bad, as signatures imply trust.
> 3. How to expire, announce new versions, get the initial trust, etc?
> ... basically how is the infrastructure bit handled at Debian/ some
> other distro
On this matter I can explain a bit about the Debian setup.
Signatures for uploads are not the ones that are used for download. However both of them rely on a large web of trust between developers, each of them having his own GPG key.
For uploads, there is a keyring (at keyring.debian.org) containing the list of authorized keys.
For downloads, the files containing the sha256sums for each package (well, actually these are hashes of files containing hashes of files… inception-style) are signed with an archive key (one for each Debian version). This one in turn having an expiration date, and being signed regularly with a master key.
I’m not sure where the archive key is stored. It probably has to be in a secured directory on the FTP-master server since it is used every day to re-sign the archive. This server is configured in a paranoid way and only a dozen of people have shell access to it.
AFAIK, the master key is split between several people using Shamir’s secret sharing.
The master key has to be signed by as many people as possible in the web of trust. This way, anyone having met one of the developers and checked his fingerprint can check the signature’s authenticity. For other people, I think the key is available in a public place on a HTTPS site, which is, well, better than nothing, but only as secure as SSL can be.
I hope this is enlightening. I don’t think you need a system as remotely complicated as the one of a distribution. Signing the sha256sums files in a directory each time it is modified should be enough. You can use an archive key for that, signed by a master key, so that you can revoke the archive key if it is lost or stolen. Then put the public keys on a HTTPS website, and start building a web of trust :)
*** Bug 145128 has been marked as a duplicate of this bug. ***
I would also really appreciate to see digital signatures along with the tarballs being distributed by ftp.gnome.org.
This is standard practice and best practice.
Take ftp.gnu.org as an example of how this is achieved. Take the recent incident at kernel.org as an example of what could happen.
The GNOME Infrastructure Team is currently migrating its bug / issue tracker away from Bugzilla to Request Tracker and therefore all the currently open bugs have been closed and marked as OBSOLETE.
The following move will also act as a cleanup for very old and ancient tickets that were still living on Bugzilla. If your issue still hasn't been fixed as of today please report it again on the relevant RT queue.
More details about the available queues you can report the bug against can be found at https://wiki.gnome.org/Sysadmin/RequestTracker.
Thanks for your patience,
the GNOME Infrastructure Team
(1) Close bugs without bothering to check if they've actually been fixed
(2) Ask us to re-open unfixed bugs on the new tracker, but
(2a) Restrict access to the tracker to people with accounts
(2b) Don't let us create accounts.
The nice thing about RT is it creating an account right after you've submitted an account. With that account you can view all the tickets you've submitted with that specific email.
My fault to not have included this detail on the custom template I sent before. Please open a new ticket by mailing firstname.lastname@example.org anytime and thanks for reporting the issue.