oneCRL.go's LoadJSONFromURL has a TODO that it should take a Reader; this would help write offline integration tests (like PR #42)

Line in question: https://github.com/mozmark/OneCRL-Tools/blob/12ad599192d7b6cf0c40348a4f87b07c63e2e02b/oneCRL/oneCRL.go#L261

There should be a tool, or tooling, to produce diffs from the historical information of OneCRL. Perhaps this could be reading the history from Kinto, or simply some other data file that is loaded and returned at each invocation.

E.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1373288 has a title that talks about CCADB but one of the entries is not a CCADB managed entry (being an extraordinary addition).

It's desirable to treat exceptional cases separately in some cases. At the moment, the tool provides no way of doing this.

Many non-BR-compliant SSL certs have been issued from the StartCom intermediate certs, and the list provided demonstrates some very sloppy issuance practices.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1386894

as per https://bugzilla.mozilla.org/show_bug.cgi?id=1374809

See https://bugzilla.mozilla.org/show_bug.cgi?id=1381863

#33 breaks downstream software. go get is unable to fetch specific git commits, but there's a web service that allows to install using specific tags from github repos.

git tag stable master~1  # or any other known-working commit
git push --tags

The idea then is to not replace that tag unless there is a newer commit that is confirmed to be working well.

We're linking all CCADB bugs to block one poor bug... let's add a configurable bug# into the config to auto-link that on issue creation.

When running oneCRL2RevocationsTxt without a network connection, it will just fail silently with return code 0. It should at least set a return code larger 0 to indicate failure for scripting, better still, additionally say something to stderr.

I finally came round to switching TLS Canary over to the brand new stable tag, just to find that it points to a broken commit b7bc37c.

# github.com/mozmark/OneCRL-Tools/oneCRL2RevocationsTxt
../../.tlscanary/go/src/github.com/mozmark/OneCRL-Tools/oneCRL2RevocationsTxt/main.go:51: multiple-value config.GetRecordURL() in single-value context

TLS Canary has been successfully using commit 244e704 in production for a while now. @mozmark, please point your stable tag to that commit as soon as possible, and leave it there until you can find a later commit that is verified to work.

mozmark@48acb6a broke package installation:

$ GOPATH="/tmp/go" go install github.com/mozmark/OneCRL-Tools/oneCRL2RevocationsTxt
# github.com/mozmark/OneCRL-Tools/oneCRL2RevocationsTxt
/tmp/go/src/github.com/mozmark/OneCRL-Tools/oneCRL2RevocationsTxt/main.go:43: undefined: oneCRL.DefineFlags
/tmp/go/src/github.com/mozmark/OneCRL-Tools/oneCRL2RevocationsTxt/main.go:48: undefined: oneCRL.GetConfig

This is causing downstream breakage in TLS Canary that we're unable to fix without tags: mozilla/tls-canary#106

It's useful to be able to get the current state of pending changes before approval so compat testing can take place before a OneCRL change is approved. oneCRL2RevocationsTxt should support this case.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1393281 and https://bugzilla.mozilla.org/show_bug.cgi?id=1394595

Since we're adding Travis in #42, let's also pick a time to go vet and go fmt this repo, and make Travis enforce it. Preferably also lock-down refs/heads/master and enforce a PR-merger workflow.

https://bugzilla.mozilla.org/show_bug.cgi?id=1391095

These data should go in mozilla-central - but for now, let's put them here.

Current master is broken:

$ go get github.com/mozmark/OneCRL-Tools/oneCRL2RevocationsTxt
# github.com/mozmark/OneCRL-Tools/oneCRL2RevocationsTxt
/tmp/go/src/github.com/mozmark/OneCRL-Tools/oneCRL2RevocationsTxt/main.go:51: multiple-value config.GetRecordURL() in single-value context

oneCRL2RevocationsTxt --env foo seems to work just fine, but what does it do?

This requires removal of the uploadURL flag / config option and the CurrentURL one too.

It'd be nice if we could use a yml config file. Flags should override config file options.

Kathleen suggests that the string used for the bug summary, "CCADB entries generated %s" be modified to say "CCADB OneCRL entries generated %s", since we might have non-revocation entries that we want to ship from CCADB in the future.