Date: Tue, 19 Jun 2018 23:21:04 -0700 From: "Simon J. Gerraty" <sjg@juniper.net> To: <cem@freebsd.org> Cc: "Stephen J. Kiernan" <stevek@freebsd.org>, src-committers <src-committers@freebsd.org>, <svn-src-all@freebsd.org>, <svn-src-head@freebsd.org>, <sjg@juniper.net> Subject: Re: svn commit: r335402 - head/sbin/veriexecctl Message-ID: <96021.1529475664@kaos.jnpr.net> In-Reply-To: <CAG6CVpV124ze%2BY6xX2ZFqbM%2B3hJNEJWR2qpnChpey=PmiW6qXg@mail.gmail.com> References: <201806200108.w5K18sIR050132@repo.freebsd.org> <CAG6CVpV124ze%2BY6xX2ZFqbM%2B3hJNEJWR2qpnChpey=PmiW6qXg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Conrad Meyer <cem@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 =E2=80=94 some files vary between space and t= ab > 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. >=20 > Some suggestions for a second attempt: >=20 > - 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?96021.1529475664>