https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6200

--- Comment #10 from Mark Martinec <[email protected]> 2009-11-11 09:42:19 
UTC ---
Created an attachment (id=4570)
 --> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4570)
A patch to Razor agents, mentioned in Comment 4

For anyone wanting to loose a dependency on Digest::SHA1 in Razor2,
attached is a patch to razor-agents, and below is my mail that I sent to
Richard Soderberg on 2009-10-26 (who seemed to be a current maintainer,
but apparently is not, as I got no response).



Richard,

I wonder, are you still the one maintaining razor-agents?

Considering the:

  https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6200

it seems Razor2 is about the only remaining module used by SpamAssassin 3.3
still depending on a module Digest::SHA1. The rest can live with Digest::SHA,
which is compatible with Digest::SHA1, but provides additional functionality
(e.g. needed by DKIM signature validation/generation).  With perl 5.10.0
the Digest::SHA became a perl base module (while Digest::SHA1 is not a base
module, it needs to be installed separately).

I'm attaching a patch against razor-agents-2.84, which lets it use either
the Digest::SHA or the Digest::SHA1, whichever happens to be available.
I wonder if this can be incorporated into the next release.


On a related note, examining the use of SHA1 one thing pops out and
appears to me like a bug. The code in Signature::Whiplash::whiplash :

        my $sha1 = Digest::SHA1->new();

        $sha1->add($host);
        $sig = substr $sha1->hexdigest, 0, 12;

        $sha1->add($corrected_length);
        $sig .= substr $sha1->hexdigest, 0, 4;

is equivalent to my:

         $sig = substr sha1_hex($host), 0, 12;
         $sig .= substr sha1_hex($corrected_length), 0, 4;


I wonder if this was really what was meant. Seems like the
intention was to do a:

        my $sha1 = Digest::SHA1->new();

        $sha1->add($host);
        $sig = substr $sha1->clone->hexdigest, 0, 12;

        $sha1->add($corrected_length);
        $sig .= substr $sha1->hexdigest, 0, 4;

(note the use of ->clone), which would be equivalent to:

         $sig = substr sha1_hex($host), 0, 12;
         $sig .= substr sha1_hex($host, $corrected_length), 0, 4;

It seems to me that whoever did the coding forgot that the hexdigest
method (and other related methods) destroy the digests state.

If this indeed a bug, fixing it will probably cause incompatibility
in queries between fixed and unfixed clients.

Regards
   Mark

-- 
Configure bugmail: 
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to