search

comotion / cpm

Console Password Manager
http://www.harry-b.de/dokuwiki/doku.php?id=harry:cpm
52 stars 13 forks source link

feature request: open password databases without local trust #53

Open comotion opened 8 years ago

comotion commented 8 years ago

submitted by @petterreinholdtsen through issue #27: """ Why would skipping the warning be a bad idea?

https://bugs.debian.org/806404 is a bug report in Debian which seem to be related to this issue, and the problem I reported there was being unable to read passwords unless trusting the key use do sign the passwords. It seem strange to me that I have to trust the people giving me passwords. I can understand such trust relationship for those I plan to give a password, but I do not really expect me to trust everyone giving me a password. """

comotion commented 8 years ago

If you are receiving passwords from people by some other channel, perhaps this does not require a trust relationship. However, in the case of a password manager, receiving passwords is akin to receiving and parsing input. There is an implicit trust relationship. CPM merely asks you to make that relationship explicit. What exactly is the problem with adding local trust for people you exchange databases with?

petterreinholdtsen commented 8 years ago

[Kacper Why]

If you are receiving passwords from people by some other channel, perhaps this does not require a trust relationship. However, in the case of a password manager, receiving passwords is akin to receiving and parsing input. There is an implicit trust relationship.

I do not understand this argument. For parsing input, I place my trust in the program doing the parsing, not the input provided. If I have to trust the data to avoid problems, I do not really trust the program...

As for receiving passwords, I would expect cpm to go in "read only mode" if I had files signed by someone I do not trust. Flat out refusing to read the file seem very strange to me. Would someone stealing a cpm data file have to trust the keys of the people the stole the file from to be able to read it?

CPM merely asks you to make that relationship explicit. What exactly is the problem with adding local trust for people you exchange databases with?

In this case, it was a problem finding time to meet and sign each others keys. I expected a trust path would be enough for cpm, but apparently not. I do not know how local signatures affect my GPG usage, and have not used them before, and did not have time to try to figure it out either.

Happy hacking Petter Reinholdtsen

comotion commented 8 years ago

re: debian bug report, that our underlying gpg library doesn't verify trust paths seems to be a bug of the library, or perhaps of our use of it. The keys you are having trouble with return "no data for verification" and so gpg cannot tell us anything about them.

For parsing input, I place my trust in the program doing the parsing, not the input provided. If I have to trust the data to avoid problems, I do not really trust the program...

This might be an argument that works for you, but it's simply not the way things really work. Underlying libraries like zlib and expat have been known to be exploitable and our program can do nothing to avoid this. The effort that has been put into CPM to insulate from this and other security problems is considerable, and although I acknowledge it is one of the less visible efforts, I consider it worthwhile.

In this case, it was a problem finding time to meet and sign each others keys. I expected a trust path would be enough for cpm, but apparently not. I do not know how local signatures affect my GPG usage, and have not used them before, and did not have time to try to figure it out either.

What's there to figure out? You don't need to sign a key to have some marginal local trust of it.

All that being said, putting CPM in read only mode might be a solution to solve your problem, I'll have a think on it.