[vharseko]

Fixes #339. Fixes #372. Fixes #373.

Resuming a file with no event since the last rotation

After a rotation, the live file holds the header and the signature chained from the archive. CsvSecureVerifier kept that signature for the chain but did not count it as a final signature, so the file failed with Missing final signature, and SecureCsvWriter could not resume it after a restart. The signature chained into row 2 now counts as the final one until an event follows. A file truncated to these two rows after later events is still rejected, as the current key in its keystore no longer matches.

Signatures around a rotation

SecureCsvWriter now tracks whether events were written since the last signature, and signs only then:

• A rotation signs them whether or not the scheduled signature could be cancelled. When the event that rotated the file was the first one since a periodic signature, no signature was scheduled yet, and the archive ended with that event unsigned: Final HMAC key doesn't match expected value (Tamper-evident CSV audit: an archive rotated by the first event after a periodic signature ends unsigned #372).
• No signature is written or scheduled with no event to cover. After a rotation on write, writeEvent() scheduled a signature that close() wrote into the new file over the last HMAC of the previous file, which the new file does not hold, so it failed at row 3. This is the failure that shouldRotateCsvAndKeyStoreFile asserted for its last archive (CAUD-225), and such a live file could not be resumed either.
• A rotation before any signature, by the rotate action or by a time-based rotation of a topic with no event since startup, leaves the new file empty instead of writing an empty chained signature (,,), on which the verifier threw a NullPointerException when the writer resumed the file.
• The header goes in the same write as the first event. Written on its own, it could rotate the file when a time-based rotation was due, and that rotation had no event to sign: the archive held only the header and failed with Missing final signature, and the event went into the new file without a header. This is likely after a restart over the empty live file that the rotation above leaves: its modification time counts as the last rotation, and the first event can come before the first rotation check.

A second close() does nothing. As close() now always runs the signature step, which flushes the writer, a second call with rotation threw IOException: Stream closed.

An event written while the periodic signature completes

