This flag indicates a failure in a token self-test.
See: PKCS#11 2.40, Table 6

Signed-off-by: Keith Koskie <[email protected]>

Signed-off-by: Keith Koskie <[email protected]>

Signed-off-by: Keith Koskie <[email protected]>

Give the SlotInfo struct its own member definitions
instead of being a wrapper around CK_SLOT_INFO. This
causes the conversion for each memmber to happen once
on construction.

Signed-off-by: Keith Koskie <[email protected]>

Using the From trait here is both more flexible and also
a better semantic match for how SlotInfo is constructed.

Signed-off-by: Keith Koskie <[email protected]>

These functions differ only in a boolean. Them being
distinct is even less necessary since they've been
accessed through parent module stubs.

Signed-off-by: Keith Koskie <[email protected]>

Fixes parallaxsecond#34 with respect to slots (still open for mechanisms)

Signed-off-by: Keith Koskie <[email protected]>

Flags being accumulated into an integer is an
implementation detail that has no significant
meaning to its consumers. Instead, expose the
information from the flags as booleans.

Signed-off-by: Keith Koskie <[email protected]>

Information from SlotFlags is now available through
SlotInfo, the only type that uses it. It's also
a read-only value. The PCKS#11 provider sets these
flags to be read, but setting the flags on the client
side at best has no effect, and at worst is misleading
about how the slot can be properly interacted with.

Signed-off-by: Keith Koskie <[email protected]>

This commit is the first of several with the end goal of
removing Flags types from the public interface. It makes
several design changes.

* Type state information encoded into an integer as flags is now
  exposed publically as booleans only.
* The boolean values are read and/or written through the structure
  that contains the flag integer value. They do not exist as
  distinct entities, but as features of their outer type.
* Flags are now type-bound to their container. Even though the
  CK_FLAGS type still backs them all, flag sets associated with one
  structure cannot interact with flags from a different structure.
* Operations on the generic flag type are restricted to those
  required to set, unset, toggle, and test the values as needed
  by their outer types. These operations are limited to avoid common
  errors while still having the terseness of binary oprations.
* Debug implementation for flags that display the full contents
  of the flag set as through it were a 'Flags' struct of named
  booleans.
* Display implementation for flags that display only the relevant
  attributes as a set of string labels.

Signed-off-by: Keith Koskie <[email protected]>

This replaces the prior documentation of SlotInfo members with
wording from the standard itself. It also adds a crate-level
Conformance Notes to provide context about documentation that
would otherise have the appearance of a guarantee issued by
this crate.

Signed-off-by: Keith Koskie <[email protected]>

Signed-off-by: Keith Koskie <[email protected]>

Signed-off-by: Keith Koskie <[email protected]>

Signed-off-by: Keith Koskie <[email protected]>

This take the three previously refactored info+flag types
and moves them together.

Before, the flag types had to reach into their parent module to bring
their associated info type into scope, while the info type had to do
the same in the other direction. While this is legal, the tighter
coupling made it natural to place them together.

This has a side effect that all FlagBit constants can be made private
within the new files.

slot/{mod.rs:SlotInfo,flag.rs:CkFlag<SlotInfo>} -> slot/slot_info.rs
slot/{mod.rs:TokenInfo,flag.rs:CkFlag<TokenInfo>} -> slot/token_info.rs
mechanism/{mod.rs:MechanismInfo,flags.rs} -> mechanism/mechanism_info.rs

Signed-off-by: Keith Koskie <[email protected]>

Signed-off-by: Keith Koskie <[email protected]>

Function added to support unit testing

Signed-off-by: Keith Koskie <[email protected]>

Signed-off-by: Keith Koskie <[email protected]>

Having a human-readable format for the flag types seemed like
a good idea initially. They were more compact than the Debug
equivalents and had the flexibility of rephrasing for clarity.
However, the format for these outputs was somewhat arbitrary
which makes them potentially unstable.

But most importantly, they were for a private type and served
no purpose within the crate.

In order for them to be usable in client code, the Display trait
would need to be implemented on the containing info type as well.
Again, the arbitrariness of the output presents concerns about
fragility in client code, and there's no obvious use case that
Debug can't also serve.

This commit will be left behind rather than squashed out in case
it becomes useful to revert.

Signed-off-by: Keith Koskie <[email protected]>

