-
Notifications
You must be signed in to change notification settings - Fork 153
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
Verify downloaded packages and include GPG keys in installer #66
Conversation
Before, during the build process, packages were downloaded over http without authentication. Now, the Release file and packages are properly verified. If verification fails, a warning will be presented to the user with the option to ignore it. Note that in order to perform GPG verification of the Release file, the user must have the Raspbian signing key in their keyring. The key can be obtained from public keyservers (0x9165938D90FDDD2E) or from https://archive.raspbian.org/raspbian.public.key.
This also switches from using the user's personal keyring to using a temporary keyring for `update.sh` and fingerprints hardcoded in `update.sh`.
Before, the key was being downloaded insecurely with wget during installation without verification. Now, the key that was downloaded and verified by `update.sh` is included in the installer image so that it doesn't need to be downloaded at install time.
Before, the output was very verbose, particularly with wget downloads. Now, much less output is generated so that it is easier to monitor. Additionally, added confirmation messages for successful verifications and changed verification problems from warnings to errors.
Before, `update.sh` would exit without any messages if not all required packages were found in the package lists. Now, it tells the user what went wrong.
I (finally) got around to testing your PR and got to say: "It's looking good!" 👍 But I'm a bit puzzled by some lines in the bootstrap.log file, particularly line 1297 and line 1310. This is quite likely due to my lack of knowledge on this, but could you take a look and see if there's any harm in it? Don't know if it's relevant, but
So there's also a 'Raspberry Pi Archive Signing Key', besides Mike Thomson's key. Should something be done with that key? |
Good catch on those warnings. I just took a look at the source for cdebootstrap and the log file you posted. Here is what I think is happening:
So, in summary, it appears that cdebootstrap downloads and verifies everything at the beginning, so the warning messages that you pointed out are not a concern. In fact, the warnings appear to be expected because line 173 in strcpy (buf, "apt-get install --yes -o APT::Get::AllowUnauthenticated=true -o APT::Install-Recommends=false"); I still find the warnings strange, though -- after all, if There is a
That's the raspberrypi.org signing key, which is necessary to install packages securely from archive.raspberrypi.org. (See issue #64.) |
On Tuesday 08 July 2014 21:07:05 Jim Turner wrote:
Thanks for your explanation :)
Yep and also --verbose. Problem is that it is only logged on screen, but not
That must have been a brain fart on my side or sth like that LOL. You're I expect to merge your PR today :) |
I didn't realize that. It should be possible to use the shell and
Sounds great! Thanks for reviewing my PR so thoroughly and for all of your work on this project. |
Ohh, definitely going to try the I do/did test it thoroughly, but the merge was also delayed by a new kernel version popping up all of a sudden and a new version of cdebootstrap. That one had a bug in it. Thankfully, plugwash uploaded a fixed version quite quickly after I reported it :-) |
Just wanted to let you know that your code works excellent!
And that was indeed correct, since when I checked the archives, I found version 1.42.11-2. |
This pull request is a superset of #63 and is rebased off of the latest master. Compared to #63, this includes a few small fixes, uses a temporary keyring instead of the user's personal keyring, adds additional functionality to fix issue #64, and improves the interface of
update.sh
. The individual commit messages provide more detail.Please double-check the fingerprints in
update.sh
. I think they are accurate but don't have a good way to verify them directly.