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: Build system changes (Russ Allbery)
2. Re: Test Git repository for INN (Russ Allbery)
3. Re: NNPS / TCP port 433 (Russ Allbery)
4. Re: Removing obsolete control messages in INN 2.7 (Russ Allbery)
5. Re: innupgrade for old shared libraries? (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Tue, 23 Nov 2021 15:02:31 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Build system changes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> I think we should wait for the new build system for the 2.7.0 release
> (if of course you have time to make it work). I had in mind a 2.6.5
> last release for the 2.6 branch in the first semester of 2022, and 2.7.0
> a few weeks later.
> I would also like to add Cancel-Lock support in 2.7.0 (but of course it
> can come later).
Ah, yes, that sounds great.
I made some progress on this but then I got distracted by work and other
things, so I haven't been able to get to it for the past two weeks. I am
going to pick it up again, and should have time in the next month and a
half to finish it. (Hopefully sooner than that, of course.)
> - Remove or fix installation of signcontrol #28
> => couldn't signcontrol just be moved to the "contrib" directory then? It
> will no longer be installed by default and overwritten during a "make
> update"
I see that you did this and I agree with that, but also we could just drop
it from the INN distribution entirely. It's available via the pgpcontrol
distribution also from ISC if anyone wants it, and I think the number of
INN users who need to issue control messages is very small. The number
who both need that and who benefit from having it included in INN may be
zero.
--
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: Tue, 23 Nov 2021 15:13:02 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Test Git repository for INN
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> FYI, I've done a first pass of clean up:
> - merge redundant labels into one (for instance "bug"/"T: defect",
> "enhancement"/"T: enhancement", "wontfix"/"R: wontfix",
> "documentation"/"C: doc");
> - remove labels ("R: fixed" because it is implied by a closed ticket
> without the "wontfix" or "invalid" tag, unused "T: task");
> - add "RFC compliance" to easily grab all the issues and PR related to
> NNTP standards and the format of Usenet articles (we previously had it
> as a keyword in Trac, and an associated report for it).
> I hope it is a bit clearer now.
This looks great, thank you!
Probably over the holidays I'm going to do some cleanup of my server that
was hosting Trac and the Subversion repository. Is there anything left
there that still needs to be moved before it can be safely shut down?
(I'll keep an archive just in case.)
--
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: Tue, 23 Nov 2021 15:21:39 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: NNPS / TCP port 433
Message-ID: <[email protected]>
Content-Type: text/plain
Grant Taylor <[email protected]> writes:
> The powers that be ~> industry seems to keep waffling back and forth on
> explicit vs implicit port encryption. As I understand it, it started
> with separate implicit ports (a port was either encrypted exclusive or
> not) because STARTTLS was not yet a thing. Then it went to combined
> explicit ports (because you explicitly stated if you wanted encryption).
> And now we seem to be going back to separate implicit ports in an
> attempt to avoid downgrade attacks on explicit ports.
The tension is between folks with a security focus and folks who were
worried about running out of assigned ports if every protocol got two port
assignments. Currently, the security perspective is in ascendence again,
in part because implementing STARTTLS securely turns out to be
surprisingly difficult. See, for example:
https://www.usenix.org/conference/usenixsecurity21/presentation/poddebniak
(And indeed INN may well be vulnerable to many of those problems. I
haven't checked and the researchers limited their investigation primarily
to email.)
> I would expect that the NNSP port 433 could be explicit encrypted via
> STARTTLS much like NNTP port 119.
It certainly could be, although I don't know how many implementations
support this. (innd does not.)
> I'm of the mind that we as the NNTP using community make a server rule
> -- a la. "house rule" -- that the NNSP port 433 be implicitly TLS
> protected much like NNTPS port 563 is. -- I say this because the
> current industry best practices are to use implicit encryption. So if
> the NNSP port 433 is largely unused and we want to start making use of
> it, why not impose implicit encryption.
Unfortunately, there is quite substantial existing use of 433 unencrypted
and innd among others doesn't support TLS on that port right now. So I
think there's some work ahead of us before we could get to that point.
The flag day of switching port 433 from unencrypted to encrypted is a bit
tricky to navigate.
--
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: 4
Date: Tue, 23 Nov 2021 15:27:05 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Removing obsolete control messages in INN 2.7
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> I suggest a bit of clean up for obsolete control messages in INN 2.7:
> - remove control/modules/{sendsys,senduuname,version}.pl;
> - remove the "doifarg" keyword from controlchan and control.ctl
> documentation (it is only used for these 3 kinds of control messages);
> - but keep the recognition of the sendsys, senduuname and version control
> messages in inncheck and scanlogs (because they are still referenced in
> control.ctl) as well as filter_innd.py in the example of a regexp for
> obsolete control articles.
Sounds good to me. I can't imagine us ever wanting to support those
control messages.
> There is a common man page for send-ihave (ihave control messages) and
> send-nntp (usual articles). I suggest to:
> - remove the send-nntp script, and mention in NEWS that nntpsend or
> innfeed should be used instead;
I agree, I don't understand why that script exists when nntpsend exists.
nntpsend feels like a more sophisticated version of send-nntp.
> - keep the send-ihave script as well as control/modules/{ihave,sendme}.pl
> as the ihave and sendme control messages are not obsolete. Though I
> would be half-tempted to also drop them... Even the documentation says
> "the author of this manpage is unsure as to how [send-ihave] actually
> works or used to work". Indeed, it is not clear how ihave batch files are
> generated... (no examples)
My recollection is that this stuff is all intended for UUCP feeds. The
idea is that you tell your UUCP peers what articles you have available via
ihave control messages, you respond with a sendme control message for the
articles that you want, and the sendme controlchan module creates a batch
file to send to that site via UUCP.
I have no idea if any UUCP site is still using ihave/sendme control
messages to control the feed, rather than simply sending everything.
Obviously, this mechanism was more important when UUCP was done via
long-distance telephone calls and modems, where you wanted to minimize the
amount of time the line had to stay connected.
--
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: 5
Date: Tue, 23 Nov 2021 15:34:52 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: innupgrade for old shared libraries?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Shared libraries installed by previous INN versions tend to accumulate
> in the pathlib directory. Shouldn't we remove old ones? (keeping only
> the previous one for instance)
> Or should we expect other programs installed on the system, outside INN,
> to go on using old versions of our libraries and therefore we should
> leave them?
The reason to keep old versions would be to support a downgrade, which
right now is theoretically possible by renaming the .OLD files back and
changing the SONAME symlink to point to the previous version of the
library. Keeping more than one old version with the current SONAME is
probably pointless since we don't keep more than one old binary.
Old SONAMEs could in theory be used by other files on the system, so it's
a question of how safe we want to be in innupgrade. I might err on the
side of keeping them, I guess, since we don't know for certain that
they're no longer needed. But I wouldn't object strongly to removing them
either.
--
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 135, Issue 6
*******************************************
