Re: encrypted file and directory names?

Adam Spiers writes: > I got the impression that the point of pass was to provide an > additional line of defence above what the filesystem already provides. > If the filesystem can be trusted to keep things secure then you could > simply store all your credentials in it in

Re: encrypted file and directory names?

Marin Usalj writes: > There's still syncing those passwords over the wire and across > different filesystems. I don't fully trust cloud VPS fs encryption > either. In that case you may want to consider the git-remote-gcrypt extension. This will allow you to encrypt the

Re: encrypted file and directory names?

Doing any of these and obfuscating filenames would destroy a lot of what makes pass great. Pass stores it's passwords in files that can be simply used with pass, or without pass by just using gpg. Changing filenames to something the user did not chose destroys this simplicity. Also, there is no

Re: [pass] pass and tomb together

On Sun, 5 Feb 2017 22:39:52 +, Alexandre Pujol wrote: >pass-tomb [3] is my solution to these issue. It provides a Unix >Philosophy compatible solution to the tree problem in pass. This is a >pass extension providing a convenient solution to put you password >repository in

Re: [pass] pass and tomb together

> Did you read my latest proposal yet? > > > https://lists.zx2c4.com/pipermail/password-store/2017-February/002714.html > > I think it should be secure, and would not completely transform pass. In my opinion this is the perfect example of solution that would transform pass. >From the pass

Re: [pass] pass and tomb together

On Sun, Feb 05, 2017 at 10:39:52PM +, Alexandre Pujol wrote: Hi all, They have been a lot of discussions in this ML about the fact that files and directories names are not encrypted in the password store. Just check [1] for last year discussion and [2] for this year discussion. There aren't

[pass] pass and tomb together

Hi all, They have been a lot of discussions in this ML about the fact that files and directories names are not encrypted in the password store. Just check [1] for last year discussion and [2] for this year discussion. There aren't any good solution yet. Most of the solution proposed are either

Re: encrypted file and directory names?

On Sun, Feb 05, 2017 at 10:27:58AM +0100, Sebastian Reuße wrote: Adam Spiers writes: There is one feature which I consider pretty essential, and as far as I can see, it's not supported by pass yet, which is to keep the entire metadata encrypted, including the directory

Re: encrypted file and directory names?

On Sun, Feb 05, 2017 at 08:26:18AM +, Brian Candler wrote: On 05/02/2017 03:53, HacKan Iván wrote: I thought the same, but implementing it is a real pain in the ass. I'm currently working on something I'll send soon, and then I'm gonna work on an extension to do just that :) If this

Re: add new dump command

I second that idea. Would you mind creating a new thread for it? On February 5, 2017 11:17:32 AM GMT-03:00, Alexandre Pujol wrote: >+1 > >My email explaining how to create an extension can be found here:

Re: add new dump command

On 02/05/2017 09:04 AM, HacKan Iván wrote: > Funny thing is, I said the same the first time someone answered me that (a > week ago) :D > > I can't find that email, but I wrote one: > https://github.com/HacKanCuBa/pass-extension-insertfile > > Basically, an extension is a file named

Re: add new dump command

+1 My email explaining how to create an extension can be found here: https://lists.zx2c4.com/pipermail/password-store/2017-January/002685.html I think a page on password-store.org documenting extension creation could be useful. On 05/02/17 14:04, HacKan Iván wrote: > Funny thing is, I said the

Re: add new dump command

Funny thing is, I said the same the first time someone answered me that (a week ago) :D I can't find that email, but I wrote one: https://github.com/HacKanCuBa/pass-extension-insertfile Basically, an extension is a file named command.bash in .extensions directory in the store

Re: add new dump command

On 02/04/2017 10:52 PM, HacKan Iván wrote: > Yo should better implement this as an extension: pass dump. > I'm not really sure what you mean by "as an extension". Are there any docs on creating extensions for "pass"? What other extensions already exist? Dusty

Re: encrypted file and directory names?

Adam Spiers writes: > There is one feature which I consider pretty essential, and as far as > I can see, it's not supported by pass yet, which is to keep the entire > metadata encrypted, including the directory names and file names. > Without this it doesn't seem to provide

Re: encrypted file and directory names?

On 05/02/2017 03:53, HacKan Iván wrote: I thought the same, but implementing it is a real pain in the ass. I'm currently working on something I'll send soon, and then I'm gonna work on an extension to do just that :) If this is implemented I'd definitely prefer to see it as an extension,