FreeCAD
Appimages should be signed
When using the AppimageUpdate tool with the FC AppImages, one sees this anxiety-generating warning (see below). Beside the fact that one can still run the Appimage, the process doesn't inspire much confidence. What could we do about this?
CC @sgrogan @bblacey @looooo
What could we do about this?
Use the -s switch of appimagetool to embed a signature into the AppImage.
Example of a user inquiry from the forum: https://forum.freecadweb.org/viewtopic.php?f=4&t=33244&p=279262#p279233
Not sure how to do this via ci. If anyone has experience with signing please send a PR or give some instructions.
Not sure how to do this via ci. If anyone has experience with signing please send a PR or give some instructions.
@probonopd care to show us an example?
The problem is not being able to sign the packages. The main problem is including the signing step in Travis build procedure. I plan to take a look at some of the remaining FreeCAD 0.18 related AppImage issues in near future. Will ask on forum if anybody having the needed permission on Travis is interested in making it work. I can help figuring out the steps needed after.
I prefer discussing such in-depth things on forum:
https://forum.freecadweb.org/viewtopic.php?f=10&t=34981&p=329620#p329620
Thanks.
@probonopd care to show us an example?
Check out appimagetool -s. It will sign with the key from your default GPG keyring.
@probonopd care to show us an example?
Check out
appimagetool -s. It will sign with the key from your default GPG keyring.
Can this be done in TravisCI? (sorry not very familiar with the workings of GPG
Sure, we are doing it for our own AppImages. It's a bit tricky: We encrypted the private key in an archive secured with a long password which is stored as a secure variable in Travis CI.
https://github.com/AppImage/AppImageKit/blob/6baa36d0b1e0481aa36a36bb54140b81959b3874/travis/travis-build.sh#L24-L26
First thanks for all the information. Concerning the FreeCAD 0.19 release i don't plan to implement this for now. The idea of sharing the private key, although encrypted, is what ticks me off.
P.S. Will leave the report opened for possible future re-evaluation. If somebody else would like to go ahead with this. I am OK with that.
The idea of sharing the private key, although encrypted, is what ticks me off.
Can you elaborate? You are not "sharing" the private key if you use it to sign an AppImage, you are just using it to make the signature. If you don't want Travis CI to sign the AppImages, you could
- Have Travis CI build an unsigned one
- Sign it after the fact on your local developer machine
If this is what you need, please let us know, so that we can discuss to implement this workflow in our tooling.
Yes, i was talking about possible automation on Travis. As for other option, doing the signing locally, at best we likely would end up signing the "stable" AppImage. We had a few discussions about that on the forum in the past. Somehow i feel that currently this is just not feasible. For checking downloaded package integrity we provide a checksum. Beyond that, like downloading the package and re-upload the signed package, or sharing the encrypted private key. I don't plan to do that for now.
IMHO, since we now have a technically feasible option to distribute appimages over bittorent (#49), we should resume discussions about signing them.
fwiw, it is possible to create a new key that is just used for AppImage signing purposes.
If I read the above correctly, FreeCAD AppImages are currently not signed because the AppImage team is hesitant to upload, even encrypted, the FreeCAD private key somewhere. Which I can understand. Hence I suggested a completely new key to be made for the only purpose of signing AppImages.
We're now generating through GIthub actions. Here is how to store secret variables in Actions
https://docs.github.com/en/actions/reference/encrypted-secrets
I'll volunteer to create a gpg key just for appimages and share it with @looooo
Sure, we are doing it for our own AppImages. It's a bit tricky: We encrypted the private key in an archive secured with a long password which is stored as a secure variable in Travis CI.
https://github.com/AppImage/AppImageKit/blob/6baa36d0b1e0481aa36a36bb54140b81959b3874/travis/travis-build.sh#L24-L26
this doesn't look encouraging:
#### NOTE ####
# Signing is currently broken, as the secret to decrypt the key is not available at the moment.
# Even worse, putting key material in a third-party execution environment is not a good idea
# to begin with.
# The signing doesn't add anything security wise anyway, so it doesn't really matter if it works
# at the moment or not.
#### END NOTE ####
ref: tps://github.com/AppImage/AppImageKit/blob/a3c69f66ea6404315bd02724cde92494a42ab3f0/ci/build.sh#L34-L40
Contributions to https://github.com/AppImage/AppImageKit to improve the situation would be welcome.