Re: Security Vulnerability: Faulty GPG Signature Checking

[Gabriel Filion]

On 2018-06-15 10:47 AM, Ben Oliver wrote:
> On 18-06-16 01:53:52, Steve Gilberd wrote:
>> One other thought regarding the choice of language. I personally keep a
>> copy of pass stored *inside my pass git repository*, so that I can still
>> easily use it on systems where pass is not installed without adding too
>> many extra steps. Bash is everywhere, which makes it extremely portable.
> 
> That's a really interesting use-case that should definitely be taken
> into account. I always keep it in my PATH so I never think of it as a
> script really, but if people are doing this then it is quite a good
> reason to stay with bash.

other scripting languages can also let you do this. a python script that
has a #! as a first line can be moved around and still work. you can
also use a virtualenv to keep around a complete working environment with
you.

bash is horrible at handling strings of text inside variables without
opening up holes everywhere.

the biggest disadvantage to bash is really the need to call gpg directly
and parse its output. doing this is really the biggest PITA that could
end up exploding maintenance of this project.



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

Re: Security Vulnerability: Faulty GPG Signature Checking

[Greg Minshall]

Ben,

> No. It only stops people from adding new commits who don't have your
> GPG key.

thanks (again).  one thing is that now "pass insert" requires inputting
your gpg key (in order to sign, presumably).  so, a very minor
annoyance.

cheers, Greg
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Security Vulnerability: Faulty GPG Signature Checking

[Tinu Weber]

On Fri, Jun 15, 2018 at 20:13:46 -0500, Brad Knowles wrote:
> Speaking as one of the guys who has been a member of the team
> supporting postmas...@python.org since 2003, the problem with Python
> as a programming language today remains the split between Python 2.x
> and 3.x, and how many systems are still in active use with an ancient
> version of the language installed as part of the system.

I don't see an issue there, they are not exclusive: one can have both
python2 and python3 installed, and the interpreter is chosen based on
the shebang anyway (so it's not really any different from having a
"split between python and perl").

Also, python2 will reach its long-overdue official EOL in 2020, so I
don't think it's worth to be considered an option.

Best,
Tinu


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

Re: Security Vulnerability: Faulty GPG Signature Checking

[Brad Knowles]

On Jun 15, 2018, at 10:26 AM, Mark Gardner  wrote:

> ​​I'm cool with Python. When I am not programming in Go, I am programming in 
> Python. It seems to be installed by default on all the Linux systems lately. 
> I am no longer so fond of perl, which is strange to say as I have done some 
> fairly big programs in perl. I found that it gets very obtuse when you need 
> to start creating nested data structures or use objects. Once upon a time, 
> perl with the the big thing. The momentum seems to have swung towards Python 
> these days.

Speaking as one of the guys who has been a member of the team supporting 
postmas...@python.org since 2003, the problem with Python as a programming 
language today remains the split between Python 2.x and 3.x, and how many 
systems are still in active use with an ancient version of the language 
installed as part of the system.

If you can write your code in such a way that it doesn't matter what version of 
Python you're using, then that's fine.

But that's also a very tall ask.

> ​I think you are conflating the dependencies that need to be installed to 
> build a compiled tool from the dependencies to install and use the tool. 
> Since most people install packages via their package manager, the former is 
> not much of an issue in my opinion. I agree that I don't want to have to tons 
> of separate libraries installed with the tool.​

I don't want to have to pull in a lot of additional dependencies in order to 
support a tool -- any tool.

The simpler and more self-sufficient you can make/keep the tool in question, 
the better.

> ​Don't know about Rust but installing a Go-based pass would be no different 
> than the current version. It would be just a single executable plus stuff 
> like examples and docs. The code would be written to check for optional 
> dependencies, such as git, and only use them if found. Just like the current 
> pass.

If the code is written in go, then it has to be compiled to run on the hardware 
in question.  I don't want to have to compile code, either.

