Re: remote plugin patch for netqmail-1.06

On 2016-02-28 16:53, Christian Jaeger wrote:
> 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.
> 
Thanks, didn't know that.

> 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.
> 
One thought behind publishing is that others - who have the knowledge - 
review the code. And reporting (potential) bugs. In best case they 
recommend to use it and use it themselves. Otherwise - in this case, the 
patch is IMHO trivial. In reality more than 99% of users trust or have 
to trust the code.

>> For me the competition is of interest.
> 
> My interest is in collaboration wherever possible.

Maybe "a challenge" is more accurate ;-). Competitions was said in a 
positive meaning, not in any case going proprietary.
> 
> 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.

In the past I had reached a point at one time, as I have had 
qmail-queue, qmail-smtpd and qmail-remote renamed. I decided for me not 
to have such a situation again. I do use QMAILQUEUE=<wrapper.sh> also, 
where wrapper.sh calls one or more external progs. This is more from an 
admins POV with the experience to keep configurations consistent.

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

> is secure, I'll stay away from changes to the Qmail code whenever I
> can.
Agree again. The patches I use are used by the community since a long 
rime - mostly. My own changes/contributions to the code are very, very 
trivial. I want stay as close as possible with the original code and 
design of qmail.
> 
>  [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

Thanks for pointing this out. I don't follow up the development of 
programming languages. I question is it worth the effort to learn 
another dialect? I saw to many projects come and die in the past. May be 
the advantages of ATS will be included to C/C++ in the future. (Btw., 
the ATS package is masked in portage .-( .). IMO the used language is a 
philosophical point.
> 
>> 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?
I rewrite the mail itself, body and/or headers depending on criterions.

> 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.
At least mask means "use at your own risk", simplified.

> 
> 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.
You're welcome as well your assistance. I have a clear plan what to do 
along my existing stuff and roadmap - (IMHO) well deliberated, but being 
fairly open for improvements, new ideas of implementations or particular 
solutions.

Kai