6 ms·

Go 1.24 Is Released

137 points by yurivish 2y ago

rickette 2y ago
Especially happy with the faster map implementation and also with text/template now supporting range-over-func. Go 1.23 introduced range over function types but the latter didn't work in Go templates until now.
quectophoton 2y ago
Nice! I was looking forward to this release because of `GOAUTH`. Hopefully this would finally make it less of a PITA to work with private git repositories, but looking at `go help goauth` I'm not holding my breath.
silisili 2y ago
> When GODEBUG=fips140=only is used, in addition to the above, cryptographic algorithms that are not FIPS 140-3 compliant will return an error or panic. Not sure I love the idea of stdlib panicking on purpose here. I haven't looked at the code, but I wonder if it's just in functions that don't currently return an error for backwards compat...
- sundbry 2y ago
  Then don't set the flag... This kind of behavior is useful when things are only detectable at runtime. Rudimentary test coverage would uproot it.
- studmuffin650 2y ago
  This is a feature that’s required in Government environments. You need a check at runtime to ensure that FIPS is set or you run the risk of breaking compliance. Which leads to inevitable audits and endless meetings. I would much prefer a panic causing an issue for 30 minutes vs. endless days of meetings to set up new controls and validations that will make your life more miserable.
- p_l 2y ago
  As sibling comments mentioned, someone's you want to enforce things. Also consider it a way to avoid hidden bugs, similar to "The server chose violence" [1] [2] as well as how much Postel's law held back interoperability (which is forgotten by many aspect of FIPS certifications) [1] https://cliffle.com/blog/hubris-reply-fault/ https://cliffle.com/blog/hubris-reply-fault/ [2] https://news.ycombinator.com/item?id=40178652 https://news.ycombinator.com/item?id=40178652
- gedw99 2y ago
  I read that will be sorted in go 1.25 https://devblogs.microsoft.com/go/go-1-24-fips-update/ https://devblogs.microsoft.com/go/go-1-24-fips-update/
- Cthulhu_ 2y ago
  The only real alternative is erroring, but those can be caught and ignored - is that something that is desireable when encryption is at stake? Warning log levels should be avoided; it's either important and actionable (error or fatal), or it isn't, in which case it's 'info' log level. I had a blog post about it (appeal to authority) but I can't find it at the moment.
