diff --git a/osbase/event/etcd/etcd_test.go b/osbase/event/etcd/etcd_test.go
index ee3672f..5effa6e 100644
--- a/osbase/event/etcd/etcd_test.go
+++ b/osbase/event/etcd/etcd_test.go
@@ -79,7 +79,7 @@
 
 // testClient is an etcd connection to the test cluster.
 type testClient struct {
-	client     *clientv3.Client
+	client *clientv3.Client
 }
 
 func newTestClient(t *testing.T) *testClient {
@@ -95,7 +95,7 @@
 	}
 
 	return &testClient{
-		client:     cli,
+		client: cli,
 	}
 }
 
diff --git a/osbase/logtree/doc.go b/osbase/logtree/doc.go
index ab3c537..1fe6d46 100644
--- a/osbase/logtree/doc.go
+++ b/osbase/logtree/doc.go
@@ -19,42 +19,42 @@
 glog-like API and io.Writer API, with loggers placed in a hierarchical structure defined by a dot-delimited path
 (called a DN, short for Distinguished Name).
 
-    tree.MustLeveledFor("foo.bar.baz").Warningf("Houston, we have a problem: %v", err)
-    fmt.Fprintf(tree.MustRawFor("foo.bar.baz"), "some\nunstructured\ndata\n")
+	tree.MustLeveledFor("foo.bar.baz").Warningf("Houston, we have a problem: %v", err)
+	fmt.Fprintf(tree.MustRawFor("foo.bar.baz"), "some\nunstructured\ndata\n")
 
 Logs in this context are unstructured, operational and developer-centric human readable text messages presented as lines
 of text to consumers, with some attached metadata. Logtree does not deal with 'structured' logs as some parts of the
 industry do, and instead defers any machine-readable logs to either be handled by metrics systems like Prometheus or
 event sourcing systems like Kafka.
 
-Tree Structure
+# Tree Structure
 
 As an example, consider an application that produces logs with the following DNs:
 
-    listener.http
-    listener.grpc
-    svc
-    svc.cache
-    svc.cache.gc
+	listener.http
+	listener.grpc
+	svc
+	svc.cache
+	svc.cache.gc
 
 This would correspond to a tree as follows:
 
-                          .------.
-                         |   ""   |
-                         | (root) |
-                          '------'
-           .----------------'   '------.
-    .--------------.           .---------------.
-    |     svc      |           |    listener   |
-    '--------------'           '---------------'
-           |                   .----'      '----.
-    .--------------.  .---------------.  .---------------.
-    |  svc.cache   |  | listener.http |  | listener.grpc |
-    '--------------'  '---------------'  '---------------'
-           |
-    .--------------.
-    | svc.cache.gc |
-    '--------------'
+	                      .------.
+	                     |   ""   |
+	                     | (root) |
+	                      '------'
+	       .----------------'   '------.
+	.--------------.           .---------------.
+	|     svc      |           |    listener   |
+	'--------------'           '---------------'
+	       |                   .----'      '----.
+	.--------------.  .---------------.  .---------------.
+	|  svc.cache   |  | listener.http |  | listener.grpc |
+	'--------------'  '---------------'  '---------------'
+	       |
+	.--------------.
+	| svc.cache.gc |
+	'--------------'
 
 In this setup, every DN acts as a separate logging target, each with its own retention policy and quota. Logging to a DN
 under foo.bar does NOT automatically log to foo - all tree mechanisms are applied on log access by consumers. Loggers
@@ -70,14 +70,14 @@
 logs of the entire tree, just a single DN (like svc), or a subtree (like everything under listener, ie. messages emitted
 to listener.http and listener.grpc).
 
-Leveled Log Producer API
+# Leveled Log Producer API
 
 As part of the glog-like logging API available to producers, the following metadata is attached to emitted logs in
 addition to the DN of the logger to which the log entry was emitted:
 
- - timestamp at which the entry was emitted
- - a severity level (one of FATAL, ERROR, WARN or INFO)
- - a source of the message (file name and line number)
+  - timestamp at which the entry was emitted
+  - a severity level (one of FATAL, ERROR, WARN or INFO)
+  - a source of the message (file name and line number)
 
 In addition, the logger mechanism supports a variable verbosity level (so-called 'V-logging') that can be set at every
 node of the tree. For more information about the producer-facing logging API, see the documentation of the LeveledLogger
@@ -88,14 +88,14 @@
 with other entries, and allows for access API consumers to maintain semantic linking between multiple lines being emitted
 as a single atomic entry.
 
-Raw Log Producer API
+# Raw Log Producer API
 
 In addition to leveled, glog-like logging, LogTree supports 'raw logging'. This is implemented as an io.Writer that will
 split incoming bytes into newline-delimited lines, and log them into that logtree's DN. This mechanism is primarily
 intended to support storage of unstructured log data from external processes - for example binaries running with redirected
 stdout/stderr.
 
