Fix insecure downloading of raspberrypi.org signing key

[jturner314]

#62 provides verified installation for http://archive.raspbian.org packages, but the installer script also installs the http://archive.raspberrypi.org repository. In order to do so, it downloads the http://archive.raspberrypi.org signing key insecurely with wget and adds it to the trusted Apt keyring without any authenticity checks. This download is vulnerable to attack. The best solutions that I can think of are:

• Include a known-good copy of the key in the installer image so that it doesn't have to be downloaded during installation.
• Don't add the http://archive.raspberrypi.org repository during unattended installation, and let users know in the README that they should add it manually if desired and verify the key themselves. This repository doesn't have many packages outside of the http://archive.raspbian.org repository, anyway (list below).

8086tiny
8086tiny-dev
compoundpi-client
compoundpi-common
compoundpi-docs
compoundpi-server
icelib
icelib-dev
omxplayer
oracle-java7-jdk
oracle-java8-jdk
penguinspuzzle
pistore
pypy-setuptools
pypy-smbus-cffi
pypy-upstream
pypy-upstream-dev
pypy-upstream-doc
python3-lirc
python3-picamera
python3-pifacecad
python3-pifacecad-emulator
python3-pifacecommon
python3-pifacedigital-emulator
python3-pifacedigitalio
python3-pifacedigital-scratch-handler
python3-rpi.gpio
python3-snap-camera
python-lirc
python-picamera
python-picamera-docs
python-pifacecad
python-pifacecommon
python-pifacedigitalio
python-rpi.gpio
raspberrypi-artwork
raspberrypi-bootloader
raspi-config
raspi-copies-and-fills
rpi-update
simbamond
smartsim
sonic-pi
wolfram-engine
xserver-xorg-video-fbturbo

[diederikdehaas]

You are absolutely right here and I'm inclined to go with your first proposed solution.
I'm thinking of obtaining and verifying the key and then add it to this project and do the same for the Raspbian signing key to be used in PR #63.
Do you think that would be a proper/secure solution?

[jturner314]

I've been thinking about this for a little while, and here's what I think is the best solution:

• Verify the fingerprints of the keys properly, and then include those fingerprints in the source of update.sh. Basically, instead of including the keys directly in the project, we include their fingerprints.
• In update.sh, retrieve the keys from https://archive.raspbian.org/raspbian.public.key and http://archive.raspberrypi.org/debian/raspberrypi.gpg.key and verify that they have the correct fingerprints.
• Use the raspbian.org key to verify the package downloads similar to Add verification for downloads of update.sh #63, and include the raspbian-archive-keyring package (which contains the raspbian.org key) in the image, as in Force authentication for cdebootstrap-static #62.
• Build the image as normal, and include the verified raspberrypi.org key that was downloaded and verified by update.sh somewhere in /usr/share.

This approach has the following benefits:

• Good copies of the keys are included in the installer image, so they don't need to be fetched insecurely at install-time.
• If someone doesn't trust raspbian-ua-netinst, he/she has to audit the code anyway. By including the fingerprints in plain text in update.sh, it's easy for him/her to check them.
• By fetching the keys during update.sh, the user gets the latest versions of those keys.

To clarify, here's a code sample for update.sh for the key-retrieval portion of this approach. It uses a temporary ./gnupg directory to avoid messing with the user's personal keyring. Note that while I think the fingerprints here are correct, I don't have a good way to verify them.

echo "Fetching and verifying GPG keys..."
mkdir -p gnupg
chmod 0700 gnupg
wget https://archive.raspbian.org/raspbian.public.key
gpg --homedir gnupg --import raspbian.public.key
if ! gpg --homedir gnupg -k 0xA0DA38D0D76E8B5D638872819165938D90FDDD2E &> /dev/null ; then
    echo "ERROR: Bad GPG key fingerprint for raspbian.org"
    exit 1
