On Thu, Apr 10, 2025 at 10:24:49PM +0000, Bjoern A. Zeeb wrote: > On Thu, 10 Apr 2025, Ed Maste wrote: > > > On Wed, 19 Mar 2025 at 17:21, Jan Bramkamp <cr...@rlwinm.de> wrote: > > > > > > As long as it's "only" a compile-time option away for FreeBSD to enable > > > this flawed cipher I would like to have it compiled in by default so it > > > doesn't require installing SSH from ports to connect to some stupid old > > > router/switch/UPS/whatever over SSH. As long as it won't negotiate that > > > cipher with the default configuration that's safe enough for my needs. > > > > > > TL;DR: Please keep it enabled it at compile-time, but configured > > > disabled. FreeBSD shouldn't require recompiling the base system to > > > connect to older embedded devices. > > > > It's a compile-time option in 9.9 and earlier. As of 10.0 the > > configure infrastructure has been removed but the source hasn't yet > > been deleted. I expect that will happen soon though. > > > > We'll keep DSA available, at least in stable branches, as long as it's > > reasonably convenient and safe to do so, but won't patch it back in > > once the source is removed. > > Is there any chance to keep an openssh (client) port (possibly with known > security risks)?
It seems like it would be reasonable to keep a copy of the 9.8 client around more or less indefinitely. Ideally tracking what ever fixes the longest lived, open Linux LTS is applying. Similarly we have an openssl-unsafe for connecting to old gear. I may be mistaken, but I believe security/putty's upstream takes the maximum compatibility approach. If I'm correct, people may want to switch to it for these needs. For a security/openssh98 or similar we might want to do something similar to the change I'm proposing in CheriBSD-ports where we want to package software with known vulnerabilities (e.g., webp with BLASTPASS) for the purpose of making security demos but make an concerted effort to make it hard to install. I probably wouldn't go as far as the linked USES=vulnerable implementation does, but perhaps it will serve as inspiration. A USES=obsolete:crypto that adds a known prefix and a knob to disable all such ports seems pretty plausible. https://github.com/CTSRD-CHERI/cheribsd-ports/pull/201/commits/3fdf8922f3f416770b265fd35f05c680ed6e00c2 -- Brooks
