Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use stronger Debian package signing key #50

Closed
joelpurra opened this Issue Dec 21, 2016 · 9 comments

Comments

Projects
None yet
4 participants
@joelpurra
Copy link

joelpurra commented Dec 21, 2016

Following the steps to install the official piwik Debian package on Debian testing (stretch), I am unable to get past apt-get update, which gives me a GPG error.

sudo apt-get update
Hit:1 http://ftp.acc.umu.se/debian stretch InRelease
Ign:2 https://debian.piwik.org piwik InRelease
Hit:3 https://debian.piwik.org piwik Release
Hit:4 http://security.debian.org/debian-security stretch/updates InRelease
Get:5 https://debian.piwik.org piwik Release.gpg [197 B]
Ign:5 https://debian.piwik.org piwik Release.gpg
Fetched 197 B in 0s (294 B/s)
Reading package lists... Done
W: GPG error: https://debian.piwik.org piwik Release: The following signatures were invalid: 1FD752571FE36FF23F78F91B81E2E78B66FED89E
W: The repository 'https://debian.piwik.org piwik Release' is not signed.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.

While vague, this seems to be the issue: The following signatures were invalid: 1FD752571FE36FF23F78F91B81E2E78B66FED89E. Note that they fingerprint is correct according to apt-key list (see output below).

I believe that the problem is that the PGP key used to sign the repository uses DSA 1024 bit, as there's a push to abandon weak/old (digest) algorithms before January 1, 2017. Official Debian repos use RSA 4096. Here's a quote:

Fixing half-broken repositories: Repositories with DSA keys need to be migrated to RSA first. Migrating from DSA to RSA is best done by signing the repository with two keys (old and new one) and shipping the new one to the users.

Would it be possible to follow the recommendation and transition to a stronger repository key?


Just to clarify that the Piwik repository key has been added to apt on my machine, according to the official instructions.

sudo apt-key list
/etc/apt/trusted.gpg
--------------------
pub   dsa1024 2013-12-19 [SC]
      1FD7 5257 1FE3 6FF2 3F78  F91B 81E2 E78B 66FE D89E
uid           [ unknown] Piwik Open Source Analytics (Debian Package) <debian@piwik.org>
sub   elg4096 2013-12-19 [E]

/etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg
----------------------------------------------------------
pub   rsa4096 2014-11-21 [SC] [expires: 2022-11-19]
      126C 0D24 BD8A 2942 CC7D  F8AC 7638 D044 2B90 D010
uid           [ unknown] Debian Archive Automatic Signing Key (8/jessie) <ftpmaster@debian.org>

(... several keys follow ...)
@mattab

This comment has been minimized.

Copy link
Member

mattab commented Dec 26, 2016

Thanks for the report. @aureq maybe you would be able to investigate this?

@aureq

This comment has been minimized.

Copy link
Collaborator

aureq commented Dec 31, 2016

@joelpurra After reading a fair bit, the issue may not be related to the GPG key type, but instead to the digest applied as part of the signing process (SHA1). But as you correctly pointed out, the instructions are vague.

I've done some test and Debian 7 (Wheezy) is fine and so is Debian 8 (Jessie). I didn't get any error message. I need to spin up an EC2 instance running Ubuntu to check how it behaves.

Going forward, I need to work on the repository to ensure the digest used is secure. So, SHA-256 or above should be used instead.

We (the piwik community) needs to plan and execute a migration plan to a stronger GPG key by using at least RSA-2048. On the Debian wiki it's mentioned that the repository should be signed with 2 GPG keys, but I'm not sure how is this meant to be done. If you know, feel free to chime in.

@aureq

This comment has been minimized.

Copy link
Collaborator

aureq commented Jan 1, 2017

@joelpurra So, the repository should now be used using SHA512 rather than SHA1. I forced the digest algo by adding digest-algo SHA512 in ~/.gnupg/gpg.conf . The I used reprepro to export once more the repository.

It should be easy to check using the following commands:

  • wget https://debian.piwik.org/dists/piwik/Release https://debian.piwik.org/dists/piwik/Release.gpg
  • gpg --verbose --keyring /etc/apt/trusted.gpg Release.gpg
