Mailing List Archive

Hello,

I've attached my procedure to install s/qmail on Debian (tested on Debian 10 ... not yet on Debian 11)

I know there is in the meanwhile an updated version of s/qmail

Best Regards

Thibault

-----Message d'origine-----
De : John Puttergill <john@itsjustit.co.uk>
Envoyé : mercredi 10 novembre 2021 10:27
À : Qmail List <qmail@list.cr.yp.to>
Objet : jms combined patch has anyone written an update

I am in the process of replacing one of my perifferal servers and am finding that qmail with the jms combined patch fails to compile on any version of Debian later than Debian 8

As best I can make out this relates to libssl 1.0 no longer being supported here is the line where it fails

> Makefile:1589: recipe for target 'qmail-smtpd.o' failed
> make: *** [qmail-smtpd.o] Error 1

thibs@thibs.com <thibs@thibs.com> wrote:
>
> I've attached my procedure to install s/qmail on Debian (tested on Debian 10
> ... not yet on Debian 11)

That's not going to scare anyone off :)

To be serious, thanks for posting this. I'm sure it will be helpful to many.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------

> On Nov 10, 2021, at 10:27 AM, John Puttergill <john@itsjustit.co.uk> wrote:
>
> I am in the process of replacing one of my perifferal servers and am finding that qmail with the jms combined patch fails to compile on any version of Debian later than Debian 8
>
> As best I can make out this relates to libssl 1.0 no longer being supported here is the line where it fails
>
>> Makefile:1589: recipe for target 'qmail-smtpd.o' failed
>> make: *** [qmail-smtpd.o] Error 1

That probably means qmail-smtpd.c didn’t compile, but doesn’t say where or how not. Could you include more of the logs (or post them somewhere and provide a link here)?

Another option for getting a reasonably functional qmail server going on Debian is to use pkgsrc, a cross-platform Unix package manager. After bootstrapping pkgsrc onto your system, you run a couple more commands, twiddle your thumbs, and end up with a running system. I’ve tested this on Debian 9, 10, and 11. Watch "demo on Debian 9, building from source packages” on this page: https://schmonz.com/2019/01/07/2018q4-qmail-updates-in-pkgsrc/ <https://schmonz.com/2019/01/07/2018q4-qmail-updates-in-pkgsrc/>

I’m sure it’s not an exact functionality match with the jms combined patch you’ve been running, but it’s close (https://marc.info/?l=qmail&m=154947925223349&w=2 <https://marc.info/?l=qmail&m=154947925223349&w=2>), it’s easy to get going, and it’s easy to incrementally incorporate your own patches on top.

The pkgsrc package is based on notqmail. I’m biased: I’m a notqmail and pkgsrc developer :-)

- Amitai

Thus said John Puttergill on Wed, 10 Nov 2021 09:27:24 +0000:

> As best I can make out this relates to libssl 1.0 no longer being
> supported here is the line where it fails
>
> > Makefile:1589: recipe for target 'qmail-smtpd.o' failed make: ***
> > [qmail-smtpd.o] Error 1

Is there any more context? This doesn't give any details about why it
failed.

Andy

I have installed qmail(-ldap) on several version of linux distro, and last
time I installed one on centos 7. When I'm on a situation like this, let
say the newer version was libssl-2.0, I'll make a softlink of libssl-2.0 to
libssl-1.0. So when make was looking for libss-1.0, she will get one,
although the one behind it was 'libssl-2.0'. As long as there was no
extreme changes in 'libssl-2.0', usually it'll work.

Regards,

On Wed, Nov 10, 2021 at 4:34 PM John Puttergill <john@itsjustit.co.uk>
wrote:

> I am in the process of replacing one of my perifferal servers and am
> finding that qmail with the jms combined patch fails to compile on any
> version of Debian later than Debian 8
>
> As best I can make out this relates to libssl 1.0 no longer being
> supported here is the line where it fails
>
> > Makefile:1589: recipe for target 'qmail-smtpd.o' failed
> > make: *** [qmail-smtpd.o] Error 1
>
>

FC Mario Patty <fcmario76@gmail.com> wrote:
> When I'm on a situation like this, let say the newer version was libssl-2.0,
> I'll make a softlink of libssl-2.0 to libssl-1.0. So when make was looking
> for libss-1.0, she will get one, although the one behind it was
> 'libssl-2.0'.

Ouch. This isn't generally a good idea, particularly with a major version
change. With some software, and a smaller version change -- say the version
in the .so filename changes from 1.3.x to 1.4.0 -- you might get away with it.
The worst that happens is your messaging app or calculator app or whatever
crashes, no harm done.

But with security-critical software like OpenSSL, things could be much worse.
The code could "work", but leak secrets like mad. Or it might start deciding
all certificates are valid, even if they're expired or forged. Or it might
decide all certificates are *invalid*.

Don't do this with security-critical components.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------

On 10 Nov 2021, at 17:07, Amitai Schleier wrote:

> On Nov 10, 2021, at 10:27 AM, John Puttergill <john@itsjustit.co.uk>
> wrote:
>
>> As best I can make out this relates to libssl 1.0 no longer being
>> supported

BTW, for a variety of reasons, the currently proposed designs for
integrating TLS into notqmail's qmail-smtpd and qmail-remote
deliberately avoid linking with any cryptographic library. You've
encountered one of the reasons: needing to keep up with OpenSSL API
and/or ABI changes.

Some other reasons:

1. Avoid adding complicated encryption code
2. Remove vestigial network-transport code (from qmail-remote)
3. Keep TLS out of our address space entirely
4. Run TLS under privilege separation
5. Let administrators choose alternate TLS implementations

Maybe you can think of more.

Due to the UCSPI-TLS interface as implemented in s6-networking and
ucspi-ssl, these proposed designs are less ambitious than they might
sound. Thanks to Scott Gifford and Charlie Brady for UCSPI-TLS, and to
Laurent Bercot and Erwin Hoffmann for providing these tools for all of
us.

Take a look (https://github.com/notqmail/notqmail/wiki/Designs) and let
us know: Would you be eager to run a qmail-derived system shaped like
this? Would you avoid it at all costs? Something in between?

- Amitai