Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Jul 2001 11:40:01 -0700 (PDT)
From:      John Merryweather Cooper <jmcoopr@webmail.bmi.net>
To:        freebsd-ports@FreeBSD.org
Subject:   Re: ports/29112: Potential security issues in Balsa & Encompass
Message-ID:  <200107241840.f6OIe1Y15114@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/29112; it has been noted by GNATS.

From: John Merryweather Cooper <jmcoopr@webmail.bmi.net>
To: freebsd-gnats-submit@FreeBSD.org, quik@quikbox.ca
Cc:  
Subject: Re: ports/29112: Potential security issues in Balsa & Encompass
Date: Tue, 24 Jul 2001 11:36:42 -0700

 Well, the problem is NOT in any of Balsa's source code.  I've grepped, 
 eye-balled, head-banged, etc. the entire source code and I can conclude:
 
 1) setkey(3), des_setkey(3), encrypt(3), and des_cipher(3) reside in 
 libcipher--correct me if I'm wrong, but this is a US-only library (at
 least legally).  Since S/MIME is not currently implemented (but there
 are plans to do so for Balsa), lacking these functions produces the
 warnings--but does not appear to affect function--
 
 2) mktemp() is not used anywhere in Balsa.  Balsa "rolls it's own"
 mktemp which resides in libmutt.  There maybe a performance advantage
 to using mkstemp() as a replacement (I will verify this)--
 
 3) gets() is not used anywhere in Balsa--fgets() is properly used
 instead--
 
 4) tmpnam() and tempnam() are not used anywhere in Balsa--all temp
 files appear to be generated using the libmutt "roll it's own"
 mktemp() replacment--
 
 Conclusion:  the gets(), mktemp(), tmpnam(), and tempnam() warnings
 appear to come as a result of support code from outside Balsa.  I
 haven't isolated which modules, yet . . .
 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107241840.f6OIe1Y15114>