Use stronger Debian package signing key

[matomo-org]

Use stronger Debian package signing key

[aureq]

@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) <[email protected]>"
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

[aureq]

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

[mattab]

Nicely done 👍

[danielhjames]

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.

[mattab]

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

[aureq]

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

[joelpurra]

@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) <[email protected]>" [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]

@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]

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.