[Bug 7155] New: Oddness with -R and --full

[bu...@bugzilla.spamassassin.org]

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7155

            Bug ID: 7155
           Summary: Oddness with -R and --full
           Product: Spamassassin
           Version: SVN Trunk (Latest Devel Version)
          Hardware: PC
                OS: Windows 7
            Status: NEW
          Severity: normal
          Priority: P2
         Component: spamc/spamd
          Assignee: dev@spamassassin.apache.org
          Reporter: kmcgrail@pccc.com

On 3/5/2015 1:01 PM, Reindl Harald wrote:
> according to spamc --help "-R" and "--full" is the same
> in fact in case of a ham-message only -R works as expected
> --full behaves identical zu --full-spam
>
> -r, --full-spam     Print full report for messages identified as spam.
> -R, --full          Print full report for all messages.
> ____________________________
>
> BROKEN: /usr/bin/spamc --full --port=10029 < sample.eml
> OK:     /usr/bin/spamc R --port=10029 < sample.eml
>

The spamc code seems to concur -R and --full are the same option:

       { "full", no_argument, 0, 'R' }

Looking in the code, nothing jumps out as a logic issue but testing on my
command line with ham shows problems

spamc -R -d spamd.pccc.com < /tmp/1
<starts with the score/threshold and then the report>

spamc --full -d spamd.pccc.com < /tmp/1
<prints nothing.  I would expect it to do the same as -R>

Testing on my command line spam:

spamc -r -d spamd.pccc.com < /tmp/2
spamc --full -d spamd.pccc.com < /tmp/2
<Identical output of just the report>

The code for R sets flags |= SPAMC_REPORT;



Also, just duplicate the docs as referring to -r for the output format was
easily missed:

       -r, --full-spam
           Just output the SpamAssassin report text to stdout, if the message
is spam.  If the message is ham (non-spam), nothing will be printed.  The first
line of the output is the message score and the
           threshold, in this format:

                   score/threshold

       -R, --full
           Just output the SpamAssassin report text to stdout, for all
messages.  See -r for details of the output format used.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7155] Oddness with -R and --full

[bu...@bugzilla.spamassassin.org]

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7155

Karsten Bräckelmann <gu...@rudersport.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #2 from Karsten Bräckelmann <gu...@rudersport.de> ---
Assuming lazy consensus, committing to stable 3.4 branch:

Sending        spamc/getopt.c
Committed revision 1803384.

Closing RESOLVED FIXED.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7155] Oddness with -R and --full

[bu...@bugzilla.spamassassin.org]

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7155

--- Comment #1 from Karsten Bräckelmann <gu...@rudersport.de> ---
The problem is in getopt.c spamc_getopt_long(). In its for(i) loop, it compares
the given long option to the array of valid options (as defined in the spamc.c
longoptions[] array).

It does so using memcmp() limited to the length of the given option (without
the option's trailing "=value", if given). The option is compared against the
array of valid longoptions in the order specified, so its order actually
matters for options that are prefix substrings of other options.

That means, a given "foo" option compares successfully to either "foo" or
"foo-bar", whichever is defined first, since we're only comparing the first 3
bytes in this example. (This does not apply to options merely sharing a common
prefix like connect-timeout and connect-retries.)

As for this bug, the option "full" matches the first 4 chars of "full-spam",
which is defined before "full" in the longoptions[] array, thus falsely being
handled as the "full-spam" or -r option.


A quick-n-dirty fix is to reverse the order of the "full" and "full-spam"
entries on the spamc.c longoptions[] array:

    { "full", no_argument, 0, 'R' },       /* substring prefix first */
    { "full-spam", no_argument, 0, 'r' },

Minimally intrusive, but only working around this one issue, not fixing the
underlying problem.

Using e.g. strcmp() instead of memcmp() unfortunately is not a simple drop-in
replacement, because the user given option string includes a "=value" suffix if
given. Hence the need for a length limited match in the first place.


The committed fix requires the length of the given option name to be equal to
the length of the compared-to option name in addition to the existing memcmp().

Sending        spamc/getopt.c
Committed revision 1802715.

This should be a minimally intrusive fix. Not extensively tested, though, so
please review -- especially if your C is better than mine. ;)

Patch applies cleanly to 3.4 branch. Should be safe for both branches.

-- 
You are receiving this mail because:
You are the assignee for the bug.