Moreover, once you have a binary that is separate from the source code, you can 
no longer guarantee the behaviour of the binary and that it really does 
correspond to the source code that may have been validated.

Keeping It Simple, Silly + There Is No Compiler = Bash plus very few other 
options.


So, KISS and TINC, please.  Beyond that, I'm not too wedded to the language.

But if you do want to keep it in Bash, here are tools out there that can help 
make that Bash code robust and pretty safe.

--
Brad Knowles 



signature.asc
Description: Message signed with OpenPGP
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Security Vulnerability: Faulty GPG Signature Checking

[Nick Klauer]

I just want to point out that there already exists a pass-compatible
version written in go: https://github.com/gopasspw/gopass

I use it, and it would just fine for my purposes.


On Fri, Jun 15, 2018 at 10:28 Mark Gardner  wrote:

> On Fri, Jun 15, 2018 at 8:13 AM, Tobias Girstmair  > wrote:
>
>> I should've probably phrased that very differently. What I meant to say
>> was I'd support a pass 2.0 written in a language that is an integral
>> part of the GNU/Linux/BSD/etc ecosystem[1]. A scripting language like
>> Python or Perl[2] would be very good options IMO.
>>
>
> ​​I'm cool with Python. When I am not programming in Go, I am programming
> in Python. It seems to be installed by default on all the Linux systems
> lately. I am no longer so fond of perl, which is strange to say as I have
> done some fairly big programs in perl. I found that it gets very obtuse
> when you need to start creating nested data structures or use objects. Once
> upon a time, perl with the the big thing. The momentum seems to have swung
> towards Python these days.
> ​
>
>> What I failed to communicate was that I don't want to have to install a
>> whole load of dependencies, be it a Rust[3] or Go compiler or let alone
>> npm/nodejs.
>>
>
> ​I think you are conflating the dependencies that need to be installed to
> build a compiled tool from the dependencies to install and use the tool.
> Since most people install packages via their package manager, the former is
> not much of an issue in my opinion. I agree that I don't want to have to
> tons of separate libraries installed with the tool.​
>
> ​Don't know about Rust but installing a Go-based pass would be no
> different than the current version. It would be just a single executable
> plus stuff like examples and docs. The code would be written to check for
> optional dependencies, such as git, and only use them if found. Just like
> the current pass.
>
> In the end I don't really care what language pass is written in. Just so
> long as it exists and works much like it does now.​
>
> Mark
> --
> Mark Gardner
> --
> ___
> Password-Store mailing list
> Password-Store@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/password-store
>
-- 

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

Re: Security Vulnerability: Faulty GPG Signature Checking

[Mark Gardner]

On Fri, Jun 15, 2018 at 8:13 AM, Tobias Girstmair 
wrote:

> I should've probably phrased that very differently. What I meant to say
> was I'd support a pass 2.0 written in a language that is an integral
> part of the GNU/Linux/BSD/etc ecosystem[1]. A scripting language like
> Python or Perl[2] would be very good options IMO.
>

​​I'm cool with Python. When I am not programming in Go, I am programming
in Python. It seems to be installed by default on all the Linux systems
lately. I am no longer so fond of perl, which is strange to say as I have
done some fairly big programs in perl. I found that it gets very obtuse
when you need to start creating nested data structures or use objects. Once
upon a time, perl with the the big thing. The momentum seems to have swung
towards Python these days.
​

> What I failed to communicate was that I don't want to have to install a
> whole load of dependencies, be it a Rust[3] or Go compiler or let alone
> npm/nodejs.
>

​I think you are conflating the dependencies that need to be installed to
build a compiled tool from the dependencies to install and use the tool.
Since most people install packages via their package manager, the former is
not much of an issue in my opinion. I agree that I don't want to have to
tons of separate libraries installed with the tool.​

​Don't know about Rust but installing a Go-based pass would be no different
than the current version. It would be just a single executable plus stuff
like examples and docs. The code would be written to check for optional
dependencies, such as git, and only use them if found. Just like the
current pass.

