-
Notifications
You must be signed in to change notification settings - Fork 22
Add support for updating specified modules via go get and record as patch to go.mod, go.sum #63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
b52bf4c
4a7b2b5
690524f
ccea3f0
6895cd0
7b4b2e4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -44,6 +44,25 @@ The archive is generated in the rpm package directory, and can be committed to | |
| for [openSUSE](https://www.opensuse.org), | ||
| [SUSE](https://www.suse.com), and numerous other distributions. | ||
|
|
||
| Upon request, `obs-service-go_modules` will update module versions in the | ||
| `go.mod` file before downloading the vendor modules, regenerate `go.sum` | ||
| file, update the `.changes` file by adding any missing version updates and | ||
| create a patch file for these that can be applied when building the package. | ||
| This feature makes it easy to apply security fixes by updating the vendor | ||
| module list before downloading the modules. | ||
|
|
||
| Taking the version information from a YAML file `obs-service-go_modules` will | ||
| pass every version update to `go get`: | ||
|
|
||
| ``` | ||
| go get <module>@<version> | ||
| ``` | ||
|
|
||
| one-by-one to the unpacked source package before downloading the vendor | ||
| modules. This command will update the package entry and recalculate the | ||
| checksum. | ||
|
|
||
|
|
||
| ## Usage for packagers | ||
|
|
||
| Presently it is assumed the Go application source is distributed as a compressed tarball named | ||
|
|
@@ -116,6 +135,102 @@ The `zstd` format has a clear advantage in speed with reasonable compression rat | |
| and is likely to become the default compression method in a future release. | ||
| Decompression timings are closely matched among `gz`, `xz`, and `zstd` compression methods. | ||
|
|
||
| ## Update Vendor Module Versions | ||
|
|
||
| Optionally, `obs-service-go_modules` will update module versions in `go.mod`, | ||
| recreate `go.sum`, update the `*.changes` file with any change that's missing | ||
| and create a patch that can be applied when building the package. The version | ||
| changes to be applied need to be specified in a YAML file. | ||
|
|
||
| ### Service Parameters | ||
|
|
||
| To do so, specify the name of the YAML file using the service parameter | ||
| `modupdates`. The default is `none` in which case no version update will be | ||
| performed. You can specify the name of the patch file to generate using the | ||
| service parameter `moddiff`. The default is `go-modules.patch`. If multiple | ||
| `.changes` files exist, missing comments will be added to all files. To apply | ||
| this update to a single `.changes` file, you may use the parameter | ||
| `changesfile`. This parameter can be provided multiple times. | ||
|
|
||
| ``` | ||
| <services> | ||
| <service name="go_modules" mode="disabled"> | ||
| <param name="modupdates">go-module-updates.yaml</param> | ||
| <param name="moddiff">go-module.patch</param> | ||
| <param name="changesfile">mypackage.changes</param> | ||
| </service> | ||
| </services> | ||
| ``` | ||
|
|
||
| ### YAML File | ||
|
|
||
| The YAML file has the following format: | ||
|
|
||
| ``` | ||
| go_module: | ||
| module_updates: | ||
| - uri: <module>@<version> | ||
| comment: <comment> | ||
| ``` | ||
|
|
||
| The module information is represented as a list of associative arrays where | ||
| each array represents a single change so multiple changes can be applied. The | ||
| value to the `uri:` key in each array represents the module/version | ||
| information that is passed to `go get` verbatim. | ||
|
|
||
| The optional `comment:` key represents additional information that will help | ||
| to determine the purpose of the version update which will be used to generate | ||
| an entry for the `.changes` file. If no comment is specified, a default comment | ||
| will be used. | ||
|
|
||
| ### Example | ||
|
|
||
| Using the [apptainer](https://github.com/apptainer/apptainer) HPC container | ||
| platform as an example to demonstrate module version updates the `_service` | ||
| file: | ||
|
|
||
| ``` | ||
| <services> | ||
| <service name="go_modules" mode="disabled"> | ||
| <param name="modupdates">go-module-updates.yaml</param> | ||
| <param name="moddiff">go-module.patch</param> | ||
| </service> | ||
| </services> | ||
|
|
||
| ``` | ||
|
|
||
| together with the YAML file `go-module-updates.yaml` (as specified in the | ||
| `_service` file): | ||
|
|
||
| ``` | ||
| go_module: | ||
| module_updates: | ||
| - uri: golang.org/x/net@v0.23.0 | ||
| comment: "This prevents an attacker from sending an arbitrary amount of\n | ||
| http/2 header data CVE-2023-45288 (bnc#1236527)." | ||
| ``` | ||
|
|
||
| produce: | ||
| 1. a file `go-module.patch` | ||
| 2. an entry in the file `apptainer.changes`: | ||
|
|
||
| ``` | ||
| ------------------------------------------------------------------- | ||
| Wed Jan 29 09:47:49 UTC 2025 - Egbert Eich <eich@suse.com> | ||
|
|
||
| - Update vendor module dependencies: | ||
| * Update golang.org/x/net to v0.23: | ||
| This prevents an attacker from sending an arbitrary amount of | ||
| http/2 header data CVE-2023-45288 (bnc#1236527). | ||
| * Update go-module.patch. | ||
| ``` | ||
|
|
||
| 3. a `vendor.tar.gz` file with updated vendor modules. | ||
|
|
||
| Note, that the `moddiff` parameter in the service file is set to the default | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So, why not just omit it there, and omit this paragraph here?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is to avoid confusion. I can move the comment up - in front of the example - but I would like to leave this with all options in place to serve as a template. |
||
| value and thus could be omitted. | ||
|
|
||
|
|
||
| ## OBS Source Service Build Mode support | ||
|
|
||
| OBS Source Services can run in one of several modes as shown in | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is that line here when it is the default value? Is there some hidden purpose for it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's an example of / template for the service file. It's not uncommon to use the default value in examples, is it? There's no hidden agenda, no.