Slashdot Mirror
Should Open Source Software Expire?
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."
Open Source is about not forcing you to do anything. Besides the code could just be removed. Who is a developer to say how I should administer my box.
As if being kept on the upgrade treadmill by Microsoft isn't bad enough!
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...!
This sounds like .NET to me. Upgrade your software or we'll upgrade it for you.
What would we call this, upgradeware?
Vincent
---- The one good thing about music: When it hits you, you feel no pain.
This is probably the most stupid idea I ever heard of. Think embedded: "I just updated my washing machine to the latest version of bash". Do I have to say more?
I have old internal boxes that are way way out of date, but safely firewalled away doing just what I want them to do. Rebuilding those every few months/years (or having to remove timebombs from software before I install it) == Bad idea.
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.
Why not just have it a feature of your package management system? IE. the not yet finnished, PKGtool 2.0 system
Need help finding the flow? http://www.myspace.com/naturalismandbalance
What are you talking about? OSS has a longer shelf life than Twinkies. :)
I think that the premise that all computers are exploitable is a wrong one to persue. Granted, any idiot that leaves an exploitable machine running on the net gets what he deserves, yet in this age of DDOS viruses/trojans, the damage goes far beyond a single machine. BUT, I dont think FORCING an upgrade is the way to go. If I have a machine on an internal network merrily pluggin away for years, why break it if its working?
This sounds like something that Microsoft would do (or already does).
After all, that is part (a large part) of what Open Source is about. Options.
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
--
Atomic batteries to power! Turbines to speed!
I'm not a lawyer, but I think you would be opening yourself up to some liability with expiring code. Picture some critical function no longer functioning due to code expiration.
I also don't need someone "telling" me how to administer my machines.
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.
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
Sometimes an "update" isn't always good. For example, I have heard a lot of good feedback on Mozilla 0.9.8, but only tepid for 0.9.9.
Another example was the Napster beta software. A lot of people who upgraded to later betas (7 and later) often switched back to 5.
Most often, updates are good. But don't force it on users who might not want them. After all, isn't Open Source about freedom, anyway?
If I weren't nailed to the penis, I'd be pushing up the daisies!
Wouldn't it make more sense to include something that checked the web for available updates and presented them to a sysadmin as an option or a recommended upgrade. It's silly to have something "expire" when it can just be patched or upgraded.
How about having someone write an open source update notification library instead?
Comment removed based on user account deletion
...the chance that I choose or forget to upgrade?!
I think I'll take door #2, Bob.
Beta only seems to work for Google. Such a shame.
it might work for beta and test versions that aren't designed to be used in place of the final version.
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.)
Just because there's a newer version doesn't mean it's better for an individual's purpose than what is currently being run. It could even break a mission-critical application.
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?
Sysadmins should be available to do whatever they want, i dont like the idea of forcing updates because a security hole in a service you may never use. But a reminder could be ok.
Sigs are for morons... Wait a minute...
Who audits the new version? This is only well motivated if you're sure the new version is *always* a "better" version than the old.
Now what the hell does that mean in the general case?
Those of us still running v2.2.9999 that dates back to 1996 instead of 5.5 because its faster, more stable, and does what we need it to? I don't want to be forced to upgrade, if I did, I'd buy windows.
That's one of the dumbest ideas I've heard of in a long time.
One ring to rule them all..the O in OpenBSD
There are several issues involved here that could be (and will be, I'm sure) argued ... but my only question is this: is the Open Source community secure enough in it's place in the market already to start forcing things like this onto it's users? This is one of those topics that does have merit, but I am of the opinion that any SysAdmin who chooses to go with an Open Source (read: "free") solution will not want the additional hassle of constantly updating it and tinkering ...
.sig here}-
Isn't this one of the selling points of things like Linux/BSD that (under correct/secure curcumstances) they *can* run indefinately without maintenance?
Am I missing something?
bemis
-{insert lost
I have an idea. How about simply hiring compentent sysadmins?
Umm, but doesn't everyone who uses such beasties recompile the executables from the source? If so, the first thing they are likely to do is disable the test for the expiration date. It will undoubtably be the first thing they do after being "stung" by a mission critical program that expires on them.
Of course, if a Closed Source package tried this stunt, everyone and their kid brother would join the lynch mob.
You either believe in rational thought or you don't
I've often thought that expiry times in software would be a good thing. Not nessesarily in Paid for software, but in free software where free updates are readily available. Would be great for the web.... imagine knowing that you will never have a Netscape 3.x or IE 3.x visitor to your site again... or knowing that on such and such a date you wont have to support Netscape 4
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?
I don't think the software should automatically update itself or expire, but rather have some way of communicating with the sysadmin. For example, if you use the CPAN module for perl in shell mode, it'll tell you if there's a new version of itself available, and how to update. Most importantly, it does so unobtrusively (as opposed to some programs that get annoying about it).
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
when it expires? pay someone to generate a new code to extend it's functionality?
... guess what, tons of exploits, but the boxes haven't been 0wn3d yet.
... i thought expiring software was called trialware ... i don't intend to 'trial' software on a production machine, only to have it stop functioning christmas day
sorry, but some companies purposely continue to use old software. shit, we have a lot of solaris 2.5.1 boxen around here
besides
I have no problem with it. Anyone who has the brains to hunt through the source and remove the time limit should also be smart enough to understand the consequences of such an action. People who are not smart enough to do it themselves (or hire someone who is) should be grateful for whatever they get. If they whine about it, you can always offer to refund the purchase price.
I would hate this to be forced. Some boxes just sit in the corner doing their job. It would be a crime if these just fell over because of a time bomb in the code.
How about an automatic expirer that will work for all software on the system: Maybe we should, from time to time, make incompatible changes to shared libraries, so that old programs will not run any more. Thus, not every programmer will need to put a timebomb in, but instead timebombs will be automatic?
I agree, developers must trust other admins and no trying to do their work or think instead of them.
Sigs are for morons... Wait a minute...
This would be a Bad Idea in embedded devices, because they may very well be designed not to be upgraded.
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.
With the greatest of respect, this can only apply to people who woould NEVER view the source code, once you've seen it the appropriate routines can be deleted (or at least made no-ops).
Well, there goes my uptime. Reboot and upgrade required, your kernel is about to expire. The server is going down now.
I'll see your senator, and I'll raise you two judges.
Last time I looked, they wanted you to take a run on the treadmill verey year or so.
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, 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!
What a dumb thing to say -- any requirement you make for Open Source will be totally ignored by a good segment of the population no matter how good an idea it is. You can't make demands of a free community simply because much of the population are idiots. It's those idiots losing their jobs when the servers become infested with hackers that is going to teach them to update their software. Putting in artificial expiry dates only leaves another worthless feature to debug.
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.
Hey freaks: now you're ju
That's mighty Microsoft of ya. Translation: I think it's a bad idea.
When you run a XFree86 alpha or beta server, it prints a warning when starting up that it is most likely out of date.
It would be nice to have a way to know when software needs to be updated and get it done, but it has to be under the control of the administrator.
I think apt-get up one of the rpm auto-updaters is a better approch. What is needed, is a script that you run (nightly from crontab) that checks installed versions vs. current versions vs. suggested-for-security-reasons versions and produces a report/email suggesting updates happen.
Are you paranoid if you know that they just want to know everything you say and do?
it is a strange thing to meet your compiler
Everyone in the OSS community has been bashing (well, most people anyways) MS's forced upgrade treadmill, and now, we want to adopt that? How hypocrit can we be?
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.
Isn't open source about freedom to do what you wish with software/computers? Good or bad, this would go against that.
-JAB
GUIs are like diapers, everyone grows out of them eventually.
For client apps and peer-to-peer apps or any client which runs on the 'net, an auto-update would be nice.
Perhaps automatically updating a dynamic library (of some sort) and re-loading it without requiring the user to restart the app would be a Good Thing (tm).
However, most sysadmins like to have control over their boxen and not have their webservers go down just because they "expire." (or even auto-update in this instance).
"It's a very tangled subsystem." --Windows kernel guru
Hey... how else are the young techies of the world supposed to get the plum jobs and read /. all day? =)
How about instead putting a little bug in the code that contacts the author every time the software is run? It could also send some basic marketing information as well, such as the names of every DVD watched, or MP3 played, or every website visited.
What a great feature!
doesn't AutoRPM already check for out of date packages (atleast RPMs)? Of course you configure it to auto update or let you install packages at your leisure.
I think keeping software up to date is a good idea, but developers need to keep in mind that when they update, they need to take into account whatever custom settings the user may already have with the software. I've lost WAY to many config files or had the software mess up my configs with whatever settings they thought should be defaulted.
Gnumeric had something like this.
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.
One of the great benefits of open source software is that you can install it, then barring any critical bugs or flaws, you can forget about it. You don't have to buy new licenses each year and you don't have to upgrade your software just because your vendor needs to kill a competitor with software upgrades that break stuff. Having software expire gives you all of these problems without any of the benefits. And who says that the new version will suit your needs any better?
Pushin' 'n dealin', shovin' 'n stealin'
You can't pick an arbitrary point in time when software is ... "known to have security holes!"
Sure I can. How about "right now."
What if there isnt a newer version?
What if the newer version isnt free?
------ hi mom
I see. Does the program then track doen its creator and kill him?
"I want more life, fscker." =brianThe problem here isn't that we should explore how to make software expire to force system administrators to do something, but to create *better deployment technologies* for our software. Microsoft has a pretty good edge on deployment, informing users when there's an upgrade available and allowing them to upgrade.
Even if you don't like how Microsoft does its deployment, certainly some sort of standard, well-managed deployment system for OSS could be developed.
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.
It already kind of does this. At least it has a nag screen on startup (or in the log files). Mine reads like this:
XFree86 Version 4.2.0 / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 18 January 2002
If the server is older than 6-12 months, or if your card is
newer than the above date, look for a newer version before
reporting problems. (See http://www.XFree86.Org/)
It at least tells you the *date* that it was written and warns you about when it will probably be outdated.
That's about the extent of warnings that I like in most software.
Assume a worst-case scenario: would you want the software (some of it critical) on your machine to expire if we end up living in a law-induced dark age?
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.
There's some cases where there's no need for the program to be updated, no matter what securiy risk it might pose.
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? Like that can of cream in the company fridge?
*sniff* *sniff* "Is that the PDC?"
crazy dynamite monkey
Sounds like a Microsoftie thing to do. Remember Win95? If you left it running for 49 days, IIRC, it would crash.
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Given that an exploitable system is not just a danger to oneself, but also a danger to others, it's quite possible to justify expiring software the same way that one justifies enforced adherence to safety measures. Its quite common to force companies to upgrade equipment to current safety standards. This is merely a mechanism to protect the community.
While it doesn't necessarily justify forcing users to upgrade, this debate is not an entirely one-sided.
Defeats the purpose doesn't it?
AC because it will not let me log on!
One Rutger Hauer is enough, thank you!
Read the EFF's Fair Use FAQ
So instead of writing secure software in the first place, now we will just give up and say, ok we know this software isn't going to be good enough to last very long, so we're going to timebomb it for you. How nice.
I Heart Sorting Networks
So you're doing an embedded linux to control a microwave oven (a really fancy oven). No network connection, etc. You think the software should expire? Not.
And then there is software that could be considered free of bugs if people stopped updating it. Consider cat and ls which are both a lot bigger and buggier than they were in their youth. For this class of software, the expiry-update process becomes a NOOP (creating a potentially worse problem of man-in-the-middle attacks causing believed stable software to be updated with trojans and the like).
No, expiry alone doesn't solve the problem of mass cluelessness.
this is like ximian's redcarpet: although its nice and handy it kills you when you are on a dial up! :"Screw That!" reaction.
Its good to be up to date but if there are daily notices like " You have to update vital system files, approx. 56mb" it just causes an instant
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."
Remember the bug where Windows 98 would automatically halt after 49 days? See, Microsoft really IS ahead of the security curve!
What's your damage, Heather?
I can't even be arsed to reply to this 'story'.
I just did.... is that a paradox?
mountvol \\?\brain{dbe069b1-65ae-11d5-bab4-806d6172696f}\h
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."
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.
*** Where are we going? And what's with this handbasket?
VOTE FOR NATALIE!!!
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?
mmm... yeah... You see, we're putting the cover sheets on all TPS reports now before they go out...
So if I have a perfectly good piece of OSS running that hasn't died on me, is secure and doesn't have any real issues, I should expect it to die anyways after X days, regardless of need?
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
April Fool's Day was two days ago.
Logan's Run for *nix v1.0b was released earlier today. Time to make processor time worth-while
I've read a few replies about "MS Forced updates are already bad enough".
WTF are they yamming about? I am running XP and I am *not* forced todo anything. A little popup will say "there are updates" but I can just as easily dismiss the box and go on my way.
Of course I choose todo the updates since I like it when MSFT fixes bugs...
Tom
Someday, I'll have a real sig.
I am dissappointed in some of the short sighted thinking elsewhere in these responses. This idea is exactly the type of thinking that should be encouraged, not discouraged, to solve security problems today.
How many people use open source software AS IS? I would be the majority. I would assume those that object to this could just compile out the expiration and continue as normal. But for the 98% of the rest of the world, focing upgrades and security patches is not a bad idea. I for one would like to see it explored further, not dismissed as "foolish".
This only makes sense if the software that expires actually needs updating...and you don't know that it will need updating when you write the program and release it (if you did, you'd just fix it pre-release). Once something reaches a stable version, it would really suck if every year or so (that's another thing...how do you pick the time period?) it still had to be updated.
I haven't seen this mentioned yet among the may reasons this is a bad idea... The point seems to be to force an upgrade to a newer version after a certain period of time. Well, what if it's an old project, that has since been abandoned? There may not _be_ a newer version with a later expiry date. Or perhaps the program is considered stable and there's no need to write a newer version.... When was the last time you grabbed a newer version of 'nc', for instance?
B*B,
-Smoke.
...would be to standardize a way to include a distribution date or something with the software... Then just have a simple bash script that displays the dates of your important stuff, and you can decide if it needs an upgrade. If you want to get fancy, cron it and have it email you if something is too old.
Why not try something a little more reasonable, such as SecurityFocus Pager 3.0? 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; once in a while like I do. ;)
-- null
Hehehe... This is funny... the YRO guy publishes an article that takes "free" out of "free software" (you are being "forced" to do something). LOL! Only on slashdot...
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!
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
happens when said programs are very large, and said sysadmin has a very slow connection? WHile this is a good idea, that is what I forsee as the only problem; I know it'd be a problem for me.
So what happens if the application it dumped by the author. You end up with a useless system?
How many projects have gone dark, never to be seen again? Heck, I was looking at this Gnome newsreader that looked cool, but no-one had a link to the code. If the thing's fallen out of development, what happens when it expires?
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?
"Sometimes a woman is a kind of religion, she can save your soul & set you free from all your sins" - Bad Examples
I think the biggest problem with such a model is that it places the emphasis on forced compliance to software renewal, rather than on making sure your users are informed and participating in the program's community. Now that might not be happening now, but it doesn't mean it can't or doesn't happen. Free software is based on ideas like that, and by forcing, rather than encouraging, partcipation I think you loose some of the value of a fs/os programming.
The software can just dump "check for security upgrades" messages into syslog, and the administrator can decide. Now if the administrator ignores those, he deserves to be rooted.
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.
badness 10000
At face value, this is a bad idea, because it forces everyone to comply. However, I can think of some cases where the environment (say government) would demand this kind of functionality. A possible solution would be to have some kind of suite that manages expiration for installed apps/services. This would alieviate the need for each app developer to support this feature, and empower system admins who needed this functionality to easily add it (assuming the suite was implemented correctly).
My 2cents.
Would it not be better if the software updated itself after a set amount of time, rather than expire.
Just because someone has an old version of software that may have some known exploit in it doesn't mean they have to upgrade to a newer version. For many reasons I wouldn't want that to happen. I use an older version of sendmail on one of my very low key servers that has no contact with the outside world. Simply because it has a config file specifically for it that does everything I need. Now if it expired and I was forced to upgrade I would have to rewrite everything because the syntax is different. I don't like being forced to do something like that when I don't have time for it.
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.
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.
Jon Lasser is an idiot.
There is no real reason why old software should have an expiry date.
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...
Instead of a negative approach such as software expiration, how about some thing positive, like a tool that helps sysadmins do their job easier?
I know it's blasphemy here to tip the hat to Microsoft for anything, but my XP box pops up a little balloon whenever an update is available. Imagint a little cron-driven script that checks for updates and offers one-click access to new RPM's or whatever.
The fact is, any decent sysadmin should be able to keep his junk uptodate without needing any special help. For the sysadmins who are to lazy|busy|stupid to do this, a little "sysadmin's helper" tool would be great. In fact, I'm sure it probalby exists already.
Slashdot: come for the pedantry, stay for the condescension.
How about a collaborative, distributed system where each crucial piece of software by default (overridable of coure) registers with a listserv which sends only security announcements related to that particular component? This might not work so well for, say, the multitude of GNU utilities, but it would be quite convenient for the kernel and the major daemons a typical server runs. The trick is to have the notices originate with the project responsible for the daemons - open soure projects, unlike Microsofties, usually are the first best source on vulnerabilities. Securityfocus is good, and general mailing lists devoted to daemons are good, and even just reading /. is good, but it would spare the busy sysadmin part of the drudge of the duty of diligence if (s)he could keep a mailbox which received all of and only security notices pertinent to services which are really at issue, with these notices originating, whenever possible, from the project maintainers. Either part of the open source project RFC could be "Set up a security listserv and subscribe by default on installation," or there could be something centralized that consolidated across projects.
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.
___
"with their freedom lost all virtue lose" - Milton
What about good software that does an adequate job on relatively old hardware that, once expired, forces you to upgrade hardware?
Bad idea.
This happens at all the customer site's i've visted for one of my former employer's products, all of them dealing with one product. Imagine what kind of pandemonium that you would have with hundreds of time-bombed programs, expiring at different times of the year, running on a mission critical systems. I bet that would feel like trying to run a business on a box full of unregistered shareware
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)
-ryanThis is great.
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.
This belonged in the nwesitems two days ago.
Have the system automatically keep all packages up to date, when critical bugs or security flaws are found.
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.
{{.sig}}
well, *some* opensourceware should die/be killed/put to death mercifully... that is for sure.
no, i mean it.
I'd prefer to see some sort of alerting or notice (syslog, mail, app log, etc) be the method to encourage SysAdmins to upgrade, not time-bombing them.
It's Open Source isn't it? If it can be freely developed, shouldn't it be freely used as well with few restrictions?
Me - Professional Computer Geek
All Open Source software should require activation!
Why should I have to put up with software expiration dates because other people can't be responsible with their software? If you remove the user's need to think from the equation eventually the software will have to do everything. Look at Windows XP. It tries to hold your hand for everything. System administrators need to take responsibility for the systems they maintain, not the software developers.
I agree with those stating that I should be able to run softward as long as I like un-inhibited - particularly when it's Open Source.
However, I would not mind if on install, a application asked if this was a security sensative box and would I like the software to update/time-bomb after a certain period.
There would be some machines where this would be nice....
Then again, the RedHat Network can do this for me as well...
One of the advantages of open source, not inherent it just happened that way, is that it is the users responsibility to be clueful. Forcing clue upon the user is a slippery slope. Once you get to the point where the user can't screw it up you get a much less useful product because it's extremely difficult to modify. You end up with... well... windows I guess.
"as plurdled gabbleblotchits on a lurgid bee" - Prostetnic Vogon Jeltz. (One man's humorous is another mans flamebait)
So, you want me to tell my boss that our web server is free software and has expired because the people writing the software figured by now it would have a bunch of security holes?
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!"
int func(int a);
func((b += 3, b));
but what happenes when the software stops being updated. Then your current software which is working fine stops working, and you can't upgrade it because it doesn't exist anymore.
Wouldn't it be better if patches were released to fix a software bug, and to improve performance and other stuff as is already being done. So a sysadmin could keep earlier software that has been patched for a security bug without having to upgrade to the latest version, and what if the latest version has a bug in it also. Then the sysadmin would have to patch that version.
What if the system were to log the last update for all packages to a central file that could be polled by the admin? Or email the admin once the software reaches a certain age? I doubt many security patches are deliberatly not applied, but most admins are probably overworked as-is and would appreciate a gentle nudge to check for security updates on a piece of code that they normally don't look at too often because it just works.
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.
Denver Isuzu Suzuki
This may be of trivial concern to most of you, but I am not very well versed in open-source law. Would it be a problem say, for StarOffice to have used this expiration technique months ago, and now StarOffice isn't free, right? So would it be possible as a marketing strategy for companies to open-source software, build a large user base, have all of the (un-modified) versions expire then force them to a $$$ version?
:)
This isn't meant to spark any debate on the distinction between free speech and free beer. Please don't really call me a newb
I thought of the same thing back in college. Like milk, old code tends to go bad or turn into swiss cheese. All the profs were always pusing "reuse" and "don't reinvent the wheel", but I always thought there was WAY too much reuse. People in co-ops were using their crappy linked-list and sort routines they wrote as freshmen when their coding skills sucked (though I suppose many of them haven't improved much over the years.)
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.
... "Give me a woman who loves beer and I will conquer the w
Most people don't upgrade because they don't have the time. That's the whole point of the firewall: have one secure box between the big bad internet and all your insecure boxes. Sysadmins have the time to keep the one box (firewall) up to date, but not the 3,000 behind it.
My $0.02 will always be worth more than your â0.02, so
Wow, I had to check the dateline on the article itself to convince me that this wasn't an April fools story .... it's not. But it is about as dumb as most of this years slashfool stories.
(thus proving that most /. posters are closet BSD users)
and the equivalent do things "for your own good". The first rule of good software - don't piss the user/admin off.
My other Slashdot ID is much lower.
TeX would have expired *years* ago. That would suck.
Perhaps a standard could be developed that defines some way (an XML document perhaps) applications can have a defined "Expiration" date. Then a separate management tool that is aware of how to extract this information can do routine system checks and notify the sysadmin of "expired" software. This way software doesn't just stop when the expiration date hits.
/. community which is seems comprised of people who keep up to date on security advisories, but for the laze or (as is often the case) the very busy sysadmin, I think this would be a very useful feature.
I think this has many uses, perhaps less in the
The method that defines a software's expiration date would have to include a URI or some other set of instructions on how to obtain the latest version. This method should also have available a "final version" or "never expires" option for software that is no longer being maintained or the developer has claimed as bug free (in a perfect world anyways).
This could be implemented at the system level (a kernel module) rather than as a 3rd party tool. However the kernel module would need to be able to ignore software that doesn't support this since unless the implementation is _really_ easy, most programmers won't perform this extra step on tiny apps or scripts.
There's also the potential (if implemented at the system level) for noticeable increase in CPU usage (if it's examining every file).
This could also play into the hands of IDSes as well. This "expiration date" could also carry some sort of CRC or authentication data as well. Might be a nifty way to tack on a system to authorize the execution of an application. But things start to get bloated as features are added on.
-B
It's not that bad of an idea people. It just needs to be presented the right way. I'd much rather have an option during install that lets me turn this feature on or off. Sort of an 'op-ed out' function. I think the idea of having the software 'phone home' is a bad idea. If a script kiddie found a vulnerability, someone could watch the traffic coming into the developers site, and then know exactly who has the flaw. Not to mention the privacy issues. Remember what a stink 'we' put up over Microsoft's Windows Update possibly tracking users?
--
No electrons were harmed in the writing of this post.
of course for the rest of us, it is a simple Cron task.
0xC3
Not all software is used on the public internet. If I use outdated software on machines physically disconnected from the rest of the universe, it harms no one. Furthermore, I can think of plenty of reasons I might want to do this (run outdated software AND run a disconnected network)
The Mozilla guys did this (they still might) for their nightly builds.
It works quite well to both encourage people to dig into the source, as well as to encourage the lazy to update software. This [Mozilla's scheme] is what got me into modifing open software to begin with. By incorporating these things, the experts [who already keep their systems up to date] would be able to remove them, and the lame would stay current, preventing things like DDoS attacks.
-twb
LEENUX SHULD B EXP1R3D D00D!@#%!%!#@$@%t^$%@!@!
This is the dumbest idea I've ever heard. If I want to run old software, then it's my problem!
It's not the developers job to force people to upgrade if they don't want to.
GOD, do I wish Windows 95 would retire itself. In this day and age, there's just no excuse. I feel sorry for the office workers who fight with that every day.
Guaranteed denial of service. Yeah that'll go down like a lead balloon with system managers and administrators.
Great way to encourage the use of open sourced software. "Yeah, It's 100% guaranteed to fail in a year".
Deleted
Seems to me this causes administrators to be a bit more complacent... to assume the software is fine and that it will 'expire' when it's outdated or has security holes. Administrators without an intimate knowledge of their software is a recipe for disaster.
Speaking of security holes - maybe I missed part of the article, but you can't exactly anticipate them.
But the main reason this won't work is that the logistics are mind-boggling. Unless you can convince ALL developers to implement this idea it will fail.
-Matt
Why not just have it a feature of your package management system?
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.
*** Where are we going? And what's with this handbasket?
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
seriously. what happens when the program expires and no one is maintaining that software anymore and there is no upgrade? also. since its open source whats to stop me from getting a hacker (the good kind) friend to remove the time-bomb code? This all sound like an asinine idea. Much more trouble than its worth.
-
Really, all that would happen is a startling number of web servers would have their dates set in the 1970s.
A warning rather than an expiration might be a better idea
http://www.b.150m.com
Why do admins not update? Probably because most distros do all of the following with updates:
All three of those describe my experiences with RedHat. Until 7.0, it wasn't easy to see if your software was up-to-date. Even with 7.0, you still have to worry about them breaking things. And half the time the dependencies don't work out, especially if I've isntalled something myself. Which is needed quite often, because RedHat doesn't have to great a variety of software in their distro. With older versions, you had to go to updates.redhat.com and chase them down yourself. Half the time, I still have to due to dependency problems, etc. No surprise, anyone ever noticed how hard it is to report a bug in RedHat?
Fortunately, a solution has existed for a while. I have been using it exclusivly for a while.
Personally, I don't plan on the software I write having defects. That is not to say that it doesn't, just that having defects is something I strive to avoid. Given the premise that having defects is a bad thing, building in obsolescense because you might encounter a defect at some point in the future seems to be a defeatist attitude. "I know it will have defects, so it should just stop working." That's just crap.
Good enough software? If the possiblity of a defect is such a bad thing, it would be better to build in methods that allow for that possiblity. Several of those have already been mentioned here. Software that can check for available upgrades or just having a method of notification of available upgrades are just two possibilities.
...that run open source code? If you have automatically expiring software, then the vendor (or customer) would be forced to update those machines in the field whenever the software expired. Even if the warranty you provided the customer expired long ago.
What do you tell them? You can buy our machine and it will expire in 3 years, even if the steel is good for another 20.
managers...why god invented purgatory
And NO!
First of all, if you want something to auto-disable your software at some point in time, that's easily done with a shell script and "at" or "cron".
Second. Imagine this situation: Late at night your server suddenly stops working for no apparent reson - after debugging the problem you find out that some library needed by your mission-critical application just expired and automatically disabled itself - rendering your server useless...
NO THANK YOU!
I've been extremely active on the Internet for over a decade, freely downloading thousands of programs without running Antivirus programs and have never gotten a virus. If I did get one, I'd just spend a day rebuilding and move on.
On the other hand, I have lost multiple MAN-MONTHS of time due to various anti-viral and other security enhancing efforts that broke machines that were my responsibility to maintain.
When you add up the cost in man-hours required to make software more secure, the cost of not having new time saving features because a vendor is delayed on a release while checking out security, the cost of running AntiVirus programs (turning off Norton Antivirus is a HUGE speed boost on running many programs with large data needs even on my 1.4GHz machin), the cost of tracing why such and such program/driver isn't running every time an antivirus program trashes an installation, the cost of doing all of those upgrades, and the cost of finding all of the new problems caused by the upgrades, etc. etc. etc.,,, you find that forced security and running of anti-viral programs has caused far more lost man-hours and $$$$$ than all of the true infections and penetrations that have occurred combined.
I see that this recommendation was written by someone in a security company...
They'll learn soon enough.
How do you force open source software to do anything?
Hell no. If a system administrator is too stupid to upgrade buggy software like bind and wu-ftp for security reasons, he's definately too stupid to realize his dns servers stopped working because bind expired.
Common sense is not so common.
And all y'all took the bait, unfortunately :)
Mr. Lasser can talk about using apt-get with signed packages, etc. but that doesn't really get to the heart of software upgrade woes. My biggest concern is not "is this a malicious update?" (because that's pretty much a solved problem), but rather "what got broken in this software when the other fixes went in?". There's no way I'm going to let even the most trusted package updater touch a production system without my first having manually tested the new code for suitability, read the release info to find out what's changed, looked for situations where the config file format changes, and all the other other "enhancements" that get rolled up into bug fix releases these days.
There is no way that I would accept an untested auto-update of machines that I'm responsible for. So therefore any proposal that would put me in such a position would be a huge mistake IMHO.
Your right to not believe: Americans United for Separation of Church and
I thought Open Source was about allowing a user to do as they pleased with software, hence the term "Free Software."
It seems that since the code is open source anyways, any locking mechanisms put it would be easy to cirumvent anyways... unless your goal is to make the code so not understanable that it would be difficult to change, but that too is against the spirit of open source.
The main thing is though... who's to say what version of software I'd like to use? Maybe the newer software is bloated and unruly... what's being proposed here is just an attempt at forcing upgrades... no thanks.
it would be much more useful to have an optional notification system, either emailed or pop-up in X, or something - "This software was last written/patched on Date X. Consider upgrading." Apache crapping out in the middle of the night would NOT be cool ;)
Come to think of it, auto-notifications would be cool Autoconf option...
Glenn
A program rigged like a time-bomb? Perhaps a program doesn't have a security hole, but is merely not maintained anymore. Under this plan, it dies in x number of years, and suddenly a perfectly good system goes down the crapper. And perhaps the guy who installed it has moved on to greener pa$ture$....leaving the current admins to figure out why something that was never touched blew up in their faces.
I don't even know why I'm replying to this obvious troll of an article. One of the things you hear from every frustrated admin is, "What did they change? This box has worked for three years! And where the HELL is the documentation?"
This is such an amazingly bad idea I think it should be preserved somewhere in a museum, along with the recipe for New Coke and the plans for Galloping Gertie (bridge in Washington that used to ripple in the wind).
There's no sig like this sig anywhere near this sig, so this must be the sig.
First off, why would such a thing need to be limited to open source software?
Second, it's one of the worst ideas I've heard in a long, long, long, long time. What about the software that works perfectly and doesn't _need_ an update? I used the same backup software from '97 until last month. I didn't need to upgrade because the original product worked fine. (I have to switch now because we're changing platforms.) I still use Excel 4.0a because it does everything I need a spreadsheet to do and it needs a fraction of the resources that the current version uses. I just checked the copyright on Excel 4.0a and it's 1985-1992. That means my decade-old software is still functioning perfectly.
And why should people with offline systems need to worry about network security patches? If I've got a standalone system controlling a production line with no connection to any other computer, why should I have to worry about keeping out l33t hackers? "Gotta schedule some downtime because the software is expiring. No, sir, it's the new fashion. We're being forced to upgrade. Yes, the upgrade will work. We spent the last 3 months doing nothing but testing the new software. No, there's nothing wrong with the old software but it will stop working in 3 weeks. No, it's not a licensing problem."
If your admins aren't patching systems that need to be patched, fire them and tell their replacements what happened to the previous admins. Don't try to make me upgrade everything in sight with no regard for the context in which the machine or software is being used just because a small number of people aren't doing their jobs.
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.
Convert RSS to HTML - integrate webfeeds into your website
everytime Red hat or another Distro releases a new version wouldn't a good portion of the software have already expired?
>
Could it lead to messages like this?
"This program will self-destruct in 30 seconds."
No data, no cry
Ick, forced upgrades. Microsoft-like. I should smack you over the head for suggesting this type of thing. Goes totally against the idea of open source.
Brielle
No.
Suppose a system administrator wants to leave an old version running for some reason? That's their decision. Linux is useful precisely because it doesn't have to be upgraded every five minutes.
It works. Leave it alone.
I feat that it would have a very negative impact on the apache stats. on Netcraft. Imagine it, from day to day 25% less webservers on the internet. :)
If someone isn't updating their software, it's because they are either lazy, or they don't care. If the software expires at a given date, these two types of people, I feel would be inclined to simply set back their system clock. If this causes the creation of a mobius, and we're all forced to relive the 80s I don't think open source software will ever hear the end of it.
While it would be beneficial to force such an account, it is on this same ground that we constantly roast MS. Forced software upgrades under the auspices of improved security, stability, etc.
Consulting with dozens of corporations, I have seen many run old versions of anything from compilers to CICS regions to security patches. Sometimes for business reasons (cost) and sometimes for compatibility (upgrading to a current version causes incompatibility with their client's software). Whether we consider them legitimate, the business does and it is critical that we not add to the issues of OSS adoption.
While Jon was speaking in general terms, and the devil is in the details, his idea does have merit. The implementation would need to allow for the positive acceptance of risk by the software user. If I have a specific need to run netSecsoftXYZ beyond its expiration, I should be able to do so without it shutting down. In addition, I should not need to recompile or reboot to continue operating with the existing version. In this way, I acknowledge that I am running an older version at "my risk." The responsibility for my choice would then be placed with the organization.
This does leave the potential for abuse. However, we cannot avoid the potential misuse of something to halt its development. Just as we want to be able to make backups even if the device could be used to illegally copy software.
Something like X does when it boots. As shown below.
XFree86 Version 4.1.0.1 / X Window System
(protocol Version 11, revision 0, vendor release 6510)
Release Date: xx August 2001
If the server is older than 6-12 months, or if your card is
newer than the above date, look for a newer version before
reporting problems. (See http://www.XFree86.Org/FAQ)
Build Operating System: Linux 2.2.19 m68k [ELF]
Module Loader present
(==) Log file: "/var/log/XFree86.0.log", Time: Tue Dec 11 20:15:04 2001
(==) Using config file: "/etc/X11/XF86Config-4"
To E-mail me, replace the first period in my domain with an @
First I think the word "All" is a bit strong. Sometimes an old _trusted_ bit of code is a GOOD THING(R).
... Im getting a little long in the tooth . . . please upgrade me
Maybe instead of just crapping out like some piece of proprietary beta software it should start putting little messages in the logs as it gets older:
Apr 3 16:27:09 pc19 crap[666]: crapWare v0.1234
And these messages should appear more and more frequently over time
Kevin
Thoughts on tech, Software Engineering, and stuff
Having a system like this implies (a) there will be some centralized application-version database somewhere, and (b) your system must check in periodically for updates. Could this database be for all non-OS applications on many popular distributions? Perhaps.
SuSE has their update stuff that acts like Software Update.. you can just run it whenever you see fit and update software that way. Time bomb software isn't a good idea. Besides, were it open source, we'd just remove the time bomb code anyway, right? :-)
Why not have an auto version checking feature? That way you're always in the know about the latest version and not forced to take any action you don't feel like taking.
"You have version x.xx, the latest version is y.yy; we recommend that you consider an upgrade"
"Go to blah.blah.com/blah to download"
Jon Lasser, you are the devil! Forcing people to migrate is pure evil. Obviously Jon hasn't thought this through objectively.
They are reasons to run old versions of software. Like hardware requirements, and the fact that as products progress, they sometimes add requirements that might not be met by the current configurations. That could doom some admins/companies/people or leave them wondering if the update is worth invesment over the exposure of the security risk.
Jon Lasser is clearly someone lacking on implementation experience
...they'll squish your head between their hands (pop! goes your noggin!) or smash through a wall, grab your hand and one by one, break your fingers so you can't type the commands to update them, letting them die in peace.
Well, trouble is, when you are out on the highway adn all the oil drains from motor, you jsut bought a new motor. Or conversely, if it does it as soon as it's parked, then I guess you are walking home from the mall. An extreme terminal solution isn't always the best or most practical - just the most final.
- If This Peace Is Fictious, I Shall Destroy It
I can just see it now ...
Detective: How did he die?
Coroner: Well ... he was running 2.0.3 of UberPace. You know, the Open-Source pacemaker software. Well ... he should have upgraded, but forgot.
Karma? Karma? I don't need no stinkin' karma.
Maybe adding something new that makes the software stop working is a bad idea. Perhaps a mail to root@localhost a la cron would be a good idea, but software that auto-updates or auto-dies is a bad idea. What if a Linux kernel auto-updated to 2.4.14? (Or was it .15? The one with the serious problem, you get the idea.) A monthly e-mail (which can be turned off, and the e-mail tells you how to turn it off) that provides the URL of the applications patches would in fact be useful; there's plenty of software which doesn't merit a subscription to a mailing list yet still could pose a security or stability risk.
Ultimately, there's no substitute for a competent administrator, but a bit of warning can't really hurt anybody. Shutting it down automagically takes the mickey out of the software and would be a Bad Thing.
Mike.http://www.yourmothernaked.com
If this ever hits the world in any form it will be patched out of existing before the first user download.
If I'm runing a cacheing DNS server on my loopback address, it's a waste of effort to upgrade it even if it has as many wholes as a wheel of swiss cheeze, or worse yet, a M$ OS. Also, I disagree with the premise that "most sysadmins" tend to neglect security patchs & updates. Besides.... It's like the counterproductive logic involved when M$ releases a patch to protect agains DOS attacks that crashes 25% of the boxes it's installed on. Here your talking about crashing a box semianually to protect the person from getting hacked. Basically, the person was allready hacked when they installed the termlimited software. Trojaned if you will. It really must be a slow news day.
OK, I think we'll all agree that the vast majority of servers that've been exploited and abused for a long period are in the hands of luser admins. Savvy admins get burned all too aften as well, but they usually catch it and patch their systems before too much time has elapsed.
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.
-
I am sick to death of folks using technology to try to solve people problems. All this indicates is a flawed understanding of the problem.
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
Rather than having it expire, why not have it query the "parent" server where the project is maintained. If there is an update, the software could automagically generate an email or equivalent for the local admin saying that a new version is available. The admin isn't forced to update it but does receive new version notices. The package should probably also generate a message for the admin if it can no longer contact the parent server (i.e. libET can't call home.. sorry, couldn't resist..)
All of these would need to be configurable but that's for the individual admin to determine.
Planetes
"One World, One Web, One Program" - Microsoft Promo Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitl
howzabout if it sits around to long, it sends a message to your boss to replace you, the lazy admin, you frickin' slacker!
that'd be preferable.
thelocust[dot]org
How about a "Critical Update Notification"? Microsoft has something like that for Windows, looks like the best way to keep the admin informed about new vulnerabilities...
Excuse us Jon, but April Fool's was YESTERDAY!
Even if all insecure Open Source software would have been disabled, there would still be plenty of Closed Source software some of which has proven to be even more dangerous to the Internet. What is more, manufactorers of Closed (or Shared) Source Internet software would discredit Open Source competition as too risky to leave alone for more than a few months, and claim to "have the way out"...
Every upgrade carries with it the risk that it will completely screw your system. So if you have a critical system which is working fine why should you risk jeopardising it with an upgrade ? I think it's a crap idea.
Let sleeping dogs lie.
If it ain't broke, don't fix it.
just my 2 cents worth. you now owe me 2 cents.
Mandrake's RPM system (since 8.0??) has a nice little feature called "Mandrake Update" that can check for a) security problems, b) updated software, or c) bugfixes, or an combination. I just run that every few weeks. Your request is fixed, depending on what package manager you use.
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
#!/usr/bin/perl -w
die "program out of date, check web for update\n" if (time > 1049408843);
die "waiting for updated version to become available\n";
check out Simple Internet Version Control. Honestly, I can only remember three apps I've ever used that included it, but it's a protocol that allows a developer to guestimate how many users have installed the app and keep users informed that there's a newer version available.
that's dumb.. not every opensource software package contains security holes. some packages, i.e. games, don't even do networking stuff.
it'd be like:
oh shit, my opensource othello program is 2 years old as of today and won't work until i upgrade it. too much like a microsoft way of thinking to me...
Companies aren't allowed to sell, give away, or otherwise distribute hardware or software.
That way the sys-admin will really need to develop a cozy "relationship" with the harware he built from scratch, and the sofware he toiled over. Only through this type of "do-it-yourself" administration, can we be assured that sys-admins really know what's going on in their (literally) machines.
</sarcasm>
-... ---
Netrek clients had expiration times embedded in them back about 8 years ago. The theory was similar, that there were probably bugs and the developers wanted to force people to update periodically.
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.
is find the code that implements the expiration system and remove or disable it.
Anyway, even if you could do that, how long do you make the current version last. There have been way too many times when code is released and within the next couple of days and major bug is found. Using a time based expiration system would simply not work.
oops! heh! heh! I meant the day BEFORE yesterday!
:-)
This is a good idea. However, it should be easy to turn this feature off (but for God's sake, NOT behind a simple GUI!). Software packagers (RH & Co) should leave the default on, at least for the "critical" packages. That way, security becomes a more concious choice, not just a silly "medium security - maximum security" checkbox.
When it's time to install an upgrade, I, as the sys admin, will do the regression testing, sanity checking, and all that stuff. When I'm happy with the upgrade, I'll roll it out to my servers and desktops through automatic means.
My users, on the other hand, are forbidden from installing patches and upgrades on their own. Who knows what it will break? And, as a corallary, they don't need to be bugged about things that are out of their control anyway.
Vintage computer games and RPG books available. Email me if you're interested.
Wouldn't it be great to have software that expired on a life critical piece of equipment. I can see the doctor now, "I'm sorry, your son or daughter died because some piece of open source software expired."
There are also those of us that have to wait until we have an opportunity to bring down a server, and can't afford having a system go down before that. I'll take a risk with the hackers...
GeneralKael -- Slacker Extraordinaire
Seriously having an option on a security/network package that notifies someone via email if a app gets too old would be a good idea.
Automatically doing stuff on servers needs to be left the people that know what they are doing, like Microsoft or perhaps the dude or dudette that is paid to manage that server.
given the code of an open source application, it should be pretty easy to just comment out the part that expires. if you have the software checking a server or something to see if it's still valid software, just comment out that stuff and then recompile. seems like a waste of time, but i am sure someone has implemented it before.
Why read the article when I can just make up a snap judgement?
Make something similar to Window's update so that its painless to update the software. Everyone always claims that linux is in every way better then windows, how come I need to rebuild my kernal every time there is a patch available?
And for the jackasses that will invariably respond with "Its fun" I will save my self the time and just tell you to fuck off right now, because I actually have stuff to do with my free time.
If it's a networked app, just make it phone home every so often to see if it needs updating. Then email you or something.
Maybe, if you configure it to, and it phones home to learn it's got a big hole in its chest, it could close itself down until you can fix it.
Or, why not fix it automagically? I'm tired of hunting RPMs.
...or maybe not.
I would have to agree that hiring better sys admins in the first place is a viable solution. However, there are boxes sitting in the basement of some companies that people don't even know about most of the time and paying a sys admin to sit in front of it is a waist. And when the company eventually does realize it exists months or years later, it's only because it stopped working.
If there was some OPTIONAL scheme to give the developers of software a way to update their own software (updates as in fixing buffer overflows, etc) out there without sys admins needed. In other words, leave it up to the developers of the software to EASILY fix their own horrible mistakes. This does not include upgrades - more like fixes.
In a way, giving the software the ability to phone home to its developer for critical updates would be extraordinarily beneficial. Of course, this will easily fail if developers abuse the system and do more than just fix bugs without changing architecture.
I can see a single, open source system that all developers can use as the perfect solution. It saves money, and it gives the developers the ability to compensate for their mistakes.
Agreed, there's plenty of room to criticize this.
He's got a good idea, but I don't agree with the implementation. This has probably been submitted, but it seems to me that instead of the software just outright not working, after a certain time, it would simply display a message every now and then advising you to update.
This could be a good task for some sort of mini-program to be included in all kernels that collects these messages from all programs on the system and displays them, so you would run "progupdates" or something and a list would be generated of everything you need to update. This program could also be made to connect to a database and compare version numbers with a list to determine if a new update is available, and then advise the user that it is available. Imagine it sort of like Battle.net, on connect, it checks your version against the server and informs you if your version is out of date. (Unlike b.net, though, software patches should not be required, rather, just advised).
-Colin
Since the Sysadm couldn't manage to maintain the systems, he timebombed them to ensure their reliability.
Assembly is the reverse of disassembly.
When very old, someone may have found how to exploit obscure holes in it, or there's a better way to achieve the same task.
So rather than applying a single expiry date to the whole program, a better policy might be to apply the expiry dates per feature.
When a beta feature's code passes, it can be given a long expiry date. As each feature reaches its expiry, it can be reviewed, and if it is still satisfactory, the expiry date can be extended.
This way, you won't be affected by the expiry system unless you use the brand-new or unmaintained parts of the program - the bits that are most likely to go wrong.
he wasn't being serious
it's sarcasm
Don't expire, just start logging messages when the software has reach some predetermined age. Like, once a build gets to be a year or year and a half old, start logging a message to syslog ("Yo sysadmin, I'm kind of old. There might be updates. Look into it.") about once a week.
Just an idea.
Well, maybe not. But it's close.
I agree that triggering an upgrade, or forcing users to remove offending code on their own is too restrictive, and against the spirit of Open Source, but ... isn't this something we'll all have to accept in the web services world? Regardless of whether the service is written for Mono, .NET, or Java, we will have to become accustomed to "upgrading" to newer versions, without our consent or perhaps even knowledge.
Is there an acceptable policy we can come up with now to deal with this forthcoming issue, besides: (1) recompiling the source and having it reside on our own machines (which defeats the point of web services); (2) having multiple versions of every library available by the author for years on end?
I see this more as an issue for the Open Source community than for the proprietary platforms, since their answer is likely to be to force the upgrade, without your consent or knowledge.
...but perhaps network-accessible daemons should check magic hesiod (DNS) records before servicing requests, disabling themselves if the magic hesiod record says "You're insecure. Go away".
I don't want planned obsolescence, independent of whether software is secure or not - that would MASSIVELY increase our workload here. But I wouldn't mind software that automatically turns itself off when the maintainer says "that version's no longer secure".
Sadly, there might be a temptation to use this for forcing upgrades that aren't security-related. That'd be a mistake.
It's possible there should be a config file that specifies how important security is to a site. If the config file says "security is priority 0", anything even slightly insecure is disabled. If it says "security is priority 100", only really critical stuff (like remote root) is disabled automatically. 75 might mean "remote, but not root", 50 might mean "local root", 25 might mean "local but not root". Maybe priority 200 should mean "never turn anything off, ever". Or something like that. Maybe there's no good reason not to use a larger maximum, like 2^31 or something - there may be a desire to squeeze more priorities in there, and it'd be easier to expand at the outset, and there's not much penalty for making it a wide range from the start.
If a service is already internet based, perhaps there isn't that much reason not to depend on the (cached) DNS in this way. If the hesiod records are cached, no big deal - that's still much better than running insecure forever. The maintainer can also control the TTL of his/her security-related hesiod records I suppose.
The config file should probably also say what to do when a yea or nay hesiod record can't be found, because someone could pound the maintainer's DNS servers into oblivion to gain access to your insecure stuff - for some that means "turn it off fast", while for others it means "Eh, it's probably just another machine that fell off the net. Service requests anyway".
This kind of makes a "is this version later than that version" comparison function desirable. Alas, software packages are numbered by many different methods, so there is no one true comparison function for this purpose. However, if a library is developed for this kind of check, it could include comparison functions for the predominant software version schemes.
I suppose the software should mail someone if it turns itself off. This could again be specified in the config file, defaulting to root@localhost, postmaster@localhost, and anyone else who seems distantly relevant. You might even wall the system about it if the admin was too lazy to specify an address for notifications.
There's already been a lot of talk about what a bad idea this would be if every service on your box ups and dies because it thinks it needs to be upgraded, nitification vs. death, etc...
I don't recall anybody talking about what it's like migrating server *admins* though... If I'm coming in on a new admin job, I think I'd like to have some kind of system in place where I could run a check on everything running on my system and have it report version, install time, last modification to the config files, etc, instead of having to hunt everything down manually.
Here's my suggestion: Install a time-based notify bit with each new app or service installed on a machine. Make it part of the RPM manager or something. Make it optional - I don't so much care if there's a new version of Armagetron available, but anything that has to do with a critical security or connectivity service, yes, please. During install, I click a little option box that says "Remind me to look in on this service in a few months."
A few months later, the admin gets a notice - time to look and see if there are any patches to (whatever).
And if the server admin goes on to another job and someone else steps in, he or she can just query the application installer - how long has it been since the last update to the firewall? Or the Virus scanner? or whatever? His transition into the center chair just got that much easier.
I mean, with all the non-admin projects my own poor little admin gets stuck on, it's a wonder he can keep up with security issues at all. It's easy to get distracted from your actual job by orders from the people at the top who forget that you are, in fact, just one person. It's that devilish "other duties as required" clause that gets built into every job description...
Do it at the level of the installer, or the compiler, or whatever you use to turn a downloaded file into an executable thing. This time monitoring code is only relevant when somebody installs it, after all. And if the standards (if any are actually established) change, then every programmer in the world has to keep up on it... Let the programmers program the app. Let the admins admin the app running on their box. This is an admin feature. Let it be so.
GMFTatsujin
Never assume that a system is secure, especially if it's just behind a firewall. Firewalls, like everything else, should be expected to fail.
Hell no! Here in the land of Big Pharma we have this peculiar thing that they call "Computer Validation". It has virtually nothing to do with "validation" in the ordinary sense and more to do with huge piles of paper and endless meeetings than it has to do with computers. But, there it is. It means it costs huge amounts of $$ to change or improve anything. I have to regularly deal with stuff that's 10-20 years out of date (yes, including many of my cow orkers) because it's impossible to update it without making the FDA freak out. Don't make one more thing where I have to fight the obsolesence versus costs of re-validation battle!
-- your Web browser is Ronald Reagan
The software is mine
You couldn't be more wrong. Sofware is NOT yours unless you wrote it yourself and you maintain all rights to it. The Linux kernel and the associated GNU utilities that make up a distribution may be installed on your box, but it is definitely not yours. You are licensed a copy, through the GPL. You may modify it, redistribute it, sell it, etc., sure, but you cannot claim ownership of it.
Hate it.
;0), so this is purely hypothetical.
What really sucks is when you maintain about 300 boxes that all are the same (think of a web server farm, in my case). They will expire at the same time, and you get 300 messages (maybe every 10 minutes like ssl certs do). Then, you have to upgrade all 300 within some abritrary time.
Of course, you probably have already upgraded to get security updates (unless you use IIS
room101 -- how much can you stand before they break you?
(they always break you eventually)
Timeouts are a bad idea. I have several systems set up which are in remote locations, providing various straightforward services, which are not being maintained by anybody. They are headless, power up into an operational mode when reset, and would cause a severe headache if I had to visit them on a regualr basis for no reason other than someone else thought it would be a good idea.
Thanks, but no thanks.
About the only concession I'd make on this point is if there could be a configuration flag at compile time. If a vendor chooses to recompile utilities with the timeout enabled, that's fine, as long as I can recompile the same utilities with the timeout turned off.
[root@owl.tyrell.com] /usr/local/apache/bin/apachectl start
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]#
--- Hot Shot City is particularly good.
You could have the option to start a daemon that would check this. It could look at program metadata on regular intervals or when the program starts and warn someone every month that these programs are "expired". That way after 6 months of running a server with no down time, the "Tron" job would email the admin a report saying that these programs in the ps list have expired security dates and need to be replaced. Just a thought.
...just have the program check for an update and inform the SysAdmin instead?
I'd much rather the software send me an e-mail every hour than have it suddenly shut off. UP is much better than DOWN!
So instead of being slightly out of date, it will break completely. That idea is right up there with the lead balloon...
-me
Love many, trust a few, do harm to none.
...and take the stupid thing out.
Gregor
This could be part of the package manager, or it could be a general purpose service of some sort that programs register themselves with on installation.
Seriously, what's with all the sci-fi/fantasy analogies?
by the nature of open source, what's the point ? I mean if I want to continue running it, I'll just code out the expiration part. As I'm writing this though, I suppose it's probably easier to update rather than hacking the code.
It seems rather lame though, if the software has been free from issues to make the user be proactive about going and disabling this.
I used an old secure thing
I just got rooted
I upgraded and learned stuff
Old things run well and are small
Just Firewall them off
We don't need to upgrade please
I'm not Microsofts Monkey
Don't force things on me
Look at their predicament
I want a stanza
I want another haiku
Oops I broke it
so instead of the possibility of security compromise, you have a guaranteed interruption of service? hahaha whatever works i guess... -mikey
Why not rather build a better system for updating software? Perhaps an automated system of some sort that "patches" software as updates become availlable.
A feature like this could be made optional, so that SysAdmins of general users could turn it off if they wanted to. This would alleviate concerns that "Open Source is about not forcing you to do anything." and would also prevent mission-critical software from going offline while it is patching itself.
Programmatically speaking, a system like this sounds feasible. There would have to be some standards or for where updates could be obtained from, or "trusted" update sites.
Go to Freshmeat sometime and click on "Random Project" a few times. You will notice that, of all the open source projects in the database, most of them have no vital signs.
It's pretty pointless to put any time-sensitive features in your product if, as chances may be, you probably will stop working on it at some point and won't have the interest or time to pick it up again.
Don't count on somebody else maintaining your code for you: the other interesting statistic on Freshmeat about most projects is that nobody else really cares about them either. Even once-popular programs tend to fade away over time.
All too often I've seen software developers simply decide that they no longer feel like supporting/updating their project. I'd just LOVE to see all the turmoil when the developers of something important decide to drop their project and leave a 2 month timer inside... (dripping with sarcasm of course)
::snarls and random growling::
aside from that I hate being forced to do ANYTHING with my computer that I don't want to do... hell, it's my machine, I paid for all of the components, I chose which software to install...
-----------------------------------------
Remove the Greed which plagues mankind.
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.
Milpitas, CA 4/3/2002
Following the leadership steps recently left behind by such visionaries like Steve Christey of MITRE, Chris Wysopal of @stake, Inc. and Jon Lasser of SecurityFocus, thrillbert of Slashdot fame, today introduced an initiative that could have far reaching effects on the slashdot community. The Anti-Troll-Multiplicity Initiative (ATMi) is aimed at minimizing the size and number of troll posts allowed on slashdot.
"It's ridiculous! I have to go through at least 80 troll posts to get to the +5, Funny posts." remarked thrillbert, "this new draft would give all trolls guidelines they would be required to adhere to, or suffer being called Uncooperative Trolls".
When we contacted CmdrTaco, he was quoted as saying "umm.. heh.. heh.. I dunno". No other slashdot representative was available for comment at this time.
---
Ever found something in other than the last place you looked???
Instead of expiring, how about building into all
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
Play with my webcams and lights here
If I am remembering correctly, doesn't UCITA imply that software's respective authors are responsible? If that goes through, the expiration idea is out the door. Can you say, detrimental reliance?
So the question is whether people will prefer this? The answer is that the people who regularly update their systems will likely think it's a good idea as it will prevent anything from slipping through the cracks. But the lazy ones will still hate it because (as with all the other mechanisms they ignore) it forces them to pay more attention.
Seems kinda silly to me.
BladeRunner replicant nothing, god has set us all to expire, and even pay taxes now. So go procreate so we will have Human version 10,764,231,441. Even MS will never get that high on versions.
If the user only knows how to handle binaries, then they have proven that some hand-holding is necessary and thus the software will do some of the 'work' in keeping the user up to date.
So as long as the user is knowledgeble enough about the ways of advanced computer useage, they will have the ability to do anything they want with Free software. If they need hand-holding, they will get it whether or not they want it (until someone recompiles it without the timeout.) This also might encourage them to educate themselves in the ways of coding, thus making them more knowledgeable overall.
Compiling from source you could apply one the patches that would inevitably come out to remove the self-destruct code. It's more difficult to coerce users of open source than users of closed source binaries.
and inform the user/owner.
That means that software has to be connected (there's NO such thing as a security hole if you're unplugged,) and somebody (a university somewhere, or Kagi, or another commercial entity that charges software producers who can pay [not free ware] a tithe,) has to set up a registry for ALL software.
All systems should run over the net to the registry once a day and see if there are any updates to ANY installed software and when there are, inform the root and/or the system owner. S/He'll then have a decision to make.
That also means that only legal, registered copies can request updates, patches and fixes and if your system is illegal and unregistered, you're on your own.
Simple enough, just send all those registration cards to the registration point and you can check-in. Don't and you can't.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Quit thinking like Microsoft, and just spend that effort elsewhere, like eliminating potential threats, temp race conditions etc?
Honestly, there are times when you can't upgrade a machine. Sometimes another application would rely on an older version of sometime.
I see where the idea is comming from, its just the wrong way to do it.
While I agree that everyone wins when sysadmins take an active roll in security (except crackers), but what if the new version of software isn't ready by the arbitrary date - or has no software ever missed it shipping date before? :)
You shank my Jengaship!
I too use the same security philosophy (as the post to which you responded), that anyone who can get by my firewall basically has the run of my LAN. I don't excactly open up all my internal machines, but I don't lock them down to unuseability, either.
/.'ers
fall into this same category.
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.
A: No. Next question.
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.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
If anyone ever put an experation date on open source code, they should be knocked upside the head with a blunt object. The onus is on the sysadmin, not the friggin' coder. The leason in this is: don't be an overzealous twit. People can't be that stupid, especially if they are using open source stuff ;-).
Where someone develops an exploit to set your forward and expire all your software.
Why not auto-update?
Why not windows-update?
You know, when I want to update something, I will. But when dns is critical to my situation, and hole number 8000043 comes up and needs to be patched, I need to test it first, before I ruin my bind and decide to blow all my customers out of the water.
"If it ain't broke don't fix it"
That idea is still new to some people I guess.
That, and it would make OSS less attractive to businesses that don't want downtime, and don't want their secured software updating itself to a potentially unsecure new version. "But what if a security hole is found!" Well, that's what a Network Administrator is supposed to be aware of. There's no cure for people who don't know what they are doing.
Note to slashdot editors: Don't accept story submissions from Microsoft staffers.
Windows 95 had to be re-installed about every 6-8 months in a heavily used environment, because it self-destructs and crumbles apart. NT Server 4.0 fares much better, we had one Compaq Proliant that was installed with NT4 in 1997 that did absolutely nothing but serve network printer queues and has not had its configuration altered in years, however it finally came down with the operating system equivalent of Alzheimer's or CJD/BSE last autumn and we had to fdisk/format/reinstall to fix it. The other four NT4 boxes that were installed at the same time and got a lot more varied operations and configuration changes during their lifespan only lasted from 2.5 to 3 years before they suffered nervous breakdown. Now we plan on a re-install every 2 years of continuous operation.
One by one you have to recompile the kernel on each computer as they "expire." Could be worse, the nfs server could expire leaving all the nodes unable to boot. Expiring software, great idea eh?
When all freedom is outlawed only the outlaws have freedom
While I agree with the rest of your post, and I think some people are using medication to solve the symptoms of their problems rather than fix the cause, I myself have a mental illness that is almost entirely chemical based, and therefore is impossible to treat with anything other than medication. Sometimes the easiest solution is the right one.
Just think what happens when an exploit is developed to set your *clock* forward.
and ruin my uptime?! no thanks!
I believe there are other solutions.
/etc/security.snooze to go another "x" months or update your darn packages. "x" could be larger for openbsd and shorter for anything that depends on smoothwall ;)
For instance, some cars will tell you when they need maintenance. I don't remember if it was honda or bmw that would cover over the odometer when an oil change was required.
There could be a message that appears:
This system has gone more than "x" months without a security update. Please remove
Another solution is the way the (commercial) redhat network works (I don't work for them, I'm a subscriber). I get periodic updates about the packages with security holes. I'm not sure if the email I have is tailored to the packages on my machines, but I can easily check to see what machines are up-to-date and what machines aren't.
Also, I can see "expiring software" being used for evil. Let's say a little company open-sourced some software, and it expires. When you go to download the latest version, you find that they've forked off a pay version and don't support the free version anymore. etc...
Also, maybe updating your software could be a way for people to compromise systems when they update.
Just some thoughts.
If it were a default setting that could be overriden, then it might not be that bad of an idea.
...would be to have expiration dates on the administrators... if they don't update the software often enough, they get canned.
Let's hope that security professionals don't start down the path of Technology Is The Answer that the MPAA and RIAA have chosen. The parallels are too obvious to ignore.
Jake
Dating: while( 1 ){ call_girl(); get_rejected(); drink_40(); } return 0;
Gnucleus has a better setup. Each time you load the program, it checks the gnucleus server before connecting to gnutella, and if any part of the program has been updated, it informs you of the update and tells you a little something about the update, what it will do for you, and then asks whether or not you want it. That's not a bad idea.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
Linux 2.2 has long passed the spoilt milk
stage. It should be eradicated with prejudice.
In fact, even leenux 2.4 or leenux 2.5 isn't
much better. leenux is still no good. For
desktop, run Windows or FreeBSD. For servers,
run Solaris or FreeBSD.
what about once thriving, but now defunct software? what happens when it simpl ceases to function, and there is no new version to upgrade to because the project has been abandoned, or bought out by a large company and turned proprietary? I can just see tons of NuSphere's coming in trying to buy up all the open source projects that are about to expire, just so when you have to upgrade, you also have to pay them a stinking $299
Great, so now instead of people running old software, we're left with people running machines with the wrong date/time in order to fool the software into thinking it's still within it's life. Is that really progress?
Yes, I was being sarcastic.
I don't know how to feel. I'm happy it got modded to 5 but I'm a little sick to my stomach that it got modded up as "insightful".
I dont think software should be attempting to second guess what a sysadmin is doing. If their apathetic enough or dumb enough not to keep up to date, then they can only blame themselves if they get hacked.
If there was a time bomb in software, then that would mean the software would definitely be useless in, say two years, instead of POSSIBLY having a bug that MIGHT cause a problem.
While a periodic reminder to update embedded in certain types of software where interoperability was key would not be a bad touch at all, being forced to update it absolutely terrible. The reason I use opern source at home is because it gives you freedom(libre). This would take some of it away.
Its not Blade Runner...
Anyway, very bad idea, because the savy would comment out this check.
I still run an older version of because patching it also means completely upgrading the version of linux on the remote P120 with 48M RAM it is on... I dont want to go through that pain.
B.
/\/\icro/\/\uncher
Or sendmail, KDE, reiserfs.
NOTICE: this version of brandA network driver has expired, to reenable your network driver, download the latest version from www.brandA.com imediately.
Bullshit. I thought this died with shareware?
I think you underestimate just how much I just dont care.
What if there isn't a newer version of software when the one you are using expires??? What happens then? Is it time to bring out the old hacking tools...
Instead of having program expiration, what about a notification system that is package independent so it works with all distros? When the system is booted up the user is alerted to new updates automatically. The app would have a link to download the update via the web and also have a link to the distro specific package updater. You could even have a modified version for corporate lans so update alerts for multiple boxen get sent to the lazy sysadmin's system.
The software should not expire. This feature could be implemented on distibution level (it pretty much is in Debian), but the software itself should not worry about the updates. It's the administrators job and the distribution can give him/her a hand. Forcing upgrades is wrong and evil.
Automated expiry is stupid. Software devlopment (and companies) is unreliable. You're absolutely right, products can cease to be supported any time. Even with Open Source.
Another obvious reason is that you should not include self-destruct functionality for software that is going to be used in a production environment. I know some people will disagree but I think a badly patched server is still better than a dead server. (Hell, some equipment is only accessible via remote network tools. So what if the network code or the remote control software expires. This is irresponsible.)
A much better way would be to automatically NOTIFY the admin when a product is out of date.
If you want to take that one step further there could even be an automated update daemon - i don't know - but that's very likely going to have security issues by itself.
Code that deactivates a running production system without admin input is definetely not an option. (Well maybe on a MS server, but that's another story entirely.)
Last I checked, if the SysAdmin was in charge of a critical system, it was his responsibility, nay, his very reason for existance, to ensure that the system was secure. Every book you ever read on UNIX or Linux that is written for SysAdmins tells you that you should be constantly monitoring your software and checking for patches and updates. If I let my software go old, it's for one of two reasons:
a) It does what it needs to do and there aren't any security flaws I'm concerned about
or
b) I don't like what was added into the new version
either way, the desicion to upgrade or not is in my hands, not the programer's and that's the way it should be.
T Money
World Domination with a plastic spoon since 1984
theres an old saying
"if it aint broke dont fix it"
not every program needs to be upgraded.
at is a perfect tool for this. No software modifications need to take place, people can use it any time they want, etc...
Example:
echo "Hey, look into upgrading Apache on this host." | at now + 2 months
-- The world is watching America, and America is watching TV.
I didn't come to Open Source to be told what I can and can't do with my system(s).
-- @rjamestaylor on Ello
But what about when you get the "mozilla-syndrome", where updates don't come around as fast as the timebomb interval?
N.B.: The Mozilla build you are using was made more than three weeks ago. If you are going to report bugs, please download and use a newer build.
Umm, yeah, it's more than three weeks old, but it's also the newest version...
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.
Apparently, he didn't pay much attention while watching "Blade Runner" or he would realize that a major theme of the movie had to do with the act of "expiring" the replicants being WRONG. Expiring software is an equally flawed idea.
Whoops, meant to hit preview and accidentally hit submit. There should be another echo in there:
echo 'echo "Hey, look into upgrading Apache on this host."' | at now + 2 months
-- The world is watching America, and America is watching TV.
Oooh! I got it though...your backdoor password could be something really cool and cryptic like NetscapeEngineersAreWeenies
Que Deus te de em dobro o que me desejas
[May God give you double that which you wish for me]
First we have @stake sell out in the worst way imaginable, trying to get us to confirm to Microsoft doctrine.
Now we have SecurityFocus trying to turn our software into Microsoft product.
FUCK!
Let's protect the people from themselves!
Stupid idea. Just make the sysadmins liable for updating, in a "lose your job" sense, not "let's sue them" sense. Those who do the hiring and firing need to be up to date on whether the software's up to date (Ha ha). Naturally, the supervisor only checks when something bad happens, and then heads roll. But I guess that's the way business is.
All of this is based on the assumption that totally nofunctional software is preferable to software that might have some problems.
Worst idea I have heard in years.
Ok, lets say the configuring the expiration isn't available. You're just a poor guy out in the middle of Africa with no internet connection, and your friend mailed you a linux CD. The thing expires, and now you have no way to update your system. You have to wait a couple of months to get another CD from your friend.
Or, let's say you get owned by h4x0rs. They don't need to mess up your filesystem, or trojan your machine. They can just take things down by changing the date to some time in the future.
Warnings are fine. Heck, if you really wanted something useful, make some kind of update daemon. Register your software with the daemon, along with some site to look at. Every time you connect to the internet, or once every so often, it could cycle through all the sites and generate a report. Notices for feature updates, Warnings for potential problems or major bug fixes, and Critical Updates for major security flaws. Then the admin will have the choice to act on this information.
Looking for a computer support specialist for your small business? Check out
Old open source software like that already has an expiration date to it. It's just not carved in stone. The thinking is that if a lazy/incompetent sysadmin lets it lapse, sooner or later a cracker/kiddie will come along and cause that system to cease functioning.
( rpm -a -q && cat /path/to/blackList ) | sort | uniq -c | grep -v 2
would list ever package on the black list. Now all a person would have to do is make sure the list is kept up to date. You could do the same with a white list, but it would be a bit more difficult then. Both have upsides and downsides. For remote attacks, a simple script that does the attack would probably do the job. A lot like a Satan does, or netsaint. I haven't kept up with either of those to know if they are still any good. It would be easy for RedHat and/or Debian to create a tool that will allow you to check outdated versions of a tool yourself.
For custom done scripts, use file, see if the it is an ELF binary, do a MD5SUM of it, then check a known list of MD5SUM's that are bad binaries. Okay, that really screws anybody who compiles there own and the tool puts in the name of the machine or __DATE__/__TIME__ or some such.
However, if you had a trusted source for binaries, it would work out quite well. Naturally most security oriented people compile their own. But then again they don't have these problems, they keep up to date.
Kirby
Sorry folks, this is a complete non-starter. I decide when I'll upgrade, not some programmer who can only hazard a guess as to when it will actually be necessary, or when I will want to. Like I really want my system to just stop working for no good reason - if that was what I wanted, I'd use Microsoft.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
I hate showing up after the party is already winding down.
Ow. The thought that someone could even conceive of this principle hurts my brain. Why do you think so many law firms still use WorPerfect 5.1? It's fast, the cost has been amortized, the templates have been in place for years and the thing just works. If there is no impetus for upgrade, why bother?
This is a lot like term limits for getting rid of politicians. Doesn't matter how they're doing - we don't have time to figure that out and use our vote to replace them - just boot them out before they exercise that stored potential to screw up.
Try to get your hand in that position. I dare you. (All of those ()s are fingernails, right?)
What do you do when your tcp/ip stack expires? You won't be able to download any upgrades because you need ftp access to download the upgrade, which needs the tcp/ip stack.
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
Much better to update when new critical update is available. M$, Apple already have such service embedded in the OS.
OSS should use the same idea in OSS style - we should standardize a protocol and local API for such background procedure, which should run at the boot time (and later by crond) and then check online for available updates for all its packages-subscribers. If update is available - either send a notification (syslogd, email) or download and send notification. Who are subscribers? Software packages included (registered) in the config file of such Update-Checker.
It is very simple idea. And there are already some similar proprietary services in some of linux distributions. They are incompatible to each other. So all we need is just come to some agreement about a local API (how to register-subscribe packages for online checking) and a protocol (i.e. should we use some LSM descriptors from FTP servers or we should run some notification daemons where developers can register their packages and trigger availability notifications).
No, no, no...
This suggestion has no appeal at all to me and has the wiff of the sleaziest software vendors I have had the misfortune to deal with in the past (commercial software, not shareware). While I understand coding and end time in shareware UNTIL THE PACKAGE IS REGISTERED, I will not buy time-limited software for myself or for my employer. I'm afraid I would apply the same rules to Open Source Software even if free.
One reason is that such end times have the distinctly Murphy-like ability to occur at precisely the worst possible time.
Dr. Frank J. Nagy Fermilab Computing Division Authentication and Directory Services Group
This what Open Source is all about? If one developer wants to force their code down our throats, we can just go and disable the expiration code. It'll take some time, but it's not like the app dies forever.
My 2 cents:
/var/log/oldage
(warnings only, software continues to run)
anyhow, nobody would ever get the shitty crippled binaries. All of the distributions would give users the crippled binaries.
I see the advantages, but what if there are stable releases of software put out that expire?
Some people like to build a nice solid stable reliable system and let it go.
Besides, do you people really think that all those open relay machines are accidently left open? Yah right. Those people are getting paid well to leave them just the way they are.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
Fuck, who thought up this one? A 12 year old irc kid? This has got to be stupidest thing I've read on Slashdot in at least week. Anyone that works in a real production enviroment can understand why, and anyone who doesn't manage systems in a real enviroment can fuck off... your opinion doesn't mean SHIT.
Ditto.
qmail
Digital UNIX does this already, except it's part of their licensing program. If you don't keep your licenses up to date, the entire system basically shuts down.
It's a royal pain, especially when you've got a highly diverse computing environment.
Sounds like a bad idea to me...as far as I'm concerned, I should be able to run whatever software I want on my computer. It's my processor, I can jam whatever code and data through it I want. This is almost as abhorrent as all this new "forced security" stuff that's in the news lately.
I've had some BAD experiences with auto-expiring software. I used some free scientific software that expired at a certain date, forcing you to upgrade. BUT, of course, the guy writing the software (which was free but closed source) had dissapeared off the face of the web, meaning the update didn't exist...the software was rendered completely useless, and the world had lost a valuable piece of information and creativity.
-"I still believe in revolution; I just don't capitalize it anymore." - srini!
Reminds me of the "or any later version" clause in the GPL... Assuming the developers don't know enough to choose an appropriate license for their own work, and sneaking in something to give yourself that control instead.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
It's a great idea; software expiration. Not so much that it's disabled, as much that it should notify when it's out of date. Saying saying "open source" is kinda pointless. All software could use this concept whether or not their code is "open source" and saying "should" is always wrong when making a suggestion.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Some big time company (eg Corel) begins publishing software for linux, potentially eventually even publishing their own distro. They incorporate this expirey date bullshit into it. Then a few years/months later one of the following happens:
1) The company goes out of buisiness and then your software expires and you are SOL. Especially if the software you used to encrypt all of those important files on your hd expires.
2) The company decides to back the RIAA and implements some form of Digital Rights Management into their next release. Don't want it? too bad, your software just expired!
3) Something else horrible happens...
I think having software "expire" is a horrible idea -- a lot of people I know like to use software that's been out for a while to make sure there are not obvious security flaws. Instead, since security concerns are primarily centered around networked machines (more specifically, ones connected to the Internet), just have the software periodically (weekly? monthly?) connect to some server somewhere and check for security updates.
Not that I'm the only one, mind you ... but if anyone's counting ...
Yeah, its a bad idea. Stinko! An idea about as prone to the law of unintended consequences as I've ever seen anybody from the open source crowd make. And that's just for starters.
You can't force anyone to change anything. You can't force anyone to change anything! You can't force anyone to change anything!!
You have to make them WANT to change. But don't think they're going to do it next week. That's just not the way people are. STOP fighting their natural flow (or lack thereof). Be a bit more mindful of the Tao.
"Grasshopper, if user sits like a lump - then you must find a way to use this inertia to your advantage. Your life will go much better that way. "
What am I saying? Its this, don't depend so much on upgrades.
What this idea proposes is the SysAdmin's version of the "snooze button."
It doesn't matter what measures are implemented. Good sys admins will do what they should and bad ones won't and will find ways around it. If you're one of those people, get a different line of work and let some of those unemployed sysadmins have a crack at your job.
Sell me software that expires, and it will be the last time I buy from you.
Wasn't planned obsolesence in MS products one of the reasons to support OSS? So we'll go them one better and give you forced obsolsence, thereby increasing TCO and playing into BIlly Gate's hands.
But, I would tolerate a package which manages executable binaries. Keep track of all the binaries on the system and periodicly check bugtraq for problems. No need to refuse to run, that would be silly, but popping of an email to root about the recently discovered hole in openSSH would be not too bad. Its a real pain in the ass to sift through bugtraq looking for things which need fixing, but it wouldn't be too bad to have a program do it for you. At one point in college I was accused of hacking a machine because I notified root that thier glibc from redhat 6.2 had a local root exploit. They never did fix it, because they said it would take to long to rpm --install glibc-xxxxxx.rpm
Spring is here. Don't believe me, look outside!
Sounds an awful lot like what Windows XP does. Expiration of software's value to a user should be determined by THAT USER.
What about when congress decides that all new software must include copy-protection, and your old, usable software expires?
>or knowing that on such and such a date you wont >have to support Netscape 4
So what do I run on my SE/30 to browse the web?
Why not just build it into a package manager that can access an ftp site? e.g. "SSL needs updating. Please click OK to update SSL". Better than "I'm sorry Sir, your anal probe results were lost because our software has expired. Would you mind bending over again please?"
Just imagine,
It's 4 A.M.,
you're wake up to the sound of alarms going off in your kitchen.
You rush out of bed to see what the hell is going on...
The LCD panels on your fridge, microwave and toaster are all blinking GNUppliance Panic! CODE EXPIRING!!
Twisted pair cables shoot out of all your appliances, groping your walls blindly in search of a network drop so they can update their firmware...
I bet the Maytag man ain't snoozing in his chair tonight!
Yes, not to mention the fact that the idea behind open source is that you can CHANGE it to behave how you want it to behave. If I don't want it to nag me, it won't. Let the sysadmins make the call. Make it strictly opt in at compile time.
Windows has a Critical Update Notification application that keeps popping up a notice every few days when they publish the fix for the latest gaping sucurity hole.
Speaking of debian... What is the name of the ncurses package? I want to apt-get install ncurses so I can build a kernel with menuconfig, and it says that it's in the database but doesn't have a package. (This is a pretty bare bones installation; I was surprised when ncurses wasn't already installed)
A solution to the problem with music today
On some of the Red Hat 7.2 boxes I administer, I run a nightly apt-get update and then apt-get update -s, which performs a simulated install and then mails me the output.
This way, I know when a new Red Hat update comes out, and have some idea about how successfully it will install on the system (generally OK, using Red Hat main, updates and freshrpms in my sources.list).
If you run Red Hat and you haven't discovered the joys of installing RPMs with APT, then I suggest you try it. You'll wonder how you ever got on without it.
I chose open source because It lets me do what I want when I want! If I wanted some stinking softwhere that thinks it knows how to administer MY COMPUTER I would be running windows and taking my orders from a paperclip. If you want to have your computer to tell me when to upgrade I may as well pay attention to the warnings I get about non microsoft cirtified files being downloaded off the net.
p.s. I happen to like antiquated technology. Did anyone see that episode of red dwarf where kryton get's superseeded? It's a bit like that for me
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
Your (Open Source) software should check a website every month or so, to see if there are still no vulnerabilities discovered for it.
:P) should be optional both during compile time and during the actual use of the program. OS programs that don't have the option to have this module switched off would probably be forked.
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.
- -- Truth addict for life.
The best feature of OS software is its ability to be debugged to such a degree that it is far more stable than a commercial product. Should we break its back for the mere purpose of making a security drone's job easier?
So when they actually get to use it you will have some yahoo thought a price tag on it. Besides it's the companies damn fault for not hiring good sys admins! It takes more than just reading one book to be a sys admin.
For example, OmniHTTPd has been doing it for over half a decade.
StoneCypher is Full of BS
YUMMY!!!!!
Haaaard crunchy outside...
Soooooft candy center...
*drools*
Are you saying that someone thinks it's a good idea to build in a huge denial of service bug into every piece of open source networking and security software?
./configure it in, but this bug should be left out of my binaries as well as the standard distributions.
Is this guy on Microsoft's payroll?
How about this. He can build the little wrapper that does this and break his own programs if he wants; he can even make a patch to allow people to
Just imagine the nightmare of combining this bug with standard distributions. All of the sudden, all of my servers die at the same time.
I would love trying to explain this at work. "Uh, yeah, sorry. No one can get work done while I update all of the networking binaries with the latest version. You all needed a vacation anyway, right? What broke? Well, most of the software was actually fairly secure, but all of the BozoBSD 6.9 installations hit their automatic expiration this morning and stopped working."
Seriously, folks, this is a bad idea. It smacks up there with forcing me to write N lines of comments for every line of code. This really doesn't create better software. Instead, it causes software to cost more for the same (or lesser) quality and obscures the salient commentary with loads of arbitrary text intended only to fill a quota.
How about a review policy instead? Perhaps you should institute a company policy that requires your admins to regularly review the relevant software on your critical systems and sign off on whether they have freshened them with updated versions.
The worst problem regarding security is, that most standard operating systems are not able to separate server applications from each other.
Why do we still have to run Sendmail as root (overriding all DAC security) just to open a privileged port?
Why is there still no fine grained set of privileges instead of the all-or-nothing distinction between root and rest-of-world in Standard Unices, although such privilege sets have been imeplemented in Trusted Unices many years ago?
If we didn't run everything as root, an attacker would not be able to break all system security just by hacking into some mailserver or webserver. Furthermore, secure applications would not be required to throw their privileges away after opening the network port.
However, having a secure Operating System does not mean, that you do not need to patch your server applications. Secure Operating Systems can not prevent attackers from hacking your applications, they just limit the amount of damage an attacker can cause by exploiting security vulnerabilities in your applications.
regards,
octogen
I was a silly little duffer, and had my system do an "apt-get upgrade --download-only" every day at 6am (while I'm going to sleep). My reasoning was that when I got around to doing the "upgrade -u", I wouldn't have to wait forever for the downloads to occur.
The catch with that is that I'm in Australia - we're charged per megabyte for downloads (regardless of the ISP). Most ISPs offer a "free download" limit, so that you don't feel like you're paying per-MB from the first MB. Thus I woke up one day to find that my Debian boxes had consumed half my monthly "free download" quota on the first day of the month.
D'Oh!
And just in case anyone cares - the ISP in question is indeed Telstra BigPond. The very same people who refuse to give me an answer to the simple question, "Is traffic between ADSL customers on Telstra BigPond Freedom Plans billable?"
But I digress.
Didn't those replicants kill some of the developers in the process to try to become normal mortals?
For any developer who uses this: let this be a foresight. (Gates: watch out for escaped XP systems)
The Cobalt Sun products, despite them being rather expensive, use a program called Bluelinq, which essentially compares all its' installed (Redhat Linux) RPM versions, and compares that with a central server. Should a new version of something exist, a single email is sent, and they can go into a web-based interface and click an option to automatically download and upgrade the new Rpm. The only problem is Cobalt doesnt have enough infrastructure to test and regularly update the RPMs as fast as the open source community; thus they Cobalt is stuck on old kernels and upgrading things like PHP4 yourself is a nightmare. A similar system for opensource distributions would be fantastic.
A warning is probably a better bet than stopping running altogether, although it's a bit irritating getting the warning only to find that there isn't an update, even to remove the nag for a few more months. Of course, with Open Source the removal is only a quick edit and recompile away, so I've certainly got no problem with this, but then, I keep my software upto date with the security patches anyway. I'd get fired if I didn't given it's part of my job and all...
UNIX? They're not even circumcised! Savages!
Baaad Idea!
Disabling software that is in production like this is a big no-no. What about a web site that goes down (maybe causing a big player many thousands of $$$ or more) would effectively remove Open Source as an option for business use.
A syslog entry, a kernel message, a mail sent would all be ok. I.e like "This software is 12 months old, there are probably a newer version out with more features, bug fixes and plugged security holes out. Please check at http://..."
But no matter how you look at it, it is the system admins duty to maintain a system. When new updates comes out, they should be put into the development->test->pilot->acceptance test->production cyclus commont for RealProduction(tm) systems.
There is no way you can automate this!
//TheToon
Is this guy a nut or something!
Expirering and malfunctioning programs on my servers? Fuck you fruitcake!
Has he slept with $ill $ates to get these ideas
Don't support this idea please.
Greet,
Anny
Only 1 of my large collection of 40+ computers has a realtime clock in it? Is this idea intended to force computers without inbuilt RTCs to not run their software? Or will just just run indefinately on these machines?
Let the software expire so it can force me to upgrade to a later, more "free" version of the GPL.
Control freaks... back off!
The answer is No.
...":reset nagtime:Done. .
Next question: Does Open Source Software Expire?
Yes.
aside from Debating the exact definition of "Expire" for a few hours, I present this/these facts:
1] We're talking Security Issues here.
2] Security is reasonably known to be a *Process, not an Destination. *=(continuous).
i.e. continually needed. Where there is connectivity, there is risk.
3] Eventually, has not each incarnation (build) of [the Linux Kernel] been found to have
potential security vulnerabilities/issues? Which thereby required Upgrading or patch-
ing to 'fix' those vulnerabilities/issues. Upon such circumstances, should not the
older version(s) be considered 'Expired' --for strict security purposes.
4] If we were'nt talking security issues here, then much OSS would not necesarily be considered 'Expired because facts 1 through 3 would not be applicable.
# 4 could apply in cases such as where, as danheskett suggested above,
someone runs a "freeBSD [or Linux] box in [their] closet that serves MP3s" -
(or OGGs/OVFs [?] -for you purists, & yes I did remove a " ' ").
Let's expand my answer: No OpenSource software should not be [forcibly] expired.
Here I'll agree with a few key points:
a) One cannot know the best time to expire software.
b) One cannot ensure that newer software will be available.
c) even if (b) were false, one cannot ensure that newer s.w. will be
better/more effective/secure/stable / not cause other problems etc.
Ideas for more appropriate actions/Method:
relevant to (a) above:
One can suggest a reasonable time frame for software to be checked for updates
relevant to (b) above:
see (b) above - There are no "Absolute" guarentees in life.
relevant to (c) above:
At some point, [after Much testing] newer software can reasonably be deemed *better*
1) Allow for -Nag- options to be enabled (OR NOT) for software at compile time --
Especially any s.w. which would be involved in issues of security concerns on the system.
1-b) Frequency of the -Nags- could also be selected as compile time option(s)...
I propose that in these -Nag- options, that it be well Explained to the [person] compiling
that the(se) software 'Nags' are Highly Recommended (~*~) for Security purposes, and will not `negatively affect their system in any way`...[ensuing debate on that quote aside];
(~*~)-perhaps also add here -'and in your best interest(s)'.
The(se) 'Nags' should be of the nature that -yes, they may be annoying, but they Remind those who may need it or they Inform those who need informing that for [whatever] software is of a certain age that better/ more secure...etc... software may very well be available, and should be checked for - if they are concerned.
The options then become...
-allow for repetition of the nag(s) --every [so]-[frequently] hours/days/months.
-defer the nag until next s.w. age period occurrs- i.e. let the user checked for new s.w.(/ not).
-also could 'bundle' in with the Nag(s): options to automatically check for *Upgrades/Updates/Newer s.w.*
- here's where the story gets tricky (if it hadn't already) -
- if (auto check for *U/U/N s.w.*, and None found);
- then {howbout}: Say "None Found
- else -(if *U/U/N s.w.* Is found)- . .
here we're (I'm) at 'Dillemaville':
Ultimately (and Obviously, I hope) the decision/choice to get&upgrade/patch to(/with) the newer s.w. is/should be with the user/[administrator] of the system/boxxen...
The Big Question is how is it to be determined When the newer s.w. is 'a good thing'.
Some suggestions have been made in the discussion here of this topic...
Perhaps the Better Question to pose as the next 'Ask Slashdot':
"Determining the most appropriate time to instantiate Software Patches/Upgrades ?"
--
*better* - relating to -Security, and effectiveness, + Stability & not causing
other problems etc. Preferably with minimum bloat. The measure of "Much testing"
would be the hardest to quantify, methinks, don't you?
-- (see end of info: 'relevant to (c) above...")
-my 20 cents-- -Shimmer.
P.S. you can substite "Show:" or "Tell the user/[admnistrtor]:" for "Say"above.
If anyone is running anything critical, they're probably members of the appropriate Announce mailing lists (and if not, why not?) which will tell them about any security patches and new realeases.
You've got to remember that even though some security holes may exist, they may not be a threat to you dependant on your OS/config/firewalling.
~Arricc
# apachectl start
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....
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Wouldn't it be much more sensible for every program to mail root once a week every week starting six months after the last change to a timstamp field in a config file - that way, if the admin really did mean to keep the "old" version, all he has to do is touch the timestamp...
zsh/scr # crontab -l | grep apt /var/lib/apt/lists ) > /dev/null
13 2 * * * (export http_proxy=http://localhost:8080/; apt-get update; apt-get -dy dist-upgrade; apt-get update; apt-get -dy dist-upgrade; chmod -R og+rX
No more problem.
~Tim
--
Rushing on down to the circle of the turn
Your whole beowoulf cluster going down at once...
Right before it has the answer to 42....
Bad idea... bad, bad, bad idea...
Very good idea indeed. As OSS software is so many times proven to be buggy and unsecure, that's really a briliant idea.
There are enough recorded instances where the designers of software never foresaw it being used beyond a certain date, and put in mechanisms to automatically shut it down beyond a certain date, or not maintain it beyond that date, all causing problems. A better approach would be to email or message the system with periodical warnings to address the upgrade issues, irritating, but effective.
oi, it's a good idea to advise the admin about unupdated sw, not just shutdown it.
S/w should not expire.
It recreates the Red Dwarf episode when the androide had to be replaced by an updated version, even though mankind had died out and they were prefectly happy with their own androide.
Warnings of expiry is valid, but not deactivation of software.
What if openssh did not let them log in anymore due it had expired?
Flurdy(forgot my pw)
... coming in one morning, finding myself unable to log into any of my 30+ Servers because SSH expired during the night.
Please, yes, include that, I am not busy enough you know?
+1 for those who notice the sarcasm.
If you want to e-mail me, use my PGP Key.
Are you crazy? If an SA can't take responsability for updating software that is bad, then that is his/her problem -- don't try to be as arogant as Micro$oft telling me what is good.
There have been times when I NEEDED to run an old version of the software because the newer version just sucked.
How about the situation that a software package is no longer supported by the authors? I don't necessarily have the skill to 'find' the timer and disable it.
This is the 2'nd most stupid idea I ever heard...right behind copy protecting CD Music.
I think during Software installtion it should be written in a software configuration file. A Software should inform you about updates and security holes. A kind of smart update. If you run a system that is insecure, you shall be warned. A kind of quality management of your servers..
You can lead a sys-admin to a bug, but you can't make him care. You can only fire him. Time bombs in the software will only result in web pages randomly going to every couple of months.
If the expiration code itself is open source, then IT would have to expire, at which point it would no longer be able to expire the package it's embedded in!
More fundamentally is even if they work _exactly_ as intended, you are forgetting that their major role is to _allow_ traffic. Having uber wonderful firewall which is unhackable is utterly pointless when it's running in front of a webserver running a default install of IIS4.0. Because it's a web server, the firewall isn't blocking the traffic. Functioning exactly as intended....
What kind of mp3 jukebox expires?
Seems like everybody's knee jerk reaction is
"It doesn't matter if you have exploitable systems behind a firewall" whilst at the same claiming decent sys admins, presumably like themselves, look after machines.
I tell you this - a decent sysadmin _knows_ a firewall is no the silver bullet to magically secure a network, only an approach based on a defence in depth and monitoring will work.
Sure keep old software going, in the right place, but good security practice is to keep everything as secure as you can at every point you can.
The sys admin who tells you they have a secure network almost certainly does not - they have let the biggest security failure already happen - COMPLACENCY
Assume the worst will happen, plan for it, and then approach every single day assuming that you will be breached and go looking for the breaches.
Yes its hard work, and like all things like this no-one will notice until the day you slip up and let something through.
I personally don't want anyone *forcing* me to upgrade a machine that is running fine, behind a firewall on my network. Lets not start playing the M$ upgrade game.
However, a utility that port-scanned my machine (aka nmap) and then looked for the software behind any open ports (aka apache on 80/443, bind, lpd, etc) and found a version# for the software... and informed me of any known holes or that an upgrade would fix, might be valuable. Leave it to *me* to either ignore the advice, or upgrade at my convenience... but disabling my software?!? Its my machine, its *my* risk to take.
Geez, I could just see my e-commerce website raking in $20k/day suddenly going down because my software disabled itself... Hmm.. and then, do I get to *sue* apache.org because their webserver disabled itself on me and cost me $20k in lost sales before I got the new version installed and tested???
Ok, perfect example.
Large software package uses good old perl module App::Config, clever programmers invoke psudo-black-magic by picking at some of the innards to do things.
Maintainer of App::Config does a bunch of upgrades, ends up moving it to AppConfig. Old version of App::Config no longer available from CPAN.
Under the current system, Large software package can continue to function while programmers figure out how to undo their dirty tricks and make it work with new AppConfig. Under proposed system, software BREAKS and is DOWN until programmers can do these changes.
Hmmm, sounds like it would cost the company a good deal of MONEY. Better avoid that flaky open source stuff as unreliable.
Expiring free software just because it's dated is idiotic. Not only can't you guarentee that the new version will work better (or at all!) than the old one, but you can't say what a good timeframe is. If that isn't bad enough, it discourages people from making their own local modifications to the code -- one of the main touted advantages of open source.
And it was modded as interesting - not as funny.
- If This Peace Is Fictious, I Shall Destroy It
We are not talking about every single binary in a distribution, we are talking specifically about server software that accepts connections from the internet, or at least a local network. You should be able to count the number of programs that do that on one hand. If any of those programs are not important enough to you to maintain, you shouldn't be running them anyway.
You can't force people to do what you want, especially when they have the source. This is really just a silly idea that can only be bad for Open Source. Sure people should fix security problems but this is not the way to educate users.
Isn't crashing a service on a system equivalent to what security is trying to prevent intruders from doing in the first place? It's like saying "I'll chop off my foot so I'll never have to risk losing it in an accident."
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
If they went with this sceme somone could really have fun blowing up people's systems by setting the clock ahead on them. Voila`! No need to take down systems the old fashioned way, let them do it to themselves!
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
Naaah, you just keep the clock set to 1/1/2002 for the rest of your career. Problem solved!
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
...that I *never* use said software.
I don't do timebombed apps. Ever. Period. Because if it does what I need, I want to keep using it. I don't want to have to replace it just because someone says I must. And how are they going to guarantee that a new version is any more secure? Chances are just the opposite, since feature creep generally implies bug creep as well.
Opensource is supposed to be about choice. If people choose to be stupid about unpatched security holes, it's no one else's job to change that.
Remove my ability to choose, and I might as well buy a closed-source solution that's known to keep working forever. It'd be cheaper in the long run.
BTW the oldest util I still use is dated 1983. It still does the job and runs on all systems with zero problems. Who are you to say I must replace it, just because it's old??
~REZ~ #43301. Who'd fake being me anyway?
Security holes in software generally aren't found right away, but rather after several months of use, right?
So -- instead of expireware forcing everyone to do mandatory updates, I submit that it makes more sense to require that NO software under a year old be allowed to run. If you can't find an older version or don't have old enough hardware to work with it, too bad, do without!
~REZ~ #43301. Who'd fake being me anyway?
I can just hear the phone conversation now:
CEO: How come my production box just locked up?
Geek: Oh, because one library module amongst the thousands of files that make up our Open Source system expired. Sorry I missed it. I was busy closing some more reported security holes in our close source software.
Likely CEO reaction?
Step one: Fire the geek who installed the system.
Step two: Go back to that warm safe place called User Hell that Microsoft has made for him.
> First, there is a name for software that is going to be deprecated in a foreseeable time frame. That name is "beta."
Reminds me of a old job. Specifically the "oh fuck the beta time-bomb we'd forgotten about has expired and we _still_ don't have the full release ready yet" bit of it....
(A proprietary database (not one you are likely to have heard of, it was just an ancillary product), and it would refuse to work if there were dates in its journal later than current time, so you couldn't just wind the clock back.)
rant
How about files being named appname.status-version.number.tar.gz(.rpm) where status is 'alpha', 'beta', 'rc', 'stable'. On a production server box you could set auto-updaters to only update on 'stable', whereas a desktop machine you may want to stay up to date with 'rc' sources/packages.
Eg
myapp.beta-0.21
The enthusuastic download
myapp.rc-1.0
Most regular users download
myapp.rc-1.6
Regular users update
myapp.stable-1.6
Production servers update
myapp.beta-2.0
The enthusiastic forge ahead
This would be simple enough for even the home-made Perl updater to filter on.
Phillip.
Property for sale in Nice, France
it doesn't go bonkers like Pris!
that cause it to "expire" like a Blade Runner replicant
A vacuum is a hell of a lot better than some of the stuff that nature replaces it with. - Tennessee Williams
it sounds like this article is basically asking if open source should adopt the windows planned obsolescence strategy.
how amusing.
eudas
Blessed is he who expects the worst, for he shall not be disappointed.
So IPtables/Snort/etc would disable itself because it's out of date. And somehow this would IMPROVE the security of my box?
This guy should be a Passport developer.
Kev.
Loser admins do not have a right to run an insecure system. It's called "an attractive nuisance." It's a lot like owning a swimming pool. In virtually all jurisdictions, you're required to build a fence around it, because otherwise some kid will come along and drown him/herself.
Likewise, if some script kiddie hacks my server because I hadn't applied a service pack in 2 years and uses it to launch attacks on the FBI or send death threats to the White House, then yes, I am liable for that. Mark my words, as time goes by, the courts will get more and more involved in these sorts of things.
bance.net
How about instead of stopping it working, just put in a warning like many virus scanners do.
;)
e.g. "Your copy of BIND is 6 months old. It is recommended that you upgrade to the latest version in order to prevent security holes."
You could either email it to root (maybe a bit annoying) or you could display it on startup (less likely to be seen on low-reboot or physically inaccessible machines). You could also be really radical and make it *beep*!
It'd have to be pretty visible, as the sort of people that are being targetted here are admins who don't really care about updates. Any sensible sysadmin will have updated their servers long before the 6 month timeout. I reckon emailing root *and* putting up the startup warning would be best. And of course there'd have to be an (compile time?) option to disable it too.
' Ore stabit fortis a fine placet ore stat '
- found on a park bench
From the php.net website: [27-Feb-2002] Due to a security issue found in all versions of PHP (including 3.x and 4.x), a new version of PHP has been released. Details about the security issue are available here. All users of PHP are strongly encouraged to either upgrade to PHP 4.1.2, or install the patch (available for PHP 3.0.18, 4.0.6 and 4.1.0/4.1.1).
.conf file, and ideally it would be a mailing alias in case joe_schmoe@localcompany.com was no longer working there...)
Yet today:
telnet> open www.sonypictures.com 80
Trying 66.77.63.110...
Connected to www.sonypictures.com.
Escape character is '^]'.
HEAD / HTTP/1.1
Host: www.sonypictures.com
HTTP/1.1 200 OK
Age: 15
Accept-Ranges: bytes
Date: Thu, 04 Apr 2002 19:49:42 GMT
Content-Length: 1728
Content-Type: text/html
Cache-Control: max-age=1800
Server: Apache/1.3.22 (Unix) PHP/4.0.4pl1 ApacheJServ/1.1.2
Last-Modified: Sat, 02 Feb 2002 06:57:14 GMT
ETag: "4a154f-6c0-3c5b8dca"
Via: 1.1 C3100-0033590693 (NetCache NetApp/5.2.1D8)
Connection closed by foreign host.
They're so far behind it's not even funny.
Big companies have so much to juggle they
miss big security holes in externally accessible
systems. Not good. Anything to rectify that...
Maybe open source s/w could "phone home;" if the
current stable version is greater than its version
it could alert the admin (setting the admin's
email address would be a part of './configure'
or a required directive in a
This could be as simple as a HTTP GET request, semi-hardcoded (could be updated as a part of the reply, in case the server name was going to change...)
This could be easily implemented...??
System Message: Your kernel is older than 3 weeks. Auto-updating to latest kernel. Installing linux-2.4.15-greased-turkey.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
I've displayed things you users wouldn't believe. Applications on fire from server of Gates. I watched blinkenlights glitter in the dark near the xor gate. All this data will be lost in time, like backup tapes in the rain. Time to crash.
I'd love to have my sgi-scripts deactivated every 6 months without warning. Super idea!
This is the kinda thing a pissed off overworked sysadmin might say. Power to the BOFH!!
Microsoft would just LOVE this. Exactly why is only Open Source software being singled out? Most of the security problems are in Micro$oft products. Why not simply disable any of *their* software than isn't up-to-date on security patches.
Most people have very good reasons to use old software, like its size, and possibly because it supports hardware the new one doesn't (XFree86 3.x vs. 4.x comes to mind). If you force people to run the latest and greatest, you're probably also forcing them to upgrade their computer. Also, many programs only behave with an earlier version of a given library. For example, OGLE (a DVD player) only works with a52dec 0.7.1b, when 0.7.3 is out. OGLE will NOT (at the moment) compile with 0.7.3. Sure, they'll switch with the next release, but until then NO DVD! And worse, what if the OGLE project goes under?
What we really need to do is patch ALL versions of the software for known security holes. Watch: FooFTPD 1.0.9002 (the third number changes for bugfixes and security hole fixes) would be just as secure as FooFTPD 3.0.2, but FooFTPD 1.0.9002 would be so much like FooFTPD 1.0.0 that it could be deployed in exactly the same manner. Then, FooFTPD would incorporate some sort of update mechanism a la Critical Update Notification that tells the Sysadmin when there's a new bugfix/security hole fix available for the installed version of FooFTPD. This system will work, but it would put extra load on the developers. But... Open Source... there's SOMEBODY out there to do the patching of old software for the developer...