chore(deps): update security updates [security]#137
Conversation
📝 WalkthroughWalkthroughUpdated the module Go version and advanced multiple dependency versions in Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@go.mod`:
- Line 13: The repo still pulls the vulnerable v2 package
(gopkg.in/go-jose/go-jose.v2 v2.6.3) even though you added
github.com/go-jose/go-jose/v4 v4.1.4; migrate all OIDC-related imports and
usages from the v2 module to the v4 module (replace imports like
"gopkg.in/go-jose/go-jose.v2" with "github.com/go-jose/go-jose/v4" and update
any API differences in the OIDC verification/signature code), remove the v2
requirement from go.mod, then run go mod tidy to prune the old dependency and
verify tests/builds pass; focus changes around the OIDC packages and any files
that reference JWS/JWT types or functions.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 43664be8-9e81-474d-9c5e-68f3d4daa936
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (1)
go.mod
| github.com/formancehq/go-libs/v3 v3.6.1 | ||
| github.com/go-chi/chi/v5 v5.2.4 | ||
| github.com/go-jose/go-jose/v4 v4.1.3 | ||
| github.com/go-jose/go-jose/v4 v4.1.4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Direct go-jose requirements in go.mod =="
rg -n 'go-jose' go.mod
echo
echo "== go-jose imports across repository =="
rg -n --type=go 'go-jose|gopkg\.in/(square/)?go-jose'
echo
echo "== Potential JWE decrypt/parse entry points =="
rg -n --type=go 'ParseEncrypted|ParseEncryptedCompact|ParseEncryptedJSON|\.Decrypt\('Repository: formancehq/auth
Length of output: 650
🌐 Web query:
CVE-2026-34986 GHSA-78h2-9frx-2jm8 go-jose panic DoS JWE
💡 Result:
CVE-2026-34986 (GHSA-78h2-9frx-2jm8) is a Denial of Service (DoS) vulnerability in the go-jose library affecting JWE decryption. When decrypting a JWE object where the 'alg' header specifies a key wrapping algorithm (ending in 'KW'), the library panics, causing a crash. This allows remote attackers to trigger a panic via a specially crafted JWE, leading to DoS. Affected: go-jose versions prior to recent patches (likely v3.0.5, v4.1.4 based on release dates around March-April 2026). Sources confirm the issue via advisory titles and snippets from GitHub Advisory Database, dbugs.ptsecurity, and go-jose repo security overview. Published around April 1-3, 2026. Upgrade to patched versions to mitigate.
Citations:
- 1: https://dbugs.ptsecurity.com/vulnerability/PT-2026-30011
- 2: GHSA-78h2-9frx-2jm8
- 3: https://github.com/go-jose/go-jose/security
- 4: https://pkg.go.dev/github.com/go-jose/go-jose/v3@v3.0.4
- 5: https://pkg.go.dev/github.com/go-jose/go-jose/v4@v4.1.3
- 6: https://github.com/go-jose/go-jose/
🏁 Script executed:
# Check if v2 versions might be affected or if there's a patched v2
rg -i 'v2.6|v2.6.3' go.mod
# Look for actual JWE/decrypt usage in the OIDC code
rg -n --type=go 'Decrypt|Encrypted|ParseEncrypted' pkg/oidc/Repository: formancehq/auth
Length of output: 141
🌐 Web query:
go-jose v2.6.3 CVE-2026-34986 vulnerable patched
💡 Result:
go-jose v2.6.3 is vulnerable to CVE-2026-34986. This CVE, published around April 1, 2026, affects the go-jose library where decrypting certain JWE objects causes a panic if the 'alg' field indicates a key wrapping algorithm (ending in 'KW'). No patch information for v2.6.3 specifically is found; v2 is obsolete per official docs (versions 1 and 2 are deprecated, migrate to v4). The library maintainers recommend using v4 (current stable as of 2026), which likely includes fixes given recent releases up to v4.1.3 and v3.0.5. v2.6.3 was released March 2024, predating the CVE.
Citations:
- 1: GHSA-78h2-9frx-2jm8
- 2: https://dbugs.ptsecurity.com/vulnerability/PT-2026-30011
- 3: https://www.cvedetails.com/vulnerability-list/vendor_id-16259/product_id-36515/Go-jose-Project-Go-jose.html?page=1&order=1&trc=3&sha=b46972038ccb57bc98c7f605416da0b913a872b6
- 4: https://github.com/go-jose/go-jose/
- 5: https://pkg.go.dev/github.com/go-jose/go-jose/v3@v3.0.4
- 6: https://pkg.go.dev/gopkg.in/go-jose/go-jose.v2
🏁 Script executed:
# Search for wrapper functions that might do JWE operations
rg -n --type=go 'jose|jwe|decrypt' pkg/oidc/ -i
# Check how the v4 import is actually used in cmd/serve.go
rg -n -A 5 'github.com/go-jose/go-jose/v4' cmd/serve.goRepository: formancehq/auth
Length of output: 2010
v4.1.4 bump is correct but does not remediate v2 vulnerability; codebase uses v2 for JWS only, not JWE decryption.
Line 13 correctly updates the v4 import to the patched v4.1.4. However, CVE-2026-34986 affects JWE decryption specifically, and the codebase's OIDC modules use gopkg.in/go-jose/go-jose.v2 v2.6.3 exclusively for JWS (signature verification) operations, not JWE. The vulnerable v2.6.3 remains in the dependency graph with no available patches. Since v2 is deprecated per upstream guidance, consider migrating all OIDC imports to v4 to fully remediate the vulnerability and eliminate the obsolete dependency.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@go.mod` at line 13, The repo still pulls the vulnerable v2 package
(gopkg.in/go-jose/go-jose.v2 v2.6.3) even though you added
github.com/go-jose/go-jose/v4 v4.1.4; migrate all OIDC-related imports and
usages from the v2 module to the v4 module (replace imports like
"gopkg.in/go-jose/go-jose.v2" with "github.com/go-jose/go-jose/v4" and update
any API differences in the OIDC verification/signature code), remove the v2
requirement from go.mod, then run go mod tidy to prune the old dependency and
verify tests/builds pass; focus changes around the OIDC packages and any files
that reference JWS/JWT types or functions.
NumaryBot
force-pushed
the
renovate/security
branch
from
4312da8 to
4940f41
Compare
NumaryBot
changed the title
ℹ Artifact update noticeFile name: go.modIn order to perform the update(s) described in the table above, Renovate ran the
Details:
|
There was a problem hiding this comment.
♻️ Duplicate comments (1)
go.mod (1)
28-28:⚠️ Potential issue | 🟠 MajorVulnerable v2 dependency remains in codebase.
The
gopkg.in/go-jose/go-jose.v2 v2.6.3dependency is still present and vulnerable to CVE-2026-34986. As noted in the previous review, v2 is deprecated with no available patches. The codebase should migrate all OIDC-related usage from the v2 module to the v4 module to fully remediate this vulnerability.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@go.mod` at line 28, The go.mod currently pins the deprecated vulnerable module "gopkg.in/go-jose/go-jose.v2 v2.6.3"; replace that dependency with the supported v4 module, update all imports that reference gopkg.in/go-jose/go-jose.v2 to the v4 module path, and adjust any OIDC-related usages (types/functions in files that import jose, e.g., where you use jose.NewEncrypter / jose.Signature / jose.JSONWebKey or similar APIs) to the v4 API changes; after updating import paths and code to match v4, run go mod tidy and rebuild/run tests to ensure compilation and behavior are correct.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@go.mod`:
- Line 28: The go.mod currently pins the deprecated vulnerable module
"gopkg.in/go-jose/go-jose.v2 v2.6.3"; replace that dependency with the supported
v4 module, update all imports that reference gopkg.in/go-jose/go-jose.v2 to the
v4 module path, and adjust any OIDC-related usages (types/functions in files
that import jose, e.g., where you use jose.NewEncrypter / jose.Signature /
jose.JSONWebKey or similar APIs) to the v4 API changes; after updating import
paths and code to match v4, run go mod tidy and rebuild/run tests to ensure
compilation and behavior are correct.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: b3859798-d4c7-4e8c-b7d3-405e6f024723
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (1)
go.mod
2 participants
This PR contains the following updates:
v4.1.3->v4.1.4v1.37.0->v1.43.0v1.37.0->v1.43.0v1.40.0->v1.43.0GitHub Vulnerability Alerts
CVE-2026-34986
Impact
Decrypting a JSON Web Encryption (JWE) object will panic if the
algfield indicates a key wrapping algorithm (one ending inKW, with the exception ofA128GCMKW,A192GCMKW, andA256GCMKW) and theencrypted_keyfield is empty. The panic happens whencipher.KeyUnwrap()inkey_wrap.goattempts to allocate a slice with a zero or negative length based on the length of theencrypted_key.This code path is reachable from
ParseEncrypted()/ParseEncryptedJSON()/ParseEncryptedCompact()followed byDecrypt()on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected.This panic is also reachable by calling
cipher.KeyUnwrap()directly with anyciphertextparameter less than 16 bytes long, but calling this function directly is less common.Panics can lead to denial of service.
Fixed In
4.1.4 and v3.0.5
Workarounds
If the list of
keyAlgorithmspassed toParseEncrypted()/ParseEncryptedJSON()/ParseEncryptedCompact()does not include key wrapping algorithms (those ending inKW), your application is unaffected.If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the
encrypted_keyfield is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second.).Thanks
Thanks to Datadog's Security team for finding this issue.
Go JOSE Panics in JWE decryption
CVE-2026-34986 / GHSA-78h2-9frx-2jm8
More information
Details
Impact
Decrypting a JSON Web Encryption (JWE) object will panic if the
algfield indicates a key wrapping algorithm (one ending inKW, with the exception ofA128GCMKW,A192GCMKW, andA256GCMKW) and theencrypted_keyfield is empty. The panic happens whencipher.KeyUnwrap()inkey_wrap.goattempts to allocate a slice with a zero or negative length based on the length of theencrypted_key.This code path is reachable from
ParseEncrypted()/ParseEncryptedJSON()/ParseEncryptedCompact()followed byDecrypt()on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected.This panic is also reachable by calling
cipher.KeyUnwrap()directly with anyciphertextparameter less than 16 bytes long, but calling this function directly is less common.Panics can lead to denial of service.
Fixed In
4.1.4 and v3.0.5
Workarounds
If the list of
keyAlgorithmspassed toParseEncrypted()/ParseEncryptedJSON()/ParseEncryptedCompact()does not include key wrapping algorithms (those ending inKW), your application is unaffected.If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the
encrypted_keyfield is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second.).Thanks
Thanks to Datadog's Security team for finding this issue.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
CVE-2026-39882
overview:
this report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory
bytes.Bufferwithout a size cap.this is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can mitm the exporter connection).
severity
HIGH
not claiming: this is a remote dos against every default deployment.
claiming: if the exporter sends traces to an untrusted collector endpoint (or over a network segment where mitm is realistic), that endpoint can crash the process via a large response body.
callsite (pinned):
permalinks (pinned):
root cause:
each exporter client reads
resp.Bodyusingio.Copy(&respData, resp.Body)into abytes.Bufferon both success and error paths, with no upper bound.impact:
a malicious collector can force large transient heap allocations during export (peak memory scales with attacker-chosen response size) and can potentially crash the instrumented process (oom).
affected component:
repro (local-only):
unzip poc.zip -d poc cd poc make canonical resp_bytes=33554432 chunk_delay_ms=0expected output contains:
control (same env, patched target):
unzip poc.zip -d poc cd poc make control resp_bytes=33554432 chunk_delay_ms=0expected control output contains:
attachments: poc.zip (attached)
PR_DESCRIPTION.md
attack_scenario.md
poc.zip
Fixed in: https://github.com/open-telemetry/opentelemetry-go/pull/8108
opentelemetry-go: OTLP HTTP exporters read unbounded HTTP response bodies
CVE-2026-39882 / GHSA-w8rr-5gcm-pp58
More information
Details
overview:
this report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory
bytes.Bufferwithout a size cap.this is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can mitm the exporter connection).
severity
HIGH
not claiming: this is a remote dos against every default deployment.
claiming: if the exporter sends traces to an untrusted collector endpoint (or over a network segment where mitm is realistic), that endpoint can crash the process via a large response body.
callsite (pinned):
permalinks (pinned):
root cause:
each exporter client reads
resp.Bodyusingio.Copy(&respData, resp.Body)into abytes.Bufferon both success and error paths, with no upper bound.impact:
a malicious collector can force large transient heap allocations during export (peak memory scales with attacker-chosen response size) and can potentially crash the instrumented process (oom).
affected component:
repro (local-only):
unzip poc.zip -d poc cd poc make canonical resp_bytes=33554432 chunk_delay_ms=0expected output contains:
control (same env, patched target):
unzip poc.zip -d poc cd poc make control resp_bytes=33554432 chunk_delay_ms=0expected control output contains:
attachments: poc.zip (attached)
PR_DESCRIPTION.md
attack_scenario.md
poc.zip
Fixed in: https://github.com/open-telemetry/opentelemetry-go/pull/8108
Severity
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
CVE-2026-39883
Summary
The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin
ioregcommand to use an absolute path but left the BSDkenvcommand using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.Root Cause
sdk/resource/host_id.goline 42:Compare with the fixed Darwin path at line 58:
The
execCommandhelper atsdk/resource/host_id_exec.gousesexec.Command(name, arg...)which searches$PATHwhen the command name contains no path separator.Affected platforms (per build tag in
host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.The
kenvpath is reached when/etc/hostiddoes not exist (line 38-40), which is common on FreeBSD systems.Attack
go.opentelemetry.io/otel/sdkkenvbinary earlier in$PATHhostIDReaderBSD.read()callsexec.Command("kenv", ...)which resolves to the malicious binarySame attack vector and impact as CVE-2026-24051.
Suggested Fix
Use the absolute path:
On FreeBSD,
kenvis located at/bin/kenv.opentelemetry-go: BSD kenv command not using absolute path enables PATH hijacking
CVE-2026-39883 / GHSA-hfvc-g4fc-pqhx
More information
Details
Summary
The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin
ioregcommand to use an absolute path but left the BSDkenvcommand using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.Root Cause
sdk/resource/host_id.goline 42:Compare with the fixed Darwin path at line 58:
The
execCommandhelper atsdk/resource/host_id_exec.gousesexec.Command(name, arg...)which searches$PATHwhen the command name contains no path separator.Affected platforms (per build tag in
host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.The
kenvpath is reached when/etc/hostiddoes not exist (line 38-40), which is common on FreeBSD systems.Attack
go.opentelemetry.io/otel/sdkkenvbinary earlier in$PATHhostIDReaderBSD.read()callsexec.Command("kenv", ...)which resolves to the malicious binarySame attack vector and impact as CVE-2026-24051.
Suggested Fix
Use the absolute path:
On FreeBSD,
kenvis located at/bin/kenv.Severity
CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Release Notes
go-jose/go-jose (github.com/go-jose/go-jose/v4)
v4.1.4Compare Source
What's Changed
Fixes Panic in JWE decryption. See GHSA-78h2-9frx-2jm8
Full Changelog: go-jose/go-jose@v4.1.3...v4.1.4
open-telemetry/opentelemetry-go (go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp)
v1.43.0: /v0.65.0/v0.19.0Compare Source
Added
IsRandomandWithRandomonTraceFlags, andIsRandomonSpanContextingo.opentelemetry.io/otel/tracefor W3C Trace Context Level 2 Random Trace ID Flag support. (#8012)
WithServiceingo.opentelemetry.io/otel/sdk/resource. (#7642)DefaultWithContextandEnvironmentWithContextingo.opentelemetry.io/otel/sdk/resourceto support plumbingcontext.Contextthrough default and environment detectors. (#8051)attribute.EMPTY) ingo.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc. (#8038)attribute.EMPTY) ingo.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc. (#8038)attribute.EMPTY) ingo.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc. (#8038)attribute.EMPTY) ingo.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp. (#8038)attribute.EMPTY) ingo.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp. (#8038)attribute.EMPTY) ingo.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp. (#8038)attribute.EMPTY) ingo.opentelemetry.io/otel/sdk/metric/metricdata/metricdatatest. (#8038)go.opentelemetry.io/otel/sdk/metric.Set
OTEL_GO_X_PER_SERIES_START_TIMESTAMPS=trueto enable. (#8060)WithCardinalityLimitSelectorfor metric reader for configuring cardinality limits specific to the instrument kind. (#7855)Changed
EMPTYType ingo.opentelemetry.io/otel/attributeto reflect that an empty value is now a valid value, withINVALIDremaining as a deprecated alias ofEMPTY. (#8038)go.opentelemetry.io/otel/attributeto optimize short slice values with fixed-size fast paths. (#8039)go.opentelemetry.io/otel/sdk/traceby returning early if self-observability is not enabled. (#8067)go.opentelemetry.io/otel/sdk/metric/metricdata/metricdatatest. (#8073)Deprecated
INVALIDingo.opentelemetry.io/otel/attribute. UseEMPTYinstead. (#8038)Fixed
TraceIdRatioBaseddescription. This is a breaking behavioral change, but it is necessary tomake the implementation spec-compliant. (#8027)
go.opentelemetry.io/otel/sdk/metricwhere the lastvalue aggregation could collect the value 0 even when no zero-value measurements were recorded. (#8056)go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttpto mitigate excessive memory usage caused by a misconfigured or malicious server.Responses exceeding the limit are treated as non-retryable errors. (#8108)
go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttpto mitigate excessive memory usage caused by a misconfigured or malicious server.Responses exceeding the limit are treated as non-retryable errors. (#8108)
go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttpto mitigate excessive memory usage caused by a misconfigured or malicious server.Responses exceeding the limit are treated as non-retryable errors. (#8108)
WithHostIDdetector ingo.opentelemetry.io/otel/sdk/resourceto use full path forkenvcommand on BSD. (#8113)request.GetBodyingo.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttpto correctly handle HTTP2 GOAWAY frame. (#8096)What's Changed
190d7d4by @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/80133a57be14by @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/803118895462by @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/803666e66a94by @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/8043384a4fc4by @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/80488b7b2c7bby @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/80444befce8dby @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/80533c2dfcecby @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/80555dec52c4by @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/80633744bfb5by @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/80644internal/observpackage to stdoutlog by @yumosx in https://github.com/open-telemetry/opentelemetry-go/pull/7735de6f1ccby @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/80822d00831aby @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/80788b6b0c46by @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/80766d5a96adby @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/811229d38bb4by @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/81177c99c5cfby @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/81222New Contributors
Full Changelog: open-telemetry/opentelemetry-go@v1.42.0...v1.43.0
v1.42.0: /v0.64.0/v0.18.0/v0.0.16Compare Source
Added
go.opentelemetry.io/otel/semconv/v1.40.0package.The package contains semantic conventions from the
v1.40.0version of the OpenTelemetry Semantic Conventions.See the migration documentation for information on how to upgrade from
go.opentelemetry.io/otel/semconv/v1.39.0. (#7985)ErrandSetErronRecordingo.opentelemetry.io/otel/logto attach an error and set record exception attributes ingo.opentelemetry.io/otel/log/sdk. (#7924)Changed
TracerProvider.ForceFlushingo.opentelemetry.io/otel/sdk/tracejoins errors together and continues iteration through SpanProcessors as opposed to returning the first encountered error without attempting exports on subsequent SpanProcessors. (#7856)Fixed
request.GetBodyingo.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttpto correctly handle HTTP2 GOAWAY frame. (#7931)go.opentelemetry.io/otel/propagation. (#7834)Removed
What's Changed
df47568by @renovate[bot] inhttps://github.com/open-telemetry/opentelemetry-go/pull/79966Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Renovate Bot.
Summary by CodeRabbit