Erik Wilson
3c65daa0ab
|
5 years ago | |
---|---|---|
.. | ||
asn1 | 6 years ago | |
client | 6 years ago | |
jsonclient | 6 years ago | |
tls | 6 years ago | |
x509 | 5 years ago | |
.gitignore | 6 years ago | |
.travis.yml | 6 years ago | |
AUTHORS | 6 years ago | |
CHANGELOG.md | 6 years ago | |
CONTRIBUTING.md | 6 years ago | |
CONTRIBUTORS | 6 years ago | |
LICENSE | 6 years ago | |
README.md | 6 years ago | |
cloudbuild_tag.yaml | 6 years ago | |
gometalinter.json | 6 years ago | |
serialization.go | 6 years ago | |
signatures.go | 6 years ago | |
types.go | 6 years ago |
README.md
Certificate Transparency: Go Code
This repository holds Go code related to Certificate Transparency (CT). The repository requires Go version 1.9.
Repository Structure
The main parts of the repository are:
- Encoding libraries:
asn1/
andx509/
are forks of the upstream Goencoding/asn1
andcrypto/x509
libraries. We maintain separate forks of these packages because CT is intended to act as an observatory of certificates across the ecosystem; as such, we need to be able to process somewhat-malformed certificates that the stricter upstream code would (correctly) reject. Ourx509
fork also includes code for working with the pre-certificates defined in RFC 6962.tls
holds a library for processing TLS-encoded data as described in RFC 5246.x509util
provides additional utilities for dealing withx509.Certificate
s.
- CT client libraries:
- The top-level
ct
package (in.
) holds types and utilities for working with CT data structures defined in RFC 6962. client/
andjsonclient/
hold libraries that allow access to CT Logs via entrypoints described in section 4 of RFC 6962.scanner/
holds a library for scanning the entire contents of an existing CT Log.
- The top-level
- Command line tools:
./client/ctclient
allows interaction with a CT Log./scanner/scanlog
allows an existing CT Log to be scanned for certificates of interest; please be polite when running this tool against a Log../x509util/certcheck
allows display and verification of certificates./x509util/crlcheck
allows display and verification of certificate revocation lists (CRLs).
- CT Personality for Trillian:
trillian/
holds code that allows a Certificate Transparency Log to be run using a Trillian Log as its back-end -- see below.
Trillian CT Personality
The trillian/
subdirectory holds code and scripts for running a CT Log based
on the Trillian general transparency Log.
The main code for the CT personality is held in trillian/ctfe
; this code
responds to HTTP requests on the
CT API paths and translates
them to the equivalent gRPC API requests to the Trillian Log.
This obviously relies on the gRPC API definitions at
github.com/google/trillian
; the code also uses common libraries from the
Trillian project for:
- exposing monitoring and statistics via an
interface
and corresponding Prometheus implementation (github.com/google/trillian/monitoring/...
) - dealing with cryptographic keys (
github.com/google/trillian/crypto/...
).
The trillian/integration/
directory holds scripts and tests for running the whole
system locally. In particular:
trillian/integration/ct_integration_test.sh
brings up local processes running a Trillian Log server, signer and a CT personality, and exercises the complete set of RFC 6962 API entrypoints.trillian/integration/ct_hammer_test.sh
brings up a complete system and runs a continuous randomized test of the CT entrypoints.
These scripts require a local database instance to be configured as described in the Trillian instructions.
Working on the Code
Developers who want to make changes to the codebase need some additional dependencies and tools, described in the following sections. The Travis configuration for the codebase is also useful reference for the required tools and scripts, as it may be more up-to-date than this document.
Rebuilding Generated Code
Some of the CT Go code is autogenerated from other files:
- Protocol buffer message
definitions are converted to
.pb.go
implementations. - A mock implementation of the Trillian gRPC API (in
trillian/mockclient
) is created with GoMock.
Re-generating mock or protobuffer files is only needed if you're changing the original files; if you do, you'll need to install the prerequisites:
mockgen
tool from https://github.com/golang/mockprotoc
, Go support for protoc (see documentation linked from the protobuf site)
and run the following:
go generate -x ./... # hunts for //go:generate comments and runs them
Updating Vendor Code
The codebase includes a couple of external projects under the vendor/
subdirectory, to ensure that builds use a fixed version (typically because the
upstream repository does not guarantee back-compatibility between the tip
master
branch and the current stable release). See
instructions in the Trillian repo
for how to update vendored subtrees.
Running Codebase Checks
The scripts/presubmit.sh
script runs various tools
and tests over the codebase.
# Install gometalinter and all linters
go get -u github.com/alecthomas/gometalinter
gometalinter --install
# Run code generation, build, test and linters
./scripts/presubmit.sh
# Run build, test and linters but skip code generation
./scripts/presubmit.sh --no-generate
# Or just run the linters alone:
gometalinter --config=gometalinter.json ./...