Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Merging tlscertfile and tlscafile to only one TLS
certificate (Russ Allbery)
2. Re: Openssl 3.0.0 (Russ Allbery)
3. Re: Openssl 3.0.0 (Noel Butler)
4. Re: Openssl 3.0.0 (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Wed, 08 Sep 2021 15:53:37 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Merging tlscertfile and tlscafile to only one TLS
certificate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> A ticket has recently been opened regarding the use of tlscertfile and
> tlscafile. (Looks like it is easier to contact us via Github than Trac!)
> https://github.com/InterNetNews/inn/issues/164
> Currently, we have 2 files to deal with TLS certificates:
> - tlscertfile, from which INN loads only one certificate (the first);
> - tlscafile, from which INN loads all intermediary certificates.
> Another possibility would be to only have 1 parameter, pointing to a file
> containing the whole chain.
There are some mechanisms for obtaining certs where this separation is the
most natural, and others where it's the most natural to have the full
chain back to a CA in one file. Back when it was typical to buy a
commercial certificate, sometimes the result of that signing process would
be only the signed server certificate and to have a separate chain file
that you had to download that had the intermediate certs.
(BTW, tlscafile is kind of a misnomer. It's essentially useless to have
the actual CA certificate around, since the client has to provide it
anyway. It contains all the certificates leading back to, but not
including, the CA, although I think it's harmless to put the CA in there
as well.)
I think we should support loading all the certificates in tlscertfile, and
then, if tlscafile exists, add the certificates from it. That should give
us the best of both worlds: existing usage will still work, but people can
migrate to putting the whole chain in tlscertfile. And then if we choose
we can deprecate tlscafile, similar to how Apache has deprecated
SSLCertificateChainFile, which is the equivalent of our current scheme.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 2
Date: Wed, 08 Sep 2021 16:03:40 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Openssl 3.0.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Russ, is there a reason why lib-pathname.m4 checks for /usr/lib32 or
> /usr/lib64 only? I suggest to also add a check for /lib32 or /lib64.
> With the following patch, configure correctly finds
> /home/iulius/work/openssl-3.0.0/lib64 Note that I have /lib64 but not
> /usr/lib64 on an (old) Jessie Debian system. Seems like newer versions
> have both.
Debian does not use /lib64 paths, so it's correct to not detect this on
Debian. (They're explicitly forbidden by Debian Policy in favor of using
multiarch.) This seems like a bug in OpenSSL that nontheless it installed
itself in <prefix>/lib64, presumably assuming the whole world is Red Hat.
If we want to work around this bug, we need different logic for
RRA_SET_LDFLAGS than for RRA_SET_LIBDIR, since it's incorrect on this
system for the latter to use /lib64, but the former should presumably fall
back to /lib64 if /lib is not present.
I assume you were using --with-openssl. You can work around this with
--with-openssl-libs, but it would probably be better if you didn't have to
if OpenSSL does this everywhere.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 3
Date: Thu, 09 Sep 2021 12:01:02 +1000
From: Noel Butler <[email protected]>
To: [email protected]
Subject: Re: Openssl 3.0.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 09/09/2021 09:03, Russ Allbery wrote:
> Julien ?LIE <[email protected]> writes:
>
>> Russ, is there a reason why lib-pathname.m4 checks for /usr/lib32 or
>> /usr/lib64 only? I suggest to also add a check for /lib32 or /lib64.
>> With the following patch, configure correctly finds
>> /home/iulius/work/openssl-3.0.0/lib64 Note that I have /lib64 but not
>> /usr/lib64 on an (old) Jessie Debian system. Seems like newer
>> versions
>> have both.
>
> Debian does not use /lib64 paths, so it's correct to not detect this on
> Debian. (They're explicitly forbidden by Debian Policy in favor of
> using
> multiarch.) This seems like a bug in OpenSSL that nontheless it
> installed
> itself in <prefix>/lib64, presumably assuming the whole world is Red
> Hat.
The whole world doesnt use debian either :)
Slackware also uses such paths (lib64) etc, and sure as hell isnt a red
hat derivative
--
Regards,
Noel Butler
This Email, including attachments, may contain legally privileged
information, therefore at all times remains confidential and subject to
copyright protected under international law. You may not disseminate
this message without the authors express written authority to do so.
If you are not the intended recipient, please notify the sender then
delete all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20210909/6afe7306/attachment-0001.htm>
------------------------------
Message: 4
Date: Wed, 08 Sep 2021 20:15:48 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Openssl 3.0.0
Message-ID: <[email protected]>
Content-Type: text/plain
Noel Butler <[email protected]> writes:
> On 09/09/2021 09:03, Russ Allbery wrote:
>> Debian does not use /lib64 paths, so it's correct to not detect this on
>> Debian. (They're explicitly forbidden by Debian Policy in favor of
>> using multiarch.) This seems like a bug in OpenSSL that nontheless it
>> installed itself in <prefix>/lib64, presumably assuming the whole world
>> is Red Hat.
> The whole world doesnt use debian either :)
> Slackware also uses such paths (lib64) etc, and sure as hell isnt a red
> hat derivative
(It's a reference to an old saying "all the world is a VAX" about
portability issues in software.)
There are two major ways of doing multiarch libraries, the Red Hat way
(/lib64) and the Debian way (/usr/lib/x86_64-linux-gnu). I call them that
because my recollection is that those are the Linux distributions that
developed those specific mechanisms when we started the transition to a
64-bit world (well, Debian and Ubuntu did theirs together). So a more
precise way of saying it would be "assuming the whole world uses Red Hat's
multiarch scheme."
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 133, Issue 4
*******************************************
