How to refer to this software as a package name in downstream distributions?

[xnox]

After reading https://github.com/microsoft/go?tab=readme-ov-file#trademarks I am not sure how to best package this edition of patches, and make it not confusing.

Because current name based of URL github-microsoft-go has like 3 trademarks =)

Would the below be acceptable usage?

name: go-msft-1.22
description: "golang toolchain with https://github.com/microsoft/go patches"

When packaged in WolfiOS see https://github.com/wolfi-dev ?

If above is not acceptable, maybe i can use a codename like "gaufre" (which is french word for gopher ;-))

[dagood]

name: go-msft-1.22
description: "golang toolchain with https://github.com/microsoft/go patches"

I brought this up with others from the microsoft/go team and we think that name and description is fine (it's within the guidelines). Something like "golang toolchain with patches/enhancements from Microsoft" would also be fine.

In case you hadn't noticed already, we release already-patched Go source tar.gz files in our GitHub releases. Those feed into the Azure Linux build system. Taking the patch files directly is also fine of course, especially if you don't want to take all of them. 🙂

[xnox]

Something about xz tarballs downloaded from github is treated as fishy in 2024 =))))))) so will prefer git checkout. Thank you for your response.

[xnox]

go-msft-fips go toolchain compiled with microsoft/go patches applied.

Is what we went with. See https://images.chainguard.dev/directory/image/go-msft-fips/overview Please let me know if anything is out of place.

Note that unlike the images that are provided by https://github.com/microsoft/go-images there is a certified OpenSSL FIPS module included, and the toolchain itself is compiled with the systemcrypto experiment enabled, meaning go install and go get use OpenSSL cryptography in FIPS mode, which is very neat as all the h1 go.sum hashes are verified using FIPS certified cryptography.

[dagood]

I like it! The section on how to interrogate the resulting app binary is particularly interesting and something we haven't tackled yet in our own docs.

Neat to have the compiler running in FIPS mode. 🙂 We (obviously) haven't encountered that requirement yet for our own project.

[xnox]

I like it! The section on how to interrogate the resulting app binary is particularly interesting and something we haven't tackled yet in our own docs.

Neat to have the compiler running in FIPS mode. 🙂 We (obviously) haven't encountered that requirement yet for our own project.

all of that text was written by me, and I have previously contributed (or attempted to contribute to azure docs) and signed appropriate clas or something rather, and it can be licensed/authored at appropriate licenses if you want to incorporate or reuse any of that. But also all instructions there are unlikely to be copyrightable as it recycles publicly available commands - it really is just calling go version -m and explaining what that output prints which is a standard golang toolchain feature.

Separately when chainguard builds FIPS images - we have scripts / checks that parse all of container images, search for any go binaries, and check that they have symbols tables enabled; correct experiment on; cgo on; and exibit symbols pointing at openssl - if any "crypto" imports are present (as we do have some go apps that have no crypto and thus do not link-in anything, most notably gops application). Note that go version -m / or go version -m path/to/extracted/rootfs works recursively scanning all the binaries in a given directory to implement similar validations. Such simple checks have caught mistakes of miss-building application before shipped in fips images.