Bug 138539 - Choose Crypto-Key for each protocol not for the hole metacontact
Summary: Choose Crypto-Key for each protocol not for the hole metacontact
Status: RESOLVED INTENTIONAL
Alias: None
Product: kopete
Classification: Applications
Component: Cryptography Plugin (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR wishlist
Target Milestone: ---
Assignee: Kopete Developers
URL:
Keywords:
: 131345 139862 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-12-08 15:56 UTC by Andreas Bayer
Modified: 2007-10-20 21:31 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Bayer 2006-12-08 15:56:22 UTC
Version:            (using KDE KDE 3.5.5)
Installed from:    Debian testing/unstable Packages

Hi,

pgp cryptography with icq in kopete seem to have several problems with the maximum length of icq messages.

So i would like to set cryptography-key not for the hole metacontact, but for each protocol.

If someone have several msn-ids then he may have several pgp-keys for theses adresses too. So i need to choose for each ids the correct key.


thx
Comment 1 Bram Schoenmakers 2007-01-10 20:37:23 UTC
*** Bug 139862 has been marked as a duplicate of this bug. ***
Comment 2 Charles Connell 2007-07-17 05:09:18 UTC
I understand the message length problem. I do not think, however, that public keys should be associated with pure-contacts. One meta-contact represents one person, and therefore one public key. If the people you chat with uses multiple key pairs, they are the ones at fault. Key pairs are meant to be a digital representation of one's identity, therefore individuals should only have one. I am looking into the message length issue. That is the real bug. I suggest marking this as WONTFIX. Opinions welcome.
Comment 3 Charles Connell 2007-07-17 19:59:18 UTC
Since no one has responded, I will shut this bug down myself.
Comment 4 Charles Connell 2007-10-20 21:31:08 UTC
*** Bug 131345 has been marked as a duplicate of this bug. ***