Signing keys clarification needed

[kapitainsky]

Trying to sign AppImage with my pgp keys:

Embedding MD5 digest
gpg2 and sha256sum are installed and user requested to sign, hence signing
Error: cannot embed key in AppImage: size exceeds reserved ELF section size

Could not find any information about what keys are permitted, obviously mine is too long (4096 bits). Any details on this somewhere?

The issue is in reference to linuxdeploy/linuxdeploy-plugin-appimage#9

[probonopd]

Hello @kapitainsky and welcome to AppImage.
In the current implementation, ELF section .sig_key is 8192 bytes long. It is not part of the spec yet, but we are working on it.

I have been using 4096 bit GPG keys successfully. The ASCII ("armored") version of the public key needs to fit into 8192 bytes, and it does easily (for me):

https://travis-ci.org/probonopd/cool-retro-term/builds/616227444#L791

Could it be that you have a key with subkeys, or something like that?

I realize that setting up signing is currently a cumbersome, manual process and I am writing a tool to automate it.

cc @TheAssassin

[kapitainsky]

Indeed I have a subkey. Have to look at it closer.

But as I see that all signing is still work in progress. It is fine. I will stick in the meantime to detached signature file.

Will come back to it when it is more mature. Thanks a lot!

[kapitainsky]

One last thought on this. I might have one or more subkeys but it should not mean that AppImage should include all of them. Only one used for signing will be sufficient. Also if definition of .sig_key section is not part of spec maybe it would be wise not to limit its lengths? Who knows what future holds for keys. You used gpg to do all job anyway. And if some key is 8KB or 20KB does not really matter given size of typical AppImage

[TheAssassin]

Currently the maximum size must be known beforehand, as it needs to be pre-allocated. This will be fixed in future type specifications.

Remember, your key doesn't require the very generous 8kB very likely. We only save the public part into the AppImage.

[kapitainsky]

Correct. But as I have subkeys overall size can be bigger. It is only necessary to save key used for signing not all of them which is probably what is done today. And IMHO format specification should be future proof as much as possible. Why to limit yourself to 8k? Make it variable and not limited by design decision.

[probonopd]

Why to limit yourself to 8k? Make it variable and not limited by design decision.

The keys are saved in ELF sections that are allocated at compile time of the AppImage runtime, when we don't know the size of the key yet. The key (and the signature) are not saved inside the AppImage filesystem but in ELF sections to make it possible to exchange/update them without having to recreate the whole filesystem.

The solution is to use a dedicated signing key that is only used for this purpose. I am working on a tool to make setting this up almost fully automatic.

[kapitainsky]

ok... people have keys. and keys have history and built trust. You cant just say Appimage needs new special key. So far only option is to just say --sign. I cant choose what key to use. Think from user perspective. I have had my key for years. It works. gpg does good work. I sign email and files for years. and suddenly it is oups you need another key.

[kapitainsky]

maybe whole concept to including public part of the key is just wrong? why not only signature? AppImage is not going to solve keys trust issues. and should not even try.

[TheAssassin]

Pretty shortsighted point of view. Of course you need the public key, it's essential to actually check if a signature is valid. It doesn't mean you have to trust the signature. That trust must be created differently.
AppImageUpdate for instance is making heavy use of the embedded pubkey. The trust is created using a transitive model (à la "I have the old AppImage, I trust it, so if the new AppImage's signature is valid and the old signature is valid as well, I can trust the new AppImage if it's signed with the same key as the old one"). You have to have both keys in order to make such a comparison.

The problem here is not that the key is embedded. The problem is the "signing algorithm" that makes way too many assumptions, which is due to the annoying point of view seen in many AppImage related tools which I often disagree with, that configuration is bad and unnecessary and the tool always knows better than the user.

So, don't hate the signature embedding, hate the tool which does the embedding in a way that a) breaks and b) is not what you want. The assumption that the size of the section is sufficient was made on facts; you can calculate the space one single key requires nowadays, and 8k is a good bit larger than that. The space could always be increased.

I have written the algorithm to embed the keys back in the good ol' days, and basically followed the scheme that the original signature embedding was following, i.e., just calling gpg with some export parameter and embedding the result. We can make the embedding more configurable to allow you to select the right key to embed. Or, even better, just export the required subkey.

[probonopd]

When it comes to signing, signatures, and trust, it is important to know the "threat model" and what we want to achieve. Since this is a complex topic, I would suggest that we write a "theory of operation" that explains it. @TheAssassin has already pointed some points out.

We can make the embedding more configurable

Actually, I'd propose to the exact opposite - make it zero-configuration, "just works". My experience is that everything that can be configured will increase complexity and breakage. I have an example implementation in the works.

[kapitainsky]

ideally would be both worlds together @probonopd "just work" should be default but @TheAssassin is right that giving "advanced" configuration options for "power users" make all tool much more powerful

