feature request: open password databases without local trust

[comotion]

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]

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]

[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]

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.