chore(deps): update module github.com/oapi-codegen/oapi-codegen/v2 to v2.7.2 #118
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "renovate/github.com-oapi-codegen-oapi-codegen-v2-2.x"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
v2.7.1→v2.7.2Release Notes
oapi-codegen/oapi-codegen (github.com/oapi-codegen/oapi-codegen/v2)
v2.7.2: More fixes for code injection issuesCompare Source
String escaping fixes due to more code injection issues
We've had two more code injection issues reported in
oapi-codegen, thanks @Gal3M, @mrostamipoor for these findings.These specific issues are now patches in the main branch and in this v2.7.2 release.
You shouldn't blindly trust OpenAPI specs
This code wasn't originally written assuming code generation from random specs from the internet, and it never took any measures to protect itself from malicious specifications, the assumption being that you control your specification, and that you actually look over generated code.
For example, all these RCE exploits rely on using the package
init()function in the generated code to run some malicious code at package startup. A way to test for this is to see whether aninit()function is emitted, which we currently don't do.When working with OpenAPI specifications, especially specs you find on remote servers, you should download the spec locally, run some kind of spec validator on it, like openapi-spec-validator, and only then feed it into oapi-codegen. We're very permissive in accepting broken specifications, intentionally, since people feed a lot of garbage input, but this flexibility also makes us weak to these kinds of attacks. There are hundreds of injection sites in
oapi-codegenbased on my survey.For the next minor release,
v2.8.0, we're going to validate the spec before code generation (#2435), however, since this introduces a new set of failure modes, I don't want to include it in a maintenance release version. The future release is resilient against many forms of injection, and the spec validation has the added benefit that it can generate meaningful error messages for garbage input, where currently, we generate non-compiling code.Until then, please do sanity checks on your input specifications, on the generated output, and don't fetch specs from the internet in your build, commit both the spec locally into your source control, and go through code review. In our repo, we've hooked up Greptile to catch issues like this, and you should also use some code quality tool. We can't possibly protect against every kind of attack with simple heuristics.
Sponsors
We would like to thank our sponsors for their support during this release.
We'd also like to thank Greptile for allowing our project to use their code review system.
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate.
⚠️ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:
The artifact failure details are included below:
File name: go.sum
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.