On Wed, May 14, 2014 at 11:21:43AM -0400, Ted Unangst wrote: > On Wed, May 14, 2014 at 12:44, Stuart Henderson wrote: > >>> $ \time -l signify -C -p /etc/signify/openbsd-55-pkg.pub -x SHA256.sig > > moo-1.3p1.tgz > >>> Signature Verified > >>> moo-1.3p1.tgz: FAIL > >>> 65.83 real 31.48 user 34.32 sys > > > > This was due to malloc flags 'S' or more specifically the 'G' (guard > > pages) component of this. (yes, from 0.06s to 65.83s). > > There is a preposterously inefficient realloc loop used to parse > SHA256 files. As long as it's only checking the base checksums, it's > ok. Really, the feature was only added to make checking bsd.rd easier > when upgrading. > > It won't be hard to fix, but as also noted, the ports SHA256 format > isn't acceptable either. Now I have two problems...
There's no point in providing SHA256.sig for packages. For one thing, it goes out of synch rather easily. For another thing, it's redundant with the package signatures themselves. THAT SHA256 file exists only to make it easier to check that a transfer went out okay. It's not there to protect against any kind of malice... (Ironically, signify produces base64 signatures, but doesn't grok base64 sha256 checksums... may I lol ?) Doing any kind of check as to the integrity of the package repository would be a ways more complicated problem... we're getting close to the certificate revocation problem. That way lies madness.