Hixon10 2y ago
What would be an use case for `os.Root`? Based on my understanding ( https://github.com/golang/go/issues/67002 https://github.com/golang/go/issues/67002 ), it is related to security. However, under the hood, it doesn't use `Chroot`, so I could imagine, that eventually someone finds a way to escape from the Root.
- nesarkvechnep 2y ago
  Why would it use `chroot`? Combined with a sandboxing facility, like Capsicum, you can open a directory before entering capability mode and later, you use `os.Root` to open files in the file system tree under the opened directory.
  - Hixon10 2y ago
    > Why would it use `chroot`? I am not sure, is this custom Os.Root implementation good enough to relay on it? I see that it is based on openat, and validation of paths/symlinks. But should we expect CVEs, which will break this protection layer?
    - nesarkvechnep 2y ago
      Let me get my crystal ball.
- duskwuff 2y ago
  chroot only makes sense for applications which can commit to exclusively operating out of a single directory, ever. (It also requires the process to have superuser privileges, so it can't be used by applications which are run as users.) os.Root() is more about putting a "seatbelt" on filesystem operations - like restricting operations related to an application's cache to its cache directory, or restricting a file server to serving files from the appropriate shared directory. It's not the same kind of ironclad guarantee as chroot, but it'll still protect an application from simple directory traversals.
  - Hixon10 2y ago
icelain 2y ago
Finally, generic type aliasing was long overdue
melodyogonna 2y ago
Boring, I like it.
theasisa 2y ago
I am most excited about the new tool flag so I can get rid of ugly tools.go.
eberkund 2y ago
Is it possible to specify tags to use to install tools specified with the tools directive? I tried the following but it doesn't seem to work (it installs without the tags): go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest

137 points by yurivish 2y ago

Especially happy with the faster map implementation and also with text/template now supporting range-over-func. Go 1.23 introduced range over function types but the latter didn't work in Go templates until now.

quectophoton 2y ago

Nice! I was looking forward to this release because of `GOAUTH`. Hopefully this would finally make it less of a PITA to work with private git repositories, but looking at `go help goauth` I'm not holding my breath.

silisili 2y ago

> When GODEBUG=fips140=only is used, in addition to the above, cryptographic algorithms that are not FIPS 140-3 compliant will return an error or panic. Not sure I love the idea of stdlib panicking on purpose here. I haven't looked at the code, but I wonder if it's just in functions that don't currently return an error for backwards compat...

sundbry 2y ago
Then don't set the flag... This kind of behavior is useful when things are only detectable at runtime. Rudimentary test coverage would uproot it.
studmuffin650 2y ago
This is a feature that’s required in Government environments. You need a check at runtime to ensure that FIPS is set or you run the risk of breaking compliance. Which leads to inevitable audits and endless meetings. I would much prefer a panic causing an issue for 30 minutes vs. endless days of meetings to set up new controls and validations that will make your life more miserable.
p_l 2y ago
As sibling comments mentioned, someone's you want to enforce things. Also consider it a way to avoid hidden bugs, similar to "The server chose violence" [1] [2] as well as how much Postel's law held back interoperability (which is forgotten by many aspect of FIPS certifications) [1] https://cliffle.com/blog/hubris-reply-fault/ https://cliffle.com/blog/hubris-reply-fault/ [2] https://news.ycombinator.com/item?id=40178652 https://news.ycombinator.com/item?id=40178652
gedw99 2y ago
I read that will be sorted in go 1.25 https://devblogs.microsoft.com/go/go-1-24-fips-update/ https://devblogs.microsoft.com/go/go-1-24-fips-update/
Cthulhu_ 2y ago
The only real alternative is erroring, but those can be caught and ignored - is that something that is desireable when encryption is at stake? Warning log levels should be avoided; it's either important and actionable (error or fatal), or it isn't, in which case it's 'info' log level. I had a blog post about it (appeal to authority) but I can't find it at the moment.

Hixon10 2y ago

What would be an use case for `os.Root`? Based on my understanding ( https://github.com/golang/go/issues/67002 https://github.com/golang/go/issues/67002 ), it is related to security. However, under the hood, it doesn't use `Chroot`, so I could imagine, that eventually someone finds a way to escape from the Root.

nesarkvechnep 2y ago
Why would it use `chroot`? Combined with a sandboxing facility, like Capsicum, you can open a directory before entering capability mode and later, you use `os.Root` to open files in the file system tree under the opened directory.
- Hixon10 2y ago
  > Why would it use `chroot`? I am not sure, is this custom Os.Root implementation good enough to relay on it? I see that it is based on openat, and validation of paths/symlinks. But should we expect CVEs, which will break this protection layer?
  - nesarkvechnep 2y ago
    Let me get my crystal ball.
duskwuff 2y ago
chroot only makes sense for applications which can commit to exclusively operating out of a single directory, ever. (It also requires the process to have superuser privileges, so it can't be used by applications which are run as users.) os.Root() is more about putting a "seatbelt" on filesystem operations - like restricting operations related to an application's cache to its cache directory, or restricting a file server to serving files from the appropriate shared directory. It's not the same kind of ironclad guarantee as chroot, but it'll still protect an application from simple directory traversals.
- Hixon10 2y ago

icelain 2y ago

Finally, generic type aliasing was long overdue

melodyogonna 2y ago

Boring, I like it.

theasisa 2y ago

I am most excited about the new tool flag so I can get rid of ugly tools.go.

eberkund 2y ago

Is it possible to specify tags to use to install tools specified with the tools directive? I tried the following but it doesn't seem to work (it installs without the tags): go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest