Re: [RFC/Proposal] Replacing libesmtp in Balsa

[Peter Bloomfield <PeterBloomfield bellsouth net>]

Hi Albrecht:

On 01/19/2017 01:56:54 PM Thu, Albrecht Dreß wrote:
> Hi all,
>
> in March 2016 we discussed on this list the status of the libesmtp library [1].  It appears that libesmtp is 
> either dead or no longer supported.  At least the web site is not reachable any more.  In particular, 
> security fixes (afaict, libesmtp supports only TLS 1.0, but not the recommended TLS 1.2) are not applied.
>
> On the other hand, GLib/GIO actually has everything we need for networking: classes for TCP streams, with and 
> without TLS encryption (the latter based on gnutls), and data input streams for line-based CRLF terminated 
> input.  And GMime implements all message encoding stuff, so we can simply use these well-maintained 
> components to implement everything we need.
>
> As only a limited set of the functionality from RFC 5321 is required in Balsa, my idea is to write a few 
> simple classes (as a separate library included in balsa) on top of GIO as to replace libesmtp.  This would 
> remove all conditional code (mainly in libbalsa/send.c) checking for the existence of libesmtp.
>
> I started with the implementation a while ago, and have a "proof-of-concept" version up and running on top of 
> the balsa-master branch.  The current status of the library:
> - implemented the base class
> - implemented the SMTP class, supporting SMTP with and without STARTTLS as well as SSMTP, plus everything we 
> need in Balsa
> - support for LOGIN, PLAIN, CRAM-MD5 and CRAM-SHA1 authentication and for DSN's
> - documentation (almost complete...)
> - unit tests with coverage analysis and leak checks using inetsim
> - implementation tries to follow the MISRA C:2012 (MISRA C3) [2] and SEI CERT Secure Coding [3] standards for 
> safer code
>
> In Balsa, I removed all libesmtp-related conditional stuff.
>
> Still missing:
> - using the Balsa authentication cache and the certificate acceptance dialogues (easy)
> - implementation of private (user) certificate authentication (easy; rarely used, though)
> - more AUTH mechanisms (Kerberos, NTLM, ...; probably difficult, but I /think/ they are also rarely used)
>
> As an additional benefit for further code simplification, it should be easy to derive classes for the (also 
> line-based, CLRF-terminated) POP3 and IMAP protocols from the base class.  I actually have a /very/ basic 
> POP3 implementation, but it's neither documented and tested thoroughly, nor included in Balsa.
>
> What do you think about this approach?  If you think this would be a good idea for Balsa, should we create a 
> new branch, or directly use it in master (see also Peter's somewhat related message today regarding Gtk4)?
>
> Thanks in advance,
> Albrecht.
>
>
> [1] <https://mail.gnome.org/archives/balsa-list/2016-March/msg00007.html>
> [2] <https://www.misra.org.uk/Publications/tabid/57/Default.aspx>
> [3] <https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard>

That's huge! The library would bring Balsa up to date with security developments, and open the way to keeping 
it that way.

This is definitely something we should implement in master, and get into a new release as soon as it's been 
tested. Please send in patches whenever you're ready to install them.

Thanks for all the efforts!

Peter