Way to redact secrets in logs

[Cube707]

When using access tokens or passwords as command line arguments, clinks will remember them in its history and auto-complete them in the future. While this is a big time-saver, its also a possible security issue.

Is there a (easy-isch) way to redact this secrets, similar to how GitHub/GitLab redact secrets in the logs of pipeline jobs? If not would this be a feature you are interested in adding?

For my current usecase it would be enough to define a regex that just removes the secret.

[chrisant996]

When using access tokens or passwords as command line arguments, clinks will remember them in its history and auto-complete them in the future. While this is a big time-saver, its also a possible security issue.

Is there a (easy-isch) way to redact this secrets, similar to how GitHub/GitLab redact secrets in the logs of pipeline jobs? If not would this be a feature you are interested in adding?

For my current usecase it would be enough to define a regex that just removes the secret.

@Cube707 This is a very interesting topic; thanks for bringing it up.

There's no way to offer "guarantees" about thoroughness or accuracy of any redaction. So, I'm uncomfortable about trying to built some kind of redaction mechanism, since at its very best it could only be a hacky kludge that only works for some specific substrings. It could not be accurate or thorough.

What Clink currently has is the history.dont_add_to_history_cmds setting which just blocks certain commands from being stored in the history. That obviously isn't a convenient solution for redaction, since e.g. ssh commands only need to be excluded from history if they contain certain flags.

How would you construct such a regex? If the regex contains the secrets, then how/where can the regex be stored so that the regex itself isn't exposed? Do you want a bunch of different regexes for different commands? I'm worried that this approach can balloon out of control quite quickly.

A different approach might be to add a mechanism to allow argmatchers to specify that certain flags should be redacted in history. E.g. an argmatcher for the net use command could mark the password option as needing to be redacted. But that would be problematic for two reasons: (1) then to get redaction for everything you'd need to either write your own argmatchers or convince other argmatcher authors to update their argmatchers, and (2) some users don't want/need redaction.

So, it's not clear to me HOW to perform redaction in a realistic manner. And it can never be very accurate or thorough, which makes me uncomfortable about adding a feature that claims to do something ... but does it so poorly that it's easily circumvented. That would invite angry support tickets, for which nothing can really be done. So, I wouldn't want to do more than provide hooks that someone can use to set up their own custom redaction mechanism, so that they themselves are responsible for how successful/accurate/thorough it is.

I'm very willing to add some kind of mechanism. The hard part is designing a mechanism that's easy to use and is reliable/effective enough to be able to call it a redaction mechanism without inciting lots of negative feedback about its limitations.

I'm open to thoughts and ideas.

[chrisant996]

It's also worth noting that as long as no instances of Clink are running, then the clink_history is just a text file and you could have a script or program that scrubs it.

BUT that's not a good option because:

1. If any instances of Clink are running, then they all have pointers into the clink_history file, and so modifying the clink_history file out from under them can cause them to malfunction and can cause corruption in the history file.
2. It would only clean out secrets later; it wouldn't prevent secrets from being initially written to the history.

[Cube707]

This are all very good points and I totally understand that you would shy away from giving any guarantees.

The current use case that lead me to opening this request are access-tokens for GitLab. They follow a well known, pretty unique format, so a regex to catch them would be quite straight forward. And as they are short lived in nature I would be totally sufficient to just have them replaced by **** before dumping them into the history file. (meaning they would restore "incorrectly" on lookup)

So for my specific use-case a simple form of argmatcher or similar that just lets me redact pars of history-entries would be sufficient.

What Clink currently has is the history.dont_add_to_history_cmds setting which just blocks certain commands from being stored in the history.

This may actually be enough for me. I will look into this. Thanks for the tip.

So, it's not clear to me HOW to perform redaction in a realistic manner. And it can never be very accurate or thorough, which makes me uncomfortable about adding a feature that claims to do something

I also thought about this but agree that there is no straight forward, easy solution and this will require some careful consideration.

It's also worth nothing that as long as no instances of Clink are running, then the clink_history is just a text file and you could have a script or program that scrubs it.

BUT that's not a good option because:

This kind of inside is exactly why I wanted to ask before hacking anything together 😄

[Cube707]

Thank you for your inside on this

[chrisant996]

This probably won't be directly helpful, but I'll share it just in case:

The recommended secure way to handle this sort of thing is to have the secrets stored in an encrypted format on a special hardware security device, and to not pass any secret on the command line at all.

Passing any secret on a command line leaves it exposed in multiple places in memory where hacking software can potentially retrieve them in plain text.

By keeping the secrets stored securely in a special hardware security device, the OS can securely prompt for a PIN to control access to the secret in a secure manner. (Even if Clink had support for redaction, that would only touch on part of the deeper and larger problem.)

That's how the code-signing secrets work, e.g. for code-signing the Clink executables for a release. They exist only in a special hardware security device. I never pass secrets on a command line. Period. I have too much security training to do that anymore (and part of the training has been through the Vicarious School Of Hard Knocks, though thankfully I don't have direct personal experience with those kinds of mistakes).