p5-IO-Compress-Zlib and p5-IO-Compress-Bzip2 modules to p5-IO-Compress.
Explicitly depend on p5-IO-Compress only if PERL_LEVEL < 500903
Bump PORTREVISION
- Add support for amd64 [1]
- Add 23 new ports to to bsd.fpc.mk
- Remove obsolete patch file patch-packages-fcl-db_Makefile
- Turn off some optional dependencies like databases/unixODBC,
graphics/svgalib, databases/oracle8-client for avoid break amd64 support
- Clean up
PR: ports/146001
Submmitted by: Christopher Key <cjk32__ at _cam.ac.uk>
Patch reviewed by: marcov_ at _pascalprogramming.com (fpc developer)[1]
RPM 4.8.1 uses a strange default for the %{_var} rpm macro...
The bug was fixed in RPM 5.0.0, variables need to be expanded.
PR: ports/149498
Submitted by: Anders F Björklund <afb@rpm5.org
Environment. Its design adheres to the Xfce philosophy, which basically
means Squeeze is designed to be both fast and easy to use.
WWW: http://squeeze.xfce.org/
PR: ports/148438
Submitted by: David Demelier <markand at malikania.fr>
Approved by: rene@ (mentor vacation)
ABI backwards compatible. It is unnecessary to have more than one same
libraries (ie: neon28 and neon29) as it creates issue in our ports tree such
as CONFLICTS and made our Makefile complicate.
- Remove www/neonpp and www/neon28.
- Add USE_GNOME=ltverhack; it corrects the shared library version by change
from libneon.so.29 to libneon.so.27. It won't get bump again with no reason
unless ABI changes.
- Bump the PORTREVISION on all ports and chase the shared library change.
- Add info in the UPDATING for how to rebuild on all ports that depend on
neon.
PR: ports/148295
Approved by: lev (maintainer timeout, no respone for months),
portmgr
Tested by: pointyhat-exp by pav
from the author follows.
Bug 1: Infinite loop in MS-ZIP decoder [1]
The MS-ZIP and Quantum decoders read bits in roughly the same way as the LZX
decoder, however they don't have "inject two fake bytes" code.
In the situation where read() provides zero bytes, e.g. at the end of file or
end of a CAB block, the LZX decoder handles this by injecting two fake bytes,
then returns an error on subsequent calls. MS-ZIP and Quantum instead return
zero bytes without error. However, all three decoders are written to presume
they will get at least one byte. So this could lead to an infinite loop in
MS-ZIP and Quantum. An infinite loop has definitely been seen in MS-ZIP -
there is a while loop in inflate() of an uncompressed block (block type 0)
which won't end until enough input is provided.
Partial solution: change "if (read < 0)" to "if (read <= 0)" in mszipd.c and
qtmd.c.
- http://libmspack.svn.sourceforge.net/viewvc/libmspack?view=revision&revision=90
However, this breaks compatibility with a number of MS-ZIP/Quantum encoded
files. A full solution would be to implement the same bit-reading system as
LZX. I've done this now, merging all the bit-reading and huffman-reading
code into two new files; readbits.h and readhuff.h
- http://libmspack.svn.sourceforge.net/viewvc/libmspack?view=revision&revision=95
There are several further changes made to integrate readbits.h and readhuff.h,
I recommend you look at the latest version in the source repository.
- http://libmspack.svn.sourceforge.net/viewvc/libmspack/libmspack/trunk/mspack/
Bug 2: Segmentation fault in "cabextract -t"
This bug may not affect you, depending on your implementation of
mspack_system->write(). It does cause a segfault in cabextract's
cabx_write() in "-t" (test archive) mode.
In the Quantum decoder, when the window wrap is reached, all currently
unwritten data is flushed to disk. Sometimes, less data is needed than
is flushed, which makes the variable out_bytes negative.
When the main decoding loop finishes, a final call to write() is made if
out_bytes is not zero. In that situation, it calls mspack_system->write() with
a negative byte count, e.g. -129 bytes. You should reject this. In
cabextract's "-t" mode, this is not caught, but instead converted to an
unsigned integer and passed to md5_process_bytes(), which tries to
read e.g. 4294967167 bytes, causing it to read beyond the end of
valid process space and thus segfault.
Solution:
- Break out to the end of the decoding loop immediately if the flush would be more than needed.
http://libmspack.svn.sourceforge.net/viewvc/libmspack/libmspack/trunk/mspack/qtmd.c?r1=114&r2=113
- Add checking of the "bytes" argument in mspack_system read() / write() implementations, just to be sure.
http://libmspack.svn.sourceforge.net/viewvc/libmspack?view=revision&revision=118
Security: SA40719 [1]
perl script.
Benefits:
- perl is no longer required as a dependency
- other contents than data.tar.gz (data.tar, data.tar.bz2, data.tar.lzma,
data.tar.xz) is now properly dealt with
- deb package isn't sucked into memory anymore
Submitted by: Alex Kozlov <spam@rm-rf.kiev.ua>