-Log Access API
+# Log Access API
 
 The Log Access API is mostly exposed via a single function on the LogTree struct: Read. It allows access to log entries
 that have been already buffered inside LogTree and to subscribe to receive future entries over a channel. As outlined
@@ -111,6 +111,5 @@
 logging entry. Helper functions are available on LogEntry that allow canonical string representations to be returned, for
 easy use in consuming tools/interfaces. Alternatively, the consumer can itself access the internal raw/leveled entries and
 print them according to their own preferred format.
-
 */
 package logtree
diff --git a/osbase/pki/certificate.go b/osbase/pki/certificate.go
index b925958..93e6ed9 100644
--- a/osbase/pki/certificate.go
+++ b/osbase/pki/certificate.go
@@ -115,7 +115,8 @@
 
 // Client makes a Kubernetes PKI-compatible client certificate template.
 // Directly derived from Kubernetes PKI requirements documented at
-//   https://kubernetes.io/docs/setup/best-practices/certificates/#configure-certificates-manually
+//
+//	https://kubernetes.io/docs/setup/best-practices/certificates/#configure-certificates-manually
 func Client(identity string, groups []string) x509.Certificate {
 	return x509.Certificate{
 		Subject: pkix.Name{
diff --git a/osbase/tpm/eventlog/eventlog.go b/osbase/tpm/eventlog/eventlog.go
index 03aaf69..2166e54 100644
--- a/osbase/tpm/eventlog/eventlog.go
+++ b/osbase/tpm/eventlog/eventlog.go
@@ -96,7 +96,7 @@
 
 // TPM algorithms. See the TPM 2.0 specification section 6.3.
 //
-//   https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2-Structures-01.38.pdf#page=42
+//	https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2-Structures-01.38.pdf#page=42
 const (
 	algSHA1   uint16 = 0x0004
 	algSHA256 uint16 = 0x000B
@@ -383,7 +383,7 @@
 // parser instead of holding a measurement. For TPM 2.0, this event type is
 // used to signal switching from SHA1 format to a variable length digest.
 //
-//   https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientSpecPlat_TPM_2p0_1p04_pub.pdf#page=110
+//	https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientSpecPlat_TPM_2p0_1p04_pub.pdf#page=110
 const eventTypeNoAction = 0x03
 
 // ParseEventLog parses an unverified measurement log.
@@ -445,7 +445,8 @@
 }
 
 // Expected values for various Spec ID Event fields.
-//   https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf#page=19
+//
+//	https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf#page=19
 var wantSignature = [16]byte{0x53, 0x70,
 	0x65, 0x63, 0x20, 0x49,
 	0x44, 0x20, 0x45, 0x76,
@@ -459,7 +460,8 @@
 )
 
 // parseSpecIDEvent parses a TCG_EfiSpecIDEventStruct structure from the reader.
-//   https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf#page=18
+//
+//	https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf#page=18
 func parseSpecIDEvent(b []byte) (*specIDEvent, error) {
 	r := bytes.NewReader(b)
 	var header struct {
@@ -522,7 +524,8 @@
 }
 
 // TPM 1.2 event log format. See "5.1 SHA1 Event Log Entry Format"
-//   https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf#page=15
+//
+//	https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf#page=15
 type rawEventHeader struct {
 	PCRIndex  uint32
 	Type      uint32
@@ -567,7 +570,8 @@
 }
 
 // TPM 2.0 event log format. See "5.2 Crypto Agile Log Entry Format"
-//   https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf#page=15
+//
+//	https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf#page=15
 type rawEvent2Header struct {
 	PCRIndex uint32
 	Type     uint32
diff --git a/osbase/tpm/eventlog/internal/events.go b/osbase/tpm/eventlog/internal/events.go
index eb121b2..23b00c2 100644
--- a/osbase/tpm/eventlog/internal/events.go
+++ b/osbase/tpm/eventlog/internal/events.go
@@ -57,7 +57,8 @@
 // EventType describes the type of event signalled in the event log.
 type EventType uint32
 
-// 	BIOS Events (TCG PC Client Specific Implementation Specification for Conventional BIOS 1.21)
+// BIOS Events (TCG PC Client Specific Implementation Specification for
+// Conventional BIOS 1.21)
 const (
 	PrebootCert          EventType = 0x00000000
 	PostCode             EventType = 0x00000001
@@ -193,7 +194,7 @@
 // ParseUEFIVariableData parses the data section of an event structured as a
 // UEFI variable.
 //
-//   https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_Specific_Platform_Profile_for_TPM_2p0_1p04_PUBLIC.pdf#page=100
+//	https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_Specific_Platform_Profile_for_TPM_2p0_1p04_PUBLIC.pdf#page=100
 func ParseUEFIVariableData(r io.Reader) (ret UEFIVariableData, err error) {
 	err = binary.Read(r, binary.LittleEndian, &ret.Header)
 	if err != nil {