Subject: -current config(8) + files.opencrypto == cryptographic roulette?
To: None <email@example.com>
From: Rafal Boni <firstname.lastname@example.org>
Date: 11/21/2003 21:34:43
I just tripped over some build lossage which appears to be due to
the addition of opencrypto (well, at least the config glue) to the
Here's what happened:
* Not having updated since ~ the end of September, I
did a 'build.sh tools kernel' to update tools and
build a new kernel for my x86 desktop box. I used
the same config file as always, which produced the
currently-running kernel (1.6ZC).
* The kernel failed to link due to missing cast128
symbols; investigation shows that the cast source
files were simply not emitted into the Makefile
by config(8) [actually by the TOOLDIR's nbconfig].
* Further attempts at re-running both the installed
config(8) and the TOOLDIR nbconfig lead to Makefiles
which were sometimes missing the DES sources, the
Blowfish sources (or again, the CAST128 sources), or
the Rijndael sources.
My suspicion was on the OpenCrypto changes, since that was the
last major thing that should have touched the crypto code. On
a hunch, removing the inclusion of 'files.opencrypto' from sys/
conf/files actually led to a kernel compile which included all
the crypto algorithm code (it didn't build since now there was
no 'opencrypto.h', but creating an empty opencrypto.h made it
go and build succesfully).
The culprit appears to be the clash of crypto attributes in
files.opencrypto vs. files.ipsec (I'm running without open-
crypto or fast-ipsec, but with IPSEC, IPSEC_ESP and IPSEC_
DEBUG)... I haven't done much more digging but figured I'd
report it here before someone else lost some hair. I'll file
a PR if nobody has fixed this already (or convinces me that
the lossage is specific to me).
Rafal Boni email@example.com
We are all worms. But I do believe I am a glowworm. -- Winston Churchill