gpg: armor header: Version: GnuPG v1.4.9 (GNU/Linux)
Detached signature.
Please enter name of data file: Release
gpg: Signature made Sun 01 Jan 2017 12:36:03 AM UTC using DSA key ID 66FED89E
gpg: using PGP trust model
gpg: Good signature from "Piwik Open Source Analytics (Debian Package) <debian@piwik.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 1FD7 5257 1FE3 6FF2 3F78  F91B 81E2 E78B 66FE D89E
gpg: binary signature, digest algorithm SHA512

Could you please check on your side if you're still having the issue? Thanks

@joelpurra

This comment has been minimized.

Copy link
Author

joelpurra commented Jan 2, 2017

@aureq: thank you for looking in to it!

@joelpurra After reading a fair bit, the issue may not be related to the GPG key type, but instead to the digest applied as part of the signing process (SHA1). But as you correctly pointed out, the instructions are vague.
...
We (the piwik community) needs to plan and execute a migration plan to a stronger GPG key by using at least RSA-2048.

Yes, I do believe the preferred way forward is to upgrade both the digest and key algorithm/length. The Debian recommendation specifically state that DSA keys first need to be upgraded to RSA keys, but does not state that there is a check for the key algorithm/length. It seems a RSA-4096 bit key and SHA-512 digest is the preferred way forward though.

@joelpurra So, the repository should now be used using SHA512 rather than SHA1. I forced the digest algo by adding digest-algo SHA512 in ~/.gnupg/gpg.conf. The I used reprepro to export once more the repository.
...
Could you please check on your side if you're still having the issue? Thanks

Running the commands I get the below output. All looks good regarding the digest algorithm.

gpg --verbose --keyring /etc/apt/trusted.gpg --verify Release.gpg Release
gpg: armor header: Version: GnuPG v1.4.9 (GNU/Linux)
gpg: Signature made Sun 01 Jan 2017 01:47:00 AM CET
gpg:                using DSA key 81E2E78B66FED89E
gpg: using pgp trust model
gpg: Good signature from "Piwik Open Source Analytics (Debian Package) <debian@piwik.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 1FD7 5257 1FE3 6FF2 3F78  F91B 81E2 E78B 66FE D89E
gpg: binary signature, digest algorithm SHA512, key algorithm dsa1024

With the new digest algorithm, sudo apt-get install piwik also works well. This fixes my issues. Good news indeed.

I leave it up to the project maintainers to keep this issues open, or to close it in favor of a new issue pertaining to the repository key algorithm upgrade.

Thanks again @aureq!

@aureq

This comment has been minimized.

Copy link
Collaborator

aureq commented Jan 15, 2017

@joelpurra @mattab As for now, the GPG keys are bundled within the package itself which will allow us to upgrade them more smoothly. I've included a 4096 RSA key which will replace the 1024 DSA key in a few months.

@aureq aureq closed this Jan 15, 2017

@mattab

This comment has been minimized.

Copy link
Member

mattab commented Jan 15, 2017

Nicely done 👍

@danielhjames

This comment has been minimized.

Copy link

danielhjames commented Jan 16, 2017

An alternative is to have a mini-package with no dependencies (other than standard packages) which sets up both the new apt repository and the keys on the target system. Then, when the real Piwik package is installed, it will be done inside the trusted environment. Although this requires one extra step for the user, the mini-package is just a few lines of code so it is very easy for security-conscious users to review.

@aureq

This comment has been minimized.

Copy link
Collaborator

aureq commented Jan 16, 2017

@danielhjames I considered this solution (along with setting the package repository) but I'm unlikely to implement it just yet. As you noted, that's an extra step for the end user. Yes, it add flexibility but not necessarily some security.
I'll keep that in the back of my mind but for a later time.

@danielhjames

This comment has been minimized.

Copy link

danielhjames commented Jan 17, 2017

Hi @aureq I have an example of the mini-package which you might like to take a look at here: https://github.com/danielhjames/airtime-easy-setup

For me, the security question is "how much code am I asking the user to trust before trust is established?" which is why the mini-package is kept small and easy to review.

For this particular package, I used a long list of dependencies so that when the main package was installed, there would be no extra packages required. However I think it would be better to depend on packages in Debian/Ubuntu's 'standard' task only for the mini-package, as this makes the mini-package easier to install with tools that do not do dependency resolution, such as dpkg. Tools such as gdebi-core are easier for users but may have unwanted dependencies in a server environment, such as Python 3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.