Re: Exmh releases, and a large bunch of small changes in the exmh tre e...

>>>[email protected] said:

 > (Read on, important stuff (point 4) towards the bottom)
 > 
 > I had a longish weekend with nothing to do, so I started hacking some 
more c
     ode.
 > 
 > And as often happens, I got diverted off the original goal, which was to 
fix
      the
 > remaining bugs in the separate-window for ftoc and/or msg code.  What I 
just
 > dropped into the CVS tree:
 > 
 > 1) A bunch of html and doc fixes, some typos, broken links, bad color 
choice
     s
 > (somebody thought #fffff0 was visible against 'white' :) and the like.

Thanks!

 > 2) misc/README.mybogo.tcl was both crufty and outright wrong, plus it 
didn't
 > support spamassassin, so I fixed the bogo.tcl already in the lib/ tree. 
:)
 > There should now be a Preferences for 'Bayesian spam filter', and the 
Messag
     e
 > window should now have a Spam... menu.  Still to do:

Thanks again!

 > 2a) Come up with a clever way to hide or grey out the Spam... menu if
 > the user hasn't configured it in Preferences.

This isn't that hard.  It would be easier with an overall
preference item to "enable spam menu" ... :-)  I may get to this.

 > 2b) the original mybogo.tcl talked about adding key bindings - anybody 
think
 > that's a good/bad idea?  Easy enough to do, but consensus would be nice.

I use <Key-S> for "mark spam", and might presumably use
<Key-H> for "mark ham".  That runs so slowly, however,
that I don't use it much.  Instead I tend to move messages
en masse to another folder, then sa-learn the whole thing.
Ideally, we'd do the learning as a kind of background task
just as Delete and Refile are done.  But, that's a lot of work.

 > 2c) Buglet - you can't feed an entire folder to the spam filter unless 
you
 > select at least one message.  A better fix would probably be to move the
 > 'entire folder' variants from the mops list to the fops list...

Yes, let's move folder-wide operations to the fops menu.

 > 3) I did a mass cleanup of a lot of places where we were doing things 
like
 > 'exec chown' or 'exec rm', and changed them to equivalent native Tcl 
'file'
 > calls.  This was for 2 reasons:  (a) just clean up and efficiency, and 
(b) (
     leading
 > in to the next point...)

Thanks!

 > 4) I did a fairly extensive security audit, and found some *nasty* bugs 
abou
     t a
 > week or so ago - basically, an attacker could manage to pass fairly 
arbitrar
     y
 > text to an 'exec' call in a number of places.  The two biggest got 
patched i
     n
 > CVS a week ago, stashed under some other actual bug fixes for mime.tcl.  
I w
     anted
 > to try to keep the cat in the bag until I was able to deal with the 
other 'e
     xec'
 > calls.
 > 
 > The security hole is pretty big - it can be triggered by a remote 
attacker w
     ith a
 > specially crafted piece of malformed MIME.
 > 
 > Given that the hole was a metamail-related one, maybe that's even more 
reaso
     n
 > to find an alternate base64 {en,de}coder and heave all the Metamail code 
ove
     r the side.
 > 
 > I think the hole is big enough to merit a 2.7.1 release at least - what 
do o
     thers
 > think?

Yes, this all merits 2.7.1.  I will contribute (uh, copy) the Tcl-based
versions of mimencode so we don't have that dependency.  We could probably
have a general "metamail enabled" preference that would disable the
right-button "send to metamail" menu item.

--
Brent Welch
Software Architect, Panasas Inc
Delivering the premier storage system for scalable Linux clusters

www.panasas.com
[email protected]