Opened 9 years ago
Closed 9 years ago
#15360 closed task (fixed)
Ubuntu's ppa uses weak digest algorithm (SHA1)
Reported by: | Zranz | Owned by: | |
---|---|---|---|
Component: | webservices | Version: | VirtualBox 5.0.18 |
Keywords: | ubuntu, repository, ppa | Cc: | |
Guest type: | all | Host type: | Linux |
Description
Ubuntu's virtualbox repository uses an insecure method for authentication. This is the warning I receive when using "sudo apt update" in Ubuntu 16.04:
W: http://download.virtualbox.org/virtualbox/debian/dists/xenial/InRelease: Signature by key 7B0FAB3A13B907435925D9C954422A4B98AB5139 uses weak digest algorithm (SHA1)
Thank you.
Change History (6)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
comment:3 by , 9 years ago
Unfortunately it seems to be impossible to sign a repository with 2 keys. We use reprepro to create the Debian/Ubuntu repository and specify the keys with
SignWith: 2980AECF 98AB5139
but the files are only signed with the first (the new) key.
comment:4 by , 9 years ago
Thank you, the problem is now fixed.
For reference to other users, this command fixes the warning:
wget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo apt-key add -
Full instructions are here: https://www.virtualbox.org/wiki/Linux_Downloads
comment:5 by , 9 years ago
If someone can explain me how to tell reprepro to signatures with the old key and with the new key, please let me know. At the moment it's required to install the new key, otherwise apt will completely refuse to use the Jessie / Xenial repo.
comment:6 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
From: https://wiki.debian.org/Teams/Apt/Sha1Removal
Fixing half-broken repositories
The repository owner needs to pass --digest-algo SHA512 or --digest-algo SHA256 (or another SHA2 algorithm) to gpg when signing the file. 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. A relatively safe way to ship the key would be to embed it in the package. Some months after those changes, it is OK to drop the old key from the repository and the users machines (if shipped with a package).