Check the gpg signature when updating about appimageupdate HOT 49 CLOSED

Taking this as a feature proposal for the rewrite.

from appimageupdate.

I am working on this again. We verified the pubkey in the repo is the one of the key we use to sign the appimagetool/appimaged AppImages at the moment. That means there must be an issue in the signature verification. I am quite sure it's a workflow problem. AppImageUpdate calculates the SHA checksum with the signature key, but it seems appimagetool calculates its hash before embedding the key.

from appimageupdate.

@probonopd it's a misconception in the implementation in AppImageUpdate that I found, which I'm going to fix soon (hopefully).

from appimageupdate.

Thanks @pamarcos. Please be aware that @TheAssassin is currently rewriting AppImageUpdate in C++, so it's probably not worthwhile to continue working on the bash-based AppImageUpdate script.

from appimageupdate.

We should think about what happens in which case:

• File is not signed -> Warning but user can choose to continue
• File is signed but signature cannot be verified because public key is not in user's keychain -> Warning but user can choose to continue
• File is signed and signature can be verified using public key in user's keychain -> No warning
• Signature of updated file does not match signature of original file -> Warning but user can continue

Over time, we may opt to make "user can continue" more cumbersome in order to prevent users from just clicking "OK" all the time.

from appimageupdate.

You don't need the keychain at all, or should give it a lower priority. I plan to extract the signature from the previous AppImage, and then use its public key to verify any subsequent signature. This is quite secure, and doesn't bug the user too much or hack around with his private keychain. Speaking of keychains, we'd have to set up a separate one for these purposes anyway. And nothing really stops a process of putting in new keys into any keychain owned by the current user, so that doesn't really provide any security.

from appimageupdate.

I plan to extract the signature from the previous AppImage, and then use its public key to verify any subsequent signature.

Where do you get the public key from, if not from the keychain?

from appimageupdate.

Hm, good point. They're not bundled with the signature (although that would make a lot of sense actually, they're public anyway).

What I want to say is, we should not alter the user's private GPG keyring. What we could do however is create our own keyring in e.g., .config/appimage/update/keyring.gpg or something like that.

Since I'd anyway try to fetch the missing key from a PGP server (like, pgp.mit.edu) if it's not available locally, we could ask the user to confirm the key, and eventually put it in AppImageUpdate's keyring. I know, most people are most likely just going to hit OK anyway, but privacy aware people at least have a chance to audit their keyring, which provides a core principle of secure systems, being transparent to the user.

from appimageupdate.

I don't think we should alter anything. How the user gets the public keys into his keyring is not something we should be concerned with, at least initially. I could imagine that e.g., openSUSE would pre-install their public keyring into the system's default keychain.

If as a user I trust e.g., krita.org, then I as the user could import their key into my keyring if I want appimaged to set their AppImages as trustworthy (e.g., run outside of a confined Firejail sandbox).

At least initially.

But this is up for discussion.

from appimageupdate.

I started working on this feature. For now, I plan to show a dialog whenever a validation fails, to give the user feedback about what's going on (given there's a signature, if there is not, a warning will be logged). We could also just fail the updates, but I don't think that average users would understand why an update has failed.

The validation should work like this:

• AppImageUpdate checks whether a signature is contained in the new file
• A check is performed whether the signature's contents apply (i.e., the hash sum matches) (doesn't work, as GPG yields gpg: Can't check signature: public key not found when it doesn't find the public key)
• Now, there's a couple of options how this can continue:
  • signature found in the old AppImage (this works since for a short amount of time, we have both old and new file available for these purposes):
    • if the key is found in the local keychain(s), the key will be trusted, and the signature will be verified using that key,
    • if the key is not available in the local keychain, but the same key has been used for both signatures, AppImageUpdate will attempt to download the key to a temporary keychain and validate the new signature
      • if that fails, the validation fails
      • otherwise, a warning will be returned that the key is unknown
  • if the same key has been used for both AppImages, the validation will return a success state
    • otherwise, it will return a warning state
  • if there is no signature in the old AppImage, the signature's keys are not compared, otherwise it works like the same
    Note for myself: workflow graphs in bullet lists aren't very readable.

