Skip to content

Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.8.2 (master) - #1040

Open
red-hat-konflux[bot] wants to merge 1 commit into
masterfrom
konflux/mintmaker/master-master/github.com-oapi-codegen-oapi-codegen-v2-2.x
Open

Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.8.2 (master)#1040
red-hat-konflux[bot] wants to merge 1 commit into
masterfrom
konflux/mintmaker/master-master/github.com-oapi-codegen-oapi-codegen-v2-2.x

Conversation

@red-hat-konflux

@red-hat-konflux red-hat-konflux Bot commented Oct 23, 2026 •
edited by sourcery-ai Bot
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
github.com/oapi-codegen/oapi-codegen/v2 v2.7.1 → v2.8.2 age confidence

Release Notes

oapi-codegen/oapi-codegen (github.com/oapi-codegen/oapi-codegen/v2)

v2.8.2: : Security fixes for code generation

Compare Source

🎉 Notable changes

This is a security release on top of v2.8.1. It addresses two further security findings reported against oapi-codegen, both in code generation:

Both only matter when you generate code from a specification, or a document it references, that you do not control. Thanks to @​manus-use for reporting them.

Implicit discriminator mapping keys are validated

When a discriminated oneOf or anyOf lists a $ref variant that the mapping does not name, the generator maps it under the schema's name and writes that name into the generated ValueByDiscriminator switch. Explicit mapping keys were already checked, but the implicit ones were not, and a schema name is otherwise allowed to contain quotes. The derived key is now validated like an explicit one, including when the union is assembled by an allOf merge from a member holding the variants and another holding the discriminator, and a backslash is now rejected in any mapping key, since it would start an escape sequence in the generated case label. A null-typed branch, which the generator skips as a nullability marker, is left alone.

The contents of whole-document $refs are validated

A $ref without a fragment, such as $ref: ./other.yaml, has no name the generated code could refer to, so the generator inlines the referenced document as if it were written in place. Spec validation stopped at every $ref on the assumption that external content is never copied into the output, so the property names, parameter names and header names of such a document reached struct tags and string literals unchecked. The validator now walks a whole-document reference's contents for schemas, parameters, request bodies, responses, headers and callbacks, visiting each document once. References with a fragment are still not followed, and a document replaced by an x-go-type override is not walked either, since none of it reaches the generated code.

As with v2.8.1, valid specifications generate byte-for-byte the same code as before; a specification that would have produced code it had no business producing is now rejected with an error that points at the offending value.

