A customer is waiting for a new version of S3Guardian. The need sounds simple: replicate the data, install updates without losing control, and be able to verify what was delivered. For the team that develops and maintains the program, that request still crosses several worlds: code, tests, delivery decisions, installation and support.
Between those steps, information scatters easily. A commit describes a fix, a report confirms a test, a ticket explains a decision. A few weeks later, finding out why a version was delivered, what it contained and what was actually installed becomes an investigation.
The scenario that brings together KARL Git, KARL Core, KARL Signing, KARL Evidence and KARL Support is about keeping that continuity, then extracting evidence the customer can verify independently.
A fix starts with a fact that can be reproduced
Take a concrete incident: during replication, an interruption leaves an incomplete file at the destination. The customer opens a case in KARL Support. They state the S3Guardian version in use, describe the circumstances and provide what is useful for the investigation.
The case grows step by step. Support records the observations, separates facts from hypotheses and ties the attempts to the reported problem. A first lead is abandoned. A second one makes it possible to reproduce the behaviour.
That distinction matters. A hypothesis written in a ticket must not become, merely through the passage of time, a demonstrated cause.
KARL Core acts here as a durable, governed memory layer. It keeps the events and references needed to recover the context: which state of the program was involved, which items were recorded, by whom and in what order. This memory covers the information that was actually captured; it does not reconstruct operations that stayed outside the path.
From diagnosis to a code change
The development team picks up the case in KARL Git. It links the fix to the identified problem and prepares a test that can reproduce the incident.
Before the change, the test fails. After the fix, it passes. Further tests check that the change has not degraded ordinary replication, resume after interruption, or error handling.
The useful results join the version record. The commit brings the change; the tests explain what was checked. The decision to keep this fix is recorded, together with any reservations.
The link between KARL Git and the KARL Core memory makes it possible to follow that progression without reducing the story to the final state of the repository. The original problem, the fix that was retained and the information available at the time of the decision can be found again.
This does not mean the program is free of bugs. It makes it possible to say precisely which fix was made and which checks the delivery rests on.
Before delivery, freeze what is handed to the customer
The version is ready. The team gathers the program to distribute, the code references, the test results and the version information. The fingerprints of the deliverables identify the exact files involved.
KARL Evidence assembles these items into a release evidence pack. It computes the fingerprints of the pieces and prepares a manifest that describes the pack contents. Once that manifest is frozen, KARL Signing applies the signing policy defined for this use.
The responsibilities stay distinct. KARL Evidence builds the exportable record. KARL Signing selects the authorised key and provider, then performs the signature. KARL Core keeps the governed memory of the path from which the applications selected the items.
Note:
- The cryptographic choice has two levels.
- Ed25519 and RSA-PSS-SHA256 are signature algorithms.
- PKCS#11 is an interface for communicating with a cryptographic provider.
An organisation can therefore use a software provider, or choose a provider reachable through PKCS#11, according to its policy and the mechanisms supported. FreeHSM v2.3.1 (Apache 2.0 licence), developed by Afchine Madjlessi, is a software option selected for this connection in the Evidence Pack.
Using PKCS#11 does not, by itself, mean that the keys are protected by hardware. In every case, the private key stays on the signing provider's side: it is not included in the pack given to the customer.
Following the installation
The customer receives the S3Guardian version and the pack associated with the delivery. The installation can then be followed in KARL Support.
The operator records the installed version, the operations performed and the results of the acceptance tests. The selected information must be useful as evidence without unnecessarily exposing secrets or the customer's data.
If unexpected behaviour appears, the case stays open. Observations and further interventions extend the chronology. The initial delivery keeps its identity; a later fix becomes a new version, with its own evidence.
When acceptance is complete, the customer's validation can be recorded with its context and its scope. It does not turn the tests that were run into a universal guarantee: it states what was accepted in that environment.
KARL Evidence can then produce a second pack, devoted to the installation. It references the delivered release and gathers the items retained to document its installation and validation.
The two packs answer two different questions: what did we deliver, and what did we install and check at this customer's site?
Verify without depending on the supplier
The customer keeps the packs and can pass them to an auditor. With KARL Evidence PACK and a verifier compatible with their format, they check the fingerprints of the pieces and the signatures on a disconnected machine.
They need the public material required for verification, and trust anchors approved separately. A key present in a pack does not become trustworthy merely because it appears there.
This verification requires neither a connection to KARL Core, nor access to KARL Git or KARL Support, nor a private key, nor a FreeHSM instance. The report states the checks that succeeded, the anomalies and the points that remain undetermined.
Historical formats and the new common format must still be distinguished: this path assumes choosing the verifier suited to each pack.
The customer thus has a documented story, from the reproduced problem to the installed version. They can examine the retained items and check their integrity without depending on permanent access to the supplier's services.
The signature does not prove that a diagnosis was right, or that software contains no defect. It makes it possible to verify that the items presented are the ones sealed with the identified key. On that precise basis, the conversation between developer, support and customer becomes more solid.