discussion - CLI usability about santa HOT 3 CLOSED

I'd think the common-case for using santactl at all is to whitelist, and --path seems to would be easiest to copy-paste into terminal from the block dialog … Could we make the rule subcommand not require --whitelist or --path

Whitelisting may be the common case but making it the default would be a surprise to many people and I would rather users/admins be explicit about their intention than accidentally whitelisting something they intend to blacklist.

Would allowing the command to operate on multiple paths be OK? E.g:

santactl rule --whitelist --path /path/to/file1 /path/to/file2 /path/to/file3

would also be nice if the dialog went to the pasteboard escaped... I'm asking too much, aren't I.

I'm sure we can manage that.

Path also doesn't currently try to extract leaf certs for building the rule (if present), could that functionality be enabled?

It does, e.g:

santactl rule --whitelist --certificate --path /Applications/1Password.app

Would add a rule for AgileBits' developer cert.

from santa.

Ah, I swore I got a message saying e.g. /Apps/1Password was an invalid argument, I probably left out the --certificate. I'm easily confused about flag ordering as well (gives sideways glance to variation between git subcommands), so while I agree that admins do need to exert some caution either way, at least collapsing/making --certificate optional would be nice. Encouragement-wise, admins should be having a sad every time they need to specify a binaries fingerprint, so having it bark at you to explicitly add the --sha256 option when a certificate isn't found seems a good nudge in the maintainable direction.
I also finally noticed the globbing in the example help output displays for fileinfo - super fast!

from santa.

I'm going to close this out for now, and consider escaped text a 'nice to have' feature request that may be supplemented by more tooling or user-friendliness to reduce the dependence on CLI interaction in the future.

from santa.