Re: Upcoming GMime 3.0 changes

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...

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 <>).  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. 
<> and 
<>), 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!


Version: GnuPG v2


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]