mktemp = coreutils conflict

Robert Connolly robert at linuxfromscratch.org
Wed May 21 14:32:45 PDT 2008


Mktemp was added to Coreutils-6.10, and both LFS and HLFS removed the Mktemp 
package with the Coreutils upgrade. The main reason the Mktemp package 
existed was because no one else maintained one, but now Coreutils does.

A quick look at the differences tells me that the Coreutils version was 
written from scratch, and not based on the Mktemp package. The Coreutils 
version is a bit more secure... the Coreutils version uses /dev/urandom by 
default for mktemp, shuf, shred, sort (from lib/randread.c), and it's 
non-optional. Coreutils also uses secure getenv so TMPDIR isn't passed up 
from su or sudo. The --help from Coreutils' version is also more usefull. 
There may be more differences, but this should be enough to say the GNU 
version is better for the majority of us.

robert

On Wednesday May 21 2008 10:08:42 am Kevin Day wrote:
> I just noticed that coreutils is installing its own version of mktemp
> over the one installed by the mktemp project
>
> I am not certain whether this is better, worse, or the same because I
> have no idea how their implementation differs, if any.
>
> I looked around on the LFS/BLFS lists to see if they mention mktemp as
> a program of coreutils and found no reference.
> This was probably not caught because they installed mktemp after
> coreutils, but for some reason I ended up installing mktemp-1.5 before
> coreutils and noticed this issue.
>
> I expect one should use the configure option:
> --enable-no-install-program=mktemp to default to the mktemp project.
>
> However, this begs the question if the coreutils is any more or any
> less secure than the mktemp project's mktemp program.
>
> --
> Kevin Day


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20080521/5929925a/attachment.sig>


More information about the hlfs-dev mailing list