wasmtime / issue #5193 wiggle: Suppress tracing on a per-... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #5193 wiggle: Suppress tracing on a per-...

Wasmtime GitHub notifications bot (Nov 03 2022 at 20:48):

Feature

For functions that may pass sensitive information (think secrets), we should have the ability to suppress tracing of those functions.

Implementation

I have an implementation (which I'll open a PR with) which replaces the newly-added tracing boolean flag to the from_witx! macro with one called suppress_tracing which has a format equivalent to the existing async flag. In other words, you can match everything by setting it to * (the equivalent to tracing: false now), or you can specify a list of identifiers in braces to disable logging for certain functions.

Examples:
wiggle::from_witx!({
    suppress_tracing: *,
    witx: ["..."],
});
wiggle::from_witx!({
    suppress_tracing: {
        module1::func,
        module2::another_func,
    },
    witx: ["..."],
});
We can reuse the existing AsyncConfField and AsyncFunctions types for this, so I have renamed them to be more general in my implementation.

Alternatives

I had originally implemented this alongside the existing tracing flag, and we could continue to have that one if it's important for usability or backward compatibility. But as I was implementing it it seems odd to have both since there was a lot of overlap, and the async implementation fit it nicely.

It's a bit negatory -- "suppress_tracing" -- which I don't love in an API but I think is necessary because you'll generally want to select specific sensitive functions that you don't want to trace. In the implementation I flip the meaning so there isn't negation-of-negation.

Wasmtime GitHub notifications bot (Nov 03 2022 at 20:57):

pchickey assigned issue #5193 (assigned to pchickey):

Feature

For functions that may pass sensitive information (think secrets), we should have the ability to suppress tracing of those functions.

Implementation

I have an implementation (which I'll open a PR with) which replaces the newly-added tracing boolean flag to the from_witx! macro with one called suppress_tracing which has a format equivalent to the existing async flag. In other words, you can match everything by setting it to * (the equivalent to tracing: false now), or you can specify a list of identifiers in braces to disable logging for certain functions.

Examples:
wiggle::from_witx!({
    suppress_tracing: *,
    witx: ["..."],
});
wiggle::from_witx!({
    suppress_tracing: {
        module1::func,
        module2::another_func,
    },
    witx: ["..."],
});
We can reuse the existing AsyncConfField and AsyncFunctions types for this, so I have renamed them to be more general in my implementation.

Alternatives

I had originally implemented this alongside the existing tracing flag, and we could continue to have that one if it's important for usability or backward compatibility. But as I was implementing it it seems odd to have both since there was a lot of overlap, and the async implementation fit it nicely.

It's a bit negatory -- "suppress_tracing" -- which I don't love in an API but I think is necessary because you'll generally want to select specific sensitive functions that you don't want to trace. In the implementation I flip the meaning so there isn't negation-of-negation.

Wasmtime GitHub notifications bot (Nov 03 2022 at 20:58):

pchickey unassigned issue #5193:

Feature

For functions that may pass sensitive information (think secrets), we should have the ability to suppress tracing of those functions.

Implementation

I have an implementation (which I'll open a PR with) which replaces the newly-added tracing boolean flag to the from_witx! macro with one called suppress_tracing which has a format equivalent to the existing async flag. In other words, you can match everything by setting it to * (the equivalent to tracing: false now), or you can specify a list of identifiers in braces to disable logging for certain functions.

Examples:
wiggle::from_witx!({
    suppress_tracing: *,
    witx: ["..."],
});
wiggle::from_witx!({
    suppress_tracing: {
        module1::func,
        module2::another_func,
    },
    witx: ["..."],
});
We can reuse the existing AsyncConfField and AsyncFunctions types for this, so I have renamed them to be more general in my implementation.

Alternatives

I had originally implemented this alongside the existing tracing flag, and we could continue to have that one if it's important for usability or backward compatibility. But as I was implementing it it seems odd to have both since there was a lot of overlap, and the async implementation fit it nicely.

It's a bit negatory -- "suppress_tracing" -- which I don't love in an API but I think is necessary because you'll generally want to select specific sensitive functions that you don't want to trace. In the implementation I flip the meaning so there isn't negation-of-negation.

Wasmtime GitHub notifications bot (Nov 05 2022 at 18:31):

pchickey closed issue #5193:

Feature

For functions that may pass sensitive information (think secrets), we should have the ability to suppress tracing of those functions.

Implementation

I have an implementation (which I'll open a PR with) which replaces the newly-added tracing boolean flag to the from_witx! macro with one called suppress_tracing which has a format equivalent to the existing async flag. In other words, you can match everything by setting it to * (the equivalent to tracing: false now), or you can specify a list of identifiers in braces to disable logging for certain functions.

Examples:
wiggle::from_witx!({
    suppress_tracing: *,
    witx: ["..."],
});
wiggle::from_witx!({
    suppress_tracing: {
        module1::func,
        module2::another_func,
    },
    witx: ["..."],
});
We can reuse the existing AsyncConfField and AsyncFunctions types for this, so I have renamed them to be more general in my implementation.

Alternatives

I had originally implemented this alongside the existing tracing flag, and we could continue to have that one if it's important for usability or backward compatibility. But as I was implementing it it seems odd to have both since there was a lot of overlap, and the async implementation fit it nicely.

It's a bit negatory -- "suppress_tracing" -- which I don't love in an API but I think is necessary because you'll generally want to select specific sensitive functions that you don't want to trace. In the implementation I flip the meaning so there isn't negation-of-negation.

Last updated: Dec 23 2024 at 12:05 UTC