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=1flag restores the previous behavior. - Production impact
- The source does not say.
- Try it
- Run a Go program that creates a file with
os.OpenFileusingos.ModeStickyon 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
// 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.Readerparameter for randomness and always use the system random source (crypto/internal/sysrand.Read). AGODEBUG=cryptocustomrand=1flag restores the old behavior. A newtesting/cryptotestpackage will allow deterministic randomness in tests. - Production impact
- The source does not say.
- Try it
- Compile a program that calls
rsa.GenerateKeywith a customio.Readerand 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.
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
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