FR: Mark certain fields as non-logging/debug only.

[novaksam]

THIS IS ONLY INTENDED FOR AUTOPKG BETAS.

Describe the problem
It would be nice to have the ability to mark certain fields, either with an xml attribute or some other method, as non-logging outside of debug output. This would help hide credentials or other secrets from log files that we may not want exposed in logs.

[nmcspadden]

You're going to need to provide a lot more context, examples, and information in this feature request. This is too vague to consider.

…

On Thu, May 16, 2024 at 7:05 AM Sam Novak ***@***.***> wrote: Assigned #941 <#941> to @nmcspadden <https://github.com/nmcspadden>. — Reply to this email directly, view it on GitHub <#941 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJFTXYO7RCIIE5V7F3AMM3ZCS4LFAVCNFSM6AAAAABH2JS5RSVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSHAZTINJQGU2TOMQ> . You are receiving this because you were assigned.Message ID: ***@***.***>

-- -- Nick McSpadden ***@***.***

[novaksam]

@nmcspadden Totally fair, understandable.

As autopkg is working right now, utilizing JamfUploader, the recipe run plists contain the credentials used to connect to smb shares; another potential example is an API key. I'm proposing some sort of processing to mark certain fields as 'non-logged' in logging output.

I'm thinking perhaps something like:

<key debugonly="true">test</key>
<string>hello</string>

And then a modification to the logging system to check if a property is hidden/protected/marked then don't emit a log line unless debug/high verbosity is enabled.

If it doesn't make sense to implement something like this, as it would probably affect quite a few items, then feel free to close this.

[gregneagle]

<key debugonly="true">test</key>
<string>hello</string>

would not be legal syntax for an Apple plist.

Best that could be done would be something like

<key>private_data_keys</key>
<array>
    <string>Foo</string>
    <string>Bar</string>
</array>

Where would this extra data live? I'd guess in a recipe override. So then does this affect logging only for the specific recipe? I'd assume so.

Since there's lots of decisions to be made like this, I would not expect any of the "main" maintainers to work on this unless they themselves found this important/useful. Someone is going to have to make the effort at the very least to think through this and define how it would work and how it would be implemented.

I'd also think naming choices are important. You've twice mentioned "debug" output, yet autopkg doesn't really define anything specifically as debug. Instead it has various levels of verbosity. So should this mechanism be connected to the various levels of verbosity, or is it completely binary (as in never output these values)? I'd think that would be easier to implement and understand, and if an admin wanted those private fields output available, they could just adjust the override.

So again, you are seeing that there's a lot of thinking and discussion that would need to happen here. Good luck!

[nmcspadden]

Can you also show a precise example of (redacted/sanitized) output in a recipe? It would be helpful to be extremely exact in what output is being produced that you'd desire to suppress, so whatever plans are made can be done with the correct goal in mind.

…

On Sat, May 18, 2024 at 10:26 AM Greg Neagle ***@***.***> wrote: <string>hello</string>``` would not be legal syntax for an Apple plist. Best that could be done would be something like ```<key>private_data_keys</key> <array> <string>Foo</string> <string>Bar</string> </array>``` Where would this extra data live? I'd guess in a recipe override. So then does this affect logging _only for the specific recipe_? I'd assume so. Since there's lots of decisions to be made like this, I would not expect any of the "main" maintainers to work on this unless they themselves found this important/useful. Someone is going to have to make the effort at the very least to think through this and define how it would work and how it would be implemented. I'd also think naming choices are important. You've twice mentioned "debug" output, yet autopkg doesn't really define anything specifically as _debug_. Instead it has various levels of verbosity. So should this mechanism be connected to the various levels of verbosity, or is it completely binary (as in _never_ output these values)? I'd think that would be easier to implement and understand, and if an admin wanted those private fields output available, they could just adjust the override. So again, you are seeing that there's a lot of thinking and discussion that would need to happen here. Good luck! — Reply to this email directly, view it on GitHub <#941 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJFTX5EDV3H62T7SYVR4FTZC6FLVAVCNFSM6AAAAABH2JS5RSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJYHA4DQNJXGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- -- Nick McSpadden ***@***.***