I do recognize this is open source and so I am not "demanding" that you spend your time on any of the things outlined below, especially since the current code appears to be working (besides what has open issues), but I do feel like this project does not fully recognize its role in the supply chain, so this issue should be more of a discussion what you think reasonable, or maybe tracking what was done or what could be done.

If I find the time to actually work on appimagetool (beyond just reviewing changes as they happen), I think my primary goals would be

• ensuring there is no undefined behaviour - make use of static analysis (-Wall -Wextra -Wconversion -Werror, maybe scan-build),
• checking hash or signature of all downloads¹ - the runtime is not checked, mksquasfs is not checked,
  • also printing hashes or versions of files involved that are only checked via signature or adding them to an SBOM,
• make use of gh attestation
• maybe trying to generate an SBOM
• maybe adding tests that run with ASAN and UBSAN and
• maybe trying to get rid of the C++ - while I don't think C++ is bad, I think that it adds very little value in its current use, but pulls in the libcpp, and the problem it tries to solve could be solved differently.

Additionally, I am already re-hosting the builds from this repo in tagged releases so we can pin them by hash in the "downstreams" I am involved in.

Somewhat related: The security considerations in type2-runtime look quite a bit better than the ones here. It is missing -Wextra, -Wconversion and maybe testing with ASAN and UBSAN as well though, which would all increase confidence in the correctness of the current code, any future code changes, and compiler compatibility. I do think the "one C file" requirement could be dropped by doing amalgamation in the Makefile, making it easier to test individual parts.