<p dir="ltr">So we would have a "gpg tree data file manager" in the backend</p>
<p dir="ltr">And in the frontend plugins like<br>
Extract_first_line<br>
Copy_to_clipboard<br>
Extract_json_field<br>
And so on...</p>
<div class="gmail_quote">Le 29 avr. 2014 18:33, "Matthieu Weber" <<a href="mailto:mweber@free.fr">mweber@free.fr</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue 29.04.2014 at 05:34:40PM +0200, René Neumann wrote:<br>
> Am 29.04.2014 17:17, schrieb Alfredo Pironti:<br>
> >><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>
> >><br>
> ><br>
> > I think it's a matter of separation of concerns (or "who to blame?").<br>
> > Sticking to Unix philosophy, each tool is good at doing one (its) thing.<br>
> > 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>
Then I would suggest to split pass into a backend tool that stores<br>
passwords as encrypted files, but makes no assumption whatsoever about<br>
the content of the files, and a frontend tool that makes some<br>
assumptions about the content (such as "the password is on the firt<br>
line") and provides more advanced services (like copying the password to<br>
the clipboard). Commands that are not understood by the frontend are<br>
then delegated to the backend.<br>
<br>
As such, the FF plugin is just another frontend, and the menu-based tool<br>
yet another frontend. The problem of course would be to have a file<br>
format that can be understood by several different frontends.<br>
<br>
Alternatively, what I described as frontends could, in the case of<br>
text-based tools, be implemented as plugins into the current tool. This<br>
would of course increase the complexity of the tool, something that<br>
Jason has fought very hard on this list.<br>
<br>
Matthieu<br>
--<br>
 (~._.~)            Matthieu Weber - <a href="mailto:mweber@free.fr">mweber@free.fr</a>              (~._.~)<br>
  ( ? )                <a href="http://weber.fi.eu.org/" target="_blank">http://weber.fi.eu.org/</a>                    ( ? )<br>
 ()- -()          public key id : 0x85CB340EFCD5E0B3             ()- -()<br>
 (_)-(_) "Humor ist, wenn man trotzdem lacht (Otto J. Bierbaum)" (_)-(_)<br>
_______________________________________________<br>
Password-Store mailing list<br>
<a href="mailto:Password-Store@lists.zx2c4.com">Password-Store@lists.zx2c4.com</a><br>
<a href="http://lists.zx2c4.com/mailman/listinfo/password-store" target="_blank">http://lists.zx2c4.com/mailman/listinfo/password-store</a><br>
</blockquote></div>