On Tue, Mar 04, 2003 at 02:25:38PM -0500, Hall Stevenson wrote: > At 02:04 PM 3/4/2003 -0500, stan wrote: > >On Tue, Mar 04, 2003 at 05:02:10PM +0000, Colin Watson wrote: > >> On Tue, Mar 04, 2003 at 11:32:34AM -0500, stan wrote: > >> > On Tue, Mar 04, 2003 at 06:15:02AM -0800, Marc Wilson wrote: > >> > > On Tue, Mar 04, 2003 at 08:37:02AM -0500, stan wrote: > >> > > > I did apt-get update and apt-get dist-upgrade on some of my > >> > > > machines running testing, and I was surprised to not [pull patched > >> > > > sendmail binaries, based upon the announcement of a vulnerability > >> > > > in it yesterday. > >> > > > >> > > Testing doesn't have security updates, and has never been advertised > >as > >> > > having security updates. Are you volunteering? > >> > > > >> > > <sigh> Someone else running testing in a production environment. > >> > > >> > And my choices are? > >> > > >> > As I see them. > >> > > >> > 1. Run unstable, and have a broken system more often than not. > >> > 2. Run stable and have 1970's versions of software/ > >> > >> That's a hopeless exaggeration; I run stable happily on my home server. > >> Anyway, if you run testing you need to manage the security yourself by > >> backporting patches. I don't believe anyone will ever have told you > >> otherwise. > >> > >> (It's not an ideal situation, true. However, it's reality.) > >> > >Not idael at all. As a matter of fact, it makes the whole concept of a > >testing release pretty useless. Look: > > > >13:58:15 up 249 days, 5:48, 1 user, load average: 0.35, 0.32, 0.36 > > > >[EMAIL PROTECTED]:~# cat /etc/debian_version > >testing/unstable > > > >This is a amchien providing production related process control information > >in a paper mill. The uptime would be longer, but I had a bug in my software > >that was generating zombies, and ahd to reboot to clean up that mess. > > > >That's certainly "stab;e"enough for em. And it gets apt-get dist-upgraded > >pretty much every weekday morning. > > > >So, we have a pretty "stable" release good enough "IMHO" for "real > >production" work. But we choose to cripple it by not providing security > >updtaes? > > > >Sounds like bad allocation of resources to me! > > Sounds like that machine could function without internet access and > therefore probably not need to be concerned about this sendmail > vulnerability. If it does need outside access, say for allowing you to > remotely reach it, does it need to run sendmail also ?? Couldn't a smaller, > simpler SMTP app work okay ??
Ture on both counts. > > I guess this particular issue with sendmail patches being available in > testing isn't your real complaint though... > Exaclty. My point is that the testing release ahs proven to be stable in a production environemnt (for me at least), and has, for example, much more current perl modules, than stable. This is required for our software to work. So, I would like to be able to beleove that a amchine running "testing" is at least reasoably secure. -- "They that would give up essential liberty for temporary safety deserve neither liberty nor safety." -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]