GPG signatures for source validation #5619
Comments
|
We are setting up the keys for the release of 1.8.2 |
|
So much love <3 |
|
The git tag is now signed https://github.com/arduino/Arduino/releases/tag/1.8.2 About the signing of the single packages, instead of generating a signature for every package, what about signing the sha512sum.txt? This way we can sign all the packages at once, something like: https://downloads.arduino.cc/arduino-1.8.2.sha512sum.txt.asc |
|
The way we build packages is we download the .tar.gz from github and validate this tarfile against the .asc or .sig file. This process is automated in a way that it only trusts the selected GPG keys and that it automatically checks the available signatures. Signing the shasum file is way more complicated and can cause wrong parsing/security issues. There was some controversial internal discussion about those upstream signatures and they should just be avoided if possible. What I suggest is to simply publish the release via gpgit thats automates the whole process for you and everything will be signed properly. If you dont want to use that, please sign the github.tar.gz files manually as described in the readme. You should however always verify those before blindly signing them (thats what gpgit also does for you). The .zip files on downloads.arduino.org should also be signed, as some build deps need to be downloaded from there instead (libastyle for example). This also implies that all subprojects (arduino-builder, ctags etc) needs to be signed too. Best on github and on downloads.arduino.org. Please also do not use insecure sha1 signatures and upgrade to gpg2 possibly. |
ok fair enough
The archives are made locally and uploaded to the download server, there is no need to check that the zip archive content, just created, is the same as the source folder being zipped... Another question: shall we publish the public key on the arduino website? PS: I'm still confused on how all this infrastructure can improve things (since an attacker that successfully gain access to the webserver can still easily replace all the archives, signatures and public key altogether...) |
Yes, and you should consider posting it on other places as well, such as to a public key server. I use https://pgp.mit.edu/ myself, @NicoHood may have other recommendations.
This is a valid concern, but between submitting your public key to a keyserver and people having this already cached locally, the damage can be minimized. Previously, an attacker could replace everything and no one would be the wiser. Now, an attacker could still replace everything but this could be detected by a careful third party that actually checks signatures and doesn't necessarily rely on the single copy of your public key to be intact and unaltered. |
Those do not need additional checks, but signatures. I was talking about this github sources here. Those are generated from github and need to be checked before signing. This is where gpgit automates the process. You need to sign the arduino.cc and the github files as arduino.cc files contain prebuilt releases and github the sources. Some parts of the arduino package are build from source (and more are coming) and a few still rely on the prebuild arduino.cc downloads. As an alternative you could provide the source files also on arduino.cc and sign them also locally. look at
@cmaglie Best would be on website, github and keyservers. I prefer
And now it comes into place that your public key is already known by us. On a package update we validate against the known public fingerprint and this will fail if the signature/archive changed. Thatswhy keeping the gpg key secure with a strong password is of very high importance. As an alternative you can make other trusted users sign your fingerprint to give it more trust. This builds a trust chain. I can for example sign your key, stating that I trust the owner. But thats mostly only used in linux distributions with a master key schema. Thatshy publishing you fingerprint on multiple sources is very important. People wont hopefully hack arduino.cc and github at the same time. |
|
The current tar.xz looks better. However inside the files are named wrong due to a wrong use of git archive. A slash at the end is missing to create a folder instead of renaming all files. I hope this was not produced by my script, otherwise I need to fix it. |
|
Oh yes I created them manually, probably I missed the slash :-/ |
|
The new signatures have this fingerprint: How was the key generated? Because it is not trusted by default. If it was my script, I need to change that. I am currently searching for the reasons. The key has no expire date. That is possibly the reason. And beside the issue it is not good to have a key that never expires. Please use a value of 1 or 2 years. |
|
I made it, what does it mean that it's not trusted by default? |
I do not know yet why this happens, because it never happened. But I guess its the expire date. Please add an expire date and upload the key again to the servers. |
|
Could it be that the key is not marked as trusted in your trust chain? |
|
@cmaglie that never happened before, but yes it could be. However its not normal. In any case: Please add an expire date for your own security. I am currently trying to find the cause of this issue. |
|
@NicoHood, I just downloaded the key and for me it does not look weird: This does say "unknown" for trust level, but that's because it has no signatures and thus no signature path to my own key. I'm not sure how that is for other packages, but I suspect they just have a path into the web of trust? In any case, this would be good for the Arduino key as well, to get into the web of trust. Do any Arduino developers have personal keys they can sign it with? I can also sign it with my key if we can do some out-of-band verification of the fingerprint. |
Well, that is the whole point of the chain of trust: when you download a key from a keyserver you cannot be 100% sure that is genuine and not a fake one, unless the key is signed from a trusted 3rd party. |
|
It was a problem on my side. Sorry. You should add the mentioned (full!) fingerprint to the website along with the signatures and source. It would be nice if you can also sign the other tarfiles from downloads.arduino.cc so every download is signed. Edit: |
|
I just uploaded a signature for the key to the keyservers. |
|
Everything should be in place now, I've published the GPG key on the website too: https://www.arduino.cc/en/Main.Software#source |
|
@cmaglie Incredible! You signed almost every source. Thanks so much <3 Missing signatures: And the docs files: |
|
ctags source is still not signed, avr core also not. The new wifi updater also has no signature. I will postpone updated until all sources are signed |
|
It should signed everything now. |
|
Could it be the |
|
https://github.com/arduino/Arduino/releases/download/1.8.7/arduino-1.8.7.tar.xz Missing. Signature also. |
|
Done! with the new script this should not happen anymore in the future (hopefully)... |
|
The signature is now available. But the tarfile does not have a separate folder inside. Normally a tarfile contains a folder of the tarfilename where all data is placed. This makes it easier to extract it into its own folder, rather than putting everything into the working directory. Especially for our automated extracting this makes it more complex than needed. The older releases included such a folder, so I guess this was just accidentally missed. It would be nice if you could fix that :) Also this signature is missing: And this one: Signatures are still missing for the avr core too: |
|
ok updated arduino-1.8.7.tar.xz as you suggested (and also the script). added the other missing signatures |
|
Thank you very much! |
|
added the signature |
|
==> ERROR: Failure while downloading https://downloads.arduino.cc/liblistSerials/liblistSerials-1.4.2.zip.asc |
|
added the signature |
|
The release 1.8.9 has no downloads, nor signatures on github.com. |
|
The download is now available. Missing is: |
|
Added missing signatures |
As we all know, today more than ever before, it is crucial to be able to trust
our computing environments. One of the main difficulties that package
maintainers of Linux distributions face, is the difficulty to verify the
authenticity and the integrity of the source code.
The Arch Linux team would appreciate it if you would provide us GPG signatures
in order to verify easily and quickly your source code releases.
Overview of the required tasks:
GPGit is meant to bring GPG to the masses.
It is not only a shell script that automates the process of creating new signed
git releases with GPG but also comes with this step-by-step readme guide for
learning how to use GPG.
Additional Information:
Thanks in advance.
The text was updated successfully, but these errors were encountered: