Skip to content

Conversation

@yobson
Copy link
Contributor

@yobson yobson commented Nov 24, 2020

This was to fix this bug.
Changes made:

  • Looked for .sig_key part of ELF
  • Added it to the length that is to be set to 0 in the hash

Currently, it works on the assumption that these parts are adjacent in the ELF.

@probonopd
Copy link
Member

Thank you very much @yobson, highly valuable.

Copy link
Member

@TheAssassin TheAssassin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this PR. Indeed it fixes the problem with current runtimes.

However, I'm not so sure we should merge it at this point. It lacks support for older runtimes, and makes assumptions about the ELF file layout.

I could live with merging this, though, as this tool should be rewritten in a less annoying programming language at some point anyway.

fprintf(stderr, "Failed to read .sha256_sig section");
exit(1);
}
if (!appimage_get_elf_section_offset_and_length(filename, ".sig_key", &skip_offset_key, &skip_length_key)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Older AppImages simply don't have this section at all. When AppImageUpdate gained some actual signature verification support, there was a need for the pubkey to be distributed along with the AppImages. Before, that wasn't needed.

I think if we fix this, there should be a fallback for these older runtimes. I could however also live with this tool not supporting old AppImages any more. (The old code can always be restored from the repo, after all.)

@probonopd what do you think?

@yobson
Copy link
Contributor Author

yobson commented Dec 5, 2020

It would be really easy to get it working for older runtimes as well, I'd just need to check for the existence of the new elf section. I'll do that when I'm back in work on Monday. So at least don't merge until then.

If you like, I can try a rewrite in another language. It isn't a complicated tool to write. But I'd need three things from you:

  1. What structural assumptions I can make about the elf
  2. What language I should use. My weapon of choice is normally haskell but I think that might be an antisocial choice.
  3. If I should rewrite any of the other tools? Like the sha digest

I'd do that as another merge request.

@TheAssassin
Copy link
Member

Standard C++11 might work as a language, we already use that elsewhere. But we can also keep C. The masterplan is to rewrite these things in Rust at some point, but that only makes sense if you start over the entire project.

@probonopd
Copy link
Member

probonopd commented Dec 5, 2020

Please let's keep this repository, especially runtime.c and its dependencies pure C.
For libappimage C++ is ok as far as I am concerned, unless runtime.c has it as a dependency.
In fact, I would like to see this repository's dependency on libappimage (and ideally everything else that doesn't come with every Linux distribution) to be removed.
If the runtime gets rewritten in Rust, we can't use libappimage for it anyway.

I am starting to wonder whether we should write it in Go...

@yobson
Copy link
Contributor Author

yobson commented Dec 5, 2020

I'll update this repo in c. No problem.

Rust/go/c++ for the more general case rewrite of a few of these tools. Jury still out. Where shall I write this code if not in this repo?

@probonopd
Copy link
Member

@yobson I think regarding this PR nothing needs to be rewirtten as the validate tool is already C, isn't it?
Or are you talking about rewriting other pieces?

@yobson
Copy link
Contributor Author

yobson commented Dec 5, 2020

@TheAssassin pointed out that this pull request would break support for older appimages. I'm going to make a change so that it supports new and and old appimages (very quick fix)

But the tool makes some assumptions about about the structure of the app image which I think @TheAssassin doesn't think is a good idea to make, so I'm happy to rewrite it in another language so that it doesn't break down the line either.

@yobson
Copy link
Contributor Author

yobson commented Dec 5, 2020

Don't merge what I just pushed. I did it quickly on a mac. I'll test it when I'm in the office with my linux machine.

@yobson
Copy link
Contributor Author

yobson commented Dec 7, 2020

@TheAssassin, It should now be backwards compatible.

@probonopd probonopd changed the title Bug #949 Fix Bug #949, "BAD signature" when validating Dec 7, 2020
@yobson
Copy link
Contributor Author

yobson commented Dec 13, 2020

Is there anything else I need to do? I'm new to open source workflows

@rajivshah3
Copy link

@TheAssassin would you mind reviewing this PR again? We're still hoping to be able to sign AppImages but we want to make sure the signature is correct

@Apfelwurm
Copy link

any chance this could get reviewed again?

Copy link
Member

@TheAssassin TheAssassin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good, haven't tested it, though. @Apfelwurm you may want to provide feedback on this.

@Apfelwurm
Copy link

Nice, that was fast :) Thank you! I have quickly tested it with https://github.com/Apfelwurm/appimagevalidate and when i checked out the current master here the error was still reproducable. When i use yobsons current master everything works like i would expect it.

@yobson
Copy link
Contributor Author

yobson commented Feb 13, 2022

Lovely to hear!

@TheAssassin
Copy link
Member

that was fast

I never saw that notification that an update had been pushed. I just saw that yesterday.

@yobson thanks for your contribution.

@TheAssassin TheAssassin merged commit 76bf860 into AppImage:master Feb 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

"BAD signature" when validating signed AppImage

5 participants