Adding some folks who are helping gk with various elfsign problems ... On Mon, Apr 23, 2007 at 09:46:20AM -0400, Richard Lowe wrote:
> J?rgen Keil wrote: > >Seems I found something; I wrote > >>Problem is that after the bfu, elfsign fails verification > >>for the kernel module /kernel/crypto/arcfour. This > >>breaks WEP support for the wlan driver "ipw", and it seems > >>as a result of this, my machine was unable to boot into multiuser mode (the > >>kernel complains about /kernel/crypto/arcfour > >>module verification errors). > >> > >> > >>I'm seeing errors like this: > >> > >># elfsign verify -v /kernel/crypto/arcfour > >>elfsign: verification of /kernel/crypto/arcfour failed. > >>format: rsa_md5_sha1. > >>signer: O=Sun Microsystems Inc, OU=Solaris Cryptographic Framework, > >>CN=SunOS > >>5.10. > >.. > >>Question is: how do we bfu upgrade to newer onnv > >>bits? Is the certificate file /etc/crypto/certs/SUNWObjectCA > >>invalid? > >The problem is that the opensolaris mercurial repository > >doesn't have the SCCS keywords expanded any more: > >http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/cmd-crypto/etc/certs/SUNWObjectCA > >Note the ident "%Z%%M% %I% %E% SMI" line in this > >file. Problem is that /usr/lib/libelfsign.so.1 has the > >MD5 checksum of both /etc/crypto/certs/CA and > >/etc/crypto/certs/SUNWObjectCA compiled into the libelfsign.so shared > >library > >and the code refuses to > >use these certs if their MD5 checksum doesn't match > >the compiled-in values: > >% strings - /usr/lib/libelfsign.so.1 | /usr/xpg4/bin/grep -E '^[0-9a-f]{32}$' > >4ede9ecb4868c0d2683b602f71596085 <<--- MD5: "SUNWObjectCA" > >2646d63d62617aeae629d85cbd5daefc <<--- MD5: "CA" > >% gmd5sum /etc/crypto/certs/CA /etc/crypto/certs/SUNWObjectCA > >2646d63d62617aeae629d85cbd5daefc /etc/crypto/certs/CA > >a8e0f35c570d3b379424f99f8ef5d409 /etc/crypto/certs/SUNWObjectCA > > Ok, if this is the cause this is going to be problematic. > > The obvious fix would be for the closed bins to be built with usr/src get > -k'd, > but I suspect that would break something else instead > > The other obvious fix would be to hotwire the bridge to not get -k the > affected > certs, that's bogus. > > This always had the chance for explosive failure (since various crypto bits > were/are pulled from the last build, as they had to be RE signed), but we'd > been getting somewhat lucky (I, apparently, still am, this isn't biting me). > > I've Cc'd both people who should be familiar with the closed-bins build, > perhaps they see a way to make this not explode? > > -- Rich > > _______________________________________________ > tools-discuss mailing list > tools-discuss@opensolaris.org _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
