Conversation
Signed-off-by: Hilmar Falkenberg <hilmar.falkenberg@sap.com>
MJarmo
left a comment
There was a problem hiding this comment.
Could you clarify whether this OTEP is primarily an API/data-model proposal or an end-to-end reliability guarantee proposal? Right now it mixes semantic model, SDK behavior, transport changes, and sink durability semantics
| | `Attributes` | `map<string, AnyValue>` | Arbitrary key-value pairs for additional context. | | ||
| | `Signature` | `bytes` | Digital signature of the audit record for integrity verification. | | ||
| | `Algorithm` | `string` | Algorithm used for the digital signature (e.g., `RS256`, `ES256`). | | ||
| | `Certificate` | `bytes` | Digital public certificate used for the signature verification. | |
There was a problem hiding this comment.
I'm not sure if we want to pass down cert and algoryth we use for singing logs
There was a problem hiding this comment.
the receiver needs at least a pointer (e.g. issuer/subject name and the trusted certificate chain) to the public cert and which algorithm to use for the validation or not?
|
|
||
| The `IntegrityHash` is computed by the **sink**, not the SDK, so it reflects the | ||
| record as actually persisted – not as emitted. The emitting service MAY store | ||
| the receipt for its own tamper-detection purposes. The emitting service SHOULD compute the same hash locally and compare it to the receipt to verify integrity. A mismatch indicates the record was altered in transit or by the sink, which should trigger an alert (e.g. log an error, raise an incident). |
There was a problem hiding this comment.
Not sure I fully understand the intended trust model here. If the sink computes the hash and returns it to the SDK, tampering may only be detected after successful persistence, meaning a modified record could still be stored. Would it be better to make client-side canonical hashing/signing the baseline, then return a simple acknowledgement (status/record_id)? Sink-computed hash could remain an optional advanced feature for backends that support persisted-state attestation
There was a problem hiding this comment.
hmm... my idea is to have on both ends a way to figure out log tampering. With the signature the sink can verify that nothing has been changed (and yes, theoretically it might be sufficient to simply reply with ack)... but can the client then really be sure, that exactly what was sent is acknowledged?
If we think further and have queues/batches and partial successes... if the partial success would contain a list of hashes, then the client could figure out what was successful transmitted and try to resend the logs with the hashes, that were not acknowledged. So the hash becomes something like the unique ID. Maybe this is over engineered. Something I would like to discuss with a broader architect round (or other experts in reliable auditing).
Durability at the sink is out of scope Signed-off-by: Hilmar Falkenberg <hilmar.falkenberg@sap.com>
…lemetry#4878) Adds a new section recommending strict YAML parsing practices for configuration files, including use of YAML 1.2 Core Schema, disabling dangerous deserialization features, and using safe parser modes. This helps prevent security issues and unintended type coercion. Fixes # ## Changes Please provide a brief description of the changes here. For non-trivial changes, follow the [change proposal process](https://github.com/open-telemetry/opentelemetry-specification/blob/main/CONTRIBUTING.md#proposing-a-change). * [ ] Related issues # * [ ] Related [OTEP(s)](https://github.com/open-telemetry/oteps) # * [ ] Links to the prototypes (when adding or changing features) * [x] [`CHANGELOG.md`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/CHANGELOG.md) file updated for non-trivial changes * For trivial changes, include `[chore]` in the PR title to skip the changelog check * [ ] [Spec compliance matrix](https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix/template.yaml) updated if necessary --------- Signed-off-by: Gregor Zeitlinger <gregor.zeitlinger@grafana.com> Co-authored-by: Jack Berg <34418638+jack-berg@users.noreply.github.com>
Fixes open-telemetry#4984 ## Changes Moves Prometheus Metrics Exporter spec **Host configuration** status from `Development` to `Stable`. Implemented by [3+ SDKs](open-telemetry#4984 (comment)). * [x] Related issues open-telemetry#4984 * [ ] Related [OTEP(s)](https://github.com/open-telemetry/oteps) # * [ ] Links to the prototypes (when adding or changing features) * [x] [`CHANGELOG.md`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/CHANGELOG.md) file updated for non-trivial changes * For trivial changes, include `[chore]` in the PR title to skip the changelog check * [ ] [Spec compliance matrix](https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix/template.yaml) updated if necessary * [ ] [Declarative config data model](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/data-model.md#overview) is updated if SDK config surface is changed
…pen-telemetry#4964) Fixes open-telemetry#4925 ## Changes * Editorial change: Move type-specific content to the respective type's section * Specify that the actual trace Id and span ID take precedence over keys with the name "trace_id" and "span_id", and that they should be dropped last. * Restructure spec into bullet points. @open-telemetry/prometheus-interoperability @krajorama @ywwg @aknuds1 --------- Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com>
…pen-telemetry#5020) Towards stabilization of "environment variables as context propagation carriers". According to my review, the Java and Go implementations are already spec compliant. The rest need some little improvements related to normalization. --------- Co-authored-by: Carlos Alberto Cortez <calberto.cortez@gmail.com>
) Fixes a remark made in open-telemetry#5026 (comment). ## Changes Groups the Prometheus stabilization changelog entries into top level bullet points. * [ ] Related issues # * [ ] Related [OTEP(s)](https://github.com/open-telemetry/oteps) # * [ ] Links to the prototypes (when adding or changing features) * [ ] [`CHANGELOG.md`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/CHANGELOG.md) file updated for non-trivial changes * For trivial changes, include `[chore]` in the PR title to skip the changelog check * [ ] [Spec compliance matrix](https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix/template.yaml) updated if necessary * [ ] [Declarative config data model](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/data-model.md#overview) is updated if SDK config surface is changed
…metry#5032) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [github/codeql-action](https://redirect.github.com/github/codeql-action) | action | patch | `v4.35.1` → `v4.35.2` | --- ### Release Notes <details> <summary>github/codeql-action (github/codeql-action)</summary> ### [`v4.35.2`](https://redirect.github.com/github/codeql-action/releases/tag/v4.35.2) [Compare Source](https://redirect.github.com/github/codeql-action/compare/v4.35.1...v4.35.2) - The undocumented TRAP cache cleanup feature that could be enabled using the `CODEQL_ACTION_CLEANUP_TRAP_CACHES` environment variable is deprecated and will be removed in May 2026. If you are affected by this, we recommend disabling TRAP caching by passing the `trap-caching: false` input to the `init` Action. [#​3795](https://redirect.github.com/github/codeql-action/pull/3795) - The Git version 2.36.0 requirement for improved incremental analysis now only applies to repositories that contain submodules. [#​3789](https://redirect.github.com/github/codeql-action/pull/3789) - Python analysis on GHES no longer extracts the standard library, relying instead on models of the standard library. This should result in significantly faster extraction and analysis times, while the effect on alerts should be minimal. [#​3794](https://redirect.github.com/github/codeql-action/pull/3794) - Fixed a bug in the validation of OIDC configurations for private registries that was added in CodeQL Action 4.33.0 / 3.33.0. [#​3807](https://redirect.github.com/github/codeql-action/pull/3807) - Update default CodeQL bundle version to [2.25.2](https://redirect.github.com/github/codeql-action/releases/tag/codeql-bundle-v2.25.2). [#​3823](https://redirect.github.com/github/codeql-action/pull/3823) </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - "before 8am every weekday" - 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. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/open-telemetry/opentelemetry-specification). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xMjMuOCIsInVwZGF0ZWRJblZlciI6IjQzLjEyMy44IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJkZXBlbmRlbmNpZXMiXX0=--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…y#5031) The link was removed in open-telemetry#5014 I was able to locate a copy and created a new Google Doc with the same content.
Per https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4430-span-event-api-deprecation-plan.md#via-the-sdk Declarative configuration PR: - open-telemetry/opentelemetry-configuration#588 Prototypes: - Java: https://github.com/open-telemetry/opentelemetry-java-contrib/blob/42fea9d335c9a53089996fa5888e06926f6f4a5c/processors/README.md#event-to-spanevent-bridge - Go: open-telemetry/opentelemetry-go-contrib#8760
This PR contains the following updates: | Update | Change | |---|---| | lockFileMaintenance | All locks refreshed | 🔧 This Pull Request updates lock files to use the latest dependency versions. --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - Between 12:00 AM and 03:59 AM, only on Monday (`* 0-3 * * 1`) - 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. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://redirect.github.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/open-telemetry/opentelemetry-specification). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xMjMuOCIsInVwZGF0ZWRJblZlciI6IjQzLjEyMy44IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJkZXBlbmRlbmNpZXMiXX0=--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…-telemetry#4768) ## Changes Adds the merge algorithm specified in OTEP#264 to the Resource + Entity data model specification (both still in development). This merge algorithm has been used in Entity prototypes for the past year and has not seen any change. It's been adaptable enough to handle several re-architectures of SDKs through prototyping, so we're confident in pushing it forward into the specification. A few caveats: - See the note on Resource DataModel about conflicting merge algorithms. This one currently focused only on merging entities into resource when there is a known set of entities in the existing resource. - I've split the merge algorithm into two: The Entity portion about eligibility of merging and descriptive attribute merging, and then the more robust resource section. Link to prototypes: - Java: https://github.com/jsuereth/opentelemetry-java/blob/wip-entity-and-providers/sdk/common/src/main/java/io/opentelemetry/sdk/entity/internal/EntityUtil.java#L289 - TypeScript: open-telemetry/opentelemetry-js#5620 --------- Co-authored-by: Dmitry Anoshin <anoshindx@gmail.com>
### Context - Align environment variable context propagation name restrictions with POSIX.1-2024 and define normalization behavior. ([open-telemetry#4944](open-telemetry#4944)) - Decouple the responsibilities of the environment variable propagation carrier. ([open-telemetry#4961](open-telemetry#4961)) - Remove misleading implementation approach the environment variable propagation. ([open-telemetry#5003](open-telemetry#5003)) - Change Environment Variables as Context Propagation Carriers document status to Beta. ([open-telemetry#5020](open-telemetry#5020)) ### Traces - Stabilize Tracer `enabled` operation ([open-telemetry#4941](open-telemetry#4941)) - Stabilize `AlwaysRecord` sampler. ([open-telemetry#4934](open-telemetry#4934)) ### Metrics - Add development `maxExportBatchSize` parameter to Periodic exporting MetricReader. ([open-telemetry#4895](open-telemetry#4895)) ### Logs - Add event to span event bridge. ([open-telemetry#5006](open-telemetry#5006)) ### Resource - Clarify that a Resource describes the observed entity, not the component that technically emits telemetry. ([open-telemetry#4905](open-telemetry#4905)) ### Compatibility - Deprecate OpenTracing compatibility requirements in the specification. ([open-telemetry#4938](open-telemetry#4938)) - Stabilize sections of Prometheus and OpenMetrics Compatibility. - Stabilize Prometheus Classic Histogram to OTLP Explicit Histogram transformation. ([open-telemetry#4874](open-telemetry#4874)) - Stabilize Prometheus Timestamp and Start timestamp transformation. ([open-telemetry#4953](open-telemetry#4953)) - Clarify Prometheus Native Histogram to OTLP Exponential Histogram conversion, add conversion rules for Native Histograms with Custom Buckets (NHCB) to OTLP Histogram. ([open-telemetry#4898](open-telemetry#4898)) - Stabilize Prometheus Dropped Types transformation. ([open-telemetry#4952](open-telemetry#4952)) - Stabilize OpenTelemetry Attributes to Prometheus labels transformation. ([open-telemetry#4963](open-telemetry#4963)) - Stabilize Prometheus Exemplar to OpenTelemetry Exemplar transformation. ([open-telemetry#4962](open-telemetry#4962)) - Stabilize Prometheus Metadata transformation. ([open-telemetry#4954](open-telemetry#4954)) - Stabilize OpenTelemetry Metric Metadata to Prometheus metric metadata. ([open-telemetry#4966](open-telemetry#4966)) - Stabilize OpenTelemetry Exemplar to Prometheus Exemplar transformation. ([open-telemetry#4964](open-telemetry#4964)) - Stabilize sections of Prometheus Metrics Exporter. - Stabilize host configuration. ([open-telemetry#5025](open-telemetry#5025)) ### SDK Configuration - Declarative configuration: add in-development guidance for exposing the effective `Resource` returned by `Create`. ([open-telemetry#4949](open-telemetry#4949)) - Require spec changes to consider declarative config schema ([open-telemetry#4916](open-telemetry#4916)) - Add strict YAML parsing guidance to configuration supplementary guidelines. ([open-telemetry#4878](open-telemetry#4878)) ### OTEPs - Process Context: Sharing Resource Attributes with External Readers. ([open-telemetry#4719](open-telemetry#4719)) - Support multiple Resources within an SDK. ([open-telemetry#4665](open-telemetry#4665)) --------- Co-authored-by: Jack Berg <34418638+jack-berg@users.noreply.github.com>
|
superseded by apeirora#1 |
replaced by: apeirora#6