[cvs] bogofilter/contrib bogopass,1.3,1.4

[Matthias Andree]

Allyn Fratkin <allyn at fratkin.com> writes:

> perhaps a private ~/.bogopass.XXXXXXXX would be better?  most people
> don't have writeable home directories.  i DON'T think we should be
> trying to tell administrators (or worse, users) that they should change
> their /tmp permissions just to use bogopass.

A /tmp that does NOT use the +t permission bit is as good as
/dev/null. Anyone can remove your files while you still need them
(bogopass does).

Yes, using ~/.bogofilter or ~/.tmp would be a fix for that, but I'm not
changing that code any more. Make it secure, but don't add luxuries. I
believe it's secure, and if root has . in his $PATH and something bad
happens for this reason, we can blame it on a grossly negligent setup.

>> Seriously, I think we should only fix the remaining /usr/bin/env versus
>> $PATH consistency issues and keep it the way it is.
>
> ok, i'm fine with deleting the PATH setting and using "/usr/bin/env perl"
> to find perl.  or explicitly setting the perl path and using searching the
> incoming PATH for unbase64 and bogofilter.  or hardcoding all paths.
> the only variation i'm really against is "/usr/bin/env perl" followed
> by explicit PATH setting.

Agreed, the latter inconsistent. Your change ought to be ok.

> i've made some final changes to bogopass (matthias, your latest change
> was passing back the corrupted unbase64-ed message again),

Wee. I'm changing variables now so as to sell myself a clue. Sorry for
that. Thank you for reparing it.

> and i am fine the way it is now.  i also deleted the explicit PATH
> setting since matthias had put back the "/usr/bin/env perl".

OK.

> i think it is ok to ship.  matthias, do you agree?

Yes, 1.8 was ready to ship.

I added support for maildrop's reformail, enhanced the error messages,
use POSIX to parse the exit code in parsewait() and other places and
enhanced the detection if bogofilter failed. We don't want to pass on
junk output as though it was the real mail.

Note reformail does NOT enforce the "From " line unless you request that
with -f1. I'm not doing that now, I believe the "From " line should be
added no earlier than on final delivery to a UNIX mbox, we don't want
"From " lines in Maildir/ deliveries.

Could you please have a look if it still works?

-- 
Matthias Andree