[Kde-pim] Need help with the undefined reference hack

Ingo Klöcker kloecker at kde.org
Mon Oct 24 22:11:42 BST 2011


On Thursday 20 October 2011, Milian Wolff wrote:
> On Wednesday 19 October 2011 21:48:17 Ingo Klöcker wrote:
> > On Wednesday 19 October 2011, Milian Wolff wrote:
> > > Christian Mollekopf, 19.10.2011:
> > > > On Wednesday, October 19, 2011 1:13 PM, "Andras Mantia"
> > > > 
> > > > <amantia at kde.org> wrote:
> > > > > Christian Mollekopf wrote:
> > > > > > In the long run only if there is a way to get hold of the
> > > > > > encrypted/unencrypted content without the MessageViewer.
> > > > > > (Frankly I'm not a big fan of using the MessageViewer for
> > > > > > the feeder, but it seems to be the only way).
> > > > > 
> > > > > Yes, using the messageviewer for this is not a good solution.
> > > > > Sincerely I'd just ignore indexing of encrypted mails for now
> > > > > and move the
> > > > > feeder to kdepim-runtime.
> > > > 
> > > > I'd prefer that solution too. Objections anyone?
> > > > 
> > > > > There is anyway a need for explicitly enable that indexing
> > > > > (as normally the
> > > > > user doesn't want to have (part of) its encrypted content
> > > > > unencrypted in a
> > > > > database), and most users probably don't have that many
> > > > > encrypted mails anyway.
> > > > > 
> > > > > Then we can find a solution later for encryption.
> > > 
> > > what what? if encrypted stuff gets indexed in plain text
> > > somewhere I'd see that as a severe security breach. So yes,
> > > please do disable this - I wasn't even aware that this is done
> > > so far!
> > 
> > It has already been said that it's off by default and I agree that
> > it must not be enabled without explicit consent of the user.
> > Nevertheless I want to point out that it depends on your threat
> > model whether indexing encrypted messages is a problem.
> > 
> > If you use mail encryption for protecting the content of messages
> > during transit and when stored on an IMAP server then indexing of
> > encrypted messages (where the index is stored on your local
> > harddisk) is no problem at all.
> > 
> > If your threat model includes physical or remote access to your
> > local filesystem/harddisk then not using indexing will not protect
> > you because the attacker will simply own your box, steal your
> > OpenPGP key and install a keylogger or a special version of gpg in
> > order to steal your passphrase.
> > 
> > So, before you talk about a severe security breach please explain
> > your threat model.
> 
> I agree that I didn't think too much about it.
> 
> But personally, I still have to insert a password to read encrypted
> mails - even though I use gpg agent... So just having the private
> key does not seem to be enough?!

It's not enough, but somebody who can steal your private key might also 
be able to steal your passphrase (e.g. by installing a trojan pinentry 
application).


> Also: isn't the nepomuk database back'ed-up by default and hence such
> backups would contain the plaintext passwords?  Which a user would
> then probably move to some other backup place, like an unprotected
> usb/harddisk or so..

I don't follow you. What has nepomuk to do with passwords? Are you 
talking about passwords stored in encrypted messages?


> Furthermore, wouldn't the same reasoning of yours ("plaintext is OK
> as it's in local files only") also apply to all kind of
> configuration files? KWallet e.g. also uses a password by default.
> So imo it's good practice to never leave stuff in plaintext around,
> "just because it's local".

Well, yes and no. I encrypt all of my data using harddisk encryption. 
This protects my data from people stealing my hardware. It does not 
protect my data from people breaking into my box, but if my box is 
rooted then all hope is lost anyway which is why I do not put more 
effort into additional protection.

Given that almost none of the messages I receive are encrypted I'd 
probably keep encrypted messages from being indexed. I'm not sure what 
I'd do if a significant amout was encrypted.


> And ps: of course this discussion is more or less moot if this
> feature is already a) disabled and b) only enabled by explicit user
> choice in the future.

I fully agree.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20111024/61fe637b/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list