fi
wget http://archive.raspberrypi.org/debian/raspberrypi.gpg.key
gpg --homedir gnupg --import raspberrypi.gpg.key
if ! gpg --homedir gnupg -k 0xCF8A1AF502A2AA2D763BAE7E82B129927FA3303E &> /dev/null ; then
    echo "ERROR: Bad GPG key fingerprint for raspberrypi.org"
    exit 1
fi

If this sounds good to you, I can merge pull requests #62 and #63, add a little more code to implement this approach, and then send one big pull request with all of the changes.

Even with this approach, it would be good for the key fingerprints to be more widely publicized so that users could more easily verify those in update.sh, and it would be nice to see a stronger web of trust around these keys -- Raspbian and the Raspberry Pi Foundation could sign each other's keys, some Debian developers sign the Raspbian key, etc.

[diederikdehaas]

msg from plugwash (signed with his key which is in the debian keyring):
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I confirm the key being used to sign the Raspbian repository as for 2014-06-17 is

pub 2048R/90FDDD2E 2012-04-01
Key fingerprint = A0DA 38D0 D76E 8B5D 6388 7281 9165 938D 90FD DD2E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJToL6hAAoJEAxI6ip6j/17F2UP/AuWP2+2lbphMoAzxbTgd6Hp
YpuNGgtuXtQXhAWBS6Ml2tTBbOwqPlESbVhVDKunf5TlP2KJvAO4p9nrnRiqwiOl
5gpJ3RA8zoLuTrIfwSEvzbtDGbAAoHHsGogwurn5TB3EMJY+Kktwwm4JYtJvjkjy
C4w8kuhuiRosm8FjXchhWbKI4bANfqZ1BpCOkwyP8T7gf0qQTynbWls7VDQTHC2T
Yhy1G6qQlGylSDr6D/5yin9J1rmAywpSrVU4fIeR3C/V1YeWgZZbDNHrIbvUJ5T8
ntKSrS1wYLc4dGeLIi2zc3BZWpHxC00GzaC1w6v9aH4qsxmVpM0U0sQ4Rup++8qV
VCmYJf22BzVhPeYYjRA0M1hnTjXnMT6FqtD9arVob1EJHtMYlDJiowKDhZC5qxND
q1nKmWWNhTTAieA7VwstADsuAjo2NIF57EQilluhZUdLlsfY8cZomAivAbpCaC7R
lDYzb/sFa94F1dK5tlBv2/jItZXuUkFadh3ie+ynnZccY4mb31zGmp1/EQOfaisn
rAvZ6qIgPNHf1O66P4yYsHBKnzLQLkcs4SsI3XmO/6PHXVXG3CQ0DULUISTaiHES
4D9Os6ryuptmbfRUQOJW7jsSXMn2OyMQVWmySobv5SQK1cydwwrLmgCaKPi1FF3/
+dZEIwZCwzx2E1UiqJRu
=gc3M
-----END PGP SIGNATURE-----

[diederikdehaas]

I've now also started a thread on the raspberrypi.org forums in hope of improving the situation:
http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=79804

[diederikdehaas]

And yes, this does sound very good to me.
So if you could implement it, that would be much appreciated 👍

If you could use several commits for it, that would be awesome.
And I highly appreciate the excellent commit messages you use :-)

[diederikdehaas]

I'm inclined to (also) go with

• Don't add the http://archive.raspberrypi.org repository during unattended installation

That way it is easy to fix Issue #65 (see #65 (comment)).
It would also make other stuff easier/cleaner, since we don't have to take the raspberrypi packages into consideration anymore, which more then once interfere with the raspbian packages.

[jturner314]

Pull request #66 implements the first suggestion: update.sh downloads the raspbian.org and raspberrypi.org GPG keys, verifies their fingerprints using hard-coded values, and includes them in the installer image so that they don't have to be downloaded at install-time.

It would also make other stuff easier/cleaner, since we don't have to take the raspberrypi packages into consideration anymore, which more then once interfere with the raspbian packages.