In the end I don't really care what language pass is written in. Just so
long as it exists and works much like it does now.​

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

Re: Security Vulnerability: Faulty GPG Signature Checking

[Ben Oliver]

On 18-06-16 01:53:52, Steve Gilberd wrote:

One other thought regarding the choice of language. I personally keep a
copy of pass stored *inside my pass git repository*, so that I can still
easily use it on systems where pass is not installed without adding too
many extra steps. Bash is everywhere, which makes it extremely 
portable.


That's a really interesting use-case that should definitely be taken 
into account. I always keep it in my PATH so I never think of it as a 
script really, but if people are doing this then it is quite a good 
reason to stay with bash.


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

Re: Security Vulnerability: Faulty GPG Signature Checking

[Kevin Lyda]

Close to what I do - I keep a copy in my vcsh home repo.

Kevin

On Fri, Jun 15, 2018 at 2:55 PM Steve Gilberd  wrote:

> One other thought regarding the choice of language. I personally keep a
> copy of pass stored *inside my pass git repository*, so that I can still
> easily use it on systems where pass is not installed without adding too
> many extra steps. Bash is everywhere, which makes it extremely portable.
>
> It's fairly common for me to use it from a live distro (typically
> sysresccd), and sometimes on some other system that isn't mine.
>
> Cheers,
> Steve
>
> On Sat, 16 Jun 2018 at 01:49 Steve Gilberd  wrote:
>
>> On Sat, 16 Jun 2018 at 01:36 Ben Oliver  wrote:
>>
>> > I don't think that 'simple' necessarily means bash.
>>
>> It doesn't - 'simple' and 'written in bash' were two separate points. I
>> was endorsing bash, because:
>>  (a) bash is something I already know and can easily audit; and
>>  (b) bash has no concept of packages which removes the temptation to
>> import arbitrary functionality.
>>
>> I don't have any objection to other languages in principle, but bash has
>> some compelling points that make it ideal *for my particular use-case*.
>>
>> > You know how pass works, even without looking at the source code.
>>
>> But I'm not looking at the source to figure out how it works. I'm looking
>> at the source to ensure it is trustworthy.
>>
>> Cheers,
>> Steve
>> --
>>
>> Cheers,
>>
>> *Steve Gilberd*
>> Erayd LTD *·* Consultant
>> *Phone: +64 4 974-4229 <+64%204-974%204229> **·** Mob: +64 27 565-3237
>> <+64%2027%20565%203237>*
>> *PO Box 10019, The Terrace, Wellington 6143, NZ*
>>
> --
>
> Cheers,
>
> *Steve Gilberd*
> Erayd LTD *·* Consultant
> *Phone: +64 4 974-4229 <+64%204-974%204229> **·** Mob: +64 27 565-3237
> <+64%2027%20565%203237>*
> *PO Box 10019, The Terrace, Wellington 6143, NZ*
> ___
> Password-Store mailing list
> Password-Store@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/password-store
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Security Vulnerability: Faulty GPG Signature Checking

[Steve Gilberd]

One other thought regarding the choice of language. I personally keep a
copy of pass stored *inside my pass git repository*, so that I can still
easily use it on systems where pass is not installed without adding too
many extra steps. Bash is everywhere, which makes it extremely portable.

It's fairly common for me to use it from a live distro (typically
sysresccd), and sometimes on some other system that isn't mine.

Cheers,
Steve

On Sat, 16 Jun 2018 at 01:49 Steve Gilberd  wrote:

> On Sat, 16 Jun 2018 at 01:36 Ben Oliver  wrote:
>
> > I don't think that 'simple' necessarily means bash.
>
> It doesn't - 'simple' and 'written in bash' were two separate points. I
> was endorsing bash, because:
>  (a) bash is something I already know and can easily audit; and
>  (b) bash has no concept of packages which removes the temptation to
> import arbitrary functionality.
>
> I don't have any objection to other languages in principle, but bash has
> some compelling points that make it ideal *for my particular use-case*.
>
> > You know how pass works, even without looking at the source code.
>
> But I'm not looking at the source to figure out how it works. I'm looking
> at the source to ensure it is trustworthy.
>
> Cheers,
> Steve
> --
>
> Cheers,
>
> *Steve Gilberd*
> Erayd LTD *·* Consultant
> *Phone: +64 4 974-4229 <+64%204-974%204229> **·** Mob: +64 27 565-3237
> <+64%2027%20565%203237>*
> *PO Box 10019, The Terrace, Wellington 6143, NZ*
>
-- 

