secretlint VS shell-plugins

In most cases, you can't automatically fix any confidential information you find, but I've noticed that it's OK to automatically remove or mask any confidential information that has been left in .bash_history or .zsh_history. To automatically modify API tokens left in history files, Secretlint v6 adds a --format=mask-result formatter .

Software development: textlint, Secretlint, HonKit and other development and maintenance.

Continuously committed repositories include JSer.info, textlint, and JavaScript Primer, etc. On the other hand, the newly created ones after the launch of GitHub Sponsors include philan.net, HonKit, Secretlint, etc.

secretlint is pluggable linting tool to prevent committing credential like SSH private key, GCP Access token, AWS Access Token, Slack Token, and npm auth token.

secretlint is a pluggable linting tool to prevent committing credential.

You can setup pre-commit Hook per project or pre-commit Hook globally. This git's pre-commit prevent you to commit your credentials like GitHub Token, SSH key, AWS crendentials.

Consider 1Password, with the added bonus of the `op` CLI tool and a variety of other dev conveniences.

CLI: https://developer.1password.com/docs/cli/get-started/

Shell plugins: https://developer.1password.com/docs/cli/shell-plugins

Secrets automation: https://developer.1password.com/docs/secrets-automation

1Password Shell Plugins: Eliminate API access keys stored on disc and securely authenticate any CLI with your fingerprint, Apple Watch, or other biometrics.

I often regret any contact I have with the Bitwarden fanbase, because whooo they are rabid, but I guess I used to be a rabid fan of 1P so maybe fair's fair :-D Anyway ...

- https://github.com/bitwarden/clients/issues/1620 was created 2021, after it was migrated from the issue that was open even longer in the other repo, and now they've locked the issue because they're tired of people complaining about the extension losing their credentials

- there are a ton more Item types in 1Password, which some people consider just cosmetic ("you can create your own fields") but https://bitwarden.com/help/managing-items/ compared to https://support.1password.com/item-categories/ is night and day, setting aside the native support for SSH agent that's built into 1P nowadays

and here starts the list of even more highly subjective items, which I acknowledge are highly subjective

- the folder based item management in Bitwarden is highly inferior to the tags based management in 1P. Creating folders itself is a major PITA, whereas creating tags in 1P is ... just type the new tag name. Maybe people enjoy putting the "tags" in there item's names or whatever, and doing away with folders in Bitwarden, but ... the fact they're trying to implement tagging on the cheap indicates they want tags but Bitwarden doesn't see the world that way

- I find the attachment management process cumbersome in Bitwarden, whereas in 1P there are actually two orthogonal ways of managing attachments: they can be first class Items (called "Document" items) meaning that is the whole secret that one would care about, and they can also be arbitrarily attached to other Items in kind of a supporting role. I have scans of my passport attached to the Passport item type because so many places ask me to upload a scan of my passport. Same for my driver's license on the formal Driver's License item type

- in the theme of "finding it cumbersome," I find that 1Password seems to care a lot more about UX than Bitwarden. Now, of late I am having to qualify any such statement because yikes that 1P 8 rewrite was catastrophic. But, rewrite-induced-self-inflicted-harm aside, I still think 1P cares a lot more about UX than Bitwarden

- also subjective, but I really enjoy the `op run` <https://developer.1password.com/docs/cli/reference/commands/...> and its ability to resolve specially formatted env-vars <https://developer.1password.com/docs/cli/secret-references> in the sub-process. That process seems to be the basis of their shell plugins system <https://developer.1password.com/docs/cli/shell-plugins> but TBH I find just having env-vars lying around to be more convenient than their shell plugin system for my workflow. The fact that the `op` binary is smart enough to use DBus to auth to my desktop session means I can also use it as an implementation of pinentry

A perfectly reasonable question may be "well, it's open source, why not start fixing bugs?" The things about using folders and the lack of item types indicates to me that they're just rowing in a different direction than what I would like, and the fact that they're a commercial company means unless I directly would benefit from fixing a bug means I am not incentivized to contribute free labor

Credentials are often stored as raw text in .config/ or ~/.aws. These can be found in 1Password Shell Plugins, op run, zenv, envchain, etc. to avoid storing raw tokens in files.

You can find the code for the shell plugins on this GitHub repo.