Dan Peretz <dan.peretz...@gmail.com> wrote: > Thank you for responding, Theo :) > > On Thu, Aug 13, 2020 at (...):59 AM Theo de Raadt <dera...@openbsd.org> 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."
I disagree with your direction. You are now explaining to someone how to create invalid images, rather than > > 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]" I disagree. I think it is good enough the way it is. I don't think People need to know all the details behind a warning. > > 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... What you describe cannot be done. You aren't thinking critically.
