Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft Go 1.24 FIPS changes

devblogs.microsoft.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Microsoft Go 1.24 FIPS changes

#61

Post by arp242 »

dstroot wrote: post #45

TIL there are multiple flavors of Golang including “Microsoft Go”. Wow - I’ve been away from Golang too long. I was initially shocked and then kind of sad that Go is not so simple anymore.

https://github.com/microsoft/go/blob/microsoft/main/patches/...

Upstream Go tricks Windows into enabling long path support by setting an undocumented flag in the PEB. The Microsoft Go fork can't use undocumented APIs, so this commit removes the hack.

There is no documented way to enable long path support from within the process, so this this is a breaking change for the Microsoft Go fork. Note that the Go standard library makes a best effort to support long paths by using the `\\?\` prefix when possible, so this change should only affect long relative paths, which can't be used with the `\\?\`.

lol?

Re: Microsoft Go 1.24 FIPS changes

#62

Post by cpuguy83 »

Tempest1981 wrote: post #57
dstroot wrote: post #45

TIL there are multiple flavors of Golang including “Microsoft Go”. Wow - I’ve been away from Golang too long. I was initially shocked and then kind of sad that Go is not so simple anymore.

Is the fragmentation due to FIPS 140-2 alone? Or are there other differences? Why couldn't the crypto changes be rolled into mainstream Go?

The crypto changes are being rolled into mainstream Go, just that mainstream Go does not want the openssl/SCOSSL/SymCrypt parts.

Re: Microsoft Go 1.24 FIPS changes

#63

Post by adonovan »

dagss wrote: post #40
AaronFriel wrote: post #16

Earlier quoted context omitted.

The comment is accurate that if you don't need this, you can ignore it. It's likely not an avenue for backdoors. I wouldn't say it's security theater but it just isn't meaningful to most. As for why not a library? Go has a pretty big "batteries included" implementation for networking. For customers demanding FIPS compliance it isn't enough to say, write all of your own application code to use a package that does FIPS…

Wouldn't declaring the "replace" directive in go.mod once take effect for all the dependencies?

"replace" is an operation on modules. Networking is part of the standard library, which is a single (very special) module. Even if you could "replace" std, it would not really be less than creating a fork.

Re: Microsoft Go 1.24 FIPS changes

#64

Post by Tempest1981 »

cpuguy83 wrote: post #62
Tempest1981 wrote: post #57

Earlier quoted context omitted.

Is the fragmentation due to FIPS 140-2 alone? Or are there other differences? Why couldn't the crypto changes be rolled into mainstream Go?

The crypto changes are being rolled into mainstream Go, just that mainstream Go does not want the openssl/SCOSSL/SymCrypt parts.

Ah, thanks. This reply also had more FIPS details:

https://news.ycombinator.com/item?id=42966945

Re: Microsoft Go 1.24 FIPS changes

#65

Post by treesknees »

lantastic wrote: post #33
tptacek wrote: post #25

Earlier quoted context omitted.

Whether FIPS 140 is actually a good target for cryptography is another question Answer to that question: it is not. It's a thing you only do when you are forced to by some requisitions process.

Does this mean FIPS-enabled software never runs as such in production (or at all) in environments where it is supposedly mandated?

In some cases that's true, but not all. We have customers who require that our software supports running in a FIPS compliant mode, but never actually end up enabling it in production. But they wouldn't have bought our software without the option of enabling FIPS mode.

Re: Microsoft Go 1.24 FIPS changes

#66

Post by greenavocado »

__s wrote: post #60
AaronFriel wrote: post #13

The upstream Go 1.24 changes and macOS support using system libraries in Microsoft's Go distribution are really significant for the large ecosystem of startups trying to sell to institutions requiring FIPS 140 certified cryptography. For a variety of reasons - including "CGo is not Go" ( https://dave.cheney.net/2016/01/18/cgo-is-not-go ) - using boringcrypto and requiring CGO_ENABLED=1 could be a blocker. Not using s…

I had to deal with FIPS compliance while at MS for FedRAMP compliance. It's not a technical problem, but a compliance problem If you don't need FIPS for compliance you're better off investing in much more useful things for security (more effective linting, test coverage, keeping dependencies up to date, etc)

Is the juice worth the squeeze for FIPS compliance? It sounds absolutely miserable

Re: Microsoft Go 1.24 FIPS changes

#67

Post by rdtsc »

greenavocado wrote: post #66
__s wrote: post #60

Earlier quoted context omitted.

I had to deal with FIPS compliance while at MS for FedRAMP compliance. It's not a technical problem, but a compliance problem If you don't need FIPS for compliance you're better off investing in much more useful things for security (more effective linting, test coverage, keeping dependencies up to date, etc)

Is the juice worth the squeeze for FIPS compliance? It sounds absolutely miserable

Uncle Sam wouldn’t even consider purchasing your product if it doesn’t tick some boxes. Now there are ways to get exceptions if you go high enough up the chain.

But it is a miserable exercise all in all. As you’re implementing it, you think “this is making things worse, less robust or secure, but oh well, that’s the only way it will sell”.

Re: Microsoft Go 1.24 FIPS changes

#68

Post by tete »

dstroot wrote: post #45

TIL there are multiple flavors of Golang including “Microsoft Go”. Wow - I’ve been away from Golang too long. I was initially shocked and then kind of sad that Go is not so simple anymore.

> I was initially shocked and then kind of sad that Go is not so simple anymore.

Yeah, it's really sad. Go basically became like any other language.

Now even fun stuff like net.IP, and a netip, with netip.Addr. Lots of way to write the same thing. And an even further shift from Go initially being something along the lines of "You shouldn't control or even think of the garbage collector" to now having runtime.AddCleanup) as well as more fun hacks to technically stay compatible.

Now, I am not saying that the changes are bad per se, but more that they simply aren't matching the original design/claims/goals. I remember Rob Pike saying things like "The language likely won't change much" other than generics which have been said to likely come since pre-1.0 basically since Go got a website. The idea clearly was to stay simple, but that seems to have been thrown overboard. I wished Go's predecessors (Limo, Alef, et al) or something similar would have made it out of the more researchy state.

But hey looks like some more stable languages get traction. To my complete surprise Ada is making a comeback with [Alire](https://alire.ada.dev/) and such. Not really a Go competitor, but nice to see it's still being worked on.

Re: Microsoft Go 1.24 FIPS changes

#69

Post by __s »

greenavocado wrote: post #66
__s wrote: post #60

Earlier quoted context omitted.

I had to deal with FIPS compliance while at MS for FedRAMP compliance. It's not a technical problem, but a compliance problem If you don't need FIPS for compliance you're better off investing in much more useful things for security (more effective linting, test coverage, keeping dependencies up to date, etc)

Is the juice worth the squeeze for FIPS compliance? It sounds absolutely miserable

Depends on what you mean by juice. Is it worth the money? Yes

Re: Microsoft Go 1.24 FIPS changes

#70

Post by fowl2 »

arp242 wrote: post #61
dstroot wrote: post #45

TIL there are multiple flavors of Golang including “Microsoft Go”. Wow - I’ve been away from Golang too long. I was initially shocked and then kind of sad that Go is not so simple anymore.

https://github.com/microsoft/go/blob/microsoft/main/patches/... Upstream Go tricks Windows into enabling long path support by setting an undocumented flag in the PEB. The Microsoft Go fork can't use undocumented APIs, so this commit removes the hack. There is no documented way to enable long path support from within the process, so this this is a breaking change for the Microsoft Go fork. Note that the Go standard li…

Presumably there's some reason Go can't just use an embedded manifest[1] like everyone else?

Ahh, I'm inferring (from [2]) even with the manifest entry, a system wide registry key is also required to get long paths working:

> I'm working with the Windows security team to find a way to enable long path support without having to modify the registry, just by using the embedded manifest, but the chances of this happening soon are quite low.

[1] https://learn.microsoft.com/en-us/windows/win32/fileio/maxim... [2] https://github.com/golang/go/issues/69853

Post reply on HN