CVE-2007-0855: Stack-based buffer overflow allows user-assisted remote attackers
to execute arbitrary code via a crafted, password-protected archive.
"go, go, go, get it in" naddy@, ok MAINTAINER
initial port, most things appear to work after fixes to handle new gd,
to get plugins to work, and to fix xlib output).
Set up as a MULTI_PACKAGES so that we can sort further components into
distinct parts later.
the new release fixes the incorrect manual page regarding rebuilding
sendmail with milter support; we have milter support by default
for years now; noticed by otto@, update provided by dhartmei@
without the need to have the packages around.
It's really easy now to check if a new package conflicts with other stuff
in the ports-tree:
$ find-all-conflicts -p /usr/ports newpkg.tgz
help & ok espie@
- fix the build on the arm architecture by moving the cpu_get_real_ticks()
function for non-optimized to the correct place
- add correct REGRESS_TARGET even if the regressions tests are utterly broken
- bump PKGNAME
SUPDISTFILES, so we get them as well.
This misbehavior noticed by Mikolaj Kucharski.
(the intention is obviously to regrab everything to verify whether
anything changed, and that includes SUPDISTFILES)
highlights are:
- bug 5318: fix for CVE-2007-0451: possible DoS due to incredibly
long URIs found in the message content.
- bug 5240: disable perl module usage in update channels unless
--allowplugins is specified
- bug 5288: files with names starting/ending in whitespace weren't usable
- bug 5056: remove Text::Wrap related code due to upstream issues
- bug 5145: update spamassassin and sa-learn to better deal with STDIN
- bug 5140 and 5179: improvements and bug fixes related to DomainKeys
and DKIM support
- several updates for Received header parsing
- several documentation updates and random taint-variable related issues
A more detailed change log can be read here:
http://svn.apache.org/repos/asf/spamassassin/branches/3.1/Changes
ok nikolay
the doco claims this is safe cos the directory has extremely restricted
permissions, but noone i know agrees with this or feels safe. this change
installs a config under /etc/subversion/config that disables this
behaviour.
discussed with pval@ ckuethe@ ok robert@ sturm@ ajacoutot@
