[pass] copying usernames and urls

[Alfredo Pironti]

On Tue, Apr 29, 2014 at 5:08 PM, René Neumann <lists at necoro.eu> wrote:

> Am 29.04.2014 16:57, schrieb Alfredo Pironti:
> >
> > Letting software run on unexpected data (the case where the user invokes
> > the additional command on unformatted data) can have bad consequences.
> > Sure one can try to implement conservative checks to gracefully fail, but
> > they increase
> > complexity and sometimes one just misses such checks. Since this is
> > software running on sensitive data, taking the conservative approach
> > (of not parsing user data at all) seems safer, although functionality may
> > be hindered a bit.
>
> Just to see, if I understand your point: If pass itself does not enforce
> a format per se, but offers some subcommand that expect a certain
> format, things may go wrong. So for the fields example, there may be
> someone, who (by chance) has a password that starts with 'User:' which
> now gets output though it should not.
>

Something like that to begin with. If we end up with different subcommands
for different formats, things could get funnier.


>
> If this is your point, doesn't the problem exist anyway? It can happen
> the same, even if the command is not part of pass but external (or a
> shell pipeline ...). The only reasonable thing here would be to have
> educated users who 'know what they are doing' (i.e. for the example
> above see the problem and change the pwd accordingly).
>

I think it's a matter of separation of concerns (or "who to blame?").
Sticking to Unix philosophy, each tool is good at doing one (its) thing.
So if the firefox plugin uses a specific format and at some point fails
in parsing it, you can blame the plugin rather than pass. Pass is kept
simple and audited for its core tasks.

That said, I'm not defending this position too much. I'd just like to raise
a flag
about this potential issue, and the associated raise in complexity if a
format gets handled by pass.

Of course then, one should agree on the format (why <key>:<value> and not
JSON? what about assigning a type to the value? etc)


>
> - René
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20140429/62e94627/attachment.html>