Re: Upcoming GMime 3.0 changes

[Peter Bloomfield <PeterBloomfield bellsouth net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Albrecht,

On 06/22/2017 03:26:16 PM Thu, Albrecht Dreß wrote:
> Hi Peter:
>
> Am 21.06.17 22:03 schrieb(en) Peter Bloomfield:
> > I installed GMime 3.0.1 from git, and I have a patch against Balsa git master for building with it, keeping 
> > the ability to build with 2.6 through the magic of #if. It just adapts Balsa's current code to work with the 
> > new API, but even so it's a big mess, over 2k lines of patch, touching 32 files and creating 160 blocks of 
> > conditionally compiled code.
>
> Ouch.  It's very interesting and encouraging to hear that you succeeded in compiling the sources.  But I 
> strongly advise against using it through preprocessor conditionals.  It basically makes the code unreadable 
> and unmaintainable, and has always been a source for funny (more or less, actually) errors.  Better create a 
> new branch...

Agreed.
…
> If we want to make Balsa more popular, IMO we have completely different problems.  I don't watch other 
> distos, but Debian and Ubuntu all ship with some 2.4.12 variant.  But this one will just stop sending 
> messages at some (near?) point in the future as it relies on the ancient libesmtp library which supports 
> (insecure) SSL 3 and TLS 1.0 only, so MTA's will probably simply refuse to talk to Balsa.
>
> Package maintainers *hopefully* now look at Balsa's master branch, iirc you sent an announcement last year.  
> Again changing master to something relying on non-standard packages is an extremely bad idea and will 
> encourage maintainers not to put too much effort in something which looks like a quite unstable and 
> experimental project.  Until Balsa disto packages silently die for the reasons above.
>
> Looking at my personal agenda, I think the following points should be addressed shortly:
> - Some improvements in the crypto code, in particular replacing the clumsy gpg code for talking to key servers by 
> GpgME.  Goal: remove gpg config dependency, better user experience, preparation for EasyGPG which will rely on 
> Gpgme keyserver interaction (see <https://wiki.gnupg.org/EasyGpg2016>).  I'm working on that.
> - Replace the low-level networking parts in libimap, depending on openssl, by libnetclient.  Probably much 
> work, I'll look into it after finishing the first task.  Goal: drop openssl dependency (and its frequent 
> security issues), as everything will then be in gio (i.e GnuTLS).
>
> And, if everything has been tested, it would be time for a new stable release IMO, which should be promoted 
> for inclusion into distos.

Looks like a plan!

> Oh, and I think we should also look into the code quality (see e.g. 
> <https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard> and 
> <http://www.embedded.com/electronics-blogs/beginner-s-corner/4023981/Introduction-to-MISRA-C>), documentation and 
> coding style.  Static analysis (FlexeLint or similar) would be great.  Not visible to the user, but improves stability 
> and security.

For the cosmetic part, we could uncrustify the whole tree. Improving code quality will take longer!

Best,

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAllNJQ8ACgkQH1/UtbkqdPUIbQCfUWdDACdfbm4uA98InnUjP9rG
f9YAn3pYSK/CEALuEjZeZ1iUsDB0crXi
=wg7Z
-----END PGP SIGNATURE-----