<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Le ven. 2 juin 2017 à 21:05, Frank Grüllich <<a href="mailto:frank.gruellich@gmail.com">frank.gruellich@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jun 02, 2017 at 07:42:26AM +0000, Matthieu Fronton wrote:<br>
> Le ven. 2 juin 2017 à 07:42, Frank Grüllich <<a href="mailto:frank.gruellich@gmail.com" target="_blank">frank.gruellich@gmail.com</a>> a<br>
> écrit :<br>
> > > [store raw file]<br>
> > What's the big advantage over<br>
> ><br>
> >  % pass insert --multiline "some/path/to/secret" < secret.data<br>
> ><br>
> > ?<br>
> I have to admit I didn't think about in the first place... :)<br>
> But I also believe this is more a workaround than a native feature.<br>
<br>
That workaround enables some nice tricks, eg.:<br>
<br>
 % openssl genrsa 2048 | pass insert --multiline "some/path/to/<a href="http://www.example.com" target="_blank">www.example.com</a>.key"<br>
 % pass "some/path/to/<a href="http://www.example.com" target="_blank">www.example.com</a>.key" | openssl req -new -key /dev/stdin -out "www.example.com.csr" -subj "/CN=<a href="http://www.example.com" rel="noreferrer" target="_blank">www.example.com</a>"<br>
<br>
which stores/uses they secret key almost directly in/from a safe place<br>
(and does not create a useful CSR, of course).  Your implementation<br>
enables (if not encourages) the user to put the key on some potential<br>
unsafe storage.<br><br></blockquote><div><br></div><div>Nice one.</div><div>End of topic :)</div><div><br></div><div>Thanks</div></div></div>