Input Examples and Hardware-Free Tests

example/input.json is the production input template. Its empty slotIds list enables automatic token-present slot discovery. To restrict scanning, use a list such as ["0", "1"]. Replace the host, PIN, and certificate/key placeholders with registered Luna client credentials before running against hardware. The empty state reflects full scans; the plugin does not implement incremental scanning.

example/input-mock.json is consumed by TestMockScanEnumerationAndEmission. It demonstrates an explicit two-partition filter and the shared PIN using deliberately fake credentials. The test injects the in-process PKCS#11 mock, validates the example configuration, and exercises partition scanning and streamed output without Luna hardware or the vendor library.

Run from go-modules:

go test ./luna-hsm-plugin -run '^TestMockScanEnumerationAndEmission$' -count=1

The mock input is a test fixture, not a production plugin mode: passing it to the plugin binary does not select a mock provider. SoftHSMv2 end-to-end coverage is not implemented, so no runnable SoftHSM configuration is claimed here. This mock test does not verify NTLS, client registration, PED authentication, or real Luna firmware behavior. example/output.txt contains representative line-delimited results for all five asset types, not the limited mock fixture's expected output.

Partition Failures

Successful automatic discovery with no token-present slots completes as an empty scan with the normal final state. Connection tests still require at least one usable partition; slot-discovery errors remain failures.

Scanning continues with remaining partitions after a partition-local failure, such as an unavailable slot, a rejected PIN, or an enumeration failure. Results from healthy partitions are emitted, but the final result reports an incomplete scan with the failed partitions' host and slot IDs; no success state is emitted. Output-write failures stop the scan immediately. Connection tests remain fail-fast.

Resource Identity and Compatibility

Resource IDs use host/token-serial/object-class/object-identity, regardless of the slot filter or number of discovered tokens. When a token serial is absent, the partition component is slot-N; token labels are not used because they may be duplicated or renamed. Serial-based identities survive client slot reassignment. Slot-based fallback identities require stable client slot numbering. Token serials must uniquely identify partitions on the configured host.

The object identity priority remains CKA_ID, unique ID, DER fingerprint, then label hash. These resource IDs feed asset URNs and URLs.

The original single-slot implementation generated serial-based IDs as host/serial/object-class/...; these IDs are preserved and require no serial-based migration.

The intermediate feature-branch implementation in commit 53bfe9f added host/serial/slot-N/... only for multi-slot scans. Deployments that ran this intermediate code can have those IDs; they change once to host/serial/... after the stable-identity fix in commit 21539386. This format was not emitted by the original single-slot implementation. Earlier IDs based on token labels or bare slot numbers also change once to the host/slot-N/... fallback when the serial is absent.

This plugin does not rename or delete previously stored assets, emit legacy aliases, or automatically reconcile history. Reconciliation is needed only for assets whose IDs change: first confirm the deployed build and stored ID format, then reconcile or retire affected old IDs through the downstream inventory's supported workflow. Otherwise old and new assets may coexist until reconciled. Do not simply strip slot components when serials are duplicated; verify partition and object identity first.

Requirements

• Luna client registered with the HSM appliance
• Read-capable partition credentials (PIN)
• Network connectivity to Luna appliance on port 1792 (NTLS)