* Add automatic plugin reload
* Refactor builtin/backend
* Remove plugin reload at the core level
* Refactor plugin tests
* Add auto-reload test case
* Change backend to use sync.RWMutex, fix dangling test plugin processes
* Add a canary to plugin backends to avoid reloading many times (#3174)
* Call setupPluginCatalog before mount-related operations in postUnseal
* Don't create multiple system backends since core only holds a reference (#3176)
to one.
From the sshpass manpage:
> The -p option should be considered the least secure of all of sshpass's options. All system users can see the password in the command line with a simple "ps" command. Sshpass makes a minimal attempt to hide the password, but such attempts are doomed to create race conditions without actually solving the problem. Users of sshpass are encouraged to use one of the other password passing techniques, which are all more secure.
This PR changes the sshpass behavior to execute a subprocess with the
SSHPASS envvar (which is generally regarded as more secure) than using
the -p option.
@jefferai and I discussed this on Friday. With three fully-documented
SSH backends, the page is lengthy, ungreppable, and intimidating. This
commit separates the SSH backends into their own pages with as little
text changes as possible.
When we "nest" like this, it's important to use a common suffix,
"Database Secret Backend" in this case, so that the SEO minions can
properly group search results for end users.
According to #3116, it seems like this parameter isn't used. I couldn't trigger any differences by playing around with transit signing function, and could not find anything in the source code that actually parses this param. Presumably, it is unused?
Seth Vargo