Re: remote plugin patch for netqmail-1.06

On February 28, 2016 12:40:25 PM GMT, Kai Peter <[email protected]> wrote:
> I don't know very much about distributions which are based on binary 
> packages. Whatever dpkg-divert does.

The `dpkg-divert` command registers a new path name for a file in a 
given package. So if qmail is installed as a .deb package, and I run

   dpkg-divert --local --divert /usr/sbin/qmail-remote.orig --rename /usr/sbin/qmail-remote

then from that point on the original qmail-remote executable lives at 
`/usr/sbin/qmail-remote.orig`; package upgrades won't touch the old 
location, `/usr/sbin/qmail-remote`, anymore, hence I'm free to put my 
own executable (wrapper, replacement) there (which the other parts of 
qmail still call, dpkg-divert doesn't change what paths that programs 
use, by design). Diversions can be done, undone or changed at any time 
without having to reinstall the package.

Because Qmail is so modular, it is a brilliant example where that 
mechanism works very well. That, together with my wish to avoid 
patching Qmail whenever possible (primarily for security reasons, 
because C is so fraught with perils), led to my question.

> Do I use 'a system that allows for hassle-free renaming of 
> binaries'? I have to out me as a Gentoo user, switched from LFS a 
> few years ago.

I haven't used Gentoo, so I don't know whether it supports something 
similar. I guess in the worst case you'd have to patch the installer, 
either as the end user of the package, or as the maintainer you might 
be able to introduce an install time flag. I can see that a run time 
configuration has benefits over an install time one, of course. Given 
that you're providing the change as part of eQmail, users will pretty 
much have to trust you to be able to write secure C code anyway unless 
they are reviewing all changes.

> At least this could be the start of a discussion (again), what is 
> the best distro to use.

That is not my intention.

> The choice to use it is yours, the user.

Of course.

> For me the competition is of interest.

My interest is in collaboration wherever possible.

Of course the two solutions of renaming qmail-remote for callbacks or 
patching in a mechanism to achieve the same thing can perfectly live 
side by side and each mechanism isn't much work to implement.

What I'm more worried about are DKIM, backscatter handling, and 
perhaps encryption. What I wish is that there's a solution that works 
well (geared towards small setups as that's what I do) and is 
secure. Many (most?) of us are probably using Qmail because of its 
security; but that's very easy to spoil by patching it. If there were 
a move towards a modern way to prove changes to the Qmail code secure 
(by e.g. starting to integrate the Qmail code with the ATS programming 
language[1] and writing new extensions in ATS, or using some other 
kind of framework to achieve static proofs) then I'm all for going 
that route. Without that or any kind of solid way to show why the code 
is secure, I'll stay away from changes to the Qmail code whenever I 
can.

  [1] https://en.wikipedia.org/wiki/ATS_(programming_language) 

      For an example how it can be useful:
      https://bluishcoder.co.nz/2014/04/11/preventing-heartbleed-bugs-with-safe-languages.html

> Just one example. I use it for rewriting bounces too. A result of I 
> won't rewrite the original sources too much.

You mean original Qmail sources, or sources in the email headers?

> > 
> > Did you see better-qmail-remote?[1] What are you doing differently?
> > 
> Hmm. different? Really - nothing! I did made and use the core of my 
> patch before better-remote was announced.
> > [1] https://github.com/pflanze/better-qmail-remote
> I did have a look at this. Main issue for me was that hashcash was 
> masked on Gentoo, at least for amd64 arch.

I'm not sure what masked means, I can see from the page of the gentoo 
package that it doesn't have a maintainer, I guess that's what you're 
referring to.

FWIW, better-qmail-remote simply uses hashcash if it's installed and 
silently doesn't if it's not. Thus I'm not sure why you're seeing it 
as an issue.

Anyway if you've implemented your own solution before my publication 
and believe in it that explains why you stay with it of course.

As I said above, from my point of view I want security, and the 
flexibility to be able to work on it myself, too, without fear of that 
breaking security. Plain C isn't satisfying these wishes. If you're 
planning to work out a solution to these, then I may well become a 
contributor.

Christian.