Based on the Go 1.22 release notes from the Go team (3-Clause BSD License), with many interactive examples added. This blog post is synchronized with the source document as it gets updated.

High pressure, high forces, long lever arms...all of that meant heavy and strong (read: expensive) parts which I was not looking forward to having to fabricate. Instead, I settled on the simpler idea of harnessing the power of compressed gas. Instead of using a high mechanical advantage lever to push a piston, compressed CO2 would be dispensed from a small and inexpensive 12g or 16g cartridge which would then generate the requisite pressure to properly extract espresso. This concept is not actually novel; both an unsuccessful kickstarter and a now-defunct handheld espresso maker (with a fanatical user base) employed this mechanism.

But let's take a step back and review the past 25 years leading to this decision.

In this write-up, we’ll delve into how, through differential fuzzing, we uncovered a bug in Go’s exp/net HTML’s tokenizer. We’ll show potential XSS implications of this flaw. Additionally, we’ll outline how Google assessed this finding within their VRP program and guide how to engage and employ fuzzing to evaluate your software.

Go 1.21 adds a new port targeting the WASI preview 1 syscall API through the new GOOS value wasip1. This port builds on the existing WebAssembly port introduced in Go 1.11.

WebAssembly (Wasm) is a binary instruction format originally designed for the web. It represents a standard that allows developers to run high-performance, low-level code directly in web browsers at near-native speeds.

Go first added support for compiling to Wasm in the 1.11 release, through the js/wasm port. This allowed Go code compiled using the Go compiler to be executed in web browsers, but it required a JavaScript execution environment.

As the use of Wasm has grown, so have use cases outside of the browser. Many cloud providers are now offering services that allow the user to execute Wasm executables directly, leveraging the new WebAssembly System Interface (WASI) syscall API.

Cgo calls take about 40ns, about the same time encoding/json takes to parse a single digit integer. On my 20 core machine Cgo call performance scales with core count up to about 16 cores, after which some known contention issues slow things down.

Release day classic! Fixed two bugs not noticed until just after release. One was a crash in the markdown parser which ironically broke the 0.2 release announcement.

Pushed an emergency fix, will resolve with a better fix in time.

Also trying out committing release numbers to the in tree version string.

New release. Lots of features and fixes.

Notifications, chat, (experimental) filters. The UI is basically the same, but lots of stuff reworked so it's more obvious what you're doing and where you're going.

I think this is approaching my vision for the software. It's not done, but all the pieces are in place.

=== 0.3.0 Imperfect Future

• Subscribe to post for comment notifications.
• Very basic search feature.
• Syntax highlighting for code blocks.
• More consistently useful logging.
• Experimental filters.
• Inline images in posts.
• Cleaner UI and navigation.
• Dark mode.
• Improved URL scheme.
• Previews for picture groups.
• Normalize some links (youtube only atm).
• Improved federation.
• Include replies collection in posts.
• Background refresh.
• Group chat.
• A little more tag support.
• Nicer online help.
• Detect recent duplicate links.
• Site alerts, woop, woop.
• Initial support for featured posts.
• Notifications for most events.

It was obvious already before that NVD really does not try very hard to actually understand or figure out the problem they grade. In this case it is quite impossible for me to understand how they could come up with this severity level. It’s like they saw “integer overflow” and figure that wow, yeah that is the most horrible flaw we can imagine, but clearly nobody at NVD engaged their brains nor looked at the “vulnerable” code or the patch that fixed the bug. Anyone that looks can see that this is not a security problem.

The vulnerability should be obvious: at some point in the boot process, the VMK transits unencrypted between the TPM and the CPU. This means that it can be captured and used to decrypt the disk.

The new log/slog package in Go 1.21 brings structured logging to the standard library. Structured logs use key-value pairs so they can be parsed, filtered, searched, and analyzed quickly and reliably. For servers, logging is an important way for developers to observe the detailed behavior of the system, and often the first place they go to debug it. Logs therefore tend to be voluminous, and the ability to search and filter them quickly is essential.

Very basic, only the site: operator and plain text is implemented, but if you were worried that you may have missed out on some twitter drama, it's now only a few keystrokes away.