debug.ReadBuildInfo() doesn't work for the Debian package, where there
is no git repository (at best; could be the Debian packaging one). The
go module doesn't have a version either.
Add a quick shortcut at the top, that sets the version to main.Version
if it's non-empty -- which is by default, so no change in behavior.
Effectively, this allows one to use the standard
-ldflags=-X=main.Version to set the version, like we intend to do in the
Debian package.
Specifically, certspotter no longer terminates unless it receives SIGTERM
or SIGINT or there is a serious error.
Although using cron made sense in the early days of Certificate
Transparency, certspotter now needs to run continuously to reliably keep
up with the high growth rate of contemporary CT logs, and to gracefully
handle the many transient errors that can arise when monitoring CT.
Closes: #63Closes: #37Closes: #32 (presumably by eliminating $DNS_NAMES and $IP_ADDRESSES)
Closes: #21 (with $WATCH_ITEM)
Closes: #25
When Cert Spotter starts monitoring a log that it has never monitored before,
it can either start monitoring it from the beginning, or seek to the end and
start monitoring there.
Monitoring from the beginning guarantees detection of all certificates, but
requires downloading hundreds of millions of certificates, which takes days.
With the new -start_at_end option, you can save significant time by
starting at the end. You will miss certificates that were added to a
log before Cert Spotter starts monitoring it, but you can always use the
Cert Spotter API <https://sslmate.com/certspotter/api> or crt.sh to find them.
Previously, the -start_at_end behavior was implied the first time you
ever ran Cert Spotter. This is no longer the case.
It may still be possible to audit other STHs, and to scan new entries
up to the latest verified STH. This allows Cert Spotter to continue
to make forward progress even if a log is persistently skewed (as the
DigiCert has been lately).
Also, rework some code to be simpler and less redundant.
Andrew Ayer