Thank you for responding, Theo :) On Thu, Aug 13, 2020 at (...):59 AM Theo de Raadt <[email protected]> wrote: > > the FAQ is wrong. > > Those images don't contain signatures because my build & sign > procedure does not have a way to sign something, then continue > building, then sign the result. > > > If you looked, you would see there is an unsigned SHA256 file. >
Yes, I opened the install ISO and I see. I also read the INSTALL.amd64 doc. Maybe change the FAQ to something like this? "[...] If someone were to make a rogue installation image, they could certainly change the installer to say the files were legitimate. Regardless, an unsigned SHA256 file is used by the installation to detect accidental corruption in the file sets. If the distribution sets do not match their recorded checksums, the installation program will complain." > > It already uses the SHA256 file to determine which files to install, > this is done, but a hash is not a cryptographic signature, so the warning > issued is accurate. > Maybe also rephrase the warning by the installer to something like this, to make it clearer to the admin that the installer does not skip verification *completely*: "Directory does not contain SHA256.sig. Continue without verifying authenticity? (The sets will still be verified against accidental corruption with SHA256.) [no]" > > Huh. What you are asking for cannot be done. And obviously a bogus > image would declare that it isn't bogus. > True, but I meant that if the ISO boots a BSD.RD file, then the ramdisk (booted from that exact file) would verify the checksum of that file, from the disc. Obviously not from RAM. It's not foolproof, and it surely doesn't help against malicious alterations, but I think this is better than not doing so...