An alternative is to modify the priorities in /etc/apt/preferences. For example, APT could be configured to always use raspbian.org except under one the following conditions:

• if the package is only available in raspberrypi.org,
• if raspberrypi.org is specified manually, or
• when upgrading packages installed from raspberrypi.org with the latest version available in the raspberrypi.org repositories.

For information, see sections 6.2.5 and 6.2.6 of this page or the man page for apt_preferences. I think that adding the following to /etc/apt/preferences should do the trick (where $release is that of scripts/etc/init.d/rcS):

Package: *
Pin: release o=Raspbian,n=$release
Pin-Priority: 990

You can check your current priorities by running apt-cache policy.

[diederikdehaas]

if raspberrypi.org is specified manually, or

Do you know how to do that?

I've been trying all day to find a way to install a package (libraspberrypi-bin to provide vcgencmd) from the raspbian archive and not the raspberrypi.org archive.
What I want to do is use values of the release-line from apt-cache policy (just like you'd specify in /etc/apt/preferences) in the apt-get install libraspberrypi-bin command.
But the following doesn't work apt-get install libraspberrypi-bin libraspberrypi0 -o release::o=Raspbian or a whole bunch of variations on that line.
The only one that does seem to work is apt-get install libraspberrypi-bin=1.20140618-1~nokernel1 libraspberrypi0=1.20140618-1~nokernel1 but that would be obsolete the moment a new version is released (and I'd have to make a new installer).

I am kind of weary of providing an /etc/apt/preferences file OOTB since it has rather far-reaching consequences and if ppl don't want it, they'd need to find a way to override it.

[diederikdehaas]

I may/might go for disabling the raspberrypi.org repos at some point, but that would be in a version 1.1.x series and I have no plans for that now.
But thanks to some discussion on the #raspbian IRC channel, I found a variant which I am comfortable with:

Package: libraspberrypi-bin libraspberrypi0 libraspberrypi-dev libraspberrypi-doc
Pin: release o=Raspbian,n=$release
Pin-Priority: 800

(not sure if prio 800 is effectively different from 990, but it would make it easier to give repos a prio above and below it)
With that I can include vcgencmd in the image, without installing the rpf kernel and bootloader.

[diederikdehaas]

The key used to sign the raspberrypi.org archive is now published securely on https://www.raspberrypi.org/raspberrypi.gpg.key
And ShitfPlusOne send me the following msg, just like plugwash has done earlier:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I confirm the key being used to sign the raspberrypi.org repository is
pub 2048R/7FA3303E 2012-06-17
Key fingerprint = CF8A 1AF5 02A2 AA2D 763B AE7E 82B1 2992 7FA3 303E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVSO8TAAoJEKQcgohUhKUlTT0H/3lc1X/p3DwgbSrdIiVNLawX
0dbkLrvvJCrOYaV/xztosDnTPU3AF3HFqjVWmliBMcW0rFBXWz03tfXD38OszEK7
jzt3oNdoVetCl5K8QCDHqMtwIgIMKg0w0oojFPwFAqxJ4i8QlfC6YwZtW0Wge9Zz
SwTWnZKbv8gvLRukNjHjGtddDKwX6yqg58McXkZ7VAdUFxujJ7iOnexAXXMz0b1N
Gzmec/QbE4LuhVKxTmH2howOGeXJ8UDCqDQDzbxbcQnTrk5wnVPrWMuVhSFH8BD+
ue5Nmc34zV98t2rheUkZZXpIjIcdzYrrakI2p8cWhu8CUivgndkOVCev/PaU7D4=
=G/So
-----END PGP SIGNATURE-----

[diederikdehaas]

For safe-keeping I've now posted both confirmations on paste.debian.net
plugwash: https://paste.debian.net/171594/
ShiftPlusOne: https://paste.debian.net/171595/

[diederikdehaas]

This issue is now fixed with the release of v1.0.7 of the Raspbian unattended netinstaller.