Conrad Meyer <c...@freebsd.org> wrote: > First and foremost: nothing is actually signed, anywhere. The
The signing of manifests is external. The veriexecctl tool is I assume a straight copy of what's in NetBSD (I've not looked at it in at least a decade). A veriexec loader that leverages signed manifests requires some signing infra. That's a big topic all by itself. As I mentioned in my talk at BSDCan, the signing server we use is open source and handles pretty much anything OpenSSL can, as well as OpenPGP (and others). I also made a point of suggesting that the packages for base system include signed manifests. Tweaking the veriexec loader to only process manifests after verification is not hard - one of the first things I did when pulling veriexec into Junos almost 15 years ago. > As a corollary to the above, the name "signature file" is used > repeatedly in the code, which is misleading. The file contains hashes > (digests), not signatures (MACs). The file itself is unsigned. > Nothing about this has signatures. NetBSD refers to the hashes as fingerprints - AFAIK that terminology is retained. If the term signature is used to refer to anything other than the signed manifests that should be fixed. > There's absolutely no reason to use sha1 or ripemd in new designs. > These should be removed. Sorry I disagree - not with ripem (we never supported that or any of the non-NIST approved hashes), but sha1 is still approved by NIST for firmware integrity checks - which is what this is, and sha1 is cheaper than sha256. As I mentioned in my talk we've included support for sha256 for 10+ years, but do not plan to drop sha1 until NIST deprecate it for that purpose since boot time is a very sensitive subject for us. > The patchset is littered with style issues. One fairly obvious issue > is mixed indentation styles — some files vary between space and tab > indentation from line to line. You can probably blame me for some of that. I only recently found a style9.el that does a half decent job of formatting per style(9). > Please revert this patchset. It's not ready. > > Some suggestions for a second attempt: > > - Maybe use HMACs instead of raw hashes Why? > - Maybe sign the source-of-trust file We do. As noted above, we cannot upstream that until FreeBSD has suitable signing infra. > - Fix the style issues > - Fix the compiler warnings at 6 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
