Re: [PATCH] Remove absolute paths from gpg.rc
On Wed, Mar 21, 2007 at 03:51:02PM +0100, Oswald Buddenhagen wrote:
> On Wed, Mar 21, 2007 at 12:27:10AM +0000, Dave wrote:
> > On Tue, Mar 20, 2007 at 12:14:17PM +0100, Oswald Buddenhagen wrote:
> > > otoh, most users *are* idiots (yes, even the unix users -
> >
> > Idiots have the right (a) to exist, and (b) not to have decisions that
> > are rightfully theirs stolen by a zealous system, not even in the name
> > of security. People don't lose their rights by being idiots.
> >
> i believe that you believe this - it's so truly american.
I don't necessarily disagree with that statement.
> i even know
> for a fact, that many of your kind agree with using heavy weaponry to
> "convince" others of these ideals.
Many do, and many don't. At the end of the day, indirect Democracy has certain
problems. On the other hand, a country trying to defend itself against
terrorists in a world that doesn't care is in a rather unenviable position.
> the problem with this attitude is
> that *a lot* of people have to suffer from those idiots.
A lot of people also have to suffer from the terrorists that these idiots are
fighting. At any rate, we're getting a tad off-topic, no?
> blind trust in
> unlimited freedom based on the assumption that the bad things will go
> away by themselves eventually
That's basically one of the main attitudes that lead to most of the world not
really caring much about countries sponsoring terrorists. I'd rather not
discuss these topics on-list unless you believe that the consequences of the
discussion are relevant.
> won't make perversions like creationism,
> scientology or hate tv vanish, quite on the contrary.
I definitely don't want to get into _these_ topics, since they open many new
cans of worms in new domains.
> and they *do* hurt
> - some short-term, some long-term, some physically and some
> economically. and no matter how you twist it, it limits the freedom of
> those affected.
I'd say that if your sysadmin is supporting crackers, you're in the unenviable
position of being an agent of a terrorist. The only difference is that unlike
an employee, it's kinda hard for you to quit your "job" when you're simply a
citizen/resident of a country whose government supports terrorists. Either way,
it's important to point out that your freedom has already been affected by your
own government if you're an Iraqui, Iranian, Syrian, Lebanese, etc., resident.
If a foreign country decides to quit doing business with your country, you're in
a position analogous to a physical user of a system that other systems around
the world are blocking because your sysadmin is rogue. Again, it's not so easy
for you to jump ship in the real world, due to the finiteness of land on our
planet that hasn't already been claimed by some other country. In the world of
computers, new "land" is being built every day. Many people own a whole network
of "land." If you don't like your sysadmin, you might have to settle for a less
powerful system (since you no longer have the resources of your old sysadmin
available), but at least you can have _a_ system. In the real world, finding a
square inch of unowned land (not counting Antarctica, which under international
treaty can't be owned) is a challenge. You're also on your own as far as
protecting your new country, even if you discover some new land (or take a page
from our book and nuke the natives). The local police does a fairly good job of
protecting your computer in any first-world country, in the real world.
> how does *that* fit with your ideals?
We're in the wrong place to debate ideals in other contexts. If you want to
discuss ideals in the hopes of being able to apply them to Mutt, no problem, but
I don't think the list would be happy if we went off on endless tangents.
> the bottom line is
> that sometimes you have to limit some freedoms to preserve other, more
> important ones. anything else is simply irresponsible.
I'd like you to elaborate on exactly which freedoms you propose to limit in
order to preserve which other, more important ones. In my book, the most
important freedoms are those of the system owner, if we start out from a
worldview that recognizes the concept of private property. (If we don't, we can
get into a lot of hot water in the real world.)
> > > and even the most security conscious ones make mistakes.
> >
> > It's up to an individual user to decide not to trust himself, if he
> > knows he's in the habit of making mistakes.
> >
> this is silly. everbody makes mistakes.
That doesn't matter. The user is in charge of deciding how many (if any) limits
he wants to place on his own decisionmaking authority. The question is outside
of the domain of the programmer.
> confirmation dialogs are a
> typical example of a measure to prevent small mistakes from having big
> effects.
That's why mv(1), for example, offers the -i option. If you don't
trust yourself to move carefully, you can instruct the move command to
force you to confirm actions that it interprets as possible mistakes.
However, the -i option isn't on by default, since it'd violate the UNIX
philosophy of doing your job right (without asking ten million unnecessary
questions first). (It'd also violate the principle of least surprise,
incidentally, since an mv(1) user expects "mv a b" to result in "the
object formerly known as a" now being b. It's not up to the user to
guess all the artificial reasons that mv(1) might fail; guessing all
the real reasons is hard enough. Adding fake reasons for failure (or
worse, attempting to prompt a user who may not even understand the prompt
(say, another program ... yes, I know you can test if it's a tty, and
make assumptions based on that test, and create even more complexity,
but you'll only be creating more surprises by doing so ... remember,
following the KISS principle is by definition the simplest method of
following the principle of least surprise, since b is merely a natural
consequence of a) surprises.)
> but like any other safety measure, they have to be placed
> wisely.
You just hit the nail on the head: the user himself is the only one in a
position to reverse engineer his own psychology in order to place prompts
wisely. A programmer should write programs that simply do their job without
asking qusetions, and leave Psychology assignments to Psychology experts. A
programmer shouldn't have to be a security expert and a psychology expert, in
addition to being an expert at whatever task he's actually hoping for his
program to perform after all the prompts. Programs should perform tasks, not
prescribe user interfaces.
> same goes for security, only that it is way harder.
Sticking to the KISS principle is an easy way of avoiding the whole problem.
Let the user decide for himself what type of UI he wants.
> > > i can accept absolute paths determined at configure time in the
> > > default config,
> >
> > I can't. The configure script has no authority to steal decisions
> > from the user. The user owns his copy of Mutt, not the other way
> > around.
> >
> dude, it is a config file that can be overridden, so such dogmatic
> argumenation is completely pointless.
As Robin Hood would put it, it's the principle of the matter, if nothing else.
(We don't know if it's anything else, because once you start violating user
rights, all bets are off. It's stupid to ask people to prove that there's
something else before accepting that it's wrong, since by violating user rights,
you're setting yourself and your users up for trouble. It might not bite today,
but it'll bite eventually.) It doesn't matter whether a certain behavior is the
default because a config file installed automatically makes it so, or because a
command-line switch is required to change the setting, or even because the
program triggers that behavior based on some random number that it generates
every morning. At the end of the day, the program, as installed normally,
tramples its owner's rights.
> an actual reason would be the principle of least surprise: if i put a
> new gpg in front of $PATH, i expect it to be used by every program
> without checking each program's configuration first. one could call this
> a part of the unix principle, too. :)
You aren't disagreeing with me here about the solution (or even about a
problem), only about the root of the problem. The root of the problem to you
is a purely practical matter, AFAICT. To me, the root of the problem is simply
that the programmer has no right to steal the user's free choice. The practical
problems are all nothing but the inevitable results of violating user rights.
- Dave