> Richard Lowe wrote: > Beyond all that, I *still* can't figure out why this > isn't blowing up on me...
You need a recent on-closed bits archive to reproduce the problem; so far on-closed-bins-20070409.i386.tar.bz2 seems to be the only on-closed-bins archive that has the extra check in /usr/lib/libelfsign.so.1 to reject certificates with unexpected MD5 checksums. The extra check can be found in function libelfsign.so.1`_C01A7B0E; after calling _C01A7B0C the return value for _C01A7B0C is now checked; in previous libelfsign.so.1 libraries the return value from function _C01A7B0C was ignored, it seems. Btw. for some reason the on-closed-bins-20070416.i386.tar.bz2 archive is missing on http://dlc.sun.com/osol/on/downloads/current/ ? But I guess it still contains the MD5 checksum test. on-closed-bins-nd-b61.i386.tar.bz2 doesn't reject cerificates with unexpected MD5 checksums - so the problem wasn't noticed with older on-close-bin bits. > Juergen, is there anything at all strange about the > way you're doing things? I'm using the centrino ipw driver, which needs RC4 encryption. It tries to initialize the kernel RC4 support early during ipw driver attach time. For kernel RC4 encryption, this tries to load the /kernel/crypto/arcfour module - but the module fails to load in case the MD5 checkum of /etc/crypto/certs/SUNWObjectCA isn't the one compiled into libelfsign.so.1 And I'm actually compiling my own bfu archives from source. This message posted from opensolaris.org _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
