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

[Sean Whitton]

Hello,

On Sun 09 Jan 2022 at 12:18PM -04, David Bremner wrote:

> 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 check function would look for ("--user-passwd--HOSTNAME" . USER) and
convert that into HOSTNAME/USERNAME, and see whether there is an entry
for that.  And if iden1 does not match --user-passwd--* then it would
see if there is an entry for IDEN1/IDEN2.  The same conversion would
take place at the beginning of the extract function.

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

Okay then, we can implement finding and decrypting the file ourselves.

-- 
Sean Whitton