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: Openssl 3.0.0 (Julien ?LIE)
2. Re: INN indentation (Julien ?LIE)
3. Re: Merging tlscertfile and tlscafile to only one TLS
certificate (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Fri, 1 Oct 2021 23:16:26 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Openssl 3.0.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Dominik,
>> When building against OpenSSL 3.0.0 on Fedora rawhide, I can see four
>> deprecation warnings when compiling tls.c:
>>
>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g
>> -grecord-gcc-switches -pipe -Wall -Werror=format-security
>> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>> -fstack-protector-strong
>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1? -m64? -mtune=generic
>> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
>> -fPIE -fstack-protector-strong -I../include???? -c tls.c
>> tls.c: In function 'load_dh_buffer':
>> tls.c:167:9: warning: 'PEM_read_bio_DHparams' is deprecated: Since
>> OpenSSL 3.0 [-Wdeprecated-declarations]
>> ?? 167 |???????? dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
>> ?????? |???????? ^~
>> In file included from tls.h:25,
>> ????????????????? from tls.c:20:
>> /usr/include/openssl/pem.h:469:1: note: declared here
>> ?? 469 | DECLARE_PEM_rw_attr(OSSL_DEPRECATEDIN_3_0, DHparams, DH)
>> ?????? | ^~~~~~~~~~~~~~~~~~~
>
> Oh, strange that I do not see these warnings.
I now see again the warnings! I'll have a look.
When updating INN to the OpenSSL 1.1.0 API, I unfortunately added that
piece of code in nnrpd/tls.h:
/* When building with "make warnings", ensure that INN does not
* use deprecated interfaces from OpenSSL. */
#if defined(DEBUG)
# define OPENSSL_API_COMPAT 0x010100000L
#endif
Only triggered when "make warnings" is used. That's why I did not see
the new deprecated functions in OpenSSL 3.0.0 as I was building INN with
warnings on, which wrongly enforced compatibility with OpenSSL 1.1.0 API...
I'll remove those lines which should not have hidden the fact that
OpenSSL API has changed again.
--
Julien ?LIE
??Bis repetita placent.?? (issu de Horace)
------------------------------
Message: 2
Date: Sat, 2 Oct 2021 08:15:27 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: INN indentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
> For my personal projects, I've started using clang-format to just reformat
> all of the source code and keep it consistently formatted. It requires
> some work up-front to mark some code blocks to not reformat, because it
> messes up a lot of code that's carefully laid out to make it easier to
> read
Yup, it otherwise reformats carefully laid out code like:
static CONFTOKEN PERMtoks[] = {
{ PERMlbrace, (char *) "{" },
{ PERMrbrace, (char *) "}" },
{ PERMgroup, (char *) "group" },
So it will need a bit of careful review of each converted file so as to
ensure not to reformat such code (/* clang-format off */).
Sometimes, some headers need being included before other ones for
portability reasons, so changes need careful review.
I see that HACKING recommends to include at the beginning of C files:
#include "config.h"
#include "clibrary.h"
Yet clibrary.h already includes config.h; I bet it had not always been
the case, which would explain it and why all or most of our files have
both. Maybe we could drop the inclusion of config.h then. And globally
review the inclusions when clang-format re-orders them.
> For the record, here's the .clang-format file I use for my personal
> projects:
>
> ---
> Language: Cpp
> BasedOnStyle: LLVM
> AlignConsecutiveMacros: true
> AlignEscapedNewlines: Left
> AlwaysBreakAfterReturnType: AllDefinitions
> BreakBeforeBinaryOperators: NonAssignment
> BreakBeforeBraces: WebKit
> ColumnLimit: 79
> IndentPPDirectives: AfterHash
> IndentWidth: 4
> IndentWrappedFunctionNames: false
> MaxEmptyLinesToKeep: 2
> SpaceAfterCStyleCast: true
> ---
Maybe we could just use the same to start?
We could otherwise spend months discussing each personal coding style.
I see the list is quite extensive:
https://clang.llvm.org/docs/ClangFormatStyleOptions.html
I would for instance suggest
AllowShortEnumsOnASingleLine: false
because the current layout
typedef enum _SENDTYPE {
STarticle,
SThead,
STbody,
STstat
} SENDTYPE;
seems better to me than:
typedef enum _SENDTYPE { STarticle, SThead, STbody, STstat } SENDTYPE;
I've tried it on a few files to see how they look like with this format.
AlignConsecutiveMacros: AcrossEmptyLinesAndComments
may be better but only available in clang-format 13 (not yet released!)
It think it would permit to have 62 at the same level here:
#if defined(HAVE_OPENSSL) || defined(HAVE_SASL)
# define PERMrequire_ssl 62
# define PERMMAX 63
#else
# define PERMMAX 62
#endif
> My personal style is slightly different than INN's, but they're relatively
> close. (INN has some unusual conventions for comment formatting.) The
> biggest thing that it changed in my other projects was using four-space
> indentation for nested C preprocessor directives.
Yes, seen!
Any comments from others about the style we can start with? (Let's
begin with something!)
--
Julien ?LIE
??Bis repetita placent.?? (issu de Horace)
------------------------------
Message: 3
Date: Sat, 2 Oct 2021 09:21:38 +0200
From: Julien ?LIE <[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; format=flowed
Hi Russ, Richard and Perry,
>> 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
>
> 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.
I've just had a look at it.
The change is straight-forward as we already call
SSL_CTX_load_verify_locations() to look for additional certificates in
tlscafile (which is the recommendation in OpenSSL documentation).
Suggestion follows, with updated wording in documentation (also in
nnrpd.pod, which shares the same wording as in inn.conf.pod):
diff --git a/nnrpd/tls.c b/nnrpd/tls.c
index 3b0bc7ab..67b0841b 100644
--- a/nnrpd/tls.c
+++ b/nnrpd/tls.c
@@ -391,9 +391,8 @@ set_cert_stuff(SSL_CTX * ctx, char *cert_file, char
*key_file)
struct stat buf;
if (cert_file != NULL) {
- if (SSL_CTX_use_certificate_file(ctx, cert_file,
- SSL_FILETYPE_PEM) <= 0) {
- syslog(L_ERROR, "unable to get certificate from '%s'",
cert_file);
+ if (SSL_CTX_use_certificate_chain_file(ctx, cert_file) <= 0) {
+ syslog(L_ERROR, "unable to get certificates from '%s'",
cert_file);
return (0);
}
if (key_file == NULL)
diff --git a/doc/pod/inn.conf.pod b/doc/pod/inn.conf.pod
index 85e0091b..d55af099 100644
--- a/doc/pod/inn.conf.pod
+++ b/doc/pod/inn.conf.pod
@@ -1126,9 +1126,25 @@ The path to a file containing the server
certificate to present to
TLS clients. This parameter is only used if B<nnrpd> is built with
TLS/SSL
support. The default value is I<pathetc>/cert.pem.
-Note that unlike Apache's I<SSLCertificateFile> directive, I<tlscertfile>
-should not contain a concatenation of certificates. Instead, if you have
-a certificate authority root certificate, set I<tlscafile> to its path.
+If you want to use a complete certificate chain, you can directly put
+it in I<tlscertfile> (like Apache's I<SSLCertificateFile> directive).
+Alternately, you can put a single certificate in I<tlscertfile> and use
+I<tlscafile> for additional certificates needed to complete the chain,
+like a separate authority root certificate.
+
+More concretly, when using S<Let's Encrypt> certificates, Certbot's
+files can be installed as follows:
+
+ tlscapath: <pathetc>
+ tlscafile: <pathetc>/chain.pem
+ tlscertfile: <pathetc>/cert.pem
+ tlskeyfile: <pathetc>/privkey.pem
+
+or:
+
+ tlscapath: <pathetc>
+ tlscertfile: <pathetc>/fullchain.pem
+ tlskeyfile: <pathetc>/privkey.pem
=item I<tlskeyfile>
diff --git a/doc/pod/news.pod b/doc/pod/news.pod
index 8bda82c9..8477940e 100644
--- a/doc/pod/news.pod
+++ b/doc/pod/news.pod
@@ -29,6 +29,12 @@ Thanks to Richard Kettlewell for the patch.
=item *
+The I<tlscertfile> parameter in F<inn.conf> now permits the use of
+a complete certificate chain, instead of necessarily having to use
+I<tlscafile> for additional certificates.
+
+=item *
+
The F<inn.conf> default value for I<tlsprotocols> no longer contains
TLS versions 1.0 and 1.1, which have been deprecated by S<RFC 8996>.
--
Julien ?LIE
??Cela n'a rien de remarquable. Il suffit d'appuyer sur la bonne touche
au bon moment et l'instrument joue tout seul.?? (J.-S. Bach)
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 134, Issue 1
*******************************************
