<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 29, 2014 at 5:08 PM, René Neumann <span dir="ltr"><<a href="mailto:lists@necoro.eu" target="_blank">lists@necoro.eu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 29.04.2014 16:57, schrieb Alfredo Pironti:<br>
<div class="">><br>
> Letting software run on unexpected data (the case where the user invokes<br>
> the additional command on unformatted data) can have bad consequences.<br>
> Sure one can try to implement conservative checks to gracefully fail, but<br>
> they increase<br>
> complexity and sometimes one just misses such checks. Since this is<br>
> software running on sensitive data, taking the conservative approach<br>
> (of not parsing user data at all) seems safer, although functionality may<br>
> be hindered a bit.<br>
<br>
</div>Just to see, if I understand your point: If pass itself does not enforce<br>
a format per se, but offers some subcommand that expect a certain<br>
format, things may go wrong. So for the fields example, there may be<br>
someone, who (by chance) has a password that starts with 'User:' which<br>
now gets output though it should not.<br></blockquote><div><br></div><div>Something like that to begin with. If we end up with different subcommands<br>for different formats, things could get funnier.<br></div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If this is your point, doesn't the problem exist anyway? It can happen<br>
the same, even if the command is not part of pass but external (or a<br>
shell pipeline ...). The only reasonable thing here would be to have<br>
educated users who 'know what they are doing' (i.e. for the example<br>
above see the problem and change the pwd accordingly).<br></blockquote><div><br></div><div>I think it's a matter of separation of concerns (or "who to blame?").<br></div><div>Sticking to Unix philosophy, each tool is good at doing one (its) thing.<br>
</div><div>So if the firefox plugin uses a specific format and at some point fails<br>in parsing it, you can blame the plugin rather than pass. Pass is kept<br>simple and audited for its core tasks.<br><br></div><div>That said, I'm not defending this position too much. I'd just like to raise a flag<br>
about this potential issue, and the associated raise in complexity if a format gets handled by pass.<br><br></div><div>Of course then, one should agree on the format (why <key>:<value> and not JSON? what about assigning a type to the value? etc)<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
- René<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>