At top of the pyramid, you have these top 2% of developers that are 10 times -- in some cases 100 times -- more productive than the rest. It's true in proprietary developments like Microsoft and true of open-source too. The value is the QA [quality-assurance testing to make sure the software works and finding and fixing bugs]. They cover more ground than we could ever test.
As I read this -- Marc, correct me if I'm misinterpreting -- he asserts that while community projects are just as good at *writing* code, they're fundamentally incapable of *fixing* code to the extent that corporate (open source or proprietary) projects can.
In other words, he's marginalizing many of the advantages of open source, reducing it to little more than a way to build a little extra trust with your customers and get some testing done for free, things which can and are routinely enforced by other mechanisms with proprietary licensing schemes.
That's why I read this as a claim of the failure of open source -- that it never delivers on the supposed advantages it has over proprietary development, and that we'd all be better off if the people running these community projects were corporate instead.
That said, I can certainly see how I might be misinterpreting it. It's a short interview. If you can point me to something more detailed that Marc Fleury has said on the topic, I will gladly read it and retract my condemnation if appropriate.
I'm not missing his point, I'm saying that his point is irrelevant, because it misses the point of the open source development model. Open source software evolves, both socially and technically, in ways completely alien to the proprietary world.
If you "give until you're tired of giving" as he puts it, it's because you haven't attracted other developers to give back. Either your software isn't useful enough to warrant it, or isn't of sufficient quality that people feel like investing time in it.
In other words, his theory about the failure of open source is relevant only if your software sucks. If your software sucks, it's going to fail no matter what the development model is.
If you haven't kept the code for stuff like this, you're hosed anyway.
Most small businesses don't have a single employee who knows what a compiler is. There's a whole bunch of "If you don't do this, you're hosed" stuff that small businesses just don't have the economies of scale to do. That's why they hire consultants in the first place, but sometimes they don't really know which one to hire or what to ask of them.
The hobbyist/hippie projects he cites inevitably develop into mature, disciplined programming efforts, if they're sufficiently useful. If they're not useful, they're irrelevant. There are plenty of useless, irrelevant pieces of software in both the open source and proprietary worlds. The difference is that in the open source world, it's much easier to become useful, relevant, and mature quite quickly, and draw in the development, documentation, and QA efforts of people who are being paid for it.
Clearly this man never studied economics, because he fails to recognize that money, by itself, is not a motivator of economic activity (such as expenditure of personal time or paid development resources). Money is merely convertible into utility, and it is utility which drives economic activity. People generally start F/OSS projects for one of two reasons:
A) The software will do something for them that is economically beneficial. B) The software will do something for customers that the customers are willing to pay money for, because it is economically beneficial for them.
There's no charity here, except as a welcome and encouraged side-effect. Sure, plenty of projects begin as exercises in curiosity, but anything you hear about has been developed to maturity because it was economically worthwhile for several people to spend valuable resources improving it. One of the critical strengths of F/OSS is that it allows distant people who individually lack the resources to implement a solution to their common problem to tackle it together and get a result. It also enables people who *have* the resources to pool them to get a *better* solution. That's why you see all of these competing hardware companies working together on Linux. They realize that hardware is only good if you've got software to run on it, and it's better for all of them if the software developers are working on one OS that's good on all these platforms, rather than each having to maintain their own proprietary unix.
I agree that dynamic linking has vulnerabilities, but generally speaking, if someone's got enough priviliges on your box to be exploiting any of those, they own it anyway. It's just a matter of convenience.
The "so many people" are typically the novice developers who do short contract work and then are difficult to find when something goes wrong. They build custom tools that countless businesses use all-day every day, and are either mission-critical or somewhere close to it. Large companies are generally organized well enough that this isn't a problem, since they either do it in-house, go to a reputable contractor, or make very certain that they keep the code themselves. The problem is, most of the economy is small business. They decide "It would be worth $5000 dollars if I had a program that did foo." and then they ask around and find someone willing to write that program for $5000. This someone decides they want to make the whole thing completely self-contained, so they statically link it. There's plenty of share/demo-ware out there that's shipped like this too, and small business uses that like mad. Most of them don't quite get F/OSS yet.
This happens ALL THE TIME. It's generally in software you've never heard of, but it's running on computers all around you. The comfort is, the variety of the programs susceptible to this generally makes writing a generic exploit using code execution difficult, but even denial of service is bad.
I have to say, I'm really confused here. I've got this pay stub here which shows income sufficient to support myself, despite being still in school and only an intern, from an open source company. I've also got this company financial information and analyst opinions here, with the financials showing everything positive for the last two years, and average analyst opinions leaning about as far towards "buy" as I've ever seen for any widely-followed stock.
One of two things must be happening here. Either I have been hallucinating so completely for the last year of my life that I think I'm living well and employed while I'm actually in a padded room somewhere, or the JBoss founder is just full of shit. Since even severe schizophrenics capture enough information about their surrounding to at least vaguely know where they are (though it may confuse them due to conflict with their imagined world), Occam's Razor suggests that the JBoss founder is indeed full of shit.
This is a perfect example of why dynamic linking is Usually A Good Thing. People are always going to be using libraries, and, like all code, those libraries invariably have bugs.
Appallingly, so many people still insist on static linking of published binaries, with no more compelling reason for this than a barely measurable performance boost they could make up for ten times over by profiling the app and recompiling with that data. This of course assumes that they're testing the final binary.
I don't mean to start up the static vs. dynamic linking flamewar, because there are plenty of circumstances where static linking is perfectly appropriate, but if you can't make a good argument for it, dynamic linking should be the default.
Now we have countless windows apps out there with overflows in both JPEG and PNG (recall the overflow in JPEG a few months ago). It looks like the old "images are safe" mantra that tech support has been spouting out to users regarding attachment safety is falling apart.
Yes, but "Wireless Fidelity" doesn't actually mean anything. It's a technically useless marketspeak term. Under the guise of explaining technology, they expanded a marketspeak backronym. This is what I mean when I complain about how confidently they stripped their article of any actual informative content. You have a point though. I should have clarified my complaint. My complaint is not just about what they got wrong, but about how much space that could have been spent on useful information was completely squandered in their masturbatory exposition of an incredibly primitive understanding of technology.
I haven't cringed so many times in one article in a very long time:
Wireless fidelity, or "Wi-Fi,"
That one speaks for itself.
Last year, a Michigan man was convicted of using an unsecured Wi-Fi network at a Lowe's home improvement store to steal credit card numbers.
They make it sound like he just used Lowe's to get internet access. Lowe's was sending credit card number, expiration date, cardholder name, billing address, and cvv2 number in the same unencrypted packet.
A more recent threat to emerge is the "evil twin" attack.
It's been called the "Man In The Middle" attack since long before wi-fi ever existed. Where the hell did "evil twin" come from? Are they just making shit up?
Not all encryption is rock solid, either. One of the most common methods called WEP, or Wired Equivalent Privacy, is better than nothing but still can be cracked using a program available on the Web.
He makes it sound like there's only one program on the web that can crack WEP. There are several, because there are several independent flaws in WEP, and most implementations are susceptible to multiple different attacks.
AES encryption standard
GAH!
"It's no different if I went out and bought a Microsoft program and started sharing it with everyone in my apartment. It's theft," said Kena Lewis, spokeswoman for Bright House Networks in Orlando. "Just because a crime may be undetectable doesn't make it right."
As far as I know, not even the BSA has attempted to assert that failure to abide by terms of service, in the absence of additional laws, constitutes a criminal act. At least this is a quote.
What's really appalling is the confidence with which they maul both reality and language. It's one thing to be light on details, or present them as uncertain or controversial. It's quite another to present them as a straightforward list of facts to acquaint those otherwise ignorant. They do quote Mike Godwin, but they use misuse his quote to make it sound like he's talking about something else, so they've squandered what slight authority they could have had.
You're joking, right? Basic Input Output System. No, you don't need it doing anything terribly intelligent once it's booted, but you definitely need it to NOT be doing anything incredibly stupid. I've seen plenty of repeatable post-boot panics, device resets, data corruption, machine check exceptions, etc., that were fixed by BIOS updates. Veteran laptop users will also tell you about the huge impact the BIOS version makes on how many charge cycles your battery will go before you have to throw it out and get a new one.
Also remember that a BIOS update accomplishes a firmware update for any onboard devices (except for some rare, really weird ones). The one piece of firmware that I've seen makes even more of a difference than the BIOS proper is the firmware on a RAID card, and some boards have those built in too. (And then some have fakeraid, but that's another rant.) There are even some network cards with significant firmware bugs.
I personally will cheer when BIOS is dispensed with, so long as it doesn't get replaced with something even more hideous, like ELILO on Itanium systems. Until then, I will update it any time I have a problem I can't fix in software, or any time I can on a laptop.
It used to be considered impossible to sail a boat upwind, too. The world of fluid dynamics is full of weird cheats, so the word "impossible" really shouldn't be used in describing yet-unacheived feats in the field.
The submitter evidently assumes that specs have actually been written independent of the design, as would be the case if the product was created through an organized engineering process.
1) I love my current commercial job, but there's always this sense that no matter how much I do, at the end of the day there are more tasks to do than when I began. My management is great about prioritizing projects so that this doesn't become a burden on us, but if they ever decided that we suddenly need to implement all of these great ideas we're coming up with, half the people are going to stop coming up with great ideas so they can survive, and the other half will quit. At my university jobs my role was always philosophically more of a sustaining one than a developing one, even when I was working on new projects. I was rewarded for the work I did, but I never felt there was any danger of being a victim of my own success.
2) Make friends with a well-organized, well-connected person higher up in your organization as soon as you can. Every bloated university bureaucracy has a few people in each department who can really get things done, but as this tends to suddenly make them dangerously popular, they learn to be somewhat difficult to get ahold of. You end up with this whole underground illuminati organization of people who know they can count on each other to get things done. You want to get in on this as fast as you can.
3) Pay careful attention to those benefits. Some of them could pay off HUGE in terms of things like retirement planning. Because of screwy budgeting policies (especially for a public university) you could find yourself living frugally but filling up a 401k quite quickly. I generally agree with parent's comments about tolerance as well. The liberalism is also true, but depending on what part of the country you're in, that might mean the liberal wing of the Republican party.
Years ago I tried to warn people that Tempel 1 was an alien monitoring post, and that it we needed to study it to discover their origins so we could be vigilant for their return. I was locked up for years. Now that I've escaped I find that they're smashing a rocket into it! While this at least proves I wasn't crazy, it's not going to help anything. Any civilization that has the technology to maintain a link to an outpost in a remote star system without it being detected by civilian scientists probably has the ability to defend itself against what it would probably perceive as aggression. While I'd like to believe that their advances have made them peaceful and even merciful, recent events on Earth suggest that the best we can hope for is millenia of enslavement.
If you've got a bunch of machines that rarely need to be messed with locked inside rooms/closets that will be in easy reach of the administrator(s), you can give each one a unique, high-entropy password and tape it to the box. Then a compromise of one of them will not compromise any others. If an attacker has physical access you're 0wn3d anyway.
This is particularly useful when you're doing a small business setup, when the "administrator" is the person in the office with the strongest computer skills, but has a completely different job description, and is likely to lose track of a notebook or whatever else. Contrary to the environments a lot of slashdotters work in or have worked in, most people work in companies with no dedicated technical staff, so it's quite helpful to set them up with something like this, especially if you're the contractor/friend/relative who they'd call when they need to change something and can't. Anyone who's done enough support has probably had the realization that every request to change/reset a password is an inherent security risk.
The physical access warning is key though. Left to their own devices, they won't think twice about putting the server in plain view in the reception room.
Oxytocin is released in women during nursing, helping establish a stronger bond with the baby. So really, all you have to do to get a woman to trust you is suck on her nipples!
It's the project's problem if they want the continued support of the vendors. A completely plausible example of how a vendor could be justifiably furious:
1) Vendor gets bug reports from their customers. 2) Vendor examines the code and discovers that the bug is exploitable. 3) Vendor's developers write a patch and send it to the project's security team. 4) Project security team realizes that they do a similar bad thing in other parts of their code, and the fix will need to be a much larger patch. 5) Project publishes the larger patch with full disclosure of vulnerabilities. 6) Vendor's QA and distribution people stay up all night verifying this much larger patch, to minimize the amount of time their customers are vulnerable to the exploit they discovered in the first place.
No, it doesn't always happen like this, but it can and has. This is why the vendors have set up coordinated disclosure agreements, where they all say "We're going to publish this whole thing at exactly this time." and if any vendor can't QA it and push it out to their customers in time, that's their problem.
For the millions of dollars in development effort that the various commercial distributors put into the various F/OSS projects they use, you'd think they deserve a level playing field on security. If your project doesn't think the vendors deserve this level playing field, don't be surprised when your project gets forked, or those millions of dollars in development effort get redirected to someone else's project.
When OpenSSH had a massive hole, they went around telling everyone "upgrade to this particular version or higher". When full disclosure was made a few days later, everyone realized that the default configuration of several previous versions already protected them from it anyway, and got extremely pissed off that they had to stay up all night for a couple of days to QA this change to a very critical component of their distribution, when they could have just said "turn on privilege separation until we've backported the fix". This pissed off pretty much everybody.
Speaking of pissing off pretty much everybody, I don't think that DJB speaks for a whole lot of the security community. He's respected (not necessarily liked) in the academic security community, but I doubt you'll find too many people who would argue that he plays well with others, which is kinda what this whole thread is about.
Not just Red Hat, this is SOP in the industry. But it's not "Don't release until we're ready.", rather "Please give all of the vendors the patch and a little time to build it, QA it, and prepare it for distribution, and if anyone gets left behind, that's their problem."
In many cases, bugs are actually discovered by the vendors in the first place, so publishing a patch before the time the vendors have agreed upon is in many cases incredibly rude. For the bugs discovered elsewhere or by your own developers, it's probably worth considering how much these distributors do for your product.
If you really want to screw the vendors on security patches, don't be surprised when they decide to fork your project or move all their developers to another project entirely.
Sounds like the alleged rules involve keeping bugs secret until users of the code have updated it and/or changing their release cycle to accomodate this.
Nope. What happens is that everyone agrees to make full disclosure and a patch available at exactly the same time. Sure, this delays the patch slightly, but it keeps everyone on a level playing field for security, since it means that attentive sysadmins can read the advisory, determine if it applies to their systems, and have their machines patched within *minutes* of the announcement, no matter what OS/distribution they use. It's nothing like the "upgrade to the latest version and we'll tell you why in a few days" fiasco when the double-free bug was found in OpenSSH. Coordinated security updates also go through several vendors' (different) QA processes, greatly reducing the risk that the patch broke something else.
The paper wasn't out when this article was posted, so the parent's speculation was reasonable, and mostly correct.
Anyway, while it's theoretically an issue on paged systems, the time and space granularity there is far too coarse to do something so delicate as capture an RSA key. This attack can resolve to a cache line (64 bits) rather than a page (32768 bits), and doesn't have context switches trashing the timing resolution. Thanks to some insight about how OpenSSL performs RSA operations, this is fine enough resolution to determine individual bits, which probably isn't feasible with a paging attack.
Unlike SMP, with HT you're interleaving two threads on the same physical execution unit. That means that there is data from another thread in registers at the same time that you're executing, without having enough instructions execute during a context switch to flush the pipeline. It also means that the other process's page table is in the MMU while you're executing. Even if their proof-of-concept attack doesn't work on some other operating systems, everyone needs to look over their code to make sure this isn't just an accidental effect that could change with increasing pipeline depths, different context switch logic, etc.
I used to get explorer crashes a lot, back when I had to use Windows (2000?) to support it. This being a work machine, there was about as little as possible installed on it. More often than not, it would properly restart, but every now and then I had to re-invoke Explorer from Mozilla. Yes. I associated the bitmap file type with Windows Explorer in Mozilla, and bookmarked one on my local hard drive, so that as long as I had Mozilla open when it died, I could get the rest of the GUI back.
Slashdot Mirror
As I read this -- Marc, correct me if I'm misinterpreting -- he asserts that while community projects are just as good at *writing* code, they're fundamentally incapable of *fixing* code to the extent that corporate (open source or proprietary) projects can.
In other words, he's marginalizing many of the advantages of open source, reducing it to little more than a way to build a little extra trust with your customers and get some testing done for free, things which can and are routinely enforced by other mechanisms with proprietary licensing schemes.
That's why I read this as a claim of the failure of open source -- that it never delivers on the supposed advantages it has over proprietary development, and that we'd all be better off if the people running these community projects were corporate instead.
That said, I can certainly see how I might be misinterpreting it. It's a short interview. If you can point me to something more detailed that Marc Fleury has said on the topic, I will gladly read it and retract my condemnation if appropriate.
I'm not missing his point, I'm saying that his point is irrelevant, because it misses the point of the open source development model. Open source software evolves, both socially and technically, in ways completely alien to the proprietary world.
If you "give until you're tired of giving" as he puts it, it's because you haven't attracted other developers to give back. Either your software isn't useful enough to warrant it, or isn't of sufficient quality that people feel like investing time in it.
In other words, his theory about the failure of open source is relevant only if your software sucks. If your software sucks, it's going to fail no matter what the development model is.
If you haven't kept the code for stuff like this, you're hosed anyway.
Most small businesses don't have a single employee who knows what a compiler is. There's a whole bunch of "If you don't do this, you're hosed" stuff that small businesses just don't have the economies of scale to do. That's why they hire consultants in the first place, but sometimes they don't really know which one to hire or what to ask of them.
You're missing the point.
The hobbyist/hippie projects he cites inevitably develop into mature, disciplined programming efforts, if they're sufficiently useful. If they're not useful, they're irrelevant. There are plenty of useless, irrelevant pieces of software in both the open source and proprietary worlds. The difference is that in the open source world, it's much easier to become useful, relevant, and mature quite quickly, and draw in the development, documentation, and QA efforts of people who are being paid for it.
Clearly this man never studied economics, because he fails to recognize that money, by itself, is not a motivator of economic activity (such as expenditure of personal time or paid development resources). Money is merely convertible into utility, and it is utility which drives economic activity. People generally start F/OSS projects for one of two reasons:
A) The software will do something for them that is economically beneficial.
B) The software will do something for customers that the customers are willing to pay money for, because it is economically beneficial for them.
There's no charity here, except as a welcome and encouraged side-effect. Sure, plenty of projects begin as exercises in curiosity, but anything you hear about has been developed to maturity because it was economically worthwhile for several people to spend valuable resources improving it. One of the critical strengths of F/OSS is that it allows distant people who individually lack the resources to implement a solution to their common problem to tackle it together and get a result. It also enables people who *have* the resources to pool them to get a *better* solution. That's why you see all of these competing hardware companies working together on Linux. They realize that hardware is only good if you've got software to run on it, and it's better for all of them if the software developers are working on one OS that's good on all these platforms, rather than each having to maintain their own proprietary unix.
I agree that dynamic linking has vulnerabilities, but generally speaking, if someone's got enough priviliges on your box to be exploiting any of those, they own it anyway. It's just a matter of convenience.
The "so many people" are typically the novice developers who do short contract work and then are difficult to find when something goes wrong. They build custom tools that countless businesses use all-day every day, and are either mission-critical or somewhere close to it. Large companies are generally organized well enough that this isn't a problem, since they either do it in-house, go to a reputable contractor, or make very certain that they keep the code themselves. The problem is, most of the economy is small business. They decide "It would be worth $5000 dollars if I had a program that did foo." and then they ask around and find someone willing to write that program for $5000. This someone decides they want to make the whole thing completely self-contained, so they statically link it. There's plenty of share/demo-ware out there that's shipped like this too, and small business uses that like mad. Most of them don't quite get F/OSS yet.
This happens ALL THE TIME. It's generally in software you've never heard of, but it's running on computers all around you. The comfort is, the variety of the programs susceptible to this generally makes writing a generic exploit using code execution difficult, but even denial of service is bad.
I have to say, I'm really confused here. I've got this pay stub here which shows income sufficient to support myself, despite being still in school and only an intern, from an open source company. I've also got this company financial information and analyst opinions here, with the financials showing everything positive for the last two years, and average analyst opinions leaning about as far towards "buy" as I've ever seen for any widely-followed stock.
One of two things must be happening here. Either I have been hallucinating so completely for the last year of my life that I think I'm living well and employed while I'm actually in a padded room somewhere, or the JBoss founder is just full of shit. Since even severe schizophrenics capture enough information about their surrounding to at least vaguely know where they are (though it may confuse them due to conflict with their imagined world), Occam's Razor suggests that the JBoss founder is indeed full of shit.
This is a perfect example of why dynamic linking is Usually A Good Thing. People are always going to be using libraries, and, like all code, those libraries invariably have bugs.
Appallingly, so many people still insist on static linking of published binaries, with no more compelling reason for this than a barely measurable performance boost they could make up for ten times over by profiling the app and recompiling with that data. This of course assumes that they're testing the final binary.
I don't mean to start up the static vs. dynamic linking flamewar, because there are plenty of circumstances where static linking is perfectly appropriate, but if you can't make a good argument for it, dynamic linking should be the default.
Now we have countless windows apps out there with overflows in both JPEG and PNG (recall the overflow in JPEG a few months ago). It looks like the old "images are safe" mantra that tech support has been spouting out to users regarding attachment safety is falling apart.
As Radiohead says, anyone can play guitar.
I'll be worried when it gets addicted to heroine and starts banging groupies and trashing hotel rooms.
Yes, but "Wireless Fidelity" doesn't actually mean anything. It's a technically useless marketspeak term. Under the guise of explaining technology, they expanded a marketspeak backronym. This is what I mean when I complain about how confidently they stripped their article of any actual informative content. You have a point though. I should have clarified my complaint. My complaint is not just about what they got wrong, but about how much space that could have been spent on useful information was completely squandered in their masturbatory exposition of an incredibly primitive understanding of technology.
That one speaks for itself.
They make it sound like he just used Lowe's to get internet access. Lowe's was sending credit card number, expiration date, cardholder name, billing address, and cvv2 number in the same unencrypted packet.
It's been called the "Man In The Middle" attack since long before wi-fi ever existed. Where the hell did "evil twin" come from? Are they just making shit up?
He makes it sound like there's only one program on the web that can crack WEP. There are several, because there are several independent flaws in WEP, and most implementations are susceptible to multiple different attacks.
GAH!
As far as I know, not even the BSA has attempted to assert that failure to abide by terms of service, in the absence of additional laws, constitutes a criminal act. At least this is a quote.
What's really appalling is the confidence with which they maul both reality and language. It's one thing to be light on details, or present them as uncertain or controversial. It's quite another to present them as a straightforward list of facts to acquaint those otherwise ignorant. They do quote Mike Godwin, but they use misuse his quote to make it sound like he's talking about something else, so they've squandered what slight authority they could have had.
You're joking, right? Basic Input Output System. No, you don't need it doing anything terribly intelligent once it's booted, but you definitely need it to NOT be doing anything incredibly stupid. I've seen plenty of repeatable post-boot panics, device resets, data corruption, machine check exceptions, etc., that were fixed by BIOS updates. Veteran laptop users will also tell you about the huge impact the BIOS version makes on how many charge cycles your battery will go before you have to throw it out and get a new one.
Also remember that a BIOS update accomplishes a firmware update for any onboard devices (except for some rare, really weird ones). The one piece of firmware that I've seen makes even more of a difference than the BIOS proper is the firmware on a RAID card, and some boards have those built in too. (And then some have fakeraid, but that's another rant.) There are even some network cards with significant firmware bugs.
I personally will cheer when BIOS is dispensed with, so long as it doesn't get replaced with something even more hideous, like ELILO on Itanium systems. Until then, I will update it any time I have a problem I can't fix in software, or any time I can on a laptop.
It used to be considered impossible to sail a boat upwind, too. The world of fluid dynamics is full of weird cheats, so the word "impossible" really shouldn't be used in describing yet-unacheived feats in the field.
The submitter evidently assumes that specs have actually been written independent of the design, as would be the case if the product was created through an organized engineering process.
Ha.
Hahaha.
HAHAHAHAHAHA!
I completely agree with the parent.
1) I love my current commercial job, but there's always this sense that no matter how much I do, at the end of the day there are more tasks to do than when I began. My management is great about prioritizing projects so that this doesn't become a burden on us, but if they ever decided that we suddenly need to implement all of these great ideas we're coming up with, half the people are going to stop coming up with great ideas so they can survive, and the other half will quit. At my university jobs my role was always philosophically more of a sustaining one than a developing one, even when I was working on new projects. I was rewarded for the work I did, but I never felt there was any danger of being a victim of my own success.
2) Make friends with a well-organized, well-connected person higher up in your organization as soon as you can. Every bloated university bureaucracy has a few people in each department who can really get things done, but as this tends to suddenly make them dangerously popular, they learn to be somewhat difficult to get ahold of. You end up with this whole underground illuminati organization of people who know they can count on each other to get things done. You want to get in on this as fast as you can.
3) Pay careful attention to those benefits. Some of them could pay off HUGE in terms of things like retirement planning. Because of screwy budgeting policies (especially for a public university) you could find yourself living frugally but filling up a 401k quite quickly. I generally agree with parent's comments about tolerance as well. The liberalism is also true, but depending on what part of the country you're in, that might mean the liberal wing of the Republican party.
Years ago I tried to warn people that Tempel 1 was an alien monitoring post, and that it we needed to study it to discover their origins so we could be vigilant for their return. I was locked up for years. Now that I've escaped I find that they're smashing a rocket into it! While this at least proves I wasn't crazy, it's not going to help anything. Any civilization that has the technology to maintain a link to an outpost in a remote star system without it being detected by civilian scientists probably has the ability to defend itself against what it would probably perceive as aggression. While I'd like to believe that their advances have made them peaceful and even merciful, recent events on Earth suggest that the best we can hope for is millenia of enslavement.
If you've got a bunch of machines that rarely need to be messed with locked inside rooms/closets that will be in easy reach of the administrator(s), you can give each one a unique, high-entropy password and tape it to the box. Then a compromise of one of them will not compromise any others. If an attacker has physical access you're 0wn3d anyway.
This is particularly useful when you're doing a small business setup, when the "administrator" is the person in the office with the strongest computer skills, but has a completely different job description, and is likely to lose track of a notebook or whatever else. Contrary to the environments a lot of slashdotters work in or have worked in, most people work in companies with no dedicated technical staff, so it's quite helpful to set them up with something like this, especially if you're the contractor/friend/relative who they'd call when they need to change something and can't. Anyone who's done enough support has probably had the realization that every request to change/reset a password is an inherent security risk.
The physical access warning is key though. Left to their own devices, they won't think twice about putting the server in plain view in the reception room.
Oxytocin is released in women during nursing, helping establish a stronger bond with the baby. So really, all you have to do to get a woman to trust you is suck on her nipples!
It's the project's problem if they want the continued support of the vendors. A completely plausible example of how a vendor could be justifiably furious:
1) Vendor gets bug reports from their customers.
2) Vendor examines the code and discovers that the bug is exploitable.
3) Vendor's developers write a patch and send it to the project's security team.
4) Project security team realizes that they do a similar bad thing in other parts of their code, and the fix will need to be a much larger patch.
5) Project publishes the larger patch with full disclosure of vulnerabilities.
6) Vendor's QA and distribution people stay up all night verifying this much larger patch, to minimize the amount of time their customers are vulnerable to the exploit they discovered in the first place.
No, it doesn't always happen like this, but it can and has. This is why the vendors have set up coordinated disclosure agreements, where they all say "We're going to publish this whole thing at exactly this time." and if any vendor can't QA it and push it out to their customers in time, that's their problem.
For the millions of dollars in development effort that the various commercial distributors put into the various F/OSS projects they use, you'd think they deserve a level playing field on security. If your project doesn't think the vendors deserve this level playing field, don't be surprised when your project gets forked, or those millions of dollars in development effort get redirected to someone else's project.
When OpenSSH had a massive hole, they went around telling everyone "upgrade to this particular version or higher". When full disclosure was made a few days later, everyone realized that the default configuration of several previous versions already protected them from it anyway, and got extremely pissed off that they had to stay up all night for a couple of days to QA this change to a very critical component of their distribution, when they could have just said "turn on privilege separation until we've backported the fix". This pissed off pretty much everybody.
Speaking of pissing off pretty much everybody, I don't think that DJB speaks for a whole lot of the security community. He's respected (not necessarily liked) in the academic security community, but I doubt you'll find too many people who would argue that he plays well with others, which is kinda what this whole thread is about.
Not just Red Hat, this is SOP in the industry. But it's not "Don't release until we're ready.", rather "Please give all of the vendors the patch and a little time to build it, QA it, and prepare it for distribution, and if anyone gets left behind, that's their problem."
In many cases, bugs are actually discovered by the vendors in the first place, so publishing a patch before the time the vendors have agreed upon is in many cases incredibly rude. For the bugs discovered elsewhere or by your own developers, it's probably worth considering how much these distributors do for your product.
If you really want to screw the vendors on security patches, don't be surprised when they decide to fork your project or move all their developers to another project entirely.
Remember, Free Software is about choice.
Sounds like the alleged rules involve keeping bugs secret until users of the code have updated it and/or changing their release cycle to accomodate this.
Nope. What happens is that everyone agrees to make full disclosure and a patch available at exactly the same time. Sure, this delays the patch slightly, but it keeps everyone on a level playing field for security, since it means that attentive sysadmins can read the advisory, determine if it applies to their systems, and have their machines patched within *minutes* of the announcement, no matter what OS/distribution they use. It's nothing like the "upgrade to the latest version and we'll tell you why in a few days" fiasco when the double-free bug was found in OpenSSH. Coordinated security updates also go through several vendors' (different) QA processes, greatly reducing the risk that the patch broke something else.
The paper wasn't out when this article was posted, so the parent's speculation was reasonable, and mostly correct.
Anyway, while it's theoretically an issue on paged systems, the time and space granularity there is far too coarse to do something so delicate as capture an RSA key. This attack can resolve to a cache line (64 bits) rather than a page (32768 bits), and doesn't have context switches trashing the timing resolution. Thanks to some insight about how OpenSSL performs RSA operations, this is fine enough resolution to determine individual bits, which probably isn't feasible with a paging attack.
Unlike SMP, with HT you're interleaving two threads on the same physical execution unit. That means that there is data from another thread in registers at the same time that you're executing, without having enough instructions execute during a context switch to flush the pipeline. It also means that the other process's page table is in the MMU while you're executing. Even if their proof-of-concept attack doesn't work on some other operating systems, everyone needs to look over their code to make sure this isn't just an accidental effect that could change with increasing pipeline depths, different context switch logic, etc.
I used to get explorer crashes a lot, back when I had to use Windows (2000?) to support it. This being a work machine, there was about as little as possible installed on it. More often than not, it would properly restart, but every now and then I had to re-invoke Explorer from Mozilla. Yes. I associated the bitmap file type with Windows Explorer in Mozilla, and bookmarked one on my local hard drive, so that as long as I had Mozilla open when it died, I could get the rest of the GUI back.