SignatureCounterValidator and TimeStampValidator fail, when presented tar files, which are not sorted and disjoint

[dheldt]

SignatureCounterValidator.validate() should be able to handle multiple tar files (i.e. instance of LogMessageArchive) one after another. This currently only works, if the tars are "sorted", i.e. the first tar contains all log messages up to a fixed point of time and the second contains all subsequent log messages. If the tars are "mixed" somewhat, the Validators fail and produce a lot of errors, which might be no errors.

Here I am unsure, what the best architecture is fix this issue.

[nils-tekampe]

I would suggest an architecture where a validator (or a kind of meta-validator) can only be called once but would accept a list of tar files.

[dheldt]

I made a proposal in #50.

I create a LogMessageArchive, which contains a set of LogMessageArchives, that can be validated in one step.

It would look like:

AggregatedLogMessageArchive tarSet = new AggregatedLogMessageArchive();

tarSet.add(new LogMessageArchiveImplementation(tarFile1))
.add(new LogMessageArchiveImplementation(tarFile2))
.add(new LogMessageArchiveImplementation(tarFile3))
.add(new LogMessageArchiveImplementation(tarFile4));

Validator v = new WhatEverValidator();

v.validate(tarSet);

The AggregatedLogMessageArchive removes duplicate logmessages, which occur multiple times in the archives, which solves the original problem.

Still, AggregatedLogMessageArchive has two Hashmap<String, X509Certificate> to hold the tars certificates. Here I fear, that a Hashmap was not the right choice of datatype in the first place, which now starts to create a problem. We might have the same certificate with different file names here or even different certificates with the same file name, which would mean, that we "loose" one of them in the aggregation step. Maybe this should be better a Collection<Pair<String, X509Certificate>> in the first place (i.e. in LogMessageArchive, LogMessageArchiveImplementation, and AggregatedLogMessageArchive)?