On 07/26/2015 11:38 AM, Andrew McGinnis wrote:
There's plenty of options, I'm sure. If you can define the password file for fetchmail, these are probably better solutions than mine. I'm not familiar with fetchmail.
The fundamental problem is that fetchmail requires a cleartext rc file that contains cleartext passwords. It doesn't matter that when you're not logged in or the machine is down that the .fetchmailrc is actually on an encrypted partition. Having a symlink from /home/${USER}/.fetchmailrc to /encrypted/${USER}/fetchmailrc is fundamentally no different to having an encrypted /home or an encrypted /home/${USER}. The reason for this is that to be able to use it all you need to mount the volume unencrypted. The "running" system need the unencrypted view. The protection that encrypting a drive or partition offers is useful if the laptop is stolen when powered down. If its stolen when powered up then the thief just has to make sure it never powers down! This is the basis of a novel by John Sandford http://www.johnsandford.org/kidd04.html A better approach is to have the password fields encrypted and code in the 'fetch' program (whatever it may be) that can handle that encryption. This may be a dedicated filed in a sqlite database or a record in a KDE wallet or Gnome keychain. The problem is that the author of fetchmail made a decision not to have those fields encrypted and not to have the code to handle encrypted field in the body of the program. I say "better" above because there are still modes where the password could be snooped. That's why you should use TLS. But that's another matter. Ridiculously, Eric Raymond thought it was OK to have the crypto code to handle TLS but not encrypted fields. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org