From: jim@gonzul.net (Jim Cheetham)
Subject: [sup-talk] Encrypted password in configuration file
Date: Fri, 28 Aug 2009 19:07:02 +1200 [thread overview]
Message-ID: <f4cc59760908280007i3b226f0egd063126476e6ea3d@mail.gmail.com> (raw)
In-Reply-To: <20090828012502.15484x8musndy5mo@webmail.seas.upenn.edu>
On Fri, Aug 28, 2009 at 5:25 PM, <wagnerdm at seas.upenn.edu> wrote:
> I can imagine all kinds of situations with "benevolent" attackers. ?For
> example, what about a girlfriend that pokes around your hard drive looking
> for lolcats when she's bored? ?One glance at .fetchmailrc would show it's
> not a lolcat; but that same glance could show a password that you don't
> really want her to know.
It took over 7 years before I would even tell my wife my login
password; I've since changed it and won't share it. And I trust her
implicitly with my machine -- there is nothing on there that I'm not
happy for her to see :-)
So, how does the putative bored girlfriend poke around your hard-drive
in the first place, in this scenario? If you are letting her use your
account and poke around your machine in the first place, how does her
seeing a password cause a problem?
If you don't want someone to know something, don't put them is a
situation where they might find it. You shouldn't expect a program to
employ a pointless encryption/obscuration scheme just because you
don't look after your other data. You are increasing the complexity of
the code, increasing the complexity of the testing environment,
increasing the opportunity for bugs to occur (possibly causing data
loss?), and protecting against nothing.
Now, there is an approach used by mutt that sup doesn't seem to use,
which is to prompt the user at the beginning of a session for the
various source passwords; this way they are only held in memory (and
swap files, probably). That may be a way out of the situation; as a
mail client is inherently an interactive program, there's no harm in
prompting for things missing from the config, I think.
-jim
next prev parent reply other threads:[~2009-08-28 7:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-24 20:54 Lars Kotthoff
2009-08-28 2:37 ` Jim Cheetham
[not found] ` <20090828012502.15484x8musndy5mo@webmail.seas.upenn.edu>
2009-08-28 7:07 ` Jim Cheetham [this message]
2009-08-28 7:23 ` Lars Kotthoff
2009-08-28 9:28 ` Jim Cheetham
2009-08-28 20:29 ` William Morgan
2009-08-28 22:48 ` Mike Kelly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f4cc59760908280007i3b226f0egd063126476e6ea3d@mail.gmail.com \
--to=jim@gonzul.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox