[RFC PATCH consfigurator] WIP: support pass(1) format data sources

[Sean Whitton]

Hello,

On Tue 28 Dec 2021 at 03:13PM -04, David Bremner wrote:

> ---
>  consfigurator.asd  |  3 +-
>  src/data/pass.lisp | 70 ++++++++++++++++++++++++++++++++++++++++++++++
>  src/package.lisp   |  4 ++-
>  3 files changed, 75 insertions(+), 2 deletions(-)
>  create mode 100644 src/data/pass.lisp
>
> This is an initial attempt to use a local pass(1) password store as a
> data source in consfigurator.

I don't use pass(1) but hooking up password managers sounds very useful.

> I saw the passphrase class in data.lisp, but this seems like wrong
> level to apply that.

Right, that protection is added by calls like GET-DATA-PROTECTED-STRING.

> * A typical pass entry might be "host.example.com/username", and we'd
>   currently expect people to pass IDEN1="host.example.com" and
>   IDEN2="username". In principle this collides with a file called
>   "username" on host.example.com, maybe this is not a problem?

It's more of a problem that it doesn't use the existing iden1,iden2
convention for user account passwords, and so the data source would not
be compatible with the :SUDO connection type, for example.

I think the data source needs to pick a translation of the
("--user-passwd--HOSTNAME" . USER) pair into a pass entry like
HOSTNAME/USERNAME, and then we require the user to use that sort of name
for their pass entry?  The transformation could be configurable, but
seems unlikely to be worth it.

So, the data source would have a table of such transforms, defaulting to
just joining IDEN1 and IDEN2 with a slash?

> * should we try to reduce code duplication? The function %read-gpg is
>   a small modification of data.pgp:read-store, substituting string
>   trimming for reading; the register data source function is pretty
>   similar to that in files-tree. Does it make sense to base one data
>   source on another one?

If you do want to go with not invoking the pass(1) program, then yes, I
would like to factor out some of this stuff somehow.

> * The choice of interface is the on-disk layout used by pass. This is
>   justified (?) by the existence of e.g. gopass, which does the same
>   thing.

Couldn't we just invoke pass(1) ourselves, rather than decrypting the
files directly?  Looks like there is 'pass find' for the check function,
and 'pass show' for the extract function.

-- 
Sean Whitton