🐛 Bug fixes

  • Validate implicit discriminator mapping keys and the contents of whole-document $refs (2.8.x backport) (#​2649) @​mromaszewicz

Sponsors

We would like to thank our sponsors for their support during this release.

DevZero logo

Cybozu logo

We'd also like to thank Greptile for allowing our project to use their code review system.

Greptile logo

v2.8.1: : Security fixes for codegen and at runtime

Compare Source

🎉 Notable changes

This is a security release on top of v2.8.0. It addresses five security findings reported against oapi-codegen:

Four of the five only matter when you generate code from a specification you do not control. The first one affects running servers, so please upgrade the generated code and the oapi-codegen/runtime and validation middleware modules together, as described below.

Allow-listing the remote documents a specification may reference

oapi-codegen resolves external $refs while it loads a specification. Until now it fetched any http(s) URL a document named, so a specification written by someone else could make the generator reach any host the build machine can see.

There is a new top-level configuration option, allow-remote-refs-from. Each entry is the URL of a referenced document exactly as it appears in the $ref, without the #... fragment, or "*" to allow any URL:

allow-remote-refs-from:
  - https://raw.githubusercontent.com/example/specs/main/common.yaml

For compatibility, this release defaults the option to "*" when it is omitted, so existing configurations keep working unchanged. The next minor release will default to refusing remote references. If your specification downloads other documents at generation time, tighten this now by listing them, or set the option to [] to refuse them all.

Better still, for reproducible builds, download the specifications you depend on, commit them next to your own, and reference them by relative path. References to local files are always followed, with no allow-listing involved, and your generated code no longer depends on a remote host being up and unchanged.

Strict servers bind the value the validation middleware validated

A validation middleware decodes the JSON request body to validate it, and the generated strict server then decoded it a second time. encoding/json matches member names case-insensitively, so a body such as

{"role": "user", "ROLE": "admin"}

validates as role: user but was bound as Role: "admin", bypassing the schema's constraints.

Strict servers for every supported framework now bind the value the middleware already validated, with exact member-name matching, and only fall back to decoding the body themselves when no validated value is present. For the fix to take effect you need all three of:

  • code generated with this release;
  • github.com/oapi-codegen/runtime v1.8.0 or later;
  • a validation middleware that keeps the validated value, which the following versions do by default:
    • github.com/oapi-codegen/nethttp-middleware v1.3.1
    • github.com/oapi-codegen/echo-middleware v1.2.1
    • github.com/oapi-codegen/echo-v5-middleware v0.2.1
    • github.com/oapi-codegen/gin-middleware v1.2.1
    • github.com/oapi-codegen/iris-middleware v1.2.1
    • github.com/oapi-codegen/fiber-middleware v1.3.0
    • github.com/oapi-codegen/fiber-v3-middleware v0.3.0

Without them the generated code behaves as before, so the upgrade is safe to roll out in any order, but the fix is only in effect once all three are updated.

Fewer specification strings reach the generated code unescaped

Every string that the generator copies from a specification into Go source is now either emitted through strconv.Quote or checked before generation: content types in the webhook and callback initiators, the Echo per-operation middleware key, security scopes, non-string enum values (which must now be number or boolean literals), response status keys, component names, response header styles, and, when server-urls is enabled, server names, variables and their enum values. Valid specifications generate byte-for-byte the same code as before; a specification that would have produced code it had no business producing is now rejected with an error that points at the offending value.

🐛 Bug fixes

Sponsors

We would like to thank our sponsors for their support during this release.

DevZero logo

Cybozu logo

We'd also like to thank Greptile for allowing our project to use their code review system.

Greptile logo

v2.8.0: : OpenAPI 3.1, fewer assumptions, and a giant bug hunt

Compare Source

OpenAPI 3.1, webhooks, callbacks, and a lot of polish

This is a big one. After a long stretch of internal refactoring across the last couple of releases, we've been able to land some features that have been on the wishlist for years, most notably initial OpenAPI 3.1 support. As always, the full, automatically-generated changelog is at the bottom, and the sections below call out the things you'll actually want to read before upgrading.

When this project was originally released, it supported a narrow set of OpenAPI features, and over time, it has grown from generating code for hand crafted, structurally tight specifications, to very complex, and often messy specifications. I don't think we can ever handle every specification, however, over time, we're going to give users control over as many behaviors as possible, so that our assumptions, which can't be right for everyone, are configurable. More changes of this form will continue to come in the upcoming releases.

Before you upgrade

A couple of housekeeping notes up front:

  • Go 1.25 is now required. If you're not there yet, you'll need to bump your toolchain before pulling this in. We had to update to 1.25 to pull in a kin-openapi that supports OpenAPI 3.1
  • Use generated code with runtime v1.6.0 or newer. Several features in this release (the new Duration type, escaped-path-parameter handling, typed response headers) rely on functionality that landed in the runtime, so make sure you're on github.com/oapi-codegen/runtime v1.6.0+ when you regenerate.

☢️ Breaking changes

We try hard to avoid breaking changes, and when we can't, to make them narrow or configurable.

Trailing-slash routes on the net/http server no longer act as catch-alls (#​2460)

This one only affects the standard-library net/http server (the one built on ServeMux). It's a correctness fix, which is why we decided to just do it rather than hide it behind a flag.

Here's the problem: a ServeMux pattern ending in / matches the entire subtree beneath it, but an OpenAPI path ending in / means exactly that path and nothing deeper. So we were both mismatching the spec's semantics and, worse, panicking at registration time when two such patterns overlapped ambiguously. We now anchor any trailing-slash path with {$} so it matches only what the spec says it should.

The result: if your spec has trailing-slash paths, requests to deeper URLs that used to get swallowed by the catch-all will now correctly return 404. (ServeMux still issues its usual 307 redirect from the un-slashed path to the canonical one.) If you were relying on the old subtree behavior, that was never what your spec actually declared.

Security scopes are no longer emitted by default (#​2440)

Generated servers used to emit per-scheme context key types (bearerAuthContextKey and friends), scope constants (BearerAuthScopes), and per-operation context stores that flattened your spec's security requirements into the request context. We've stopped emitting these by default.

The reason is that this machinery is fundamentally broken: it can't represent alternative (OR), combined (AND), or anonymous ({}) security requirements, so it quietly encourages people to build authorization logic on top of a representation that doesn't actually capture what the spec says. Authentication and authorization belong in the request validation middleware, which evaluates the real security requirements directly.

If you genuinely need the old emission back, there's an opt-in flag:

compatibility:
  enable-auth-scopes-on-context: true

We'd encourage you to migrate to the validation middleware instead, but the flag is there if you need a bridge.

🎉 Notable changes

OpenAPI 3.1 support (#​2336)

Finally, after several years of requests, we've been able to close #​373, adding OpenAPI 3.1 support. We've added support for callbacks and webhooks, and we support several OpenAPI 3.1 idioms, such as flexible enums via oneOf, as well as type: [T, "null"]-style nullability. This is initial support, so we'd love to hear about the specs it doesn't yet handle well.

While oapi-codegen would love to see an increase in sponsorship to make the project more sustainable, if we had to choose, we'd prefer to see that money go upstream to kin-openapi, which is the OpenAPI library that powers us and a large part of the Go ecosystem.

We're working to sponsor Pierre, the solo kin-openapi maintainer, with a significant portion of our own funds, and really hope that y'all consider sponsorship to support the important work that he does.

The OpenAPI 3.1 support in kin-openapi wouldn't have been possible without Pierre's maintainership, and a number of external contributors.

Optionally hoist anonymous schemas into named types (#​2366)

You can now opt in to having every anonymous, inline schema hoisted into a top-level named type, with a name derived from its location (path) in the spec. If you've ever wanted a real, referenceable Go type for some deeply-nested inline object instead of an anonymous struct, this is for you.

We now validate the spec before generating (#​2435)

oapi-codegen has always been extremely permissive about the specs it accepts, which is great until a malformed spec leads to non-compiling generated code and a confusing debugging session. We now run a validation pass over the spec before code generation, which lets us catch a class of errors that are hard to detect during codegen and abort early with a meaningful error message instead of emitting broken Go. As a bonus, this makes us considerably more resilient to malicious or garbage input.

Handlers are now registered in spec order (#​2465, #​2477)

Some routers make matching decisions based on the order in which handlers are registered. To make behavior predictable and match your intent, we now emit route registrations in the same order the paths appear in your spec, so you have control of the order by controlling the order in which you declare them. To go back to the previous behavior, add this to your configuration:

compatibility:
  sort-handler-registrations: true
format: duration now maps to a real Duration type (#​2458)

A type: string, format: duration schema used to fall through to a plain Go string, leaving all the parsing and validation up to you. The runtime now ships an RFC 3339 Duration type (added in runtime v1.5.0), and the default type mapping resolves format: duration to it, right alongside the other formats like date, uuid, email, and binary.

This does change the generated type for specs already using format: duration. If you'd rather keep the old plain-string behavior, map the format back explicitly in your config:

output-options:
  type-mapping:
    string:
      formats:
        duration:
          type: string
The rest of the notables and new features

A quick rundown of the other behavior-affecting changes worth knowing about:

  • Fiber v3 support (#​2431, thanks @​dillonbuchanan-maia-tech) — codegen now targets the stable Fiber v3, in addition to v2.
  • Anonymous security alternatives are allowed (#​2432, thanks @​kriptoburak) — an empty {} entry in a security list (i.e. "auth optional here") is now handled correctly.
  • Response models expose schema-extraction helpers (#​2379, thanks @​rd-andreas-tollkoetter) — added functions on response models to make it easier to pull schemas back out.
  • deprecated Godoc is emitted correctly (#​2405, thanks @​jamietanna) — deprecation markers now land on the right declarations so your tooling actually flags them.
  • Better generated client Godoc (#​2407, thanks @​jamietanna) — improved documentation comments on generated client code.
  • Escaped-path-parameter handling (#​2457) — generated code now tells the runtime whether the router delivers already-escaped path parameter values, fixing a class of decoding bugs (this is part of why you want runtime v1.6.0+).
  • Typed response headers (#​2462, #​2463) — response headers are now parsed into typed fields on the client response wrappers.

There's a great deal more in the way of bug fixes below — this release fixes a large batch of long-standing issues in the aggregate-type (allOf/anyOf/oneOf), discriminator, and external-$ref code paths. Thank you to everyone who reported issues and sent PRs.

☢️ Breaking changes

🎉 Notable changes

🚀 New features and improvements

🐛 Bug fixes

📝 Documentation updates

👻 Maintenance

📦 Dependency updates

33 changes

Sponsors

We would like to thank our sponsors for their support during this release.

DevZero logo

Cybozu logo

We'd also like to thank Greptile for allowing our project to use their code review system.

Greptile logo

v2.7.2: More fixes for code injection issues

Compare 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 an init() 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-codegen based 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.

DevZero logo

Cybozu logo

We'd also like to thank Greptile for allowing our project to use their code review system.

Greptile logo

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 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.

  • If you want to rebase/retry this PR, check this box

To execute skipped test pipelines write comment /ok-to-test.

Documentation

Find out how to configure dependency updates in MintMaker documentation or see all available configuration options in Renovate documentation.

Summary by Sourcery

Enhancements:

  • Update the indirect oapi-codegen dependency to v2.8.2, incorporating upstream OpenAPI 3.1 support and cumulative code-generation improvements and security fixes.

@sourcery-ai

sourcery-ai Bot commented Oct 23, 2026 •
edited
Loading

Copy link
Copy Markdown

Reviewer's Guide

Configuration

Upgrade oapi-codegen to v2.8.2, including the corresponding checksum updates.

  • go.mod L78
  • go.sum L331-332
Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

sourcery-ai[bot]
sourcery-ai Bot reviewed Oct 23, 2026
View reviewed changes

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've reviewed your changes and they look great!

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

@red-hat-konflux
red-hat-konflux Bot force-pushed the konflux/mintmaker/master-master/github.com-oapi-codegen-oapi-codegen-v2-2.x branch from cc46c07 to 0b951fc Compare October 27, 2026 01:30
@red-hat-konflux red-hat-konflux Bot changed the title Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.8.0 (master) Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.8.1 (master) Oct 27, 2026
@red-hat-konflux
red-hat-konflux Bot force-pushed the konflux/mintmaker/master-master/github.com-oapi-codegen-oapi-codegen-v2-2.x branch 2 times, most recently from 776e69b to a5715a5 Compare November 4, 2026 00:53
@red-hat-konflux red-hat-konflux Bot changed the title Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.8.1 (master) Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.8.2 (master) Nov 4, 2026
@red-hat-konflux
red-hat-konflux Bot force-pushed the konflux/mintmaker/master-master/github.com-oapi-codegen-oapi-codegen-v2-2.x branch from a5715a5 to 3cd9b9b Compare November 7, 2026 01:03
@red-hat-konflux
Update module github.com/oapi-codegen/oapi-codegen/v2 to v2.8.2
cf74b68 
Signed-off-by: red-hat-konflux <126015336+red-hat-konflux[bot]@users.noreply.github.com>
@red-hat-konflux
red-hat-konflux Bot force-pushed the konflux/mintmaker/master-master/github.com-oapi-codegen-oapi-codegen-v2-2.x branch from 3cd9b9b to cf74b68 Compare November 8, 2026 00:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@sourcery-ai sourcery-ai[bot] sourcery-ai[bot] left review comments
@loadtheaccumulator loadtheaccumulator Awaiting requested review from loadtheaccumulator loadtheaccumulator is a code owner
@rexwhite rexwhite Awaiting requested review from rexwhite rexwhite is a code owner
@gravitypriest gravitypriest Awaiting requested review from gravitypriest gravitypriest is a code owner
@prichard77 prichard77 Awaiting requested review from prichard77 prichard77 is a code owner
@kami-nashi kami-nashi Awaiting requested review from kami-nashi kami-nashi is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants