Re: [pass] [PATCH] Allow custom subcommands

2016-10-03 Thread Brian Candler

On 04/10/2016 05:45, Sylvain Viart wrote:

Pass itself could be signed. By the user at init.
But why? Do you have a version of Linux which only executes signed 
scripts/binaries?


As for the admin being tricked into installing a malicious plugin - 
what's the difference between that and installing a malicious version of 
'pass' itself?


The only protection for 'pass' is installing it from a trusted location, 
and/or verifying the code by eye. Surely the same applies to plugins?


Regards,

Brian.
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/password-store


Re: [pass] [PATCH] Allow custom subcommands

2016-10-03 Thread Sylvain Viart
Hi Thorsten,

Le 03/10/2016 à 19:30, Thorsten Wißmann a écrit :
>> > Does GPG web of trust sure enough, to allow co-signing script to enable
>> > such signed plugins?
> I don't understand your question. But are you asking how my patch could
> be extended to call only 'signed' extensions?

It was, yes.
I also mention the "web of trust" behavior of GPG, which nice but
complicated, just to see if some reader are involved in such reflexion… ;-)

> If some bad guy has write access to some directory in $PATH and wants to
> take over your password store, then the bad guy can simply add a
> malicious `pass` executable and the user would not notice.

Pass itself could be signed. By the user at init.
I was more thinking, about installing malicious plugin, not having
malicious inside your computer.
I don't think than a password manager can be used on a share system,
with shared memory or process…
It is only designed to work on a personal computer. (I never though
about that before but…)

> I.e. I don't think `pass` should do something like signing of program
> code. It's some separate problem to check if the programs in your $PATH
> are trustworthy or not.

I see your point, you may be right. I just emailed the reference about
signing plugins to let you know.

Not tested your plugin yet…
I like the logic like git or rvm.

Regards,
Sylvain.


-- 
Sylvain Viart - DevOps système linux - freelance developer

___
Password-Store mailing list
Password-Store@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/password-store


Re: [pass] [PATCH] Allow custom subcommands

2016-10-03 Thread Thorsten Wißmann
Hi Sylvain,

On Mon, Oct 03, 2016 at 07:20:47AM +0200, Sylvain Viart wrote:
> Le 30/09/2016 à 11:33, Thorsten Wißmann a écrit :
> > if there is an executable pass-clipwiz in the PATH. This does not only
> > fit the usual pass workflow (first show a file, then paste it using
> > clipwiz), but one also gets the tab-completion for custom pass scripts
> > for free.
> 
> Sounds cool!
> 
> See also:
> 
> [pass] Extending pass with user-defined hooks / add ons
> https://lists.zx2c4.com/pipermail/password-store/2015-August/001659.html

I see, thanks! I think the main decision is whether those extensions
should be part of "the password store" (that approach) or of the system
(my approach).

> Does GPG web of trust sure enough, to allow co-signing script to enable
> such signed plugins?

I don't understand your question. But are you asking how my patch could
be extended to call only 'signed' extensions?

If some bad guy has write access to some directory in $PATH and wants to
take over your password store, then the bad guy can simply add a
malicious `pass` executable and the user would not notice.

I.e. I don't think `pass` should do something like signing of program
code. It's some separate problem to check if the programs in your $PATH
are trustworthy or not.

Cheers,
Thorsten


signature.asc
Description: PGP signature
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/password-store