[TheAssassin]

@probonopd your experience doesn't apply to build tools then, I'd say. The solution can't be "ah, you just have to set up a custom GPG home, export your key on your old one, import it in the new one, then make appimagetool use the new, and clean up everything afterwards; not to mention you need to make sure your keys remain confidential in the process". Compared to "just export GPG_KEY_ID=<my key ID>", not making this configurable is nonsense. What's more complex: maintaining a tiny switch in the codebase or requiring huge complicated and complex workarounds to solve real-world problems?

[probonopd]

Actually, I've been working in my experimental go implementation to make all those steps (and more) fully automatic. For me, the ideal tool is a one-liner that does everything in a standardized way without needing any configuration. (And no, I'm not there yet...)

@probonopd your experience doesn't apply to build tools then, I'd say.

My experience with "traditional" build tools is that nothing works without having to "fiddle around". Notable exception: Xcode on the Mac. You click the "compile" button, and that's basically it.

[ssaavedra]

Hi!

About the ELF section sizes, I understand we need to know the public key size before compiling in order to determine the size of .sig_key. However, you could already do that if you run a strlen of the gpg --export command before compiling, and allocating the required amount of space for that purpose. This should alleviate the requirement for different sig_key sizes.

Consider also that different keys may produce different signature sizes, although the same key will produce the same signature size for different messages of the same size. Thus, you can also use this approach to calculate the .sha256_sig header when building.

Also, couple of questions on this that would appreciate clarification, both in the current state, but also to "where the spec is going".

I am implementing a verifier for signed AppImages with a controlled trust source. I don't want to rely on either validate.c nor AppImageUpdate code for several reasons, one of them is that my codebase is Python-based and the ELF format is also well-supported to read there with portable code. Also, because AppImage being a spec, it should be feasible and make for stronger spec compliance.

From my experience and use case considerations, I would strongly advocate for keeping separate sections for the public key and the signature. One can accommodate not having the public key inside the AppImage (as they could also accommodate not having the signature itself and use detached signatures), but I believe a strong point is precisely to avoid scattering different files. Using ELF sections seems like the only possible path we you ever need to re-sign AppImages due to a lost or compromised key without requiring recompilation, and also to allow CI/CD flows that could sign already-compiled AppImages as a single centralized step outside AppImage compilation.

E.g., you might want the same AppImage signed with different keys for different purposes due to different trust sources in the final deployments.

On what other content the .sha256_sig may have, I don't mind very much as long as it can be passed to gpg as if it were a PGP signature.

Tests with GPG indicate that precedent text can be admitted as long as there is a newline before -----BEGIN PGP SIGNATURE-----, but I have not reviewed if this is part of the OpenPGP spec.

From a compliance point of view, adding .sig_key would be of interest in order to assert that the digest used for the signature placed in .sha256_sig, if present, MUST assume that both .sha256_sig and .sig_key sections exist with the same length and filled with 0x00. Consider whether .upd_info should adhere or not to that same assumption. I personally don't think the update information should be immutable, and that even client-side tools or proxies might be interested in meddling with that field. If immutability of the whole archive is required, a detached signature can still be provided, but we would have no other way of providing this functionality.

Consider also that currently you are NOT signing the digest of the AppImage. You are currently signing the hex-string of the digest of the AppImage. The actual digest is a binary bytestring, not ASCII text. I don't mind very much, but you are performing a non-trivial transformation which reduces the possibilities from [0x00-0xFF] (256) to just [0x30-0x39] + [0x61-0x66] (16). The spec should be rephrased, and if a different spec is desired, an upgrade path would be desirable.

[probonopd]

@ssaavedra welcome to the AppImage project and thank you for your remarks and suggestions. Maybe you'd also like to hang out on #AppImage on irc.freenode.net where many of the devs meet.

About the ELF section sizes, I understand we need to know the public key size before compiling in order to determine the size of .sig_key.

Please keep in mind that the runtime is pre-compiled, and the key is merely placed into it by writing at a defined offset. Essentially we need to make sure that the key that gets written into the already-compiled runtime is no larger than the padding that is inside the aready-compiled ELF. The key can be shorter, though.

I personally don't think the update information should be immutable, and that even client-side tools or proxies might be interested in meddling with that field.

Agree. The update information was put into an ELF section (rather than into the squashfs filesystem) exactly for the reason that we want to allow AppImages to be moved e.g. to a different URL without the need to re-create them entirely; and allow for just changing the update information while leaving the rest of the AppImage untouched.

Consider also that currently you are NOT signing the digest of the AppImage. You are currently signing the hex-string of the digest of the AppImage.

Looks like you are knowledgeable about the security implications here. We are interested in your suggestions how to improve, e.g., for an upcoming type-3 format which we have recently started discussing.