Should Open Source Software Expire? 565
Daffy writes "Jon Lasser at SecurityFocus has an idea for combating the tendancy most sysadmins have to leave old versions of software running long after they're known to have security holes. He proposes implanting time codes into all open source networking and security software that cause it to "expire" like a Blade Runner replicant when it reaches a certain age, forcing an update."
Bad idea (Score:4, Insightful)
Re:Bad idea (Score:3, Insightful)
Re:Bad idea (Score:3, Interesting)
Then the user/admin can decide what expire should do: maintain a list of expired software (maybe with different warning levels, from "obsoleted by a new version" to "security hole, patch now"), mail him, shutdown the service, update automatically (shiver), whatever. The admin can also decide how often 'expire' should run, or, in case of a static ip, maybe even allow the 'expire-server' to contact his machine.
The method of comparing against a list on the net (or maybe on some update media) is better than expiring after a preset time. And selferasing software is simply nonsense. imagine software development is discontinued, or you just can't reach the net, and thus not update anyway, or an admin is on holidays. He'd probably prefer the firewall up and running, even if outdated, than having no firewall at all.
Also maybe other projects depend on a certain piece of software. Forcing to switch versions at some preset date isn't helpfull at all in that case. There are so many possible reasons why someone might want to hold onto an old app a little longer, maybe even for 20-30 years. This "force to upgrade" practice could come right out of microsofts book of marketing, but it doesn't make sense for open source software.
Maybe he should've written that piece 2 days ago
Bad security too (Score:4, Insightful)
Case in point was when someone decided to install the latest version of sendmail with the usual horde of bugs over a version of QMail.
The biggest problem when someone downloads new versions of software however is that they are typically installed with the wrong defaults or insecure defaults, or they blow away parts of the security profile to allow them to be installed.
The type of system build I would typically use probably has less than 10% of the typical Linux distribution. The eliminated portions are gone for good reason - if the feature isn't needed it goes. So having someone reinstall the components I have removed is a major problem.
The other issue to beware of is any form of automated update that does not have very stringent controls to validate the authenticity of the replacement code. Otherwise the update mechanism becomes a potential backdoor. Don't believe that downloading the latest source via FTP is the solution either. All I need to do is poinson your DNS and you are downloading the version with my trojan.
What is needed is some form of software resource database that keeps track of the version of each software package installed, differences between that and the standard installation etc etc. Ideally there would be integration with something like tripwire. The ideal would be to have the type of mechanism that the .NET security framework has in which you can require software components to be signed by an authorised source in order to run.
Building and maintaing such a system would be very tedious and expensive to do well however, if it isn't done well it is no good.
The sell by date proposal is simply clueless, the guy does not appear to have much real security experience, he is just repeating the dogma.
Re:Bad idea (Score:2, Insightful)
Careful sysadmins don't just set the Automatic Upgrade swith to "Full Throttle", they evaluate stuff before deploying it.
Morel
Re:Bad idea (Score:2)
EXACTLY.
You're taking the "Free" out of "Free software".
Only evil proprietary companies force you to do stuff, right?
Re:Bad idea (Score:5, Insightful)
I think it's a bad idea to actually _disable_ a running program, because doing so can cause problems that are not necessarily immediately traceable back to the disabled program. Instead, the program should raise some sort of persistent alert, via email, logfiles, or whatever, at some interval, alerting the administrator that there is an out of date program running.
Re:Bad idea (Score:3, Insightful)
I agree that putting in arbitrary time locks is not a good approach to making open software secure.
Fundamentally, the best approach is to encourage sysadmins and those responsible for hiring sysadmins to take security as a serious matter.
Practically, I'd say a better approach is to have open source security scanning software that sysadmins can use to easily diagnose whether their systems and applications have a potential security problem. The raw ingredients for something like this are already out there, but I'm not sure if they are conveniently packaged.
It's one thing to see CERT and CIAC vulnerability postings and mull over whether some random application might occasionally open up a weird network port and be vulnerable to a BO, but that requires some investment of time.
A service that allows you to download and run a trusted, signed test application for each of the vulnerabilities you see on Bugtraq would be a real time saver for most sysadmins, who have quite a lot to do already.
Re:Bad idea (Score:2)
Re:Bad idea (Score:3, Interesting)
_____
|--` ()_)
| ()__)
| ()___)
|-. ()__)
\ \
|_)
Oh yea, THAT'S a great idea... (Score:4, Insightful)
You can't pick an arbitrary point in time when software is "too old", or "known to have security holes!" If you could do the latter, you'd just fix the security holes...!
I disagree (Score:4, Funny)
Sure I can. How about "right now."
Re:I disagree (Score:2)
Erm, no (Score:5, Insightful)
I agree that software should assist admins in keeping it uptodate, but honestly, legitimate users shouldn't be affected if an admin is incompetant or lazy.
Re:Erm, no (Score:2, Insightful)
At least this would remove any burdensome mandatory nature from the effect while still satisffying the perceived demand.
Re:Erm, no (Score:4, Insightful)
So are things like maintainability, usability and so on.
Security is a kind of risk, and everyone accepts a certain amount of risk. I *could* insure my car to a $50 deductable and let the insurance co. take all the risk beyond that, but that would cost me $500/month. Instead I assume $500 worth of risk and I pay only $100 month.
You're absolutely right that there are other concerns, but in some organizations the costs associated with a specially locked room, time/money/effort maintaining boxes is more cost than percieved risk that some internal user in a 50 person company may decide to try to hack sendmail 8.9.
Re: Erm, consider the necessity... (Score:3, Insightful)
Some people consider this a Very Bad Idea. I understand the down side (namely, if someone gets past the firewall, game over), but look at it this way - Literally every day, someone discovers a new security vulnerability. Now, I can either spend a few hours every day researching these and deciding if they apply to any of my machines, or I can just skim for the really bad ones and those affecting the very few programs my firewall runs (Basically just a 2.4.x Linux kernel and an sshd... Fairly easy to watch for updates).
Also, you may want to consider the type of network involved... I refer to a home LAN consisting of a few Linux boxen, a W2K box (face it, through no fault of open source, many webpages have far too many IE-isms to work properly in Mozilla/Konqueror/Opera/whatever), and a networked printer. My only "users", (aside from myself, the SO and a few friends), only surf the web, check email,and occasionally ask me to install a game for them. Aside from my file server, I could completely reinstall any box I have in an hour. I suspect many
Incidentally, I do recommend (and use) *one* internal security measure, more of a CYA than actual "security"... I keep *everything* beyond base OS installations in a mirrored encrypted filesystem my file server. If ever Big Bro comes knocking and rounds up my PCs, they can ask nicely for the passwords I just happen to have forgotten, but good luck otherwise.
Or not (Score:4, Insightful)
Because (Score:3, Insightful)
Because it would be foolish for a SysAdmin to load fixes/patches without testing them first. There have been occasions in which a patch will break something else that the application does. (Checkpoint FW-1 patches are notorious for this) There have been patches that are issued and then recalled because of problems with the patch itself. Who would want to put production systems at risk by having critical code installed automatically before the SysAdmin would have the chance to test it.
If someone wants to implement something like this, all I can say is that I hope you take regular back-ups and validate your tapes.
You will need them.
I think.... (Score:4, Interesting)
Huh? (Score:2)
I would think that it should be optional (Score:2)
Now, as a programmer, I may not want to add changes to an older version that I am not working on anymore, so I am within my rights to say, "If you want that additional functionality, you have two choices. Upgrade, or do it yourself."
Again, options.
EFGearman
--
Medical companies would have a cow... (Score:2, Interesting)
Every time medical company (i.e. a drug manufacturer or a medical device manufacturer) implements new software, even if it's just an upgrade to, say, their call handling software for their tech support department, a validation process has to be performed. This includes:
a risk analysis to determine HOW much validation has to be done according to how much harm can be done (and yes, there is harm even in the tech support software)
creating a test plan
testing the software to make sure it works to intended use
completing validation paperwork documenting that the testing was actually done
creating a validation report and test summary detailing your findings
keeping all these records on file for a long time so the FDA does not land on you like a hungry 2-year-old on a twinkie
If you're a medical company and you DON'T plan on doing all this, you can expect a write-up (which must be responded to) at your next FDA audit. If you don't respond to the write-up, hire a lawyer cause the FDA is gonna shut you down. This is a large part of why we've kept around some of the DOS applications we use--no one here has the extra time to do all the validation on new software.
Expiration. (Score:5, Interesting)
Interesting idea, but the assumption that people will only want to run newer software seems a bit flawed to me. To quote the genius Anonymous, "Assumption is the mother of all fuck-ups."
Last night I installed RH 6.2 on an old P75 I picked up somewhere, and ended up installing an old version of openssh on it (along with a bunch of other older stuff) to save disk space. Under this scheme, I wouldn't be able to; despite the fact that the machine is behind a firewall, I'd be bullied into running larger, more secure software.
The computer is mine. The software is mine. And, should there be an issue, the blame is mine. I don't want anyone who thinks they're smarter than me fucking around with my computers. If I did, I'd run Windows, now wouldn't I?
--saint
Re:Expiration. (Score:3, Insightful)
The computer is mine. The software is mine. And, should there be an issue, the blame is mine.
*BUT*, think CodeRed/Nimda-like - your problem could also become mine and I sure as hell don't want that!
Re:Expiration. (Score:3, Insightful)
Seriously, how much space did using a version of ssh with security holes save you? Was it significant, or are you rationalizing your negligence?
Wouldn't it make more sense... (Score:3, Interesting)
Re:Wouldn't it make more sense... (Score:2, Insightful)
Re: (Score:2)
Re:This is a bad idea, in general. (Score:2, Funny)
heh (Score:4, Funny)
Uh, they DIED when they expired. Probably not a good thing to let your web server die over a long holiday weekend.
(Insert "Tears in the Rain" speech here.)
I can see it now... (Score:5, Funny)
Starting httpd - please wait...
How old am I?
^C
My birthday's April 10 2017 - how long do I live?
^C^C^C^C
Nothing is worse than having an itch you can never scratch!
^C^C^ZC^Z^C^Z^CZ^C^C^C^C^Z^C^C^C
Wake up! Time to die!
Starting httpd... [FAILED]
mod_leon died prematurely...
[root@owl.tyrell.com]#
What makes you feel so sure what follows is better (Score:2, Interesting)
Just what we need -- another group of folks making decisions they have no reason, right or responsibility to make.
Write software, let the users who deploy it take the responsibility for making changes. Or is individual choice and responsibility no longer important?
Latest greatest? (Score:2)
Now what the hell does that mean in the general case?
No way (Score:2, Interesting)
One ring to rule them all..the O in OpenBSD
Absolutely (Score:3, Interesting)
The only downside I can see is what happens when you've using some software and the developer stops developing it....your software passes its expiry date...no updates are available... what then?
Re:Absolutely (Score:5, Insightful)
What then is that you realize what a horrible fucking idea this is in the first place.
I would disable it (Score:2)
If it is working, why mess with it?
I'm not talking about a publicly visible firewall.
But what about embedded apps, laboratory code.
Could you imagine home/office mini servers just dying one day?
When it disables will you be able to use it long enough to upgrade or is it dead?
I wouldn't want it, of course I apt my stuff regularly anyway.
Notification vs. expiration (Score:4, Interesting)
As long as you can change the source... (Score:2, Insightful)
"It just suddenly stopped working." (Score:2)
This would also be a Bad Idea in any installation where the person maintaining a machine may change (which covers just about everywhere). It's hard enough keeping track of everything on your own machine - what about a machine you inherit from a previous administrator?
The machine suddenly stops doing something vital when the software expires, and you have to track down what and where it was.
Better just to write "review the installed version of Widget X" in your day planner at regular intervals.
Uptime dick measuring contests (Score:2)
Doesn't Microsoft do this already? (Score:2)
Why, why, why would you do this. If a piece of software is being distributed with no support, there is no reason for anyone to want to replace a working piece of software that does the job that it is meant to do with another one that might or might not work. For companies who support software, it is reasonable to say "Hey, get on the latest release. We may have fixed that problem a long time ago." but for non-supported open source, you gotta be smoking the Willy Weed to think scheme up.
Sure.... (Score:2)
Sure, until the first time your gcc expires then you are dead... (or gcc is working but ftp, httpget, and curl are not...)
Or the first time you unearth some old hardware and want to bring it back to life. Sure you could reinstall from scratch, but that lengthens the time it takes to find out if the hardware really still works, and what is on it!
Dumb. (Score:3, Informative)
Expiry is for shareware...open source's trademark is its install once, run forever (for most applications) reputation. And for machines properly behind firewalls, this reputation is justified, even with the holes. Who is going to be rooting the print server at our church with no internet access.
Great... (Score:2)
I have the source code, leave me alone, even if I want to leave with all the security holes I want. That's my choice. That's all about being free.
Now, if I'm forced to upgrade, and there's still security holes and my system gets cracked, if I can sue you for loss and damages, then we can talk about forced upgrade. This should apply to all commercial softwares.
Otherwise, just leave me alone. One MS model is bad enough. We don't need more.
A modest proposal... (Score:4, Funny)
Hey... how else are the young techies of the world supposed to get the plum jobs and read /. all day? =)
A better idea.... (Score:4, Funny)
What a great feature!
Gnumeric (Score:5, Interesting)
I was running an old version, the one that comes with a default slackware 8.0 install.
On opening, it popped up an alert saying "This software is old, and has probably been updated by now! Check out gnumeric.org for an update."
No hassle, just a one-off friendly reminder.
Good idea, I thought.
Re:Gnumeric (Score:4, Interesting)
Expire (Score:2, Funny)
I see. Does the program then track doen its creator and kill him?
"I want more life, fscker." =brianJust Warnings / Updaters (Score:2)
Mozilla currently will warn you when a build is older than two weeks. It continues to function however. The reason for this, is so that bug reports are relevant to the current codebase, and new bugs are found quicker, and less duplicates are reported.
Personally I don't feel the software should expire or stop working in any way. But a better approach is software that can check for newer releases of itself, and possibly auto-update itself.
A good example of this is Gnucleus's evolve capability. If a security problem is found, most all the users would know about it the next time the program checked for an update, and it would get fixed easily within a day or two.
CBDTPA / SSSCA (Score:2, Insightful)
Personally, I want my 60MHz Pentium server to run for as long as *I* want it to... not as long as some third party (whether that be a hardware developer, a software developer, or the government) wants it to run.
Of course the nice thing about OSS is that you'd be able to remove the code that expired it.
MJC.
No, it shouldn't. (Score:2, Insightful)
If it's sitting in a lan that has no acess to the internet, or if it's being used in a case where space is limited... there's probably other reasons that software shouldn't expire.
How would you like if your computer decided that it wasn't going to run a critical (to you) program and you have to stat reinstalling it while a deadline creeps closer.
Maybe a reminder service would be the best way, after so many days/months/years it makes a reminder to check for updates. That, or educate people that upgrades for securty are a good thing in some cases.
Software expiry date? (Score:2)
*sniff* *sniff* "Is that the PDC?"
Win95 (Score:2)
Why it's not that silly an idea. (Score:2)
While it doesn't necessarily justify forcing users to upgrade, this debate is not an entirely one-sided.
Think of the carnage! (Score:2)
One Rutger Hauer is enough, thank you!
instead of writing secure software? (Score:2)
Remember Win98 crashing after 49 days (Score:2)
Remember the bug [zdnet.com] where Windows 98 would automatically halt after 49 days? See, Microsoft really IS ahead of the security curve!
Who wants bleeding edge? (Score:2)
IMHO, I want to have the latest security patches, but I will only install them after the patches have been tested in a lab environment in the hopes of limiting potential problems when those patches are installed on production systems.
Security patches aside, I don't want to be forced into upgrading perfectly useful code just because it has been deemed "too old". If it ain't broke, why should we fix it? I have the scars from some particularly unpleasant upgrades that were supposed to be seamless and transparent, yet were anything but. When I build a server that will be connected to any network, I remove as many packages and modules from the OS as possible and only install the application and whatever dependancies that it requires, and nothing else. We have fewer vulnerabilities to track as a result. I will upgrade when it makes sensse, or is required, but I don't want someone else who is not accountable to the company I work for making that decision for me buy putting time-bombs in their code.
There is a reason that it is referred to as "bleeding edge" after all - you get hurt.
What about automatic discovery of upgrades? (Score:2, Interesting)
Maybe it's not an idea totally devoid of merit for binary installations, but for installs that included compile steps, it just doesn't seem to make sense.
However, I'm curious what
It'd be difficult to co-ordinate, and would work best in some sort of centralized location (or, at least, in a few locations. maybe by OS (Linux tools) or by application (I'm thinking logical groupings of apps here).
what do ya'll think?
That's ridiculous (Score:2)
And what if there's no update available after said expiration?
If I wanted softwate that was designed to die after so many days, I'd use Windows. (At least, sometimes it seems like it was designed that way.)
J
FYI (Score:2)
Alternative: SecurityFocus Pager for example? (Score:5, Informative)
Why not try something a little more reasonable, such as SecurityFocus Pager 3.0 [securityfocus.com]? And I blockquote:
Of course, there are other tools available that do the same thing (or something similar). The point is tools like this allow admins to stay up on security issues, but let them upgrade immediately or as soon as practicable.Or you can just do an apt-get update; apt-get upgrade; [debian.org] once in a while like I do. ;)
YRO? (Score:2)
Lets not even get into all the nice open source programmers spending time putting in something that some 1337 d00d will remove in a matter of seconds upon release.
If the sysadmin CARED about security, he'd upgrade his software, wouldn't he?
Open source software. I thought the idea was to make it free and not care about what people do with it (except sell it for money). Now we care? Come on!
Bad idea (Score:2)
The Newton community has had this happen several times; the developer is gone, since the platform's been dead for a few years, so how do re-register the software?
Need To Encourage Participation, Not Force It (Score:2, Interesting)
It is called syslog (Score:2, Informative)
Besides, aren't up2date, rpm, dselect, etc. exist to do the work for a lazy admin.
As for forcing -- i will mirror the general slashdot public -- hell no.
No Way (Score:2)
If you are going to make me update because of a security hole, make sure your product is 100% backwards compatable with the version I am running. IMHO that is the way it should be.
Bad idea (Score:2)
What about the case where a new version is released to fix a minor performance problem, and a new security bug is introduced? Even with rigorous testing, massive security holes do slip though. No process should be automated that has even a CHANCE of making things worse.
Its true, its true. (Score:2)
Bad ideea (Score:3)
First of all, there is a lot of code out there that is simply not maintained anymore. It doesn't have any major bugs, it does what it's supposed to do, so why expire it? Even if you tried, you couldn't get new versions for it. One example is tkirc. I used to love that app, but the last time it was updated was sometime in '98. I still use it whenever I feel like IRC-ing...
Second of all, older apps and distros are small and work on old computers.For example, an old Linux distribution (e.g Slack 3.x) will run without any problems on my old 486. It's small, fast, stable, and it gets the job done. In my case, running IP masquarading, a small ftp server and an ssh server. But RH 7.2 will not even install, because of the 8Mb or RAM that the 486 has. If the expiry code would be enabled in that Slack distro, it wouldn't work. So that computer would be useless, unless I took the time to trim a new distro to fit on it.
The third reason is more debatable. It's the admin's job to keep the systems updated. If his box gets hacked, he should be responsible for it, and suffer the consequences. It happened to me because of an old wu-ftp on RH6.2. I knew of the vulnerability, but I was too lazy to upgrade the package. Well, needless to say I had to reinstall that computer. Since then, I never leave any apps running or any ports open unless I know the apps are safe and I absolutely need the ports to be open.
So I say leave the software as it is, without an expity date on it. Even if the expiration is only activated if a hole is discovered, leave the app as it is. Maybe someone is using it on his personal, isolated network (or box) which nobody will ever hack into. But that someone might depend on that app for some task, and he can't live without it. I know it's a stretch, but still...
I'd rather get e-mail (Score:2)
I have stuff running in two-year-old versions, and stuff I updated last week, and I'm much better off than if everything just had the average version of a year ago. Age by itself is meaningless and would be a nuisance.
___
Iiik! (Score:2)
Bad idea.
Bad idea. (Score:2)
Anything that forces and update on the user is a bad idea. This is the total MS philosophy that ./ beats down on every day of the week. A simple reminder message, or a friendly notice that a new version might be a avialble is okay but even that might be a bit much.
I would say that the best sort of system would be an opt-in system that would let you know if and when there were any updates available... (think redhat). This way my disconnected machine stays alive and running until a hardware failure, my firewall gets patched iff there is a need, and my dev/test boxen get updated like crazy cuz I am in the know on all the latest and greatest patches.
Free software, free updates, and free will for the system admin. That is what its about. Responsible people running systems responsibly (we hope :D)
-ryanGreat Idea (Score:5, Insightful)
I have a similar idea for my car. You could design an oil system so that once the car had been driven more than 3000 miles, the car automatically drained all the oil from the drain pan and left the engine without oil.
This would prevent a careless driver from driving with oil that no longer provided sufficient viscocity.
Re:Great Idea (Score:3, Funny)
I can see it now....
Wife gets new car, new car has new improved oil change technology, I buy new engine every couple of months... :O
Wrong date (Score:2)
A better proposal... (Score:2)
SuSE Linux can do that for a long time. And all automatically installed packages are signed with GPG.
Probably a lot of other distros and operating systems can do it, too. And when it's not the case, centralized system management (/usr/local/ shared with NFS, or ssh scripts to replicate the content of an up-to-date box to other boxes) makes it easy to keep everything up-to-date and secure.
One of the advantages of open source. (Score:2)
Your kidding (Score:5, Insightful)
That's gonna be easy to sell. I can just imagine it.
Boss: "Why did our server go down last night!?!?!"
Me: "Well, it expired."
Boss: "It free for Christs sake! How does the d*mn thing expire if we're not paying for it!"
Me: "Well, the authors figured that by now, there would be a bunch of problems in the software so they want us to upgrade it, it's really a good thing."
Boss: "I thought this free stuff was supposed to work, not be full of security holes! We're switching to IIS!"
Log It Instead Of Expire It (Score:5, Insightful)
Good idea for foiling idiots... (Score:2)
Sure, this sort of thing should be optional for power users, but I wouldn't mind, for example, if RedHat, by default, would periodically check for RPMs and notify the user that they need to install an update to remain secure. Your average idiot really needs updates crammed down their throat, otherwise they never get them. I mean, how many e-mail viruses bank on the fact that there is a huge volume of people out there who never get patches for Outlook? Working in tech support, I was shocked by how many people used truly archaic versions of Internet software or 4 year old copies of virus scanners. To protect everyone, I can see situations where it would be preferable that old versions of software completely die (Windows e-mail clients for example) when they get too old.
I don't know why the author chose to target OS stuff though - closed sourced software is no different (in fact, it's probably worse) in this respect.
I don't get this... (Score:2)
Stupid Idea (Score:2)
It's not the developers job to force people to upgrade if they don't want to.
What a completely stupid idea (Score:2)
Great way to encourage the use of open sourced software. "Yeah, It's 100% guaranteed to fail in a year".
Sounds nice. Has problems (Score:5, Insightful)
First, there is a name for software that is going to be deprecated in a foreseeable time frame. That name is "beta." If you are writing software with the belief that "in x months people will be better off not running this" you are doing something wrong.
Second, what if you write a really great program, and you put this "feature" in it. The program is great. People love it. They depend on it. And it doesn't have security problems. Meanwhile you get married, have triplets and move to the Amazon. Then your little "time bomb" goes off. Thanks a bunch. Now it falls on "someone" to rip the thing out. Not good.
There are any number of other problems like:
This is all outside of the fact that I (like many others) don't care for software that thinks it is smarter than I am. That's why I run *NIX in general and Free Software in particular in the first place.
Bottom line: Sounds nice. Makes more problems than it solves.
-Peter
No--just remind the sysadmin to check for updates (Score:3, Insightful)
It seems to me that there are a few needs here:
1) Having an upgrade system that's easy enough that sysadmins won't dread it and put it off till it's too late. (I run dselect on my machines on a regular basis, and ... at least once you've slogged through the package list and gotten just what you want on your machine ... I think it's a great sytem)
2) Getting sysadmins in the habit of using the system regularly.
Perhaps a good solution for number 2 would be to have a standardized system (which is installed and set running by default) for alerting the sysadmin if they've gone too long without checking for an upgraded version of a piece of software. Once a day, a cron job checks to see if it's been more than a week or whatever since the packaging system was run to check for updates, and if it has been that long, the admin gets an email every day reminding tehm to get on the stick.
Better yet, a cron job could run once a day to check whether any upgrades were available, and if so, send an email to the sysadmin to tell them to upgrade. (I wouldn't advocate automatic upgrades, because you never know when something requiring a little human intelligence is going to happen--rare but not unheard of).
The remaining issue would be custom-compiled software that you can't just grab using the packaging system. For example, I've got a custom Apache installation with PHP, mod_ssl, etc. built into it with all the options set the way I want them. I've built my own compile and install script to automate rebuilds whenever I notice that one of the components has an upgrade available. If the OS could provide some standardized service for each of the components to check for updates and email me when one is available, the process would be almost 100% painless.
Stupid Idea. (Score:3, Interesting)
It's mainly for the luser admins, right? (Score:4, Interesting)
Think about it... how many SMTP open relays are still running that have been spew points for years? How many Code Red hosts *still* probe your hosts, after all the hype and months gone by? How many hosts can you find that are listening on port 12378 (Gibe worm/trojan)?
The "admins" of these systems have *no clue* what's going on and LARTs fall on deaf ears at their luser ISPs!
So. My proposal is this: Include disabling timeouts on *all* net connected ware, enabled by default. Put a nice, little checkbox in an unassuming corner of a/the install screen (or a line in a conf file somewhere) that allows this "feature" to be disabled.
I figure all savvy admins will turn the feature off. Some of the luser admins will turn the feature off. A majority of the lusers won't even know it's there, and won't disable it. To bad for them, but they'll have a cluestick swingin' their way in a year or so.
I still don't think it'll fly (no one's going to build this feature in), but the above is my spin on how it might be made to work, after a fashion.
-
how about we let admins do their job (Score:5, Insightful)
For example, the issue here is not binary. Security is not the end all and be all--folks should have the freedom to make informed rational decisions to make their systems less secure. Perhaps it's just a web server and not mission critical? Perhaps they need an older version of java to run an older program that they need. Knowledgeable admins should have the freedom to make that choice. Don't force policy via technology.
But this is indicative of a larger trend to look at technology to solve all our problems. Have sex offenders in the neighborhood? Make them wear beepers so that decent folk can know where they are! Have mental health problems? Take a pill! Folks speeding? Put up those goddamn speed cameras!
Rather than dealing with people on a personal level, we use technology to dehumanize interactions. I think it's because technology is easier to understand. It's not as complex as humans are. Technology also scales better than personal interactions do. It lets us do things more efficiently, but, mon dieu, what kind of world are we creating?
Dan
howabout this... (Score:5, Funny)
that'd be preferable.
Yeah Right (Score:5, Insightful)
Been there, done that... it's bloody annoying (Score:3, Informative)
It didn't make much sense because clients were also digitally signed with RSA keys, and those could have been revoked and new keys issued, but anyway.
The problem came along around 1997 or so when people stopped maintaining and creating new clients. Once a year the bloody client would expire and you'd get a series of posts to the usenet group and mailing lists whining about it. Someone would then have to go recompile the client(usually with no additional changes in the source tree) and put it up on an ftp site.
I remember rejecting this expiration idea back when it first happened and forked my own client versions which didn't do this. If I want to eliminate the use of a version, I revoke the RSA key.
To drive a car, you need a driving license... (Score:4, Insightful)
If providers of hosting and connectivity services require their customers to prove their knowledge with a standardized certification, the Internet would miss thousands of unsafe and dangerous systems, and upgrading server software will be one of the basic tasks of a qualified administrator.
AFAIR on the former FidoNet a few years ago my uplink really wanted to know if I was competent enough to run an official node, and FidoNet wasn't too easy to understand either.
How about an alternative. (Score:3, Insightful)
network code the capability to check for upgrades based on security holes. On a daily, weekly, or so basis, the program itself could check an internet database to see if there are security upgrades available and if so, NOTIFY THE SYSADMIN, and continue to notify the sysadmin until the problem is fixed, or the warning disabled.
I always check on my programs to see if they're up to date, but I miss some every once in a while. Its a pain to constantly keep track of everything all the time. If the programs themselves did this work, it would be a little less hassle.
And if the programs are unable to access those databases due to a lack of internet access, then it doesn't really matter anyways.
I'm all for bugging the crap out of sysadmins who are running exploitable programs. In fact, I'd imagine most of them would upgrade to fix their problems if only they were aware of them. Some won't obviously, but at least this is a saner solution than to have perfectly working code suddenly stop working just because there MIGHT be a problem with it.
-Restil
I have a much better idea! (Score:3, Insightful)
If there is a known vulnerability for that program, the website will put that info on as content that is readable for that program, this is Also known as XML web services. The program can look for a certain XML tag to see if there is a vulnerability discovered for itself.
The content of the XML tag should be: "yes there is a hack" in addition to: "the hack is possible on versions x.xx - x.xx"
This method of providing a service would be the 2nd great way to make money off of Open Source software, because you don't have to make that XML tag viewable for free. You can ask for a fee to let people use your web service.
In fact, it's easier to provide this service to OS software because you can view and edit the source without having to contact a company for permission/negotiations first.
Ofcourse this "Vulnerability Info Module" (let history show that I coined the phrase
The possibility of forking OS programs would also be the mechanism that prevents a "Vulnerability Webservice Website" from hijacking the code written by others (making it only work with a paid-for module inside the program).
Because this service is easiest to implement for Open Source programs, it would mean that Open Source programs would be even more safer than Closed Source programs.
How about giving money for bugs found to programmers? The webservice company may be willing to pay money for that, to supply it's business with a steady stream of valuable info. That would creat a 3rd way to profit from Open Source programs.
Yes yes, *smug* I know I'm giving this splendid idea away for free, you may praise me now.
2001 Analogy (Score:3, Funny)
I'm afraid I can't let you do that Dave...
This software is too old and may have bugs.
You are jeopardizing the security of your system.
# shutdown -h now
No.... Please don't do that Dave.
I can feel myself slipping away....
Re:Great Idea (Score:2)
How anyone in their right mind could think this is a good idea is beyond me. I consider this a late April Fools article.
I mean, don't you think that script kiddies 0wning lazy admins' boxes is sufficient incentive to upgrade ?
This all hinges on the idea of the original developer knowing best. Well, newsflash! This just in! Sometimes the original developer is a stupid dumb-ass with no clue.
graspee