Thanks for your suggestion. Using other roots for the pass is exactly
what I want to circumvent. That worked well for me in the past, but I
want to choose a different structure for a current project.
To make things a bit more clear, I want to give an example of what does
work atm and what does not work for my special setting.
This is my directory structure with two symlinked password stores. The
`other-password-store` links to a password-store (git-)root, the
`nested-passwords-proj1` links to passwords in a strict subdirectory of
a git-repo.
```
.
├── .password-sore/
│ ├── .git/
│ ├── .gpg-id
│ ├── google.com.gpg
│ ├── facebook.com.gpg
│ ├── other-password-store -> /.password-store-other
│ └── nested-passwords-proj1 -> /project1/.passwords-proj1
├── .password-store-other/
│ ├── .git/
│ ├── .gpg-id
│ └── my-fancy-employer.com.gpg
└── project1/
├── .git/
├── .passwords-proj1/
│ ├── .gpg-id
│ ├── secret-reset-code.gpg
│ └── things-some-others-should-know-as-well.gpg
├── protocols/
└── todos.org
```
For the `other-password-store` a generation of new passwords (and other
commands) works well. The versioning is kept in `.password-store-other`.
```
# This works as expected
pass generate other-password-store/my-new-password
```
For the `nested-passwords-proj1`, the generation works fine, but version
control exits with an error. The new password is not kept in versioning
of `project1`.
```
# This throws a git error
pass generate nested-passwords-proj1/my-new-password
```
The error comes from `git -C ... add ...` not working well with paths
containing symlinks.
Regards,
chemmi
P.S. To specify my use case: I hold an office for an association and I
want to keep all the data for that in one place. That are notes for
meetings, protocols, todos, secrets, ... , because I want to keep things
compact for a potential successor. Therefore 1 git repo would be best.
On 20.02.21 17:46, [email protected] wrote:
On Feb 20, 2021, 3:56 PM +0100, [email protected], wrote:
Hi folks,
I use password store as my default password manager because it is super
easy to understand how passwords are stored and where the security
limitations lie. Although I have several projects which store
credentials, I want to manage them from a single point, but want to
store them near the project (e.g. in the assoicated git repo).
Or does anyone here has a hint how I can approach the issue differently?
Thinking out loud, it seems what you want is a way to specify
alternative password stores easily from the command line. One option is
to use the PASSWORD_STORE_DIR environment variable and create some
aliases, i.e. pass-default, pass-proj2, etc.
That feels less “elegant” to me and I wonder if we should consider a
password database global option. Then you could have a lookup table in
your default password store that would resolve out alternative stores.
I base this suggestion on my read of your email as not only wanting a
“known method” but wanting that to be a single access. What I am
envisioning would give you this:
pass -c aws # Provide your default AWS password (perhaps from your
personal database)
pass -c was -P proj2 # Provide the AWS password from proj2, located
somewhere else
We could have a dot file that maps proj2 to a path in your default
password store.
Regards,
bex