Cheers,

*Steve Gilberd*
Erayd LTD *·* Consultant
*Phone: +64 4 974-4229 **·** Mob: +64 27 565-3237*
*PO Box 10019, The Terrace, Wellington 6143, NZ*
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Security Vulnerability: Faulty GPG Signature Checking

[Steve Gilberd]

On Sat, 16 Jun 2018 at 01:36 Ben Oliver  wrote:

> I don't think that 'simple' necessarily means bash.

It doesn't - 'simple' and 'written in bash' were two separate points. I was
endorsing bash, because:
 (a) bash is something I already know and can easily audit; and
 (b) bash has no concept of packages which removes the temptation to import
arbitrary functionality.

I don't have any objection to other languages in principle, but bash has
some compelling points that make it ideal *for my particular use-case*.

> You know how pass works, even without looking at the source code.

But I'm not looking at the source to figure out how it works. I'm looking
at the source to ensure it is trustworthy.

Cheers,
Steve
-- 

Cheers,

*Steve Gilberd*
Erayd LTD *·* Consultant
*Phone: +64 4 974-4229 **·** Mob: +64 27 565-3237*
*PO Box 10019, The Terrace, Wellington 6143, NZ*
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Security Vulnerability: Faulty GPG Signature Checking

[Ben Oliver]

On 18-06-16 01:11:51, Steve Gilberd wrote:

I feel the same - the simplicity of it, and the ability for me to easily
audit the source code, are significant reasons for my choosing *pass* as my
password manager.

I feel quite strongly that it should remain both simple / small, and
ideally still written in bash. No objections to a rewrite to clean things
up though.


I don't think that 'simple' necessarily means bash. Yeah, people can 
read the script but you can argue that about any language you know or 
don't know.


If you can re-write pass, keeping the gpg and git integration, then I 
don't think the language matters too much. If the maintainer feels a 
bash script is just spiralling out of control, then it should go.


What I like about pass is what Héctor mentioned... the fact that you can 
just use gpg to get a password out of the system is killer, and is huge 
insurance against data loss. There are other ways to access your data, 
not just with the program you created it with.


You know how pass works, even without looking at the source code. That's 
because you know how gpg and git work. It's a beautiful idea. I don't 
think that the language pass is written in matters that much so long as 
the core functionality stays.


Yes, I am a professional fence-sitter ;)


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

Re: Security Vulnerability: Faulty GPG Signature Checking

[Steve Gilberd]

I feel the same - the simplicity of it, and the ability for me to easily
audit the source code, are significant reasons for my choosing *pass* as my
password manager.

I feel quite strongly that it should remain both simple / small, and
ideally still written in bash. No objections to a rewrite to clean things
up though.

Cheers,
Steve
-- 

Cheers,

*Steve Gilberd*
Erayd LTD *·* Consultant
*Phone: +64 4 974-4229 **·** Mob: +64 27 565-3237*
*PO Box 10019, The Terrace, Wellington 6143, NZ*
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Security Vulnerability: Faulty GPG Signature Checking

[Tobias Girstmair]

On Fri, Jun 15, 2018 at 08:57:57AM +0300, Matthieu Weber wrote:
> It is very difficult to write correct programs in C, and very easy to
> write C programs with security holes in it. Since the topic here is
> security, I would advise against C. Go, Rust, Java even, or scripting
> languages such as Python, Ruby or even Perl are probaly safer than C (or
> C++).

