On February 28, 2016 12:40:25 PM GMT, Kai Peter <kp@lists.openqmail.org> 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.