AppImage
Improving supply chain / confidence
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[^1] - 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.
[^1]: Compromised SSL certs, compromised infra and compromised repositories could all lead to compromised files being fetched.
I agree with most of what you write. I've been telling the same for years. But these things take time and require a lot of effort. I've spent a lot of time already on getting to a point where all of this is possible, but actually implementing them again takes time. This "AI" (LLM) generated PR does not really inspire a lot of confidence with me, and adds a lot of overhead that should(!) have been discussed before (e.g., I do not think it is worth generating an SBOM, as it might be more of a topic for corporate/commercial use, needs to be kept up to date, and I do not want any liability for the correctness of this either).
Since this is already being "worked" on without any further discussion, I don't think I want to spend time actually getting into this. At the same time, I won't be spending time on reviewing this LLM PR. Just assigning stuff to Copilot is very annoying to me: it wastes energy, it needs a lot of back and forth, and the outcome still(!) needs to be reviewed by experts.
And don't think that this is because I'm generally sceptical of LLMs: while that contributes, it is the order of things that is problematic. First, you discuss what you want to have. Then(!), you can start "working" on it. I would have appreciated talking about the pros and cons of the points you brought up...
I personally would not have suggested letting AI do it, but I am also not against trying. I left a comment about my opinions in the PR.
SBOM would be the way to document which dependency this pulls. As for legal implications, while not a lawyer, I think the LICENSE document already (tries to) cover this. The reason I suggest sbom in a recognized format (in contrast to urls in a bash script) is that it allows you to query a vulnerability db. Nothing to do with corporate.
While I may end up suggesting AppImage at work, my motivation is the growing user base of the two bigger FOSS projects I am involved in that use AppImage because it simplifies distributing multiple versions of the builds at the same time.
The reason I suggest sbom in a recognized format (in contrast to urls in a bash script) is that it allows you to query a vulnerability db. Nothing to do with corporate.
I see. Legitimate reason. Thanks for clarifying. What format do you have in mind?
SBOM would be the way to document which dependency this pulls.
If it doesn't have to be recursive, it would be somewhat easy to do.
I had little to do with it so far, but I believe Cyclone DX JSON looks the most promising.
The format itself seems a bit complicated at first, but basically you have one top level component that is the software you generate the SBOM for, a list of other components (that the software depends on) and then a list of dependencies (that link components to each other). Almost all fields are optional and you have multiple ways to refer to the upstream (name + version, cpe, purl, ...).
The interesting SBOM would probably be for the appimagetool-*.AppImage, that should include the runtime and the contents of usr/bin with all statically linked libraries, which I agree sounds a bit hard to manage, but there is a thing called "composition", which has a property "aggregate" that allows you to specify that the dependency graph may be incomplete. The question then becomes how much you want to specify for a scanner to be useful.
So, e.g. you can say the AppImage is complete, but you did not specify the dependencies of desktop-file-validate, mksquashfs and zsyncmake.
Well. Truth be told, I just wanted to try out whether Copilot can be useful to help on this kind of non-functional maintenance tasks, which are not something I enjoy to work on in my limited free time.
So @TheAssassin if we think that overall this PR is not worth iterating further, then we can close it.
If, however, we think that with some manual improvements it could go somewhere, then anybody is free to take it up and refine it until we think it is useful. Or create another PR without the help of AI. Either way would be fine with me.
Thanks!
