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: INN indentation (Julien ?LIE)
2. Documentation for the setting of a UUCP feed with send-uucp
(Julien ?LIE)
3. Re: Openssl 3.0.0 (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Sat, 16 Oct 2021 14:24:50 +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,
>> 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.
>
> If we rename clibrary.h to portable/system.h, it will match the naming
> convention in rra-c-util where it largely comes from and will also avoid
> this problem.
I've had a look but wanted to be sure of what to do.
It seems like that all inclusions of "clibrary.h", or of both
"clibrary.h" and "config.h", should be changed to only one inclusion of
"portable/system.h".
And "clibrary.h" moved to "portable/system.h".
"portable/system.h" in rra-c-util uses:
#include <config.h>
"clibrary.h" uses:
#include "config.h"
Shouldn't the syntax with quotes be used? ("config.h" is not a system
header)
In HACKING:
"clibrary.h" does also include "config.h", but it's somewhat poor form
to rely on this; it's better to explicitly list the header
dependencies for the benefit of someone else reading the code.
:)
We can get rid of that paragraph then.
Also, from TODO:
* The include files necessary to use libinn, libstorage, and other
libraries should be installed in a suitable directory so that other
programs can link against them. All such include files should be under
include/inn and included with <inn/header.h>. All such include files
should only depend on other inn/* header files and not on, e.g.,
config.h. All such include files should be careful about namespace to
avoid conflicts with other include files used by applications.
Isn't it already done?
All headers in include/inn only include headers also in include/inn,
which never include "config.h".
I think the namespace is ok (I'm not aware of any complaints about it).
Unless I am missing something, there isn't any work to do for that task,
is it?
Finally, we already have "inn/system.h", with a few configure-time
options set (like INN_HAVE_INET6 or INN_HAVE__BOOL) needed by INN headers.
It is notably included by "inn/defines.h" which only include 3 header
files. Time has come to get rid of "inn/defines.h" at the same time,
and just include the necessary headers instead of it.
We would then have "portable/system.h" (the current "clibrary.h" which
includes "config.h") along with "inn/system.h" (which does not include
"config.h" like all headers in "inn").
>> 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
>
> Oh, that will be very nice once that's released. That's one of the
> formatting decisions that always bugged me.
I also see that the next clang-format release (13) will permit aligning
array of structs with for instance:
AlignArrayOfStructures: Right
struct test demo[] =
{
{56, 23, "hello"},
{-1, 93463, "world"},
{ 7, 5, "!!"}
};
The current formatting breaks them badly...
I believe this new style option will permit removing a few /*
clang-format off */ comments in the code.
> I'd be good to go with what's in rra-c-util right now, which is the one I
> sent earlier plus the enum change, and I think there was another vote for
> whatever as long as it's automated.
Adopted!
--
Julien ?LIE
??? Ne te r?jouis pas trop vite? Gn?thi seauton?!
? ?a veut dire quoi ?a??
? Je ne sais pas?; c'est du grec.?? (Oursenplus)
------------------------------
Message: 2
Date: Sun, 17 Oct 2021 08:58:21 +0200
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Documentation for the setting of a UUCP feed with send-uucp
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all,
Just sharing the notes I've taken during my recent migration of my news
server to another hardware. I have been running a (very little) UUCP
feed with Jeffrey for years, just for the sake of testing. It works
fine, without any problem.
In case it could help other news admins, or if you have any addition,
this is what the send-uucp documentation now contains:
SETTING UP UUCP FEEDS
Here are the steps to follow to set up a UUCP feed over SSH between two
news servers, using the UUCP implementation available in Debian as the
"uucp" package. The mechanisms described below should be transposed if
you use another UUCP implementation. (And if you do, please inform the
INN maintainers about how to set up a feed with another UUCP
implementation, so that it can be added to this documentation.)
1. First of all, make sure rnews is correctly installed setuid "news",
owned by group "uucp", and mode 4550. This will allow the UUCP
subsystem to run rnews to process UUCP batches of news articles.
The "configure" flag --enable-uucp-rnews takes care of it when
installing INN. Otherwise, you'll have to manually change the
permissions on rnews.
2. Install the "uucp" package. It will notably provide uucico(8) and
uux(1).
3. Configure in /etc/uucp/Poll the remote news servers to poll,
and the
hours during which they are to be polled. For instance, if you
send
to "news.server.to.feed" UUCP batches every 4 hours, you can use:
schedule news.server.to.feed 00
poll news.server.to.feed 00 04 08 12 16 20
If sending is hourly, just list all the hours.
4. Configure in /etc/uucp/call the credentials (usernames and
passwords) to use when authenticating against remote news servers,
one per line. For instance:
news.server.to.feed login password
5. Configure in /etc/uucp/config the UUCP name of the local news
server. For instance:
nodename my.news.server
6. Check that /etc/uucp/expire fits your needs as for the number of
days batches are retained as well as the configuration of daily
reports. Default values are normally fine, though you may want to
receive a daily report only if unusual things happen (and in that
case, just set $important_only to 1).
7. Configure in /etc/uucp/passwd the credentials (usernames and
passwords separated by a tabulation) remote news servers use when
authenticating against the local news server, one per line. For
instance:
login<TAB>password
8. Configure in /etc/uucp/sys how remote news servers connect to the
local news server. A typical entry to set an SSH connection is the
following one where *pathbin* should be changed to the real path to
rnews:
system news.server.to.feed
call-login *
call-password *
commands <pathbin>/rnews
time any
chat "" \d\d\r\c ogin: \d\L word: \P
chat-timeout 120
protocol i
port ssh.news.server.to.feed
9. Configure in /etc/uucp/port how to connect to remote news servers.
A typical entry to set an SSH connection using a private key is:
port ssh.news.server.to.feed
type pipe
command /usr/bin/ssh -a -x -q -i <key_file> -l uucp
news.server.to.feed
reliable true
protocol etyig
where *key_file* is the private key to use for the SSH connection,
like for instance /var/spool/uucp/.ssh/id_private_key.
10. Make sure the administrators of remote news servers have added the
public key related to id_private_key for connections to the "uucp"
user of the remote news servers.
11. Supposing the home directory of the "uucp" user is /var/spool/uucp,
you need to configure the SSH keys in the .ssh subdirectory.
First,
add the public keys of all remote news servers in authorized_keys.
A typical entry is:
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/sbin/uucico
-l",from="news.server.to.feed" ssh-rsa xxxyyyzzz [email protected]
This ensures the SSH connection will not be used for another goal
than exchanging UUCP batches.
12. Make sure id_private_key is correctly present, as set in
/etc/uucp/port, and only readable by the "uucp" user.
13. Manually run as the "uucp" user the command set in
/etc/uucp/port so
as to create the known_hosts file so as to make sure the SSH
setting
is fine.
/usr/bin/ssh -a -x -q -i <key_file> -l uucp news.server.to.feed
14. Parameter the feed to send to the remote servers. A typical entry
in newsfeeds to generate batches in *pathoutgoing* is:
news.server.to.feed/pathname:*:Tf,Wnb,B4096/1024:
15. Set up the compression method, batch sizes and when to generate
them
in send-uucp.cf located in *pathetc*, as described earlier in this
documentation.
news.server.to.feed bzip2 1048576 3,7,11,15,19,23
16. Check that send-uucp is started hourly in crontab by the "news"
user. For instance in /etc/cron.d/inn2:
52 * * * * news <pathbin>/send-uucp
17. Check that UUCP programs are automatically started in crontab
(usually, uudemon.hr is called hourly in /etc/cron.d/uucp to poll
remote news servers, and uudemon.day daily in
/etc/cron.daily/uucp).
It can be useful to set up a different launch time than your remote
servers. For instance, it you connect every hour at minute 10, a
remote peer may do the same at minute 40. This way, you will
exchange articles more frequently.
18. Check the logs in /var/log/uucp to ensure everything works fine,
both polling and sending.
You will see that send-uucp prepares rnews batches named like
D.0I8Y, which are then sent by uucico. At the same time, uucico
takes available batches from the remote sites, which are then
locally injected by uuxqt through rnews.
That's all!
--
Julien ?LIE
??C'est une for?t vierge o? la main de l'homme n'a jamais mis le pied.??
------------------------------
Message: 3
Date: Sun, 17 Oct 2021 13:45:17 +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 all,
> tls.c: In function 'eckey_from_name':
> tls.c:473:5: warning: 'EC_KEY_new_by_curve_name' is deprecated: Since
> OpenSSL 3.0 [-Wdeprecated-declarations]
> ?? 473 |???? eckey = EC_KEY_new_by_curve_name(builtin_curves[i].nid);
> ?????? |???? ^~~~~
FYI, all the mechanisms to select curves have changed.
I've managed to find the right function to use:
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_groups.html
We just need now a straight-forward call like:
SSL_CTX_set1_groups_list(CTX, "X25519");
intead of all the machinery to find out the ID of the curve name.
The new OpenSSL 3.0.0 is great!
I hope it will now remain stable because we have #if for 0.9.8, 0.9.8d,
1.0.2, 1.1.0, 1.1.1 and 3.0.0 versions.
I've checked that if the provided curve does not exist, nnrpd negotiates
the default one. Otherwise, it takes it into account.
[tlseccurve: "X25519" in inn.conf]
Server Temp Key: X25519, 253 bits
[tlseccurve: "P-256" in inn.conf]
Server Temp Key: ECDH, P-256, 256 bits
=> We now fully support the new OpenSSL 3.0.0 API.
--- a/nnrpd/tls.c
+++ b/nnrpd/tls.c
@@ -440,10 +440,13 @@ set_cert_stuff(SSL_CTX * ctx, char *cert_file,
char *key_file)
}
-#ifdef HAVE_OPENSSL_ECC
+#if defined(HAVE_OPENSSL_ECC) && OPENSSL_VERSION_NUMBER < 0x01010100fL
/*
** Provide an ECKEY from a curve name.
** Accepts a NULL pointer as the name.
+** The EC_KEY_new_ey_curve_name() function has been deprecated in
+** OpenSSL 3.0.0; another mechanism to select groups has been available
+** since OpenSSL 1.1.1.
**
** Returns the key, or NULL on error.
*/
@@ -512,9 +515,6 @@ tls_init_serverengine(int verifydepth, int askcert,
int requirecert,
struct stat buf;
size_t tls_protos = 0;
size_t i;
-#ifdef HAVE_OPENSSL_ECC
- EC_KEY *eckey;
-#endif
if (tls_serverengine)
return (0); /* Already running. */
@@ -593,9 +593,18 @@ tls_init_serverengine(int verifydepth, int askcert,
int requirecert,
/* We set a curve here by name if provided
* or we use OpenSSL (>= 1.0.2) auto-selection
* or we default to NIST P-256. */
- eckey = eckey_from_name(tls_ec_curve);
- if (eckey != NULL) {
- SSL_CTX_set_tmp_ecdh(CTX, eckey);
+ if (tls_ec_curve != NULL) {
+# if OPENSSL_VERSION_NUMBER < 0x01010100fL
+ /* A new mechanism to select groups has been introduced
+ * in OpenSSL 1.1.1. */
+ EC_KEY *eckey;
+ eckey = eckey_from_name(tls_ec_curve);
+ if (eckey != NULL) {
+ SSL_CTX_set_tmp_ecdh(CTX, eckey);
+ }
+# else
+ SSL_CTX_set1_groups_list(CTX, tls_ec_curve);
+# endif
} else {
# if OPENSSL_VERSION_NUMBER < 0x010100000L
# if OPENSSL_VERSION_NUMBER >= 0x01000200fL
--
Julien ?LIE
??C'est une for?t vierge o? la main de l'homme n'a jamais mis le pied.??
------------------------------
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 5
*******************************************