I should've probably phrased that very differently. What I meant to say
was I'd support a pass 2.0 written in a language that is an integral
part of the GNU/Linux/BSD/etc ecosystem[1]. A scripting language like
Python or Perl[2] would be very good options IMO.

What I failed to communicate was that I don't want to have to install a
whole load of dependencies, be it a Rust[3] or Go compiler or let alone
npm/nodejs.


[1]: By that I mean something that is pre-installed on most systems,
 which I believe both Perl and Python are. 
[2]: I've recently fallen in love with Perl. Feels like a shell, but way
 more powerful. 
[3]: Not only do none of my systems come with a rust (or go) toolchain, 
 so many Rust projects list "curl some-rust-distro.com | sudo bash"
 as step one of the install procedure - I'm not installing anything
 that's not packaged by my OS distribution (for me that even means
 no PyPi/pip or CPAN).


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

Re: Security Vulnerability: Faulty GPG Signature Checking

[Héctor Rivas Gándara]

> what initially drew people to pass over other (perhaps more conventional
database-backed) solutions

In my case, this:

$ gpg -d < ~/.password-store/test/hello.gpg

;)

-- 
Héctor Rivas

On Fri, Jun 15, 2018 at 8:32 AM, Ben Oliver  wrote:

> On 18-06-15 09:16:27, Volkan Yazıcı wrote:
>
>> I see the point of replacing bash with another programming language, that
>> being said, I feel the urge to say something about this without falling
>> into the trap of ranting about programming languages. One of the key
>> points
>> of pass that was really the selling point for me was, apart from perfectly
>> solving the problem it was designed to solve, the transparency of the
>> implementation.
>>
>
> This is it for me too. The design is so simple that the drawbacks, like
> having the file names exposed, are immediately obvious to any newcomer.
> There are no nasty suprises down the line - it's just gpg and git.
>
> I'm not saying that moving away from bash is a bad idea, just that it is
> important to think about what initially drew people to pass over other
> (perhaps more conventional database-backed) solutions.
>
> ___
> Password-Store mailing list
> Password-Store@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/password-store
>
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Security Vulnerability: Faulty GPG Signature Checking

[Ben Oliver]

On 18-06-15 09:16:27, Volkan Yazıcı wrote:

I see the point of replacing bash with another programming language, that
being said, I feel the urge to say something about this without falling
into the trap of ranting about programming languages. One of the key points
of pass that was really the selling point for me was, apart from perfectly
solving the problem it was designed to solve, the transparency of the
implementation.


This is it for me too. The design is so simple that the drawbacks, like 
having the file names exposed, are immediately obvious to any newcomer.  
There are no nasty suprises down the line - it's just gpg and git.


I'm not saying that moving away from bash is a bad idea, just that it is 
important to think about what initially drew people to pass over other 
(perhaps more conventional database-backed) solutions.


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

Re: Security Vulnerability: Faulty GPG Signature Checking

[Volkan Yazıcı]

I see the point of replacing bash with another programming language, that
being said, I feel the urge to say something about this without falling
into the trap of ranting about programming languages. One of the key points
of pass that was really the selling point for me was, apart from perfectly
solving the problem it was designed to solve, the transparency of the
implementation. The ability to just open a file and understand what is
going on is really convenient. I can just prepend a "set -x" to the top of
the script and observe/debug every single bit during execution. I developed
pass-extension-copyq  in
minutes without consulting to any manuals, but just reading the source
code. I did not need to compile anything, just made my changes and there I
go. It is not a black box, it is not a magic ball. It is a freaking awesome
single-file bash script.

Long story short... *Please, please, please, do not replace bash with a
compiled language.* Let it be Python, let it be Ruby, etc. I don't care.
(Actually I do care, availability across a wide range of platforms is a
great plus. Though I love pass so much that I can install scheme48 if pass
just happens to depend on it.) Please go with a scripting language and keep
this awesome implementation transparency intact.

On Thu, Jun 14, 2018 at 5:11 PM Jason A. Donenfeld  wrote:

