Red Hat Bugzilla – Bug 128637
texinfo: install-info & bz2 files
Last modified: 2007-11-30 17:10:46 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4.2)
Description of problem:
I was investigating some strange actions of install-info and started a
readfile calls open_possibly_compressed_file(). That function tries
opening the file with a number of different file extentions.
Eventually, it tries fopening a bz2 file. If that is successful, it
returns the FILE pointer, not a gzfile pointer.
readfile, then passes that descriptor to gzRead. I doubt that gzRead
can make heads or tails of a bzip2 compressed file. The problem is
that the zlib patch does not handle the possibility of bzip2 files.
There are 3 options as I see it:
1) remove the zlib patch. If this is done, full pathnames should be
used for the decompressors. Other security measures should be taken as
2) Delete the fopen of the bzip2 file. In this way, only uncompressed
text or gzip'ed files will successfully open.
3) Add bz2 support. This involves using a void pointer to
open_possibly_compressed_file(), using a flag to branch to bzRead
instead of gzread, using bzReadOpen, adding -lbz2 to flags, adjusting
configure to locate it, and a new BuildRequires.
I suspect a malicious person could create bz2 files knowing that
install-info may crash on them.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Found in code inspection
Created attachment 102287 [details]
patch currently being tested
In case you are considering option #1, I have attached a patch that
uses full pathnames to the compressor/decompressors. Additionally,
gunzip can handle .Z uncompress files. So gunzip was substituted for
I am currently testing in this mode and do not see anymore problems
with install-info. I commented out the zlib patch at line 51 of the
spec file and added the attached patch.
Even if you may disagree with this approach, it is wiser to use full
paths for the info utility helpers. The man utility uses full paths,
so should info.
I think they way forward is to fix the patch. Is this actually
causing problems right now? We don't ship any .bz2 info files as far
as I can see.
It may be true that you do not ship bz2 info files, but that does not
precude others from doing it. Info files that are bzip2'd are smaller.
For example, tar.info.bz2 is 90007 while tar.info.gz is 115960. It
really does add up when you have hundreds of them.
If you do not like ripping out the zlib code, please use the fullpath
part for the info utility. I think it was the first hunk of the patch.
It might even be better to turn filesys.c into filesys.c.in and use
configure/autoconf to insert the full path like 'man' does.
I have changed the zlib patch to restore popen () use;
gzipped files are handled with zlib, bzip2ed by piping from bzip2.
Thanks for your report.