https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5846
Summary: "Changes" file in distro should include human-readable
changes list
Product: Spamassassin
Version: unspecified
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P5
Component: Building & Packaging
AssignedTo: [email protected]
ReportedBy: [EMAIL PROTECTED]
I came across this again:
http://use.perl.org/~petdance/journal/30809
it's an old moan from Andy Lester about our changes file -- "Here's how to not
do a Changes file: That tells me nothing about whether I want to upgrade my
SpamAssassin install. :-("
it occurred to me that we still substantially have this problem. I
suggest we fix it by changing our build process so that, instead of
generating "Changes" from svn log, we just cut and paste the history
of build/announcements/*.txt into a single top-level "Changes" file, e.g.
Summary of changes from 3.2.2:
------------------------------
- bug 5548: Certain mail input can take a long time to scan with 100% CPU
utilisation, due to backtracking in a rule's regexp. fix
[... other changes omitted]
Summary of changes from 3.2.1:
------------------------------
3.2.1 is a major bug-fix release, including a potential local DoS. The
major highlights are:
- bug 5480: fix for CVE-2007-2873: a local user symlink-attack DoS
vulnerability. It only affects systems where spamd is run as root, is used
with vpopmail or virtual users via the "-v"/"--vpopmail" OR
"--virtual-config-dir" switch, AND with the "-x"/"--no-user-config AND
WITHOUT the "-u"/"--username" switch AND with the "-l"/"--allow-tell" switch.
This is not default on any distro package, and is not a common configuration.
More details of the vulnerability can be read at
<http://spamassassin.apache.org/advisories/cve-2007-2873.txt>.
[... other changes omitted]
Summary of changes from 3.2.0:
------------------------------
Changes to the core code:
* new behavior for trusted_networks/internal_networks: the 127.* network is now
always considered trusted and internal, regardless of configuration.
* bug 3109: short-circuiting of 'definite ham' or 'definite spam' messages
based on individual short-circuit rules using the 'shortcircuit' setting, by
Dallas Engelken <dallase /at/ uribl.com>.
[... 3.2.0 changes omitted]
you get the idea. As each release goes out, the manual gardening required
is basically just to cut and paste in the *current* release's changes block
into the file.
The svn log is, of course, still available -- in SVN. so people who
want that can still get it.
sound good?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.