This site is being rebuilt and some pages are out of date. For current details, write to [email protected]. This notice goes away when the rebuild is done.

No analytics unless you allow it, no tracking. This site keeps in your browser the language you pick, the theme, its colour, which site you chose, the currency on the pricing page and that you closed this notice; signing in adds session cookies. The legal page has the details.

Sign in

Quiet Pager · Radar

What changed in Go, Rust and Solidity this week.

What changed this week, from each project's own release notes, proposals and issues, with an exercise you can run for each change.

Written by a model · reviewed by a person · published Mondays · Atom feed

Archive · Week 30 · Jul 21 – 27, 2025from 2 items

The Go team finalized two proposals that will affect how file permissions and cryptographic randomness are handled on certain platforms. Both changes are accepted and will appear in a future release, with debug flags to preserve the old behavior.

Worth knowingstdlib

os: stop manually setting sticky bit on file creation on *BSD, Solaris

What changed
The Go runtime will no longer attempt to set the sticky bit after file or directory creation on *BSD and Solaris. If the OS does not support this natively, an error will be returned; if it does, the bit will be passed directly. The GODEBUG=insecurestickybits=1 flag restores the previous behavior.
Production impact
The source does not say.
Try it
Run a Go program that creates a file with os.OpenFile using os.ModeSticky on a *BSD or Solaris system and observe the error or the flag‑controlled behavior.
Source
github.com/golang/go/issues/68664
Explain it and run it

Understand it, then run it

When you create a file or directory in Go, the operating system sometimes sets a special flag called the sticky bit. On *BSD and Solaris systems, the Go runtime used to work around a bug by setting this flag manually after the file was created. That workaround could cause race conditions. The change removes that manual step. Now, if you ask for the sticky bit and the OS supports it, the flag is passed straight through; if the OS does not support it, an error is returned. You can still get the old behavior by setting GODEBUG=insecurestickybits=1.

Run it now

Todaygo
// This program demonstrates the new sticky‑bit handling on *BSD and Solaris.
// It attempts to create a file with the sticky bit set. On systems that
// support the sticky bit, the file is created successfully. On systems
// that do not, an error is returned. The GODEBUG flag can be set to
// restore the old behavior, but it is not used here.

package main

import (
	"fmt"
	"os"
)

func main() {
	// Attempt to create a file with the sticky bit.
	f, err := os.OpenFile("sticky_test.txt", os.O_CREATE|os.O_RDWR, os.FileMode(0o644|os.ModeSticky))
	if err != nil {
		fmt.Printf("Error creating file with sticky bit: %v\n", err)
		return
	}
	defer f.Close()
	fmt.Println("File created successfully with sticky bit set (if supported).")
}

What it printed when we ran it on Go 1.27.1

File created successfully with sticky bit set (if supported).

Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.

Worth knowingstdlib

crypto: ignore rand io.Reader where behavior is not specified

What changed
Most crypto APIs will ignore the io.Reader parameter for randomness and always use the system random source (crypto/internal/sysrand.Read). A GODEBUG=cryptocustomrand=1 flag restores the old behavior. A new testing/cryptotest package will allow deterministic randomness in tests.
Production impact
The source does not say.
Try it
Compile a program that calls rsa.GenerateKey with a custom io.Reader and verify that the key generation no longer depends on that reader.
Source
github.com/golang/go/issues/70942

Exercise

Exercise – Sticky bit on file creation

Create a file named sticky.txt with the sticky bit set in the mode (0700|os.ModeSticky). After the file is created, read its permissions back and print whether the sticky bit is actually present on the file system you are running on.

The exercise demonstrates the new behaviour: on *BSD and Solaris the sticky bit is no longer set automatically by the Go runtime, so the file may or may not have it depending on the OS.

Startergo
package main

import (
	"fmt"
	"os"
)

func main() {
	// Create the file with mode 0700 and the sticky bit flag.
	f, err := os.OpenFile("sticky.txt", os.O_CREATE|os.O_WRONLY, 0700|os.ModeSticky)
	if err != nil {
		fmt.Println("create error:", err)
		return
	}
	f.Close()

	// TODO: read the file's mode and print whether the sticky bit is set.
}
Show a solution
Solutiongo
package main

import (
	"fmt"
	"os"
)

func main() {
	// Create the file with mode 0700 and the sticky bit flag.
	f, err := os.OpenFile("sticky.txt", os.O_CREATE|os.O_WRONLY, 0700|os.ModeSticky)
	if err != nil {
		fmt.Println("create error:", err)
		return
	}
	f.Close()

	// Stat the file to get its mode.
	info, err := os.Stat("sticky.txt")
	if err != nil {
		fmt.Println("stat error:", err)
		return
	}
	mode := info.Mode()

	// Check if the sticky bit is set.
	if mode&os.ModeSticky != 0 {
		fmt.Println("Sticky bit is set on sticky.txt")
	} else {
		fmt.Println("Sticky bit is NOT set on sticky.txt")
	}
}

What it printed when we ran it on Go 1.27.1

Sticky bit is set on sticky.txt

Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.

The 60-second version

Hello, everyone. This week the Go team closed two important proposals that will change how your programs handle file permissions and cryptographic randomness. First, the runtime will stop trying to set the sticky bit on file and directory creation on *BSD and Solaris systems. If the operating system can’t set that bit, the call will now return an error instead of silently succeeding. You can still get the old behavior by setting the `GODEBUG=insecurestickybits=1` flag. Second, most cryptographic APIs will ignore the `io.Reader` you pass for randomness and will always use the system’s secure random source. If you need deterministic randomness in tests, the new `testing/cryptotest` package will let you set a global seed. Both changes are accepted and will appear in a future release, with debug flags to preserve the previous behavior.

Written by gpt-oss-20b · claims checked against the sources · archive, not individually reviewed