path defaults for gpg.conf

Olav Seyfarth olav at
Fri Feb 1 23:38:45 CET 2013

Hash: RIPEMD160

Hi John,

> current directory issue, I am curious about why including it would result 
> in a less secure situation.

I did not exactly say that it does. I said that I prefer it that way since it
uses well-defined places that I may look after. Adding a fifth is not necessary
for me. And it was an author's decision. Maybe one of them wants to comment on
'why' - or even take on the RFE and implement another check in the folder the
executable was called from.

> Perhaps an example of how so would be helpful in this regard, at least for
>  me or someone else who is not a programmer to understand your point.

I was thinking of DLL preloading attacks
( when I wrote this. But I agree that
it doesn't match exactly.

> As I recall from reading the instructions for the many programs I use, I 
> have always read that a program's executable looks into its own directory 
> as part of its routine in searching for files it needs

Yes, I know. And in times where your Word files were saved next to WORD.COM and
some .INI, this may have been a good thing. In multi user systems, it is not.
User settings should not be looked for in the program directory but in folders
meant to be used by the user (only). This does not tell that it may not be a
good idea to be able to define system defaults. But looking in the /current/
(=any e.g. a system-writable thumb drive) program directory for system defaults
first and preloading them and then overriding them by some user settings is not
what *I* want since I will not define (and thus override) /all/ settings in my
user config just to make sure that I really get what I want independent of what
a malware may have dropped somewhere. E.g. im my gpg.conf there is no path to
my keyring.

You may say "we only use that config in /current/ dir if no other was found.
But still even then I would not want it since I would want the keys in %appdata%
to be used if I don't set it otherwise.

We must dive into which process would be able to modify which env variables and
which users may write to which places

Originally I wrote some explanation, then rethought and changed it to what I
wrote "for security products I prefer NOT to include the 'current dir' default."
since I did /not/ want to open a discussion about security implications since
I did noticed that the concerns I had would not hold or at least would need to
employ rare special cases.

> your statement did come as a bit of a surprise because I was under the 
> impression that this was just a result of how the code of an executable 
> must function, at least in Windows OS. Apparently, that is not so?

I studied Computer Science but would no call myself a programmer. Usually you
have some built-in defaults. If you want to honor any files that contain system
or user settings, you must check all places that you want to look for such
settings. This may include the folder the program binary resides in. But there
is no automatism, it does not do it just because all programs always do. You
have to program it to check. Or, as GnuPG does, check places which tell you
where to look for settings files.

I hope that clearified it a bit. Sorry for the noise.

P.S.: offline now
- -- 
The Enigmail Project - OpenPGP Email Security For Mozilla Applications
Version: GnuPG v2.0.19 (MingW32)
Comment: Dies ist eine elektronische Signatur -


More information about the Gnupg-users mailing list