Problems to solve:

• How can this be implemented in a reusable way? Should the code go into libappimageupdate, or a GUI specific module?
  • Does libappimageupdate need an API redesign to allow it to post warnings and block the update process?
  • Should the verification be offered as a synchronous method of the Updater class, similar to the update check? This could, like the update check, be combined with the status message API.
• Is it sufficient to show a dialog on failed validations? Should AppImageUpdate refuse to work entirely?
  • Do we need to recommend users of the update information and signatures to test updates before publishing releases? Do we have to write a tool for this?

from appimageupdate.

I pushed an API proposal in #75.

My plan is to read the original and updated AppImages' signatures, store them in the updater class, and have

With #74, the ELF section reading code has been extracted from the update thread into a separate function. Then, the objdump-based code has been replaced with the code @probonopd wrote for AppImageKit.

Being able to read ELF sections properly now, it's easier to extract the signature sections. They're stored in the class, and after the update has run, the user can call validateSignature() to (surprise!) validate the signature using the workflow suggested above.

from appimageupdate.

We should think about the UX for this. Especially don't spew warnings all over the place, which will only do two things:

• Give the impression that AppImage is totally insecure (in general)
• Make users ignore all warnings

So what I could imagine is:

• Do not warn if an AppImage has no signature at all
• Give extra credit (think "green lock in the browser bar") for an AppImage that is signed and the signature of which can be verified using a trusted key in the keychain
• Show a warning dialog only if something nasty is going on (e.g., the new signature of an AppImage does not match the pre-update one, or the AppImage has no signature anymore post-update while it did have one pre-update, etc.)

This needs some conceptual thought - can you propose the UX?

from appimageupdate.

the new signature of an AppImage does not match the pre-update one

Doesn't make sense. Please elaborate.

I value security way higher than any user experience, and took a web browser's SSL certificate verification as a kind of role model for designing my workflow here.

I don't see a problem with the UX I suggested. Especially when comparing to what e.g., browsers, do. A browser will show a warning if a certificate's origin can't be verified, and will show an error when the crypto doesn't work.

I basically suggested the same methods. I already mentioned if there's no signatures involved, I wouldn't show a warning or error at all. And if there are, and they work fine, it's all good. However, if the verification doesn't work, you should warn and/or fail, depending on the severity of the issue.

I mean, why bother verifying it at all, if you're not informing the user about it properly, right?

If you as an app author screw up the signature part, why should an update be performed at all? If it's just your key that is unknown, a simple confirmation dialog won't prevent anybody from performing the update (in web browser words: "add a temporary exception").
I'd add browser-like icons to the dialogs, so people who are familiar with the UX of a web browser will feel comfortable with AppImageUpdate, too.

But picking up your idea about the "extra security" credit in the progress bar: We could make it yellow if there's no signatures involved, and write something to the progress label like "Warning: the update has not been signed." But that's basically an extension to what I suggested above already.

from appimageupdate.

took a web browser's SSL certificate verification as a kind of role model

Yes, I think thats the right approach.

But once Chrome starts giving warnings on every http site, I'd consider that overdone. It is an extra benefit to have https. For AppImages, we're still at a stage where the majority comes without the "secure" (signed) option. Don't throw warnings on those, at least not yet.

from appimageupdate.

