[cvs] bogofilter/contrib bogopass,1.3,1.4

Allyn Fratkin allyn at fratkin.com
Wed Dec 4 03:24:14 CET 2002


 > My fault, please apologize. I saw that a failure to launch unbase64 went
 > away unnoticed, and moved it up front -- which was wrong...

yes, bogopass in 0.9.1 is completely broken as it essentially exactly
replicates "cat message | unbase64 | bogofilter -p" which i never wanted to
happen, as it basically destroys the input message which will proabably make
any user that actually uses bogopass VERY unhappy.

david, would it be possible to re-release 0.9.1 with bogopass silently
removed?  either that or we should quickly release a 0.9.1.1 or similar
with a working bogopass.

who thought one short perl script would cause so much trouble?

>>-#! /usr/bin/env perl
>>+#!/usr/bin/perl
> 
> This trick makes sure it works with perl anywhere on the $PATH, not just
> /usr/bin. FreeBSD 5 might fail unless we use env.

understood and very clever, however if we are being
security conscious and setting PATH explicitly later, it doesn't
make sense to me to search through an unknown PATH to find perl.
that would be a gaping secuity hole.  if we're willing to search
an unknown PATH to find perl, we might as well just search PATH to
find unbase64 and bogofilter.

> We must not close the file handle yet, unlink0 needs it below.

unlink0 worked fine even if $fh was closed.

> I've tried some tricks to figure a failure to start unbase64, but at
> least my bash will happily launch bogofilter even when it cannot start
> unbase64 -- so we need to catch the unbase64 failure explicitly.

failing to start unbase64 isn't fatal (although then bogopass would be
pointless), so perhaps you could do something like
"(unbase64 || cat) < \"$fn\" | bogofilter -v $options"

> Yup, good catch; but $fn ought to be safe as long as $PROG will not
> contain blanks or shell meta characters.

agreed, but since you were quoting it other places i wanted to be consistent.

i am still uncomfortable with the idea of leaving the bogopass tmp
file in /tmp or basically using a temp file at all.  are there any
thoughts about just keeping the message in memory?  it would be much
speedier and much tigher security-wise.  of course, a large message
could take up a lot of memory and bogofilter is already keeping quite
a lot of the message in memory so it would kind of double.

still, perhaps this is just the risk one takes when using bogopass for now?
-- 
Allyn Fratkin             allyn at fratkin.com
Escondido, CA             http://www.fratkin.com/





More information about the bogofilter-dev mailing list