Signed-off-by: Keith Koskie <[email protected]>

Signed-off-by: Keith Koskie <[email protected]>

Designs considered and rejected for TokenInfo::utc_time() return type

* Option<String> of 14 original non-pad characters. This option is
  simplest but is an annoyance to anyone who wants to do anything
  except print. It might even be annoying to those people too.
* Option<String> using ISO 8601 formatting. A step up in usability
  since it's common enough that most external tools already know how
  to parse it. However, it also implies additional constraints and
  guarantees from the ISO standard that PKCS#11 doesn't. Even with
  doc warnings it felt like a bad idea knowing how little validation
  is happening behind the scenes.
* Option<(u16,u8,...)> tuple with the six parsed numerical fields.
  Serves the goal of not having custom types beyond necessity, but
  it's just too big to get away with unnamed std types only.
* An Option<chrono::DateTime> or similar. Like ISO, appears to provide
  guarantees that PCKS#11 doesn't. Also, it would require assuming a
  specific notion of valid value ranges (e.g., January is month 0 or
  1) beyond the specification that could report conformant strings as
  invalid.

The final choice was a simple new type with minimal integral members.
The members are made public so there's no need to implement getters.
This is fine because mutating the struct is meaningless; it's not used
as an input anywhere. The ISO formatting remains minimally present in
the Display trait implementation, which provides much of the
convenience of that format while weakening association with the ISO
standard by not being the type's primary representation in code.

Signed-off-by: Keith Koskie <[email protected]>

In the initial implementation, any parsing error was silently
converted to None, which indicates the token doesn't have a clock.

Signed-off-by: Keith Koskie <[email protected]>

Signed-off-by: Keith Koskie <[email protected]>

There are only two flags supported as arguments when opening a
session.

One of them must always be true, but perversely defaults to false.
This forces client code to construct a trivial value to pass. This
commit now hides this flag, setting it to its only valid value always.
This also removes a single test which checked for failure when the flag
was set to false.

With only one flag (read/write) remaining, the open session call now
accepts a boolean for the option and conversion to a wider integer
type is handled internally.

Signed-off-by: Keith Koskie <[email protected]>

This type is no longer used after the previous two commits.

Signed-off-by: Keith Koskie <[email protected]>

This type is now an rust enum which better matches the type's intended
behavior.

Signed-off-by: Keith Koskie <[email protected]>

This is only two flags, one of which isn't supported yet, and the
structure itself was effectively private despite having pub
visibility.  Because the initialization APIs need considerable
attention outside the scope of this branch, the change avoids
any elaborate redesign and just falls back to using raw CK_FLAGS.

Because this is the last use of the Flags trait, it is also removed.

Signed-off-by: Keith Koskie <[email protected]>

Suggested during review to both improve discoverability and make the
non-association with ISO more explicit.

Signed-off-by: Keith Koskie <[email protected]>

The CkFlags type was written under the assumption that it would be
part of the public API and would benefit from being bound (via
generics) to the struct that contained each flag group. But the final
API ended up keeping flags types private. With full control against
incorrect usage being internal to the crate, CkFlags offers no benefit
over bitflags, which is well established for this use case.

bitflags auto-implements the Debug trait for its structures, which
led to the corresponding tests being updated or deleted.

Signed-off-by: Keith Koskie <[email protected]>

In particular, it

* removes a lot of unnecessary interaction with ffi types,
* removes the flags from the public API,
* flattens the contents of CK_INFO into the struct,
* moves individual field conversions out of public getters into a
  one-time, struct-level conversion, and
* makes conversion from CK_INFO fallible.

Signed-off-by: Keith Koskie <[email protected]>

Signed-off-by: Keith Koskie <[email protected]>

Signed-off-by: Keith Koskie <[email protected]>

A silly mistake on my part. The token may not have a clock,
so returning an Option is appropriate. But that designation
was improperly split between the conversion function and the
getter for the token. This removes the option from the
conversion into the getter.

Signed-off-by: Keith Koskie <[email protected]>

This function was added in 5bb40c6 to support unit testing
but does not need to be public. Because it's only used
during testing, it triggers a dead code lint unless limited
to cfg(test).

Signed-off-by: Keith Koskie <[email protected]>

Signed-off-by: Keith Koskie <[email protected]>