(given there's a signature, if there is not, a warning will be logged).

Where did you read that whole "no signature = show warning" thing? I never proposed such a thing. I suggested to log a message (i.e., to the "Details" widget)...

You even suggested a slightly "more aggressive" measure for those cases, coloring the progress bar accordingly (which I extended to showing a warning in the progress label.

from appimageupdate.

Aaaah... ok ;-)

from appimageupdate.

I noticed my API proposal won't really work with the workflow I suggested.

While calling validateSignature() would work the way it's implemented right now, one can't "interrupt" an update if a validation fails, as the update thread might have removed the former AppImage. To mitigate this problem (i.e., be able to restore the old AppImage), one would have to copy (or create a hardlink) the old AppImage before starting the Updater. That's some complexity I don't want to have in the API.

Instead, we could think about implementing a callback-based method.

from appimageupdate.

the update thread might have removed the former AppImage

What do you mean by "removed"? I think we had established before that "updating" an application should mean that the newer version is downloaded but the older version is not (automatically; by default) deleted, so that users have a chance to go back to the old version if they don't like the new one.

from appimageupdate.

What do you mean by "removed"? I think we had established before that "updating" an application should mean that the newer version is downloaded but the older version is not (automatically; by default) deleted, so that users have a chance to go back to the old version if they don't like the new one.

Right. But there's the flags -r and -O that might interfere with this workflow. Further investigation needed.

from appimageupdate.

I got the basic workflow implemented in appimageupdatetool. I decided to abort on errors, and show a message on warnings. I might extend the latter to prompt the user whether to continue, but I assume people would then start to ask for a -y or --force-yes flag or something. We'll have to discuss that later on, when the validation code has been verified.

A few problems I came across so far:

• Working with gpg2 via the CLI is hard. We cannot link to GPGME (or libgpg), as they are licensed under the terms of the GPLv3. Therefore, I had to work around this by using gpg2 as a subprocess. Someone should have a look whether what I wrote is solid.
• We need to discuss whether we should bundle a copy of gpg2, to make sure it's available. At the moment, the update process is aborted whenever gpg2 is missing.
• @probonopd's "official" signing key used to sign AppImageKit etc. hasn't been published anywhere, neither keyservers nor otherwise (at least I couldn't find any pubkey file). That leads to validation errors when updating AppImageKit and/or appimaged.
• As a consequence, we could bundle some "known good" keys in a keyring that we ship with AppImageUpdate. I think it's a good idea to do so, but I'd like to hear more opinions on that. I would start by bundling our key and the openSUSE build service keys (CC @adrianschroeter).

In order to be able to test the full workflow, we'll need a couple of test projects and (ideally) a lot of testers.

from appimageupdate.

We need to discuss whether we should bundle a copy of gpg2, to make sure it's available. At the moment, the update process is aborted whenever gpg2 is missing.

For me, the the whole signature thing should be treated as an optional security benefit, with a fallback to not using it at all if it is not there. Users who want to take advantage of the gpg2 based signature stuff need to install gpg2. Users who don't want or need this should not be bothered with errors; but they should simply not see the equivalent of a "green lock symbol" either.

from appimageupdate.

we could bundle some "known good" keys in a keyring

This is where the "web of trust" idea comes in, so that we don't have to decide which keys to include. In the meantime, I'd rather like to see the keyring part in the distribution. They already today decide which keys to ship by default, and users are always free to add extra keys.

from appimageupdate.

"web of trust" doesn't work the way you need it to work, as mentioned more than a couple of times. It's like communism: nice concept, but in the real world...

Also, not an excuse for not publishing the public keys e.g., on the keyservers. If our key would have been on a keyserver, for example, the signature verification would work already fine.

Also, it kinda contradicts your "I like web of trust" concept that you didn't publish the key in said WoT...

from appimageupdate.

Only that keyservers are centralistic whereas I am imagining something more web of trust like... as in p2p. But I understand that this seems not viable at this point in time.

In the meantime, is it reasonable to leave it to distributions to decide which keys to ship by default? I mean, I would expect openSUSE to decide which of the keys used on OBS are to be trusted on which level... and frankly speaking I don't want to be bothered with this.

from appimageupdate.

Okay, then let me get more explicit. Please upload the public key, either to the keyservers, or as a file, so I can use them!

from appimageupdate.

This one?
https://github.com/AppImage/AppImageKit/blob/appimagetool/master/resources/pubkey.asc

from appimageupdate.

Don't know how I could miss that file... I was looking for something with key (or .key?) in its name... But yes, I think so.

from appimageupdate.

@probonopd from OBS POV, we could found an appimage project official OBS project, where developers can submit request their appimage builds. A team (you?) needs to review them and they would be built using that projects signing key. We could add this key then to the updater ....

from appimageupdate.

@adrianschroeter how are the files signed at the moment? They do contain a signature, as far as I can see...

from appimageupdate.

The OBS files are apparently signed with the home projects' keys. Therefore, we need a way to temporarily download the keys from OBS's systems in order to validate these signatures.

That could be achieved by using osc, the CLI, and its subcommand osc signkey <project>. However, osc is Python and therefore can't be bundled easily.

Another issue:

gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

from appimageupdate.

Okay, I tried with some external aria2 AppImage built on OBS, to see whether AppImageUpdate can update the file.

gpg2: gpg: Signature made Sun Oct 29 03:01:06 2017 CET using RSA key ID A3D71FBA
gpg2: gpg: Good signature from "home:nandub OBS Project <home:[email protected]>" [unknown]
gpg2: gpg: WARNING: This key is not certified with a trusted signature!
gpg2: gpg:          There is no indication that the signature belongs to the owner.
gpg2: Primary key fingerprint: FAE5 2C87 F1A3 BA54 51FA  6942 C8CB A639 A3D7 1FBA
gpg2: gpg: Signature made Mon Dec  4 00:05:23 2017 CET using RSA key ID A3D71FBA
gpg2: gpg: BAD signature from "home:nandub OBS Project <home:[email protected]>" [unknown]
Validation error: Bad signature

So apparently, the original AppImage's signature can be verified successfully (despite the warning mentioned in the last comment), but the verification of the updated AppImage didn't work. Investigating this at the moment.

from appimageupdate.

@probonopd from OBS POV, we could found an appimage project official OBS project, where developers can submit request their appimage builds. A team (you?) needs to review them and they would be built using that projects signing key. We could add this key then to the updater ....

Hi @adrianschroeter do you see a chance that the AppImages coming from projects that are in one of the official distributions would be signed with the distribution's key? (These are probably not the correct OBS terms, so let me give an example: "The AppImage of FreeCAD that is in Leap would be signed by a key that Leap trusts")

Reason is that our team is very small and we don't have the capacity to decide which projects should and which should not be signed. At least I personally would follow the level of trust that the openSUSE project gives to a particular project and/or maintainer.

from appimageupdate.

@probonopd if they had a OBS keyserver so that the keys could at least be searched for, that'd be a great step ahead, and would suffice for me.

from appimageupdate.

well, yes, if you would manage to get them into these projects, they would get signed with the distro key.

It might be just hard to convince the distro people to accept them there, because there is no direct benefit for them.

however, no matter which key is used, you could bless it with your official gpg key?

from appimageupdate.

I agree that using a distro(!) key for external software is a bad idea. Therefore I suggested to build a keyserver with all the OBS keys, so that they can be queried from the gpg2 CLI.

however, no matter which key is used, you could bless it with your official gpg key?

Could you elaborate on that point? I don't understand what you're suggesting.

from appimageupdate.

well, but what would you win with a key server? You would still need to verify the key IMHO.

So, you could ship the by default trusted keys with your source already, no?

from appimageupdate.

@adrianschroeter the trust model is "if the old AppImage is properly signed with the key, we trust it". So, what we'd need is the public key to actually verify the signatures.

But you're right, the whole issue can be resolved by shipping the actual pubkey with the AppImages. I have to ask myself why I didn't come up with that myself...

from appimageupdate.

I agree that using a distro(!) key for external software is a bad idea.

Just to be clear, I was not suggesting this. Instead, I was suggesting to sign AppImages of packages that are inside the distribution already with the distribution key.

But you're right, the whole issue can be resolved by shipping the actual pubkey with the AppImages.

How does this solve the question which pubkeys to trust?

from appimageupdate.

You probably misunderstood me. That doesn't solve the question at all. And I never tried to solve that question at the moment. The issue we are working on here is, you can't verify a signature's integrity without having the key. When you have the key, you can at least verify the signature applies. See #16 (comment).

Then, you can continue with the trust model workflow I suggested, which solves the question whether the key can be trusted or not. That's a completely different issue.

from appimageupdate.

OK. For the user, I conceptually would like to simplify it to three states:

• Normal (grey) = there is no signature or the signature is not trusted by the user (i.e., the pubkey is not trusted in the keyring)
• "Green lock" = the signature has been successfully verified against a pubkey that is trusted in the keyring (because the user or the distro has marked the key as trusted and has put it in the keyring)
• "RED FLAG" = the signature does not match the pre-update ("old file") signature, or has been tampered with in some other way

Does this make sense? Do we need more user-visible states? (What would "The signature has been successfully verified against an untrusted signature" mean to the "normal user"? Yellow? How does e.g., apt-get treat this state?)

from appimageupdate.

There is a need for a "less critical error" a.k.a. warning state. In this state, there is some irregularity, but it can be solved, e.g., by asking the user questions like "I don't know this key, shall we trust it?" and have the user verify the data. Of course it's not ideal to have a user check a PGP key's data (see https://en.wikipedia.org/wiki/Key_server_(cryptographic)#Problems_with_keyservers for more information), but it is not a fatal error either.
Browsers show different dialogs based on the severity of the errors as well, as explained above. If there's a problem e.g., with a handshake, the connection is aborted. If the certificate is expired, however, you can add a temporary exception. I want to use the same workflow.

from appimageupdate.

Also, I don't want to introduce a "trusted keyring" at all. It makes everything overly complicated. Normally, the key can be trusted if the old AppImage was signed with it. Why have users add keys to their "keyring" on every computer? It doesn't really add any value. If there's signatures, they shall be compliant with our trust model. If a developer screws up signing, warnings will be shown. Period. That motivates users to do it properly or not do it at all...

P.S.: Yes, we can trust the old AppImages (I mean, we run those apps...). We don't need a "trustworthy" keyring at all, actually, since we probably start to bundle the keys. I didn't think of "bundling" the keys at all. If it had been suggested earlier, I wouldn't have introduced it at all.

So, chapeau @adrianschroeter, and thanks for your awesome suggestion. It solves the issue efficiently.

The last issue is, we probably need to treat every AppImage that has been signed before the date we add the bundling like it wasn't signed.

from appimageupdate.

I merged a PR in AppImageKit to embed the signatures' keys in the AppImages as well. I'll implement the code to extract the signatures tonight. And I'll drop the "trusted keyring" again, as especially we should make sure we properly maintain the AppImages' signatures.

from appimageupdate.

I pushed the final bits to make use of the newly embedded keys.

We still get BAD signatures with our AppImages. @probonopd, what the heck is going wrong there? I mean, the verification works with AppImages built and signed elsewhere.

Last TODO: Implement the verification in the UI(s).

from appimageupdate.

We still get BAD signatures with our AppImages.

Would me having mixed up the public signature be an explanation for this? I remember it took me a couple of tries to get to a useable secret key, maybe I did not keep the public key in sync. I will have to check. This whole key handling stuff is a real pain.

from appimageupdate.

The public key is embedded now, and it's directly exported from the private key using the gpg2 CLI. It's the same key as in the repo, as far as I can tell.

from appimageupdate.

asking the user questions like "I don't know this key, shall we trust it?"

This is exactly the kind of user experience I would really want us to try hard to avoid. "Average Joe" will not understand the question, click "Yes", and think "this AppImage stuff is complicated".

(For "Average Joe" it would be better to not see a message, if a certain number of community members in "good standing" - whoever that might be - have already determined that this key should be trusted - that's what I mean with a web of trust...)

from appimageupdate.

That's why I removed that yesterday. Please try the latest Qt UI.

from appimageupdate.

AppImageUpdate calculates the SHA checksum with the signature key, but it seems appimagetool calculates its hash before embedding the key.

Since we use a digest that excludes (skips) the are in which the key is stored for AppImageUpdate, this should not matter?

from appimageupdate.