[cvs] bogofilter/contrib bogopass,1.3,1.4

[Matthias Andree]

On Tue, 03 Dec 2002, Allyn Fratkin wrote:

> 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.

I'd vote for 0.9.2 with a working bogopass, but not now, there are
questions below.

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

Not me, not you, not Suzanne. And David neither.

I'm sorry, I was part of the trouble script. I was wondering if we
should do basic tests for contrib/* programs or if we should rather
spend our time on something else, because it's explicitly marked
interim solution.

> >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.

Setting it later is for defeating Perl taint checks actually ;-) It
would be an issue if bogopass was installed setuid-root or something,
but it can safely run unprivileged, I had suggested that we set the PATH
explicitly, but then we'd bump into the 32 character limit for the #!
magic that some systems impose.


It's a remainder from when I tried to make bogopass "perl -T" proof, but
that turned out too much of an effort -- we couldn't have used system or
exec the way we do then, and we run in a controlled way.

Should we figure the Perl path at configure time then and create these
scripts with config.status?

> 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.

Yes, we might do that.

> >We must not close the file handle yet, unlink0 needs it below.
> 
> unlink0 worked fine even if $fh was closed.

"not here", it printed two lines on stderr about stat'ing a closed $fh.

> >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"

The whole point about bogopass is to emulate "bogofilter -p" with
unbase64, so we don't want "cat" in there.

> 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.

I believe the way File::Temp deals with it is safe enough. If we're
paranoid, we enforce that /tmp has its sticky bit set (so that files can
only be deleted by their respective owners) and bail out if it's unset,
or use a private .tmp file.

> 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?

"Add a swap partition. Disks are cheap." :-)

Seriously, I think we should only fix the remaining /usr/bin/env versus
$PATH consistency issues and keep it the way it is.