golang 1.19 tags aren't properly populated

[twk3]

This project now has go 1.19 tags, but the openssl branch hasn't been pushed up, and the tags aren't pointing at a ready to build golang source. So isn't currently working the way the previous tags and branches were.

Was this a mistake, or is there still work pending for the 1.19 releases?

[dbenoit17]

@twk3 we've started to take a different approach from Go 1.19 forward. Instead of hosting a full Go source tree with the openssl changes dispersed throughout, we've refactored all of the openssl code into its own standalone module, which can be vendored directly into an upstream Go tree. This helps both with porting the changes to new major versions, as well as making the changes more clear between golang-fips and upstream Go.

The go1.19-fips-release branch and corresponding Go 1.19 tags contain the setup scripts and patches required to vendor the openssl module into an upstream Go 1.19 tree. Currently there are two ways to set it up.

If your build environment has network accessibility, you can run the scripts/full-generate-repo.sh script to generate a Go tree that is patched to use the vendored openssl module.

The other option is to download the upstream Go sources and apply 000-initial-setup.patch and 001-initial-openssl-for-fips.patch directly to the upstream Go source tree whose version corresponds to the tag.

We probably need to document this more thoroughly. Let's leave this issue open until the user experience is more clear.

[twk3]

@dbenoit17 thanks for clarifying

I went ahead and accounted for this in our build system. For now I'm using full-generate-repo.sh But it sounds like vendoring it in and apply the patches would actually be better long term.

I think ideally an example of how the vendoring is intended to be pulled into the upstream checkout. And a new script for applying the patches (would currently just be the last part of the full-generate-repo scriot). In case patch sorting becomes important and is something that ends up accounted for in the script, seems better than having all the builders needing to see the problem and re-apply the sorting.