Age | Commit message (Collapse) | Author |
|
Apple, for reasons unknown, chose not to implement SOCK_SEQPACKET.
This works on Linux and *BSD, and libhal's MUX daemon uses it to avoid
having to add its own framing protocol on top of SOCK_STREAM. So, at
least for now, Mac OS X will not support the multiplex daemon, only
direct connection to the HSM by a single client.
|
|
{session,token}_object tables to preserve the mapping from pkcs11 token
objects to libhal pkey objects.
|
|
${foo_BLD} Makefile cleanup.
|
|
really need it for libpkcs11.
|
|
|
|
|
|
The Mac OS X build compiles, but is otherwise completely untested, and
won't even be testable until cryptech_rpcd support configuring
high-speed UARTs on Mac OS X (OS-specific voodoo).
|
|
|
|
tweaks Lintian wanted.
|
|
garbled reports if a test fails.
|
|
Disable 3416-bit RSA key generation tests while we sort out whether
simply padding the modulus out to the next 32-bit boundary is
sufficient to support these with ModExpS6/ModExpA7.
|
|
|
|
|
|
* Don't modify the wheel PIN unless specifically requested
* Don't try to run the Novena RPC test server (or any server) by default.
Still need to rewrite some of the RSA key tests, particularly the
external key load test, to conform to known implementation constraint
that key length must be a multiple of 32 bits; deferred until we
switch back to hardware modexp, as this won't matter until then.
|
|
|
|
|
|
|
|
|
|
|
|
key is a session object. Doesn't actually save us anything, but Jakob
tells us that this makes a difference on some HSMs so we people use
this kind of setup and we need to support it.
Explicitly disallow private keys as session objects, since we have no
way to protect them. Update unit-tests now that we return the correct
error code for this case.
|
|
|
|
keys to be stored as session objects, so test that doing so fails as
expected, and update other tests to specify CKA_TOKEN = True.
|
|
|
|
created by earlier keypair.
|
|
token, since we just demonstrated (the hard way) that testing only one
is not sufficient.
|
|
|
|
in handle lookup code.
The mapping between PKCS #11 objects and libhal handles isn't quite
right yet. This is a snapshot of bugfixes accumulated along the way,
before refactoring mapping code to deal with the underlying problem.
|
|
Error handling and hte underlying functions and macros that support it
will probably change a bit more as it goes along. Trying to strike
the right balance between having the main code be readable and having
the underlying support code be at least comprehensible and
straightforward to review.
Also need to address current over-use of CKR_FUNCTION_FAILED.
|
|
|
|
|
|
|
|
|
|
Turns out that the one remaining old PKCS #11 unit test we weren't
passing was a broken test: code was correctly rejecting CKA_ID
conflicts. Rewrote test, and added test setup code to use separate
client and server keystores when using the ks_mmap keystore driver.
|
|
At this point we are passing most of the unit tests in RPC loopback
mode. Remaining failure is TestKeys.test_keygen_token_vs_session(),
which gets HAL_ERROR_KEY_NAME_IN_USE when attempting to generate a
session key and a token key with the same CKA_ID value, so clearly
something is not quite right yet in the keystore selection logic.
|
|
|
|
|
|
defaults.
|
|
automatically if present.
|
|
|
|
libhal RPC API takes RSA key lengths in bits, not bytes.
Insisting on receiving matching CKA_ID in both public and private
templates on key generation is probably unwise, so back down using
CKA_ID from private template if provided, otherwise from the public
template, and only raise incompete template error if both are missing.
|
|
|
|
"p11util" is now something of a misnomer, since there's no longer
anything about it that's specific to PKCS #11. Probably should become
a libhal utility program, eventually.
|
|
This version isn't really expected to work properly, but it's far
enough along to be worth archiving before starting runtime testing.
|
|
So far this is just dumb little things like changed names for old data
types and functions. Changes to use new API features will come later.
|
|
|
|
anything particularly clever with the new capabilities (yet).
|
|
|
|
|
|
|
|
|