Bug#598424: Patch for CVE-2010-3394

2010-12-08 Thread Jakub Wilk 

* Etienne Millon etienne.mil...@gmail.com, 2010-11-25, 20:35:

$ LD_LIBRARY_PATH=
$ LD_LIBRARY_PATH=/foobar${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH}
$ echo $LD_LIBRARY_PATH /foobar:

LD_LIBRARY_PATH can be unset naturally, ie without the user knowing.
It is actually the default. However, if it evaluates to the empty
string it comes from the environment, ie the user set it like that. We
can't blame texmacs for that, it is the user's fault.

So, I think we don't have to handle this case.


We do. ld.so treats empty LD_LIBRARY_PATH and unset LD_LIBRARY_PATH 
equally (i.e. it doesn't add anything to search path) and so should do 
texmacs.


--
Jakub Wilk


signature.asc
Description: Digital signature

Bug#598424: Patch for CVE-2010-3394

2010-11-25 Thread Moritz Muehlenhoff 
On Sun, Nov 14, 2010 at 02:11:47PM +0100, Jakub Wilk wrote:
 found 598424 1:1.0.7.4-3
 thanks

 * Etienne Millon etienne.mil...@gmail.com, 2010-10-20, 09:44:
 It does, indeed. On line 30 of /usr/bin/texmacs, the inclusion of
 $TEXMACS_BIN_PATH/lib is properly done, because :

  - if LD_LIBRARY_PATH is empty before, the ${LD_LIBRARY_PATH+...}
  constructs evaluates to the empty string (and no colon is added)

 No. It evalutes to empty string only if LD_LIBRARY_PATH is unset, not  
 when it's empty:

 $ LD_LIBRARY_PATH=
 $ LD_LIBRARY_PATH=/foobar${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH}
 $ echo $LD_LIBRARY_PATH /foobar:

What's the status?

Cheers,
Moritz



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#598424: Patch for CVE-2010-3394

2010-11-25 Thread Etienne Millon 
On Thu, Nov 25, 2010 at 05:58:18PM +0100, Moritz Muehlenhoff wrote:
 On Sun, Nov 14, 2010 at 02:11:47PM +0100, Jakub Wilk wrote:
  found 598424 1:1.0.7.4-3
  thanks
 
  * Etienne Millon etienne.mil...@gmail.com, 2010-10-20, 09:44:
  It does, indeed. On line 30 of /usr/bin/texmacs, the inclusion of
  $TEXMACS_BIN_PATH/lib is properly done, because :
 
   - if LD_LIBRARY_PATH is empty before, the ${LD_LIBRARY_PATH+...}
 constructs evaluates to the empty string (and no colon is added)
 
  No. It evalutes to empty string only if LD_LIBRARY_PATH is unset, not  
  when it's empty:
 
  $ LD_LIBRARY_PATH=
  $ LD_LIBRARY_PATH=/foobar${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH}
  $ echo $LD_LIBRARY_PATH /foobar:
 
 What's the status?

LD_LIBRARY_PATH can be unset naturally, ie without the user knowing.
It is actually the default. However, if it evaluates to the empty
string it comes from the environment, ie the user set it like that. We
can't blame texmacs for that, it is the user's fault.

So, I think we don't have to handle this case.

-- 
Etienne Millon


signature.asc
Description: Digital signature

Bug#598424: Patch for CVE-2010-3394

2010-11-14 Thread Jakub Wilk 

found 598424 1:1.0.7.4-3
thanks

* Etienne Millon etienne.mil...@gmail.com, 2010-10-20, 09:44:

It does, indeed. On line 30 of /usr/bin/texmacs, the inclusion of
$TEXMACS_BIN_PATH/lib is properly done, because :

 - if LD_LIBRARY_PATH is empty before, the ${LD_LIBRARY_PATH+...}
constructs evaluates to the empty string (and no colon is added)


No. It evalutes to empty string only if LD_LIBRARY_PATH is unset, not 
when it's empty:


$ LD_LIBRARY_PATH=
$ LD_LIBRARY_PATH=/foobar${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH}
$ echo $LD_LIBRARY_PATH 
/foobar:


--
Jakub Wilk


signature.asc
Description: Digital signature

Bug#598424: Patch for CVE-2010-3394

2010-10-20 Thread Etienne Millon 
Hello,

 Does the following sentence relate to my question?
 
  I believe that the second warning can be
  safely ignored.

It does, indeed. On line 30 of /usr/bin/texmacs, the inclusion of
$TEXMACS_BIN_PATH/lib is properly done, because :
  
  - if LD_LIBRARY_PATH is empty before, the ${LD_LIBRARY_PATH+...}
constructs evaluates to the empty string (and no colon is added)
  - if LD_LIBRARY_PATH was non-empty, the construct evaluates to
:$LD_LIBRARY_PATH and no single colon is present

So, this part is safe.

However, in plugins/mupad/bin/tm_mupad_help, its use is not escaped
and will add a leading colon, and my previous patch addresses that.

Hope that clarifies,

-- 
Etienne Millon


signature.asc
Description: Digital signature

Bug#598424: Patch for CVE-2010-3394

2010-10-20 Thread Atsuhito Kohda 
Hi all, sorry for delay.

On Fri, 15 Oct 2010 09:51:07 +0200, Etienne Millon wrote:

 Here is a patch that fixes this issue. I believe that the second warning can 
 be
 safely ignored.

I'm preparing a fixed package but I've a question which
I' like to solve before upload it.

A patch of Etienne doesn't modify /usr/bin/texmacs at all 
but, apparently, an original bug report of Raphael
mentioned it.

On Tue, 28 Sep 2010 21:07:36 +, Raphael Geissert wrote:

 /usr/bin/texmacs line 30:
 LD_LIBRARY_PATH=$TEXMACS_BIN_PATH/lib${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH}

Is it intentional, or is the patch enough to fix 
the security bug?

Does the following sentence relate to my question?

 I believe that the second warning can be
 safely ignored.

Thanks for your contributions and I appreciate any
comment on my question.

Regards,2010-10-20(Wed)

-- 
 Debian Developer - much more I18N of Debian
 Atsuhito Kohda kohda AT debian.org
 Department of Math., Univ. of Tokushima



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#598424: Patch for CVE-2010-3394

2010-10-20 Thread Atsuhito Kohda 
Hi Etienne,

On Wed, 20 Oct 2010 09:44:56 +0200, Etienne Millon wrote:

 Does the following sentence relate to my question?
 
  I believe that the second warning can be
  safely ignored.
 
 It does, indeed. On line 30 of /usr/bin/texmacs, the inclusion of
 $TEXMACS_BIN_PATH/lib is properly done, because :
   
   - if LD_LIBRARY_PATH is empty before, the ${LD_LIBRARY_PATH+...}
   constructs evaluates to the empty string (and no colon is added)
   - if LD_LIBRARY_PATH was non-empty, the construct evaluates to
   :$LD_LIBRARY_PATH and no single colon is present
 
 So, this part is safe.
 
 However, in plugins/mupad/bin/tm_mupad_help, its use is not escaped
 and will add a leading colon, and my previous patch addresses that.
 
 Hope that clarifies,

Thanks for your clarification.  I'll upload a fixed package
as soon as possible.  Thanks again.

Regards, 2010-10-20(Wed)

-- 
 Debian Developer - much more I18N of Debian
 Atsuhito Kohda kohda AT debian.org
 Department of Math., Univ. of Tokushima



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#598424: Patch for CVE-2010-3394

2010-10-15 Thread Etienne Millon 
tags 598424 patch
thanks

Dear maintainer,

Here is a patch that fixes this issue. I believe that the second warning can be
safely ignored.

Regards,

-- 
Etienne Millon
diff -u texmacs-1.0.7.4/debian/changelog texmacs-1.0.7.4/debian/changelog
--- texmacs-1.0.7.4/debian/changelog
+++ texmacs-1.0.7.4/debian/changelog
@@ -1,3 +1,10 @@
+texmacs (1:1.0.7.4-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix security issue CVE-2010-3394 (Closes: #598424)
+
+ -- Etienne Millon etienne.mil...@gmail.com  Fri, 15 Oct 2010 09:35:34 +0200
+
 texmacs (1:1.0.7.4-2) unstable; urgency=low
 
   * Re-upload, former upload failed with wrong diff.gz perhaps.
only in patch2:
unchanged:
--- texmacs-1.0.7.4.orig/plugins/mupad/bin/tm_mupad_help
+++ texmacs-1.0.7.4/plugins/mupad/bin/tm_mupad_help
@@ -26,7 +26,7 @@
 
 SYSINFO=`$MuPAD_ROOT_PATH/share/bin/sysinfo`
 export SYSINFO
-LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${MuPAD_ROOT_PATH}/${SYSINFO}/lib:/usr/local/X11R6/motif-2.0/lib:/usr/local/X11R6/lib:$MuPAD_ROOT_PATH/$SYSINFO/bin
+LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}${MuPAD_ROOT_PATH}/${SYSINFO}/lib:/usr/local/X11R6/motif-2.0/lib:/usr/local/X11R6/lib:$MuPAD_ROOT_PATH/$SYSINFO/bin
 export LD_LIBRARY_PATH
 
 XKEYSYMDB=$MuPAD_ROOT_PATH/share/unix/XKeysymDB


signature.asc
Description: Digital signature