Perl ./Configure can leak information from chroot environment

[martyman99999@…]

I started to run ./Configure during the chroot build of Perl to experiment. One of the very first steps displayed the uname -r of the host system, so this represents an opportunity for pollution of the LFS system. I did not experiment further to see if there were other information leaks.

At the very least I recommend some research and a note in the book to be cautious. It might be best to recommend reinstalling Perl after booting into the LFS, if one wants to ./Configure.

• Marty Jack

[archaic@…]

uname -r is most likely only used as a stamp like date and time are and only pollute in the most trivial of cosmetic aspects. At this point, your concerns are just that; concerns. If you do find a bug that needs fixed, please re-open this ticket at that time.

[dbn.lists@…]

According to my grepping of the perl installed files, the hostname is added into /usr/lib/perl5/5.8.8/i686-linux/Config_heavy.pl and /usr/lib/perl5/5.8.8/i686-linux/CORE/config.h

Here's the output:

$ for F in $(paco -fzx perl); do
grep -H 'anduin' $F 2>/dev/null
done
/usr/lib/perl5/5.8.8/i686-linux/Config_heavy.pl:## Target system     : linux anduin 2.6.10-1 #1 tue jan 18 06:22:56 cst 2005 i686 athlon-4 i386 gnulinux
/usr/lib/perl5/5.8.8/i686-linux/Config_heavy.pl:cf_email='root@anduin.nonet'
/usr/lib/perl5/5.8.8/i686-linux/Config_heavy.pl:myhostname='anduin'
/usr/lib/perl5/5.8.8/i686-linux/Config_heavy.pl:myuname='linux anduin 2.6.10-1 #1 tue jan 18 06:22:56 cst 2005 i686 athlon-4 i386 gnulinux '
/usr/lib/perl5/5.8.8/i686-linux/Config_heavy.pl:perladmin='root@anduin.nonet'
/usr/lib/perl5/5.8.8/i686-linux/CORE/config.h: * Target system     : linux anduin 2.6.10-1 #1 tue jan 18 06:22:56 cst 2005 i686 athlon-4 i386 gnulinux

The config.h inclusion is in a comment, so it has no effect. Config_heavy.pl is a bit more troublesome, but as Archaic says, it's only cosmetic. A note could be added that Config_heavy.pl contains host information and can be updated with information for the final system.

[dbn.lists@…]

Here's where uname -r information ends up. This looks like more of an issue (Errno.pm), but I don't know if there's much we can do about it. It certainly has been working this way for a long time. (Apologies for excessive WikiFormatting)

$ for F in $(paco -fzx perl); do
grep -H "$(uname -r)" $F 2>/dev/null
done
/usr/lib/perl5/5.8.8/i686-linux/Config.pm:    osvers => '2.6.10-1',
/usr/lib/perl5/5.8.8/i686-linux/Config_heavy.pl:## Target system     : linux anduin 2.6.10-1 #1 tue jan 18 06:22:56 cst 2005 i686 athlon-4 i386 gnulinux
/usr/lib/perl5/5.8.8/i686-linux/Config_heavy.pl:myuname='linux anduin 2.6.10-1 #1 tue jan 18 06:22:56 cst 2005 i686 athlon-4 i386 gnulinux '
/usr/lib/perl5/5.8.8/i686-linux/Config_heavy.pl:osvers='2.6.10-1'
/usr/lib/perl5/5.8.8/i686-linux/CORE/config.h: * Target system     : linux anduin 2.6.10-1 #1 tue jan 18 06:22:56 cst 2005 i686 athlon-4 i386 gnulinux
/usr/lib/perl5/5.8.8/i686-linux/CORE/config.h:#define OSVERS "2.6.10-1"        /**/
/usr/lib/perl5/5.8.8/i686-linux/Errno.pm:"i686-linux-2.6.10-1" or
/usr/lib/perl5/5.8.8/i686-linux/Errno.pm:       die "Errno architecture (i686-linux-2.6.10-1) does not match executable architecture ($Config{'archname'}-$Config{'osvers'})";