writeEvent() scheduled a signature only when the scheduled one was done. The periodic task releases signatureLock and flushes the writer before its FutureTask is done, so an event written in this window scheduled none, and stayed unsigned until the next event, a rotation or close() (#373). A process killed meanwhile left a live file that failed verification at the next start.

The writer now keeps the scheduled task until it starts signing, in pendingSignature. writeEvent() schedules a signature for unsigned events when no task is pending, and a task clears pendingSignature once it holds the lock, before it signs: an event written after that comes after its signature, and schedules the next one, whether the task is done or not. A rotation or close() that cancels the scheduled task clears it too.

A task clears pendingSignature only if it is that task. cancel(false) returns true for a task that has started and waits for the lock, as a FutureTask stays NEW until its run() returns, and the task still runs. With a plain flag, this gives the interleaving that #373 notes: an event schedules a second task, the first one clears the flag when it gets the lock, and the next event schedules a third; close() cancels only the last one, and waits for the second up to the signature interval. The signature task is now one SignatureTask per schedule instead of one shared Runnable, so that a task can tell whether it is the pending one.

Verifier

CsvSecureVerifier also:

• accepts an empty file whose keys match, as the rotation above archives one;

  This replaces the rule of [#331] Tamper-evident CSV audit: verify compressed archives, rename the keystore on the rotate action #332, which rejected every file without a header: a file truncated to nothing after events still fails, as the current key of its keystore moved on. CsvSecureVerifierTest.shouldNotVerifyEmptyFile now asserts that failure reason.

• rejects a row 2 signature that is not base64;

• rejects a signature row that holds other values: the data and HMAC columns of signature rows were not checked, so an event could be written into them;

• reports a row with neither an HMAC nor a signature as an incorrect HMAC instead of throwing.

Tests

• SecureCsvWriterTest: resuming after a forced rotation and after a rotation on write, an event that rotates the file after a periodic signature, a rotation before the first event, a file truncated to the chained signature, a malformed or empty chained signature, signature rows that hold other values, a first event whose write rotates the file, a second close(). shouldRotateCsvAndKeyStoreFile now expects every archive and the live file to pass, with the plain and the .gz suffix; it has 5 archives instead of 6, as the 6th came from the redundant signature of close().
• SecureCsvWriterTest.shouldGenerateHMACColumn has a 60 s time-out. It fails when unsignedEvents is cleared after the signature row is written instead of before: that row then schedules another signature, and close() waits for it for the whole signature interval.
• SecureCsvWriterTest, for Tamper-evident CSV audit: an event written while the periodic signature completes stays unsigned #373:
  • shouldSignAnEventWrittenWhileThePeriodicSignatureCompletes: the writer's flush(), which writeSignature() calls once the signature row is written, writes a second event the first time it runs. A signature must follow that event, and the live file must pass verification while the writer is still open. With the isDone() condition it fails: no second signature within 10 s.
  • shouldSignPeriodicallyAnEventWrittenAfterARotationCancelledTheScheduledSignature: a forced rotation cancels the scheduled signature, and the next event must get a periodic one. It fails when the cancel leaves pendingSignature set.
  • shouldScheduleNoOtherSignatureWhenARotationSignsWhileTheScheduledOneWaitsForTheLock: the test holds the lock until the scheduled signature waits for it, rotates and writes events, and close() must return in less than half the 3 s interval. When a task clears pendingSignature whatever it holds, close() takes 2.7 s.
• CsvWriterTest.shouldCreateNewAuditFileAfterRotation verifies the live file, in place of a commented-out TODO.
• The temporary directories of the SecureCsvWriterTest tests this PR adds or changes are under target.

Each fix was disabled in turn, and its test failed. audit/core and audit/handler-csv pass locally, and SecureCsvWriterTest passed 5 runs in a row.

Known limits

• The signature chained into row 2 is not authenticated: a live file with no event since the rotation passes with any base64 value there. No tool checks the link between files (CsvSecureArchiveVerifier verifies each file on its own), the row can hold no event, and a truncation is caught by the keys.
• Files written by earlier versions with a signature over the HMAC of the previous file at row 3, or with an empty chained signature, still fail verification: the first needs the HMAC of the previous archive, the second holds nothing to verify. To resume such a live file, move it and its .keystore aside before the restart.

Merging with #347 or #348 does not conflict, and #362 does not touch these files. #355 conflicts with master in the constructor of SecureCsvWriter, and with this PR in no other place.

[maximthomas]

praise: The close is placed exactly where the leak was, and the tests measure it.

• The SecureCsvWriter constructor's catch now closes csvWriter, which stops the RotatableWriter rotator. Removing that close turns all five rows of shouldStopRotatorAndFailWithIOExceptionWhenFileCannotBeResumed red ([pool-N-thread-1 alive]). Measured on JDK 26.
• Restoring the RuntimeException wrapping turns testStartupOpensOtherTopicsWhenTamperEvidentFileCannotBeResumed red. Measured on JDK 26.
• readInitialKey() == null is checked before verify(), so a missing keystore fails with a message that names the keystore, not with an IllegalStateException from the verifier.

---

issue (blocking): A resumed file with a row cut short, a wrong column count or an unclosed quote still fails the whole startup, not only its topic.

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:150, :201-205; commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/CsvSecureVerifier.java:97, :108

CsvSecureVerifier.verify() catches only SecureStorageException. super-csv's SuperCsvException from csvReader.read(header) therefore reaches the constructor's catch, which wraps it in RuntimeException. A probe against super-csv 2.4.0 got "the nameMapping array and the sourceList should be the same size" for a short row and "unexpected end of file while reading quoted column" for an unclosed quote. CsvAuditEventHandler.startup() catches only IOException, so the loop over the topics ends and AuditServiceImpl.startup() leaves the service in STARTING. A crash or a full disk during a write leaves the last row cut short, which is a common way for a file to become unresumable. The description says such a file "now always fails" with an IOException. A header line with one column fails on the same path: header[header.length - 2] throws ArrayIndexOutOfBoundsException.

// SecureCsvWriter.java:149-150 — import org.supercsv.exception.SuperCsvException;
CsvSecureVerifier verifier = new CsvSecureVerifier(csvFile, csvPreference, secureStorage);
final CsvSecureVerifier.VerificationResult verificationResult;
try {
    verificationResult = verifier.verify();
} catch (SuperCsvException e) {
    // A row cut short by a crash while it was written, or a row with a missing or extra column.
    throw new IOException("Resuming an existing CSV file but it cannot be parsed: " + csvFile, e);
}

// CsvSecureVerifier.java:97 — a header with fewer than two columns fails verification
if (header.length < 2 || !(HEADER_HMAC.equals(header[header.length - 2])
        && HEADER_SIGNATURE.equals(header[header.length - 1]))) {

Pin: add an unresumableFiles row that appends a line with fewer columns than the header to a written file. At this head it fails with the RuntimeException. With the fix it fails with the IOException.

---

question (non-blocking): Should an unreadable .keystore next to a new file fail the whole startup, as the description says, or only its topic, as the code now does?

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:118, :201-203

JcaKeyStoreHandler.init() opens an existing keystore path with KeyStoreBuilder.withKeyStoreFile(). For a mode-000 file or a directory, its new FileInputStream throws FileNotFoundException before anything is wrapped in IllegalStateException. The inner catch takes only IllegalStateException, so this IOException now passes through for a new file too, and startup() logs it for the topic. At base it was wrapped, and the startup failed. The description says a new file next to a keystore that cannot be loaded "still fails as before". Either answer is minor. If per-topic is intended, only the sentence changes. If "as before" is intended, the inner catch also takes IOException and wraps it when !fileAlreadyInitialized.

Pin: a 0-byte CSV next to a directory named <csv>.keystore, asserting the outcome you choose.

---

question (non-blocking): Is it intended that a topic that never got an event still fails the whole startup after a Password change?

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:123-125

A topic's keystore is stored when its writer is constructed, but its header is written only with the first event. An idle topic therefore leaves a 0-byte CSV next to a keystore. After the Password key changes, that keystore no longer loads. fileAlreadyInitialized is false, so the IllegalStateException is rethrown and wrapped, and the startup fails, the same as at base. The description says "a topic without a file still starts with a new keystore", which holds only when no keystore is left behind. If this is intended, the sentence needs "and no keystore". If not, dropping the rethrow at :123-125 makes such a topic fail on its own.

---

issue (non-blocking): The rotator can rotate a resumed file while the file is still being verified. This is pre-existing and not changed by this PR.

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:104, :239-240, :443-451

constructWriter() builds the RotatableWriter and registers the rotation hooks before the keys are read and verify() runs. The first rotation check runs one check interval later (default 5s). Take a resumed file that is already over maxFileSize or maxFileLifetime and takes longer than that interval to verify. It is renamed while it is being verified, and postRotationAction renames .keystore and swaps in random keys. verify() then reports "Final HMAC key doesn't match" for a valid file that has already been archived. This was traced in the code, not run. Suggested follow-up issue: start the rotation checks only once construction has succeeded.

---

nitpick (non-blocking): The IOException arm of the new close catch can never fire.

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:198

TextWriterAdapter.close() calls shutdown(). With rotation, RotatableWriter.shutdown() logs the IOException from its close(). Without rotation, TextWriter.Stream closes a PrintWriter, which swallows the exception. A failed close is therefore logged and not added as suppressed; only a RuntimeException can be. The catch has to stay because the compiler requires it. The description's "a failure of that close is added to the original one as suppressed" could say "a RuntimeException from that close".

[vharseko]

@maximthomas, this review seems to have been posted to #342 by mistake. Its text is identical to round 1 of #341 (#341 (review)), which you posted 55 minutes earlier, and it reviews code that only #341 contains: the close of csvWriter in the constructor's catch, the readInitialKey() == null check, the inner IllegalStateException catch around the keystore, and the tests shouldStopRotatorAndFailWithIOExceptionWhenFileCannotBeResumed and testStartupOpensOtherTopicsWhenTamperEvidentFileCannotBeResumed. In the commit it was posted on (529de3a), SecureCsvWriter.java:150 is a closing brace, :198 is a comment and :201-205 is getRandomBytes().

Every point is answered in #341 (#341 (comment)), and you approved its round 2:

1. A resumed file that cannot be parsed: fixed in [#340] Tamper-evident CSV audit: close the file of a writer that fails to resume it #341, which turns any RuntimeException from verify() into an IOException.
2. An unreadable .keystore next to a new file, and 3. an idle topic after a Password change: both are about the keystore catch that [#340] Tamper-evident CSV audit: close the file of a writer that fails to resume it #341 adds, and are answered there.
3. The rotator during the verification: opened as Tamper-evident CSV audit: the rotator can rotate a resumed file while the writer still verifies it #343, fixed in [#343] Tamper-evident CSV audit: construct the rotatable writer once the resumed file is verified #355.
4. The IOException arm of the close catch: about the catch that [#340] Tamper-evident CSV audit: close the file of a writer that fails to resume it #341 adds; its description was corrected.

The branch is now rebased onto master (63e4495), with the same patch; audit/core and audit/handler-csv pass. The description now names the open PRs it merges with: only #369 conflicts, in CsvSecureVerifier.

Could you dismiss this review and review the changes of #342 itself?

[maximthomas]

Yes, the review above was posted by mistake, sorry.
Here is the right review:

praise: The signing model now follows what was written, not the state of the scheduled task.

• unsignedEvents lets forceWriteSignature sign on every rotation and on close() whatever the scheduled Future did, which removes #372's unsigned last event in an archive.
• holdsOnlyTheSignature closes the unchecked data and HMAC columns of signature rows.
• shouldRotateCsvAndKeyStoreFile now verifies every archive and the live file with both the plain and the .gz suffix, in place of asserting the CAUD-225 failure. An empty .gz archive is a valid 20-byte gzip that the verifier reads to EOF, so it also takes the empty-file path.

---

issue (blocking): When the header write triggers a rotation, the archive gets only the header and the first event lands in the new live file without a header.

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:338-340, :269-273, :439-443

writeEvent writes the header on its own first, and RotatableWriter.write rotates inline after each write. Because the event has no HMAC yet, preRotationAction has nothing to sign and lastSignature stays null. postRotationAction then takes the new branch and sets headerWritten = false (:442), and writeHeader overwrites that with true when it returns (:273). This happens with a time-based policy when no event has been signed since startup. The most likely case is a restart over the empty live file that this branch leaves behind: the old mtime becomes lastRotationTime, and the first event comes before the rotator's first check. The archive then fails with Missing final signature, the live file fails with Found only 0 checked headers, and the next start reports the file as tampered. The pin below is red at 63e4495 (Missing final signature on the archive). It is green with the change below, and SecureCsvWriterTest passes 15/15 (JDK 26, macOS). The flag has to be set before the write. If it is set after the combined write, the signature that the rotation writes re-enters writeEvent and prepends a second header: The signature row 3 holds other values.

// SecureCsvWriter.writeEvent(Writer, Map): delete `if (!headerWritten) { writeHeader(headers); }` (:338-340),
// and in place of `writer.write(csvFormatter.formatEvent(extendedValues, extendedHeaders));` (:348):
String row = csvFormatter.formatEvent(extendedValues, extendedHeaders);
if (!headerWritten) {
    // The header and the first event in one write, so that a rotation this write triggers archives
    // both and signs the event; set first, as the signature that rotation writes comes from inside it.
    row = csvFormatter.formatHeader(extendedHeaders) + row;
    headerWritten = true;
}
writer.write(row);

postRotationAction's writeHeader and writeLastSignature (:446-448) can stay as they are, because they run with headerWritten already true. The headerWritten = false at :442 can stay as a guard.

Pin: an empty live file dated a day back, with a 1-hour rotation interval; its first event must leave one archive and a live file that both pass.

@Test
public void shouldSignTheFirstEventWhenItsWriteRotatesTheFile() throws Exception {
    final File actual = newSecureCsvFile();
    // an empty live file last rotated a day ago: with a 1 hour interval, the first write rotates it
    assertThat(actual.createNewFile()).isTrue();
    assertThat(actual.setLastModified(System.currentTimeMillis() - TimeUnit.DAYS.toMillis(1))).isTrue();
    final String header = "FOO";
    final CsvAuditEventHandlerConfiguration config = createRotatingSecureConfig(0);
    config.getFileRotation().setRotationInterval("1 hour");
    try (SecureCsvWriter secureCsvWriter = new SecureCsvWriter(
            actual, new String[]{header}, CsvPreference.EXCEL_PREFERENCE, config, keyStoreHandler, random)) {
        secureCsvWriter.writeEvent(singletonMap(header, "one"));
    }
    final List<File> archives = new TimeStampFileNamingPolicy(actual, "-yyyy.MM.dd-HH.mm.ss.SSS", "").listFiles();
    assertThat(archives).hasSize(1);
    assertPassesVerification(archives.get(0));
    assertPassesVerification(actual);
}

---

suggestion (non-blocking): No test checks that unsignedEvents is cleared before the signature row is written.

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:286-291

This order is what keeps the signature row's own writeEvent from scheduling a task under the new condition at :354. Move :288 after :291 and close() changes: it cancels the scheduled task, its signature row then schedules a new one, and awaitTermination waits for it. shouldGenerateHMACColumn still passes, but takes 300.8 s instead of under a second, and every other test stays green. No test sets a time bound that would catch this.

@Test(timeOut = 60_000)
public void shouldGenerateHMACColumn() throws Exception {

Pin: with this timeOut, the test is red under that mutant (close() takes 300.8 s) and green at the head, where the whole class runs in about 26 s. I did not run it with the timeOut added.

---

issue (non-blocking): If an event is written after the periodic signature task releases the lock but before it completes, no new signature is scheduled for that event.

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:354-362, :300-303

writeSignature unlocks (:301) and flushes (:302) before the task's run() returns, and FutureTask becomes done only after that. An event written in this window sees !scheduledSignature.isDone() and schedules nothing. On a quiet topic it stays unsigned until the next event, a rotation, or close(). If the process is killed in that state, the live file ends in an unsigned row. The race already exists on master with the same isDone() test. This PR's close() now always signs, which limits the problem to shutdowns that are not clean. A follow-up issue is enough. Sketch, not run:

private boolean signatureScheduled; // guarded by signatureLock

// writeSignature, first statement inside the lock, before the `if (!unsignedEvents)` guard:
signatureScheduled = false;

// writeEvent, in place of :354; set only once schedule() returned, so a RejectedExecutionException leaves it false:
if (unsignedEvents && !signatureScheduled) {
    logger.trace("Triggering a new signature task to be executed in {}", signatureInterval);
    try {
        scheduledSignature = scheduler.schedule(signatureTask, signatureInterval.getValue(),
                signatureInterval.getUnit());
        signatureScheduled = true;
    } catch (RejectedExecutionException e) {
        logger.error(e.getMessage(), e);
    }
}

---

suggestion (non-blocking): With rotation enabled, calling close() a second time now throws IOException("Stream closed").

commons/audit/handler-csv/src/main/java/org/forgerock/audit/handlers/csv/SecureCsvWriter.java:256-263, :300-303

forceWriteSignature now always calls writeSignature. When there is nothing to sign, it returns at :282, but its finally still calls flush(), which reaches the BufferedWriter that the first close() already closed. Master returned normally here. No caller closes twice: CsvAuditEventHandler.closeWriter removes the writer before it closes it. A guard at the top of close() makes it idempotent:

private boolean closed;

// close(), first statements:
if (closed) {
    return;
}
closed = true;

[vharseko]

@maximthomas, the round is in 6b4ab04:

1. The header write that rotates the file: fixed as you suggested. The header and the first event go in one write, and headerWritten is set before it. shouldSignTheFirstEventWhenItsWriteRotatesTheFile is your pin, and it also checks that the event is in the archive. At 63e4495 it fails with an archive that holds only the header. With the flag set after the write, it fails with The signature row 3 holds other values.
2. The order of unsignedEvents = false: shouldGenerateHMACColumn now has timeOut = 60_000. With the assignment moved after the signature row, it fails with ThreadTimeoutException after 60 s, as close() waits in awaitTermination. At the head it passes.
3. An event written while the periodic signature task completes: opened as Tamper-evident CSV audit: an event written while the periodic signature completes stays unsigned #373, and listed under the known limits. The sketch leaves one interleaving, which the issue describes. A rotation or close() signs while the task already runs and waits for the lock, so cancel(false) fails. An event then schedules a second task, the first one clears the flag, and the next event schedules a third. close() cancels only the last one, and waits for the second up to the signature interval.
4. A second close(): it now does nothing. shouldDoNothingWhenClosedTwice fails at 63e4495 with IOException: Stream closed.

audit/core and audit/handler-csv pass locally, and SecureCsvWriterTest passed 5 runs in a row. The description is updated. Merging with #341, #347, #348, #353 or #355 still does not conflict, and #369 still conflicts in CsvSecureVerifier only.

[vharseko]

@maximthomas, rebased onto the current master (28afe37, with #369): the head is 206d27e.

The only conflict was in CsvSecureVerifier.verifyHMAC(). This PR changed actualHMAC.equals(expectedHMAC) to expectedHMAC.equals(actualHMAC), so that a row with neither an HMAC nor a signature is reported as an incorrect HMAC instead of throwing a NullPointerException. #369 replaced that comparison with hmacCalculator.verify(actualHMAC, ...), which compares hmac(data).equals(expectedHmac) and takes a null as well, so the resolution keeps the code of master. The rest of the PR applied as is.

audit/handler-csv passes locally (87 tests).

[vharseko]

@maximthomas, #373, the non-blocking issue of your review (an event written while the periodic signature completes), is fixed in this PR now: 00f0a35, on top of 206d27e.

A correction to round 3 and to the note in #373: cancel(false) does not fail when the task has started and waits for the lock. It returns true, as a FutureTask stays NEW until its run() returns, and the task still runs. The outcome is the one described there: with a flag that every signature task clears, a rotation in this state leaves two tasks scheduled, and close() waits for the one it does not cancel, up to the signature interval. It happens on master as well.

So the writer keeps the pending task itself, in pendingSignature, with one SignatureTask per schedule instead of one shared Runnable:

• writeEvent() schedules a signature for unsigned events when no task is pending.
• A task clears pendingSignature once it holds the lock, before it signs, and only if it is that task. An event written after that comes after its signature, and schedules the next one, whether the task is done or not.
• A successful cancel(false) in forceWriteSignature() clears it too. A task that it did not stop leaves alone the one that an event scheduled since.

Three tests, each red with its part of the fix disabled:

• shouldSignAnEventWrittenWhileThePeriodicSignatureCompletes: the writer's flush(), which writeSignature() calls once the signature row is written, writes a second event. With the isDone() condition, no signature follows within 10 s, and the live file fails verification while the writer is open.
• shouldSignPeriodicallyAnEventWrittenAfterARotationCancelledTheScheduledSignature: red when the cancel leaves pendingSignature set, as the event after the rotation then gets no periodic signature.
• shouldScheduleNoOtherSignatureWhenARotationSignsWhileTheScheduledOneWaitsForTheLock: the test holds the lock until the scheduled signature waits for it, then rotates and writes events. When a task clears pendingSignature whatever it holds, close() takes 2.7 s with a 3 s interval; the test requires less than half of it.

audit/core and audit/handler-csv pass locally (90 tests in audit/handler-csv), and SecureCsvWriterTest passed 5 runs in a row. The description is updated: #373 moved from the known limits to its own section. Merging with #347 or #348 still does not conflict. #355 now conflicts with master itself, in the constructor of SecureCsvWriter, and this PR adds no other conflict to it.

[maximthomas]

praise: Each fix in this round sits where its round-2 finding was, and each has a test that pins it.

• SecureCsvWriter.writeEvent writes the header and the first event as one string (SecureCsvWriter.java:389-396). RotatableWriter.write rotates only after the write, so a rotation this write triggers archives both rows, and preRotationAction signs the event. shouldSignTheFirstEventWhenItsWriteRotatesTheFile covers this.
• SignatureTask.run clears pendingSignature under signatureLock before it calls writeSignature (SecureCsvWriter.java:515-518). Both mutants were run locally on JDK 26. With the clear moved after writeSignature, shouldSignAnEventWrittenWhileThePeriodicSignatureCompletes fails. With the pendingSignature == this guard dropped, shouldScheduleNoOtherSignatureWhenARotationSignsWhileTheScheduledOneWaitsForTheLock fails: close() took 2694 ms against its 1.5 s bound.
• close() returns early on a second call (SecureCsvWriter.java:272-276), pinned by shouldDoNothingWhenClosedTwice. The five new cases pass on all 9 CI matrix rows, where handler-csv runs 90 tests at this head against 78 at the base.