[patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath

[Israel G. Lugo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
David Shaw wrote:
> Unless Windows can change environment variables out from under a
> running process, I don't see how any of these change in between
> passes.
Not directly, no - process address space manipulation could happen,
but of course then the tmp path would be the least of our worries. All
the better then, this makes my solution even simpler to implement. I'm
sending attached a revised patch, made against the current CVS version
of exec.c. It gets rid of the unnecessary limit and is, I believe you
can agree, quite lightweight. ChangeLog entry:

2006-05-25  Israel G. Lugo  <ilugo at bridonsecurity.com>

    * exec.c (make_tempdir) [_WIN32]: Modified to properly handle
    arbitrarily long temporary directory paths.


I trust this new patch does not seem "overkill" to you?


> Equally as much as the old and tired "Free Software people hate
> Windows" thing?
I was not implying that as an accusation... I myself dislike Windows
quite a lot. If I did assume that you did not like the OS, it was from
the impression of dismissivenesses I was left with by your reaction -
as noted in my former email. I believe that was already addressed,
though? As I said before, I came here with nothing but a constructive
purpose in mind; you've already made it clear that you have the same
intentions as well so, at least from my part, all is good.


> This is the problem.  I don't agree with your solution.  I don't think
> you need multiple passes.
Very well, I can agree to that, and it does make good sense as if we
start worrying about external manipulation then we have much worse
things to worry about than that. Please see the revised patch I am
offering in this email.


> I do question just how useful it is to allow arbitrarily large temporary
> directories when every other piece of directory fetching code for Win32
> has a MAX_PATH limit anyway, but don't really care much either way about
> this.
Assuming you will agree that the patch I'm proposing this time solves
the issue and is also very simple, I think there would be no reason
*not* to allow arbitrarily large temporary directories?

Regarding other MAX_PATH limitations built in different parts of the
code... well, they can be dealt with as well, in their own time.
Perhaps some of them could be changed to be more flexible as well.
Someone might happen to come across one such piece of code, and offer
an acceptable solution. In any case it's an independent matter; in any
software program, there will always be areas that could be improved
somehow, bugs to be discovered, features to be added. Assuming people
are motivated enough to want to contribute, the program will keep
evolving.

Regards,
Israel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFEdi5Vgn9msFnMGkcRAi8zAJ96eBU+HgqCk4BgScnoC8q3JFgidgCfawjB
fVjjCdeWE7jf3ylBX9Yl8zk=
=FuWf
-----END PGP SIGNATURE-----

-------------- next part --------------
Only in gnupg-tmplen/g10: .exec.c.swp
diff -durp gnupg/g10/exec.c gnupg-tmplen/g10/exec.c
--- gnupg/g10/exec.c	Thu May 25 22:28:08 2006
+++ gnupg-tmplen/g10/exec.c	Thu May 25 22:47:22 2006
@@ -129,16 +129,19 @@ static int make_tempdir(struct exec_info
   if(tmp==NULL)
     {
 #if defined (_WIN32)
-      int err;
+      /* Poll temp path's length */
+      int tmp_siz=GetTempPath(0, NULL);
+      int len=0;
 
-      tmp=xmalloc(MAX_PATH+1);
-      err=GetTempPath(MAX_PATH+1,tmp);
-      if(err==0 || err>MAX_PATH+1)
-	strcpy(tmp,"c:\\windows\\temp");
+      if (tmp_siz!=0)
+      {
+	tmp=xmalloc(tmp_siz);
+	len=GetTempPath(tmp_siz,tmp);
+      }
+      if(len==0)
+	tmp=xstrdup("c:\\windows\\temp");
       else
 	{
-	  int len=strlen(tmp);
-
 	  /* GetTempPath may return with \ on the end */
 	  while(len>0 && tmp[len-1]=='\\')
 	    {