On Fri, Jan 30, 2015 at 01:46:01PM +0100, Natanael Copa wrote:
> On Tue, 27 Jan 2015 17:35:36 -0800
> Isaac Dunham <ibid.ag_at_gmail.com> wrote:
> > On Tue, Jan 27, 2015 at 04:15:35PM +0100, Natanael Copa wrote:
> > > I'm bringing up this old issue because there are a couple of CVE issues:
> > > http://seclists.org/oss-sec/2014/q4/1066
> > >
> > > Do you think it would be possible to completely replace main/mailx with
> > > heirloom-mailx without breaking too much? More specifically, does
> > > heirloom/mailx' mail implementation support all the args in current
> > > mail/mailx?
> > >
> > > -nc
> > Yes.
> > heirloom-mailx does not mention -v in its help, but seems to accept it.
> > Other options/arguments seem to be compatible.
> I'm thinking how to do this for stable to fix the CVE issues. I looked
> at backporting the patches to our version but that seems like alot of
> work so I don't think that is a good option.
> It seems that heirloom-mailx also introduces krb5 dependency. I think
> we don't want that for stable, but it also looks like its optional.
krb5 is for IMAP authentication over GSSAPI; it is optional, and there
are 4 GSS libraries that can be used in theory.
The makefile probes for these, so it's simply a matter of whether
the library is in makedepends.
Our "mailx" (actually "mail") does not support IMAP at all, so dropping
krb5 from makedepends for stable should be fine.
I'm not aware of a particular need for IMAP authentication over GSSAPI,
but thought that it would be better to support it since we have Kerberos
in main/ (in other words, feel free to drop it completely if you see fit).
> The /etc/mail.rc has been renamed to /etc/nail.rc but I suppose we can
> add a pre-upgrade script that will rename existing /etc/mail.rc
> to /etc/nail.rc and add a symlink /etc/mail.rc.
> There is also a heirloom-mailx fork named s-nail. I don't know if that
> is a better alternative.
If you look back over the thread, I mentioned s-nail but chose not to
package it yet because the development plans involve(d) a bunch of code
cleanup down the road, including dropping IMAP support for a release
or two and then rewriting it from scratch.
It's probably a good idea in the long term, but I doubt that starting to
support IMAP, turning it off, and turning it on again with a complete
rewrite of the backend is going to make things easy for users or for
Once the s-nail developers have the new IMAP support finished, it would
probably be a good choice.
Received on Fri Jan 30 2015 - 14:48:19 UTC