Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Use stronger Debian package signing key #50
Following the steps to install the official
sudo apt-get update
While vague, this seems to be the issue:
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:
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
sudo apt-key list
@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 So, the repository should now be used using SHA512 rather than SHA1. I forced the digest algo by adding
It should be easy to check using the following commands:
Could you please check on your side if you're still having the issue? Thanks
@aureq: thank you for looking in to it!
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.
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
With the new digest algorithm,
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!
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.
@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.
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.