After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 645565 - Please add digital signatures to tarballs
Please add digital signatures to tarballs
Status: RESOLVED OBSOLETE
Product: sysadmin
Classification: Infrastructure
Component: Blue Sky
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: GNOME Sysadmins
GNOME Sysadmins
: 145128 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-03-22 20:21 UTC by Josselin Mouette
Modified: 2013-11-21 19:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Josselin Mouette 2011-03-22 20:21:00 UTC
This was discussed on d-d-l:

> OTOH I’d really appreciate to see digital signatures along with the
> tarballs.

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
other distro
Comment 1 Josselin Mouette 2011-03-22 20:43:44 UTC
(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 :)
Comment 2 Olav Vitters 2011-11-16 16:52:32 UTC
*** Bug 145128 has been marked as a duplicate of this bug. ***
Comment 3 g.trentalancia 2011-11-16 17:57:31 UTC
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.

Thanks.
Comment 4 Andrea Veri 2013-11-21 14:55:18 UTC
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
Comment 5 Nick Bowler 2013-11-21 16:00:01 UTC
So you:

  (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.

Great job!
Comment 6 Andrea Veri 2013-11-21 19:21:06 UTC
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 support@gnome.org anytime and thanks for reporting the issue.