Golang Nugget - Feb 17, 2025

Say Hello to Go 1.24: FIPS 140-3 Compliance, Generic Type Aliases, and Performance Boosts!

  1. Go 1.24 Release Notes — Go 1.24 is finally out, and nothing beats reading the official release notes. While they’re not always the easiest to understand (some changes feel a bit too brief), they’re still the ultimate source of truth (not that truth!). If you find yourself lost, Anton’s Go 1.24 interactive tour, along with What to expect from Go 1.24 Part 1 and Part 2, are great places to start.

  2. Why does Go's io.Reader have such a weird signature? — A great explanation of why it's Read(p []byte) (n int, err error) and not Read() (p []byte, err error). Basically, why it takes a byte slice and writes data into it rather than creating a slice and returning it.

  3. Parallel Streaming Pattern in Go: How to Scan Large S3 or GCS Buckets Significantly Faster — If you need to find a file in a large storage bucket (S3 or GCS), listing files can quickly become a bottleneck. This post covers how to speed things up by parallelising the search—partitioning the bucket based on naming patterns and using the Rill toolkit.

  4. Go slice gotchas — In Go, a slice is a lightweight wrapper around an array. Instead of holding data itself, it tracks three things: a pointer to the underlying array, the number of elements it contains, and its total capacity before needing to grow. Essentially, it's a view of the underlying array. This design has some gotchas that can turn into pitfalls if not used carefully.

  5. We Replaced Our React Frontend with Go and WebAssembly — Probably not something you'd want to do, but Dagger replaced its React frontend with a Go + WebAssembly-based UI. Still, the approach they took and the references they provided make it a worthwhile read if you want to understand WebAssembly better.

Sponsored
Jolt NetworkWeekly skills and job leads with a side of ‘I understood that reference’.

Tool Time

  1. github.com/viccon/sturdyc — A high-performance caching library built for I/O-heavy applications. It prevents cache stampedes (when multiple requests for the same data hit the backend at the same time because the cached version has expired) and reduces data source load with features like request coalescing and asynchronous refreshes. By combining fast in-memory caching with precise control over data freshness, sturdyc helps ensure system stability and efficiency at scale.

  2. github.com/xataio/pgroll — A CLI tool for PostgreSQL safe and reversible schema migrations by serving multiple schema versions at the same time. It takes care of the complex migration and lets applications continue working while the database schema is being updated. This includes ensuring that changes are applied without locking the database and that both old and new schema versions work simultaneously.

  3. github.com/destel/rill — A toolkit for composable concurrency in Go. It makes it easier to build concurrent programs from simple, reusable components.

  4. github.com/yassinebenaid/bunster — A shell compiler that converts shell scripts into secure, portable and static binaries. Unlike other tools, Bunster does not just wrap your script within a binary. It literally compiles them to standalone shell-independent programs. Technically speaking, Bunster in fact is a shell-to-Go Transpiler that generates Go source out of your scripts. Then, optionally uses the Go Toolchain to compile the code to an executable.

  5. github.com/jesseduffield/lazygit — simple terminal UI for git commands written in Go.

Deep Dive

Fact-based news without bias awaits. Make 1440 your choice today.

Overwhelmed by biased news? Cut through the clutter and get straight facts with your daily 1440 digest. From politics to sports, join millions who start their day informed.

FIPS 140-3 is a set of requirements established by the U.S. government for cryptographic modules. Any organisation working with the U.S. Federal government often needs to comply with this standard to ensure that the cryptographic techniques used in applications meet specific security requirements.

The Challenge Before Go 1.24

Before Go 1.24, getting FIPS 140-2 compliance in Go apps was tough because the Go standard library wasn’t FIPS-validated. Some of the solutions included:

  • One approach was to use GOEXPERIMENT=boringcrypto, which linked the FIPS-certified BoringCrypto library using cgo. However, this method was only supported within certain environments. The cryptography packages would call into BoringCrypto (Google cryptography lib) to handle cryptographic operations.

  • Red Hat modified their version of Go on RHEL to use BoringSSL for cryptographic functions, which was later switched to OpenSSL. This setup allowed apps built with RHEL’s Go to use cryptographic functions from a FIPS-validated version of OpenSSL. You could verify this setup by using tools like go tool nm and running the app in a container with a FIPS-compliant OpenSSL library.

These older solutions often had drawbacks, like inconsistent support, the risk of memory-unsafe code, delays in Go version updates, performance problems, and a worse experience for developers.

Go 1.24: A Native Solution for FIPS 140-3 Compliance

Go 1.24 introduces native support for FIPS 140-3 compliance, giving Go developers built-in tools to meet U.S. Government requirements for cryptographic modules. This means Go apps can meet strict standards without needing external or unsupported solutions.

  • The Go Cryptographic Module is a set of standard library packages under crypto/internal/fips140/... that implement FIPS 140-3 approved algorithms. Public API packages like crypto/ecdsa and crypto/rand automatically use this module. The module’s version 1.0.0 is currently being tested by a certified lab.

  • The fips140 GODEBUG option controls whether the Go Cryptographic Module runs in FIPS 140-3 mode at runtime. It’s off by default and can't be changed once the program starts. When enabled, the module performs extra security checks, which may affect performance.

  • The module automatically performs an integrity self-check at initialisation, comparing the checksum of the module's object file (calculated at build time) with the symbols loaded into memory.

  • All algorithms perform known-answer self-tests based on the relevant FIPS 140-3 Implementation Guidance, either at initialisation or on first use.

  • Pairwise consistency tests are done on generated cryptographic keys, which could cause a slowdown of up to 2x for certain key types, particularly for ephemeral keys. If you don’t need FIPS, don’t turned it on!

Microsoft's Approach to FIPS Compliance

Microsoft has taken a different approach with its Go build. Instead of using the new Go FIPS module, it continues to rely on system libraries for cryptographic operations. This means it uses OpenSSL on Linux and CNG on Windows. The Microsoft build now also offers preview support for macOS, using FIPS-certified Common Crypto and CryptoKit libraries.

References:

How did you like this edition?

Or hit reply and share your thoughts!

Login or Subscribe to participate in polls.

Enjoyed reading? Pass it along to someone else who might! Sharing is caring.

Seth Meyers Thank You GIF by Late Night with Seth Meyers

Reply

or to participate.