> Hey list,
>
> After discussing pass and GPG with Marcus Brinkmann at FOSDEM this
> year, and then witnessing the amazing bugs in Enigmail a while back,
> Marcus went and had a look at how our shell script is actually dealing
> with GPG output. He discovered (1) that our parsing of gpg command
> line output with regexes isn't anchored to the beginning of the line,
> which means an attacker can generate a malicious key that simply has
> the verification string as part of its username, which fixed in pass
> 1.7.2. This has a number of nasty consequences: a) an attacker who
> manages to write into your ~/.password-store and also inject a
> malicious key into your keyring can replace your .gpg-id key and have
> your passwords encrypted under additional keys; b) if you have
> extensions enabled (disabled by default), an attacker who manages to
> write into your ~/.password-store and also inject a malicious key into
> your keyring can replace your extensions and hence execute code. This
> has been assigned CVE-2018-12356.
>
> Marcus also points out two secondary problems related to integrity.
> The first secondary problem (2) is that while we try to preserve gpg's
> exit code, in case of a decryption failure, the gpg tool has a
> deficiency that it always writes to stdout before verification, which
> is mitigated in pass 1.7.2 by simply buffering the output ourselves
> (ugh). The second secondary problem (3) is that pass does not sign its
> files, which means an attacker who manages to write into your
> ~/.password-store and also inject a malicious key into your keyring
> can display the wrong password. Problem (3) is not a new finding at
> all for pass, and I group it together with the well-known related
> aspect, which is that the directory tree itself doesn't have any
> integrity: you can add, remove, and rename files trivially, if you're
> not using git with commit signing. Pass's direct use of GPG has always
> focused on secrecy without a lot of focus on authenticity, blaming the
> GPG tooling again. Our recommendations for authenticity and integrity
> continue to be to enable git commit signing, which pass has built-in
> support for.
>
> One way to add this directly to pass without relying on git to handle
> it for us is by adding signatures to each file, which I've long
> resisted for a variety of reasons, both due to the GPG tooling
> boogieman, as well as semantic issues with then verifying against user
> ids that have been removed from .gpg-id. Perhaps a different way would
> be for pass to use its own keyring, rather than the default ~/.gnupg
> keyring; we can discuss ideas like these for 1.8. Either way, if
> you're managing and sync'ing your password store using git, you really
> should be signing those git commits. Perhaps we can also consider
> _enforcing_ git signatures.
>
> I remember Marcus and my funny conversation at FOSDEM, during which he
> asked me my ideas on the GPG interface and what it provides and what
> pass might need from it, which provoked what was evidently a lot of
> pent-up frustration in me with the command line tools. I recall
> mentioning how pass is this ever-sprawling bash script filled with
> impossible to understand regular expressions, because GPG doesn't
> provide a more precise interface for verifying and extracting the
> information we need. I'm quite happy he looked into it for us.
>
> There are two reasons why my presence on this list is fairly minimal
> these days: I'm extremely hesitant to add new junk to pass, as I don't
> think feature bloat is actually a real feature with tools like this,
> which are 

Re: Security Vulnerability: Faulty GPG Signature Checking

[Sebastian Reuße]

Tobias Girstmair  writes:

> On Thu, Jun 14, 2018 at 05:09:35PM +0200, Jason A. Donenfeld wrote:

>> Our recommendations for authenticity and integrity continue to be to
>> enable git commit signing, which pass has built-in support for.

