bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtelnet: Make encryption decls compatible with C23.


From: Collin Funk
Subject: Re: libtelnet: Make encryption decls compatible with C23.
Date: Sun, 12 May 2024 00:43:18 -0700
User-agent: Mozilla Thunderbird

Hi Simon,

On 5/12/24 12:20 AM, Simon Josefsson wrote:
> I enabled c23 build for gcc-14.1 now, and it passes:
> 
> https://gitlab.com/gsasl/inetutils/-/jobs/6830704753

Nice, Thanks!

> I see we weren't using the warnings module from gnulib at all.  I recall
> we were worried that if we are going to start fixing compiler warnings
> we'll make the code even more different than other BSD-derived
> implementations.  On the other hand, I don't see why fixing valid
> compiler warnings is a bad thing.  This project have been conservative
> about adapting to modern stuff.  I wish we could test it on some ancient
> systems in a sustainable manner.

Yeah, I looked at some of the BSD's source trees and their telnet's
look equally ancient with small variations between them. This patch
should have gotten things closer to theirs at least.

>From what I can tell the configure.ac script could use some work. Many
FIXME's, the --with-{kb4,kb5,shishi} handling I mentioned in the other
mail, and some stuff that is already done in Gnulib.

Atleast that stuff doesn't have to be compared to the BSDs. Less to
worry about making changes there. :)

>> There are still some old K&R declarations and declarations missing
>> prototypes for Kerberos 4 stuff. I'm leaving them unchanged since I
>> have no way of testing them.
> 
> Yeah, I think people have been trying to kill off Kerberos 4 and have
> mostly succeeded.  However I think for InetUtils there is some value in
> having a forever-maintained telnet etc with Kerberos 4 support.  All
> these tools are basically mostly insecure anyway, so the protocol
> security argument isn't applicable here.  Testability is a real concern
> though -- we can't maintain code we can't test.  I wonder what the last
> environment Kerberos 4 was working in was -- or if we reanimate it in
> modern environments...  a bit further down on the priority list though.

That sounds like an interesting idea. It would be nice to have an
implementation that still supports legacy stuff. I don't have much
experience with Kerberos though sadly. :(

Collin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]