-----BEGIN PGP SIGNED MESSAGE----- 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 (http://support.microsoft.com/kb/2389418) 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. Olav P.S.: offline now - -- The Enigmail Project - OpenPGP Email Security For Mozilla Applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (MingW32) Comment: Dies ist eine elektronische Signatur - http://www.enigmail.net/ iQGcBAEBAwAGBQJRDEPuAAoJEKGX32tq4e9WnVIL/iMI/WqvJ/iO7In63fg+nMFp jagZ0G8rdA4eEtzdhJ6zYnlSxAV7umVL+DmDDMdLiGePdpHHtd04voeLmd6YMzz7 E/Tlkoje3ne0uuiwv50ZnQTO5lfeMmoaPbMkdsmsAOmjetmi5MetPCWsqu+3pj02 5c1m36XUVaATuZrWJ4NO2Thi5QrX6Dwbq7iIwLSDFaD7HfKiwOT8WG595HZvYPJn OcTD2JBjvufdJEI+/GB0AvAUznAMiQ5fsb2KdnoUpFBqTPvXSluy8Lg9FstrW0jR jJkP58qerFpQPJrmnoFg8rSuXGA/Cmr9RgGLeXQ0MB1tBFemwWCzBBsVddqY1egr jf9NHNehBm5z4aDbpDispyh6qdkQN29hBNYQujb33S1XHRxGxtGeBJK8OD0vGQJB OIUHdqYY0IqoZlKWyvNVL98J9Y/SdE/SsDF101+e8LC4PSwxihejh68tP5IQCl1R SHR9C+zO1bTeazf//gWmrC0rIniBvK18MsaZulfLVw== =ms+U -----END PGP SIGNATURE----- _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
