-
-
Notifications
You must be signed in to change notification settings - Fork 191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ISO signing GUI #1438
Comments
Some considerations. To me, providing gpg detached signature does both steps in one which was better, but OSes slowly stopped doing that. I will have to gather notes on that and replicate but i remember some kind if issue with busybox trying to support the alternative detached signed hash approach vs detach signing iso directly for user to be able to simply use hash file being signed. Just to note that providing hashes confirmation to the user to visually verify integrity and manually detach signing ISO requires two times processing ISO which are nomally big files. If going in that direction we might as well try to support validation against OSes provided digests and hack around busybox limitations, while detached signatures still provide authenticity and integrity validation. Distributions just now prefer to detach sign digests instead, which are smaller to verify instead of detach verifying against gpg, only because gpg was harder for users to verify, as opposed to sha256sum file that can visually be verified by the user. So detached signature validation is quicker verifying signature on hash file, exiting fast if bad, and then verify against the hash file. |
@JonathonHall-Purism i don't seem to find a hack to have gnupg output contain the 256sum calculated and be able to just prompt the user to confirm hash is as expected prior of accept created detached signature (otherwise deleting created detached signature at this point). That would be ideal but haven't found a way. Ideas? For some reason this doesn't work |
@tlaurion It seems like what we really want here would be:
But there's no way to do step 3, as far as I can tell - there's no way to have GPG create a signature for an already-known digest, it wants to digest the file itself. In theory maybe that could be added to GPG? Not sure though. Otherwise, only options I can think of:
BTW, your command above doesn't work because |
This is actually the other way I dog down. One option is to use the --debug 1024 option when you sign the file. This will write debugging data to STDOUT and show you the line containing the text SETHASH. This will be followed by the hash algorithm ID (8 for SHA256) a space, then the full hash. Dismissing the detached signature file seems the way to go in the sense that the hash is computed prior of signing so that output could be shown to the user for him to visually verify against hash files that sit alongside iso downloaded or can be compared visually on the host computer where the file was outputted. Not to be confused with supporting what other OSes are doing right now, which is to produce hashes and detached signatures of those hash files. That would deserve another issue. Tldr: the goal here would be to not hash two times the same file but once and producing hash to be outputted to screen to the user for the user to verify it visually prior of accepting the created detach signature, which is personal authenticity mark against manual integrity check. @JonathonHall-Purism you wouldn't consider accepting such implementation if implemented? |
@JonathonHall-Purism cannot do it that way. What we could do is try generating sha256sum files for iso and when confirmed by user detach sign the hash file and modify iso verification code to take into account presence of such hash files alongside iso. |
Yeah, based on what we both found this seems like the path of least resistance. |
Also supporting what other OS distributions switched to would be nice in the same effort See #1320 (comment)_ and next posts |
Something like this could cover it all (see table #1320 (comment)) :
To be tested and added properly in code base through PR. |
Interest for Ventoy restated at https://matrix.to/#/!RNcjJXCGHiyxXCHpKv:matrix.org/$oVg45lpw9Wev7EL3NTlgBGZin1C-NFVZ8YIAUeHlFU4?via=matrix.org&via=nitro.chat&via=matrix.3mdeb.com (Dasharo premier support channel: subscribers only) Should heads support booting from unverified ISO and support ventoy? #1320 (comment) |
That's two questions 🙂
I'd very much agree with supporting booting an unsigned ISO from Heads. This seems relatively simple. From a security and reliability standpoint, that's no worse than booting raw USB (dd'ed image), there's no integrity or authenticity check. Many distributions have integrity checks built into the ISO itself as well (though that's not an authenticity check, and they don't all do it in the default boot option). If we supported that, then AFAIK there would be no benefit to using Ventoy on Heads. Heads could do what Ventoy does, as I understand it. If there are other benefits to using Ventoy though I'd be happy to understand them, that's just what I gathered from reading about it.
I believe that actually being able to boot Ventoy from Heads would be a monumental effort. Ventoy is not an ELF executable or anything that we can kexec. It's a BIOS and UEFI bootloader (both provided). Booting that is not trivial because we do not have either BIOS or UEFI services available when Heads is executed as coreboot's payload. If we supported booting unsigned ISOs, there's little benefit of actually supporting Ventoy (correct me if I am wrong), so the cost/benefit analysis doesn't make sense to me. That said, being able to boot a BIOS or UEFI payload may have other advantages (we could actually invoke GRUB instead of trying to reimplement it, etc.). It's still a monumental effort, but it would eliminate large swaths of compatibility issues, maybe that could justify the cost. |
Rediscussed today at on matrix channel ar 👆 could deal with the 3 additional cases discussed in main channel today :
@JonathonHall-Purism comments? |
We could have a "signing GUI" to sign an ISO with your key. Potentially this could also allow configuring which OS keys (if any) are trusted for ISO signatures, which integrates nicely with Restricted Boot.
Ideally, this should verify the ISO against sha256sums on the device while signing, or otherwise present the sha256 to the user for verification.
Original discussion: #1419 (comment)
The text was updated successfully, but these errors were encountered: