On 2018-03-05 15:15, Kart Etlinger wrote:
> Well, all those problems can be solved by pass-tomb addon, but it uses
> zsh, which may be some problem for people who dislike zsh as coding
> language.
> So yes, the entire password store should be kept in one encrypted file
> and so it can be opened and closed.
>
> On 03/05/2018 12:16 PM, Truls Becken wrote:
>> Hi Peter,
>>
>> I know this is not what you asked about, but there is one other thing people
>> dislike about pass; the file hierarchy is in plain text. If you can fix that,
>> you might attract some users.
>>
>> -Truls
>>
>> On Mon, Mar 5, 2018 at 11:06 AM, <petern_AT_riseup.net> wrote:
>>> Hello,
>>>
>>> this mail won't be related to any suckless projects, I am looking for
>>> some guidance/tips. If this isn't a good place for such requests I can
>>> take a hint.
>>>
>>> Since I stumbled upon suckless.org (2-3 weeks) I switched to dwm and st,
>>> read the philosophy and many other pages, browsed through some source
>>> code, looked up plan 9 in a bit more detail than before, read about 9P,
>>> the list could go on for a while, you get the idea. I'm not a C
>>> programmer but decided it's time to try and write something useful.
>>> Thinking about a good project brought me to password stores. I never
>>> liked (or trusted) these big fluffy UI-driven password solutions (god
>>> forbid if they offer cloud syncing and such), so I always sticked with
>>> pass whenever possible. The only thing I dislike about it is
>>> piggybacking on gpg, which is big and scary for people who don't use it
>>> on a daily basis and from my own experience hard to understand and set
>>> up.
>>>
>>> Contemplating on what a pass-like password manager needs to do, making
>>> it as simple as possible, there's possibly 3 commands needed
>>> - init - one-time initialization of the password store, key generation,
>>> ...
>>> - set - encrypt a password
>>> - get - decrypt a password
>>>
>>> The second piece would be a daemon (agent) that caches the master
>>> password like gpg-agent or ssh-agent does. I don't want to focus on this
>>> piece until the first one is polished.
>>>
>>> Trying my hands on putting this together got me this far:
>>> https://gitlab.com/xificurC/heslo
>>>
>>> If you bore with me this far (pardon for the longer introduction) I can
>>> finally ask for some guidance: encryption isn't a topic to be taken
>>> lightly and I wouldn't like to rely on tips from random people on the
>>> internet. Storing passwords requires 1 encryption/decryption algorithm.
>>> Which one to choose? I would like to rely on libc only and am naively
>>> thinking an encryption/decryption algorithm could be easily copied into
>>> the current source code.
>>>
>>> If anyone finds it fun to look through some newcomer-level source code
>>> to give pointers on what should be changed or pinpoint bugs/issues with
>>> the code I'd be thrilled.
>>>
>>> Thanks in advance and reminding once again - if this is inappropriate
>>> for this mailing list just say the word. I'm just looking for guidance
>>> from people who value simplicity and have experience.
>>>
>>> --
>>> ------------
>>> Peter Nagy
>>> ------------
>>>
>>
What exactly is wrong with pass using the filesystem? The only
information I found on the pass-tomb site was that one can see the keys,
only the values are encrypted. Using correct permissions where's the
harm in that? I can see use-cases where it might matter but I'm aiming
for simple usage where it shouldn't really matter. Using the filesystem
makes the tool a lot easier because listing, filtering, deleting etc.
can be done with ls, grep, rm, find etc. So, is the key visibility
really the problem?
What about the encryption method? Any tips where to look? :)
--
------------
Peter Nagy
------------
Received on Tue Mar 06 2018 - 00:00:44 CET