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

[David Bremner]

Sean Whitton <spwhitton at spwhitton.name> writes:

>> * 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?

How would dispatching work here, some kind of matching on iden1? Is
there some existing machinery for this?

>
>> * 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.

I can think of two issues here. First, there are multiple pass
frontends, and we would have resolve that somehow (I know of pass and
gopass offhand). The original is a bash script, and I suspect most of
the re-implementations are driven by wanting to avoid a bash script in
the security "critical path", which is somewhat valid for us as well.
Probably more importantly, 'pass find' just wraps 'tree', which makes
the output hard to parse and (perversely) not working for exact matches.