full-disclosure - Fw: Red Hat Linux end-of-life update and transition planning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: Fw: Red Hat Linux end-of-life update and transition planning 

On Tue, 04 Nov 2003 11:26:48 PST, Jeremiah Cornelius said:
> Just look at the "latest" sendmail available for Solaris 8.

It just so happens that I know the guy at Sun who's responsible for pushing
new Sendmail releases out the door, and a number of us involved with Sendmail
hassle him about it on a semi-regular basis.  No, he can't do anything about
that one - he's tried and he can't.

The problem is this whole "stability" thing - Sendmail 8.11->8.12 was a *huge*
change architecturally (see the whole setuid/setgid thing and 'clientmqueue'),
and Sun has very strict rules that *Thou Shalt Not Make Changes Like That
Mid-Release*. Verboten. Period. Sendmail 8.12 came out after the freeze
for Solaris 8, and therefore Sol 8 is stuck on the 8.11 train.

As it was, in Spring 2001, we were having some scheduling issues - John wanted
8.12 to make it out to '8.12.0' release before the freeze date for Solaris 9 so
he could include it and not have to wait till Solaris 10, but I was still
finding new and interesting ways to break the new queuegroups support on a
regular basis.  Fortunately, that code finally stabilized and it made the
freeze date - but it was a lot closer than anybody would have preferred.

(If you think Sun is bad, go check out IBM's sendmail - by default they
still ship in an open-relay configuration.  This is intentional, because
they have policies about upgrading releases *NOT* breaking user configs
if they can possibly be avoided.  To their credit, they *do* provide a
README.ANTISPAM file in an obvious location that gives step-by-steps on
how to fix it - but IBM refuses to possibly break your MTA if it depends
on being open-relay (which is the case on some corporate internal nets).

> So, don't complain about Fedora.  You don't like it - fix it Mr. Know-it-all.

Well.. that's assuming I *was* complaining about Fedora, and that I didn't like
it.  Which of course would explain why I'm typing this on a Fedora Core 0.95
box with a 2.6.0-test9-mm1 kernel (yes, I take frequent backups. :)

Of course, I have other boxes that I'd refuse to install Fedora on for
the exact same reasons why I consider Fedora a good choice for this one.

Fortunately for all concerned, RedHat seems to want to extricate both
it's RHEL series and Fedora from the 'neither fish nor fowl' mess that
the single RedHat series was turning into.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031104/8b453c75/attachment.bin