Rethink logging #133
Rethink logging #133
Conversation
In retrospect, moving to this was a mistake: it adds lots of dependencies (including one that has a security advisory), but we can easily replicate its features locally, and do so in a way that doesn't rely on implicit global variables. This commit therefore is a sort-of manual reversion of 45666ba (an actual revert is impossible as too much has changed since then), but also very slightly improves the situation that pertained before 45666ba.
It is useful, particularly when something seems to be going wrong with snare or github settings, to have a verbosity level that tells you when a request has been received.
|
Are you sure you want to do this? The |
|
Maybe they are --- but this change also reduces the binary size by almost 10%, so it's a win in other ways. |
|
It's up to you. I'm not sure I'd have gone my own way if it were mine. People know how By the way, your vuln doesn't come from You could still use one of the standard logging libs if you wanted, for example If you say merge, I will, but I'd just use |
|
Honestly, for a daemon, I think the lightweight logging in this PR is probably for the best. I should have stuck with it in the first place! |
In 45666ba we moved to the
logcrate and friends --- but that's just bitten us withattyas a dependency which has a security advisory.This PR removes
logand back to our own (small) custom logging (that deals with stderr and syslog) (a61aec7). As a bonus I finally added the ability to see which requests are coming in (with-vv) (eba8bac). Both commits contain a bit more detail. Lightly tested on b13 and my main server and working fine.