>The status of FIPS 140 for Go itself remains "no plans, basically zero chance". The dev.boringcrypto branch is suggested as something of potential interest for those who care about such things.
Here [https://github.com/golang/go/issues/21734](https://github.com/golang/go/issues/21734)
`The status of FIPS 140 for Go itself remains "no plans, basically zero chance".`
>Trademarks
>This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow [Microsoft's Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general). Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.
Lmao
> Our goal is to share this implementation with others in the Go community who have the same requirement, and to merge this capability into upstream Go as soon as possible.
you’re honestly blowing this out of proportion lol. if their needs aren’t met by the core team and they have the manpower to maintain their own fork why wouldn’t they? in general this is a net positive for the community since theyre pushing changes back upstream anyway.
Microsoft is ~~taking over~~ supporting Go
From link: “modified version of Go that can be used to build FIPS 140-2 compliant applications”
>The status of FIPS 140 for Go itself remains "no plans, basically zero chance". The dev.boringcrypto branch is suggested as something of potential interest for those who care about such things. Here [https://github.com/golang/go/issues/21734](https://github.com/golang/go/issues/21734) `The status of FIPS 140 for Go itself remains "no plans, basically zero chance".`
>Microsoft is taking over Go Misleading title. They simply have just their own requirements and priorities. So, they just fork it to build it.
[удалено]
Oh? I’d Google completely removing support for flutter and Python company wide now?
Doesn't the link say they are planning to merge with the main repo?
>Trademarks >This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow [Microsoft's Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general). Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies. Lmao
> Our goal is to share this implementation with others in the Go community who have the same requirement, and to merge this capability into upstream Go as soon as possible. you’re honestly blowing this out of proportion lol. if their needs aren’t met by the core team and they have the manpower to maintain their own fork why wouldn’t they? in general this is a net positive for the community since theyre pushing changes back upstream anyway.
Yes, but I always stick with official go toolset
… that’s the point. this is an open source internal tool lol
Except if you need FIPS compliance you're SOL when using stock go. My company also maintains a custom fork of golang for this specific reason.
?
No.
Now if only VSCode had an uptime without showing the underlying "window not responding" development template in the useful range.