> Maybe this should be mentioned/explained on passwordstore.org
> (grepping for 'sign' didn't turn up anything useful)

Perhaps it would also make sense for Jason to refer to git-remote-gcrypt
[1], which, in addition to authenticity and integrity, also provides
confidentiality for file-system level metadata (password entry names and
the directory tree) on the remote side, something that has been
discussed here in the past.

[1] 

Kind regards,
SR

-- 
Insane cobra split the wood
Trader of the lowland breed
Call a jittney, drive away
In the slipstream we will stay
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Security Vulnerability: Faulty GPG Signature Checking

[Matthieu Weber]

On Thu, 14 Jun 2018 at 05:11PM -0400, Mark Gardner wrote:
> On Thu, Jun 14, 2018 at 19:49:56 +0200, Tobias Girstmair wrote:
> > *simple* bash scripts I've found are either trivial or
> > {fragile,wrong,buggy,insecure}. Again, I'd support C (or anything widely
> > supported) for pass 2.0
> 
> Lately I have switched all my C hacking over to Golang (Go). While pass
> would need to be compiled individually for each platform, it would keep
> portability, including Windows. We should seriously consider re-writing
> pass in Go.

It is very difficult to write correct programs in C, and very easy to
write C programs with security holes in it. Since the topic here is
security, I would advise against C. Go, Rust, Java even, or scripting
languages such as Python, Ruby or even Perl are probaly safer than C (or
C++).
 
Matthieu
-- 
 (~._.~)Matthieu Weber - mwe...@free.fr  (~._.~)
  ( ? )http://weber.fi.eu.org/( ? ) 
 ()- -()  public key id : 0x85CB340EFCD5E0B3 ()- -()
 (_)-(_) "Humor ist, wenn man trotzdem lacht (Otto J. Bierbaum)" (_)-(_)


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

Re: Security Vulnerability: Faulty GPG Signature Checking

[Mark Gardner]

On Thu, Jun 14, 2018 at 19:49:56 +0200, Tobias Girstmair wrote:
> *simple* bash scripts I've found are either trivial or
> {fragile,wrong,buggy,insecure}. Again, I'd support C (or anything widely
> supported) for pass 2.0

Lately I have switched all my C hacking over to Golang (Go). While pass
would need to be compiled individually for each platform, it would keep
portability, including Windows. We should seriously consider re-writing
pass in Go.

Another consideration is that Go doesn't use shared libraries which makes a
compiled Go program easily moved across different distributions within the
same platform by simply copying the executable.

BR,
Mark
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Security Vulnerability: Faulty GPG Signature Checking

[Ben Oliver]

On 18-06-14 19:49:56, Tobias Girstmair wrote:

Thanks for this update -- very much appreciated. :-) A few thoughts below.

On Thu, Jun 14, 2018 at 05:09:35PM +0200, Jason A. Donenfeld wrote:

Our recommendations for authenticity and integrity
continue to be to enable git commit signing, which pass has built-in
support for.


Maybe this should be mentioned/explained on passwordstore.org (grepping
for 'sign' didn't turn up anything useful)


It is in the man page, but I must admit I did not notice it and only 
enabled it based on this email!


The command is:

   pass git config --bool --add pass.signcommits true


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

Re: Security Vulnerability: Faulty GPG Signature Checking

[Tobias Girstmair]

Thanks for this update -- very much appreciated. :-) A few thoughts below.

On Thu, Jun 14, 2018 at 05:09:35PM +0200, Jason A. Donenfeld wrote:
> Our recommendations for authenticity and integrity
> continue to be to enable git commit signing, which pass has built-in
> support for.

Maybe this should be mentioned/explained on passwordstore.org (grepping
for 'sign' didn't turn up anything useful)

> rearchitecting for a long time. One plan for that would be to simply
> use a cleaner subset of bash -- no use of sed, only bash regular
> expressions. The other would be to rewrite this in a real programming
> language and link to the gpgme library, which ostensibly gives us
> fine-grained verification and checking. 

While "pass is just a shell script" was what initially drew me to it, it
also is kinda dangerous (having ~/bin/ in my path would allow e.g.
tail(1) to be replaced by an evil version saving the gpg output
elsewhere). 
Therefore, I wouldn't be against a C implementation for example for 2.0. 

> latter has been that the appeal of pass is that it's "just" a simple
> bash script; 

*simple* bash scripts I've found are either trivial or
{fragile,wrong,buggy,insecure}. Again, I'd support C (or anything widely
supported) for pass 2.0


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