Improve Error logging about csaf_distribution HOT 5 CLOSED

@tschmidtb51 Do you think that logging is too verbose?

Access to the web-interface and the api is expected only from people who want to upload documents and my thinking is that I would like to log who used these interfaces for an audit trail.

(Another use is analyzing failed login attempts, to see which issuer string was registered precisely.)

from csaf_distribution.

I guess, my main point here is, that this should not be logged as a "error" when it is in fact not an error...

I like logging of fail attempts as errors. No disagreement on that part.
But successful attempts shouldn't be logged as errors (that is confusing). Moreover, that might be a privacy issue 🤔

from csaf_distribution.

I first thought that way too: error and SUCCESS both in one line ... but then I noticed the continuation and the fact that the tool reads something not mapping to "nil" in golang on std error - so maybe that is not easily "fixable"

from csaf_distribution.

that this should not be logged as a "error"

Technically this comes from how fcgiwrap does it logging. We could do extra logging, but the question is if the extra complexity is worth it.

Moreover, that might be a privacy issue.

An audit trail maybe required for operating the service. But yes, deletion of logfiles and potential written agreements would be a topic for operating the service, so I'd guess it is out of scope for the software development. The emitted log information could be thrown away on the operation side. Usually it is a good idea to let the operators decide on what they need and how they want to solve this.

from csaf_distribution.

Let's discuss that in our next status meeting.

from csaf_distribution.