Bad news: Exim hole was going to be patched on Xmas Day. Good news: Keyword 'was' An information-leaking security hole in widely used email agent Exim – scheduled for repair on Christmas Day – may now be publicly patched earlier, possibly as soon as Friday. System administrators were stunned by the suggestion that a patch for the vulnerability would be released on December 25 when pretty much everyone …
Whilst I understand the need of making sure an update will not break existing functionality on a server I have never had a problem updating a debian based system. The (old)stable version of course.
As long as you make sure you keep your system sane and, for example, if you install custom software, make sure it's installed in a different location and if the distro has the software as a package then possibly un-install it. Say if you have your own customised bugzilla installation, then do not stupidly keep the distribution provided bugzilla package lying around and just install your own version over the system installed one. Then your shiny new bugzilla will break with the next system update (actual real life case of a (badly managed) server I took over early in a job many years ago).
On many systems I have enabled the unattended-upgrades package to update on a daily basis and I quite trust debian (old)stable updates (and ubuntu lts if you must) to happen without problems and it always has. I believe that the low chance of an update breaking something weighs up against having security patches installed as soon as possible in an automated way. In my experience people who disagree with it strongest also unfortunately have the least understanding of the subject matter.
If you want to make extra sure then only enable the security patches to be updated automatically, and leave less important updates to be done by hand.
You protect yourself against "breakage" in other ways, redundancy etc. Not by holding back on security updates.
debian user for 18 years(for personal stuff, work stuff is mostly ubuntu, and before was centos or RHEL), though I still do not trust unattended updates, even on stable(haven't run testing I think since 2003,never ran unstable). I don't recall issues of the top of my head, but I still prefer the peace of mind of knowing that the change is going through.
To my knowledge none of my personal systems have ever been compromised(I have run internet connected debian systems since 1998 and Slackware before that - debian powers my personal email server, DNSs, etc), and on the systems of my employers the only ones that I was involved with that had been compromised have been ones that I was not responsible for(on that note the number is 3 or 4 compromises over the past 16 years).
Perhaps too paranoid, or not paranoid enough not sure.
"System administrators were stunned by the suggestion that a patch for the vulnerability would be released on December 25 when pretty much everyone working in IT will have the day off."
Do these people even realize what kind of software they're using? Open source, almost per definition, is a community effort and has never really bothered itself too much with commercial interests. Heck, I can even take this further: the Holiday season, or basically any day off is per definition a period where a lot of heroic geeks get a lot of work done on their beloved projects. Have we already sunk so deep that we totally forgot and ignore the very basics of open source and how it all started?
Boohoo, a MTA project which you can pick up for free and which also gets updated from time to time (also fully free of charge!) decides to release during a vacation. How inconsiderate! If only we had a way to log onto our servers from a distance and perform the update from there. Oh wait, we have. It's called SSH!
I think some people should think twice before complaining about things like these and stop to think how much they're actually contributing to these projects themselves for doing what they do. If you want a cozy release date which never conflicts with your precious vacation then please consider using a commercial product such as Microsoft Exchange. It'll cost you some, but at least you'll have solid guarantees that whenever you're celebrating Christmas so are the programmers. So no fear of any updates getting released at inconvenient times.
Sorry for the rant, but I think some people should seriously stop taking everything within open source projects for granted.
It appears that one distro hasn't responded and the release of this update will be Christmas morning.
This isn't a feature release: it's a time-sensitive security release which will disclose a security vulnerability upon publication.
It isn't "your precious vacation", it's a pan-global public holiday where many people are travelling to spend time with family and businesses are closed.
So yes, questioning and clarifying the case for release on that particular date doesn't seem so unreasonable.
Many open source projects are contributed to by the organisations using them.
> Have we already sunk so deep that we totally forgot and ignore the very basics of open source and how it all started?
Apparently so.
Exim was written by Philip Hazel for the University of Cambridge, which will be closed at the time of release of this update.
Bug release management isn't easy.
"This isn't a feature release: it's a time-sensitive security release which will disclose a security vulnerability upon publication."
Minor security release. It's not a remote exploit of some sort, but an information disclosure issue.
But even so: the same story applies. Do note that the complainers didn't do so because of the timespan (I can respect that people want to get the fix ASAP) but merely because it just so happened to be on a Holiday.
SSH is your friend here IMO.
I think this has to be one of the dumbest things I've ever seen and it's making me seriously doubt the wisdom of using Exim anymore.
Releasing security updates when most sysadmins, network admins, change control board and service desk staff are on holiday just opens the door for hackers to exploit the bug for a week before anyone can do anything about it. It may be an open source project, but the software is run by professional institutions who have change management processes and testing processes in place that they have to go through before deploying a new version. It isn't a case of SSH in, compile up the new version with all the bells and whistles and stick it in place. There are plugins and boundary cases that'll need testing against the new version so unless we want to give up Christmas Day and Boxing Day we have to just live with the fact that Exim may get hacked or turn off the mail system.
Microsoft release their patches on a Tuesday which shows they've thought about this and realised when would be the best time to release a patch so that the sys admins have the best opportunity to test and deploy in the shortest timeframe. Only when they see live exploits of a bug do they rush out a patch.
Unfortunately Exim now seems to be aimed at the hobbyist mail administrator who is available on Christmas Day and not at the large institution who would struggle to get enough of the IT team to work Christmas Day to roll out an upgrade.
http://seclists.org/oss-sec/2016/q4/744
As at least one major distro isn't ready yet, we'll keep our initial schedule and release the fixed versions on Dec, 25th, 10:00 UTC.
As a self employed person I regularly ran updates especially on Fridays. I'd have the whole weekend to fix a potential problem (and rake in more billable hours), though normally that didn't really happen. In addition problems would not affect the users much or at all, because they'd be off in the weekend.
But being salaried and exempt (US terminology for no overtime) nowadays I too see the sense of running updates early in the week and early enough in the day. Working overtime when you don't get compensated for that is just stealing from your own wallet. But that's a whole other can of worms.
"As a self employed person I regularly ran updates especially on Fridays. I'd have the whole weekend to fix a potential problem...
But being salaried and exempt (US terminology for no overtime) nowadays I too see the sense of running updates early in the week and early enough in the day."
BTDT in both scenarios, but it was more a matter of when I/we could get the system(s) than employment status.
Production scenario: you can only book system downtime on a Friday or Saturday afternoon, but can work into the night if you have problems.
Test & Development scenario involving multiple teams: here you are not simply applying an upgrade which requires a reboot, you are implicitly including a test of shutdown and startup procedures at both the OS and application level.
In the latter case, it makes a lot more sense to do this during the day when your development and test teams and DBAs are around to sort out their bits in the event that something breaks. In my last position in this environment, any upgrade which required a reboot would be scheduled for late morning (but not a Friday), and we'd have the support of the various teams available for the whole afternoon. External support, if needed, could be invoked inside the normal 9-5 (or 8-6) cover without incurring out of hours costs.
Believe me, we're sorry for the date. It is Chrismas day. I'm not sure, if it is an almost pan-world
holiday (I have no idea about the holidays in other countries, religions, regions.)
Greetings from Germany, where I'm celebrating with my friends and family. Today and tomorrow. (Except for the the time between about 9am and 11am UTC, when you'll find me on IRC)
io_uring is getting more capable, and PREEMPT_RT is going mainstream The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
