Perhaps this entire class of problem can be solved by not providing such accurate timers in the CPU or randomize them somehow, making them useless for measuring these kinds of tiny variations but still useful for measuring things on the order of microseconds.
I don't see how a different timing would allow you to deduce anything from something that was loaded into the cache. A cache load on modern CPU's consists of loading multiple bytes at a time (8, 16, 32) and a slight timing difference won't tell me the value of those --
just if something was loaded or not, not any of the individual hundreds of bits.
Now, *if* you could do a second read on the same location *after* it was loaded into the cache (perhaps bypassing the security check as it won't hit DRAM) then you could extract all the information.
Or potentially you could do some kind of comparison or and/or masking on the read value and deduce individual bits from the timing differences...
Closed source code is just as bad. Software is written by people. Sometimes it is better (as people get paid to make it good) and sometimes it is worse (as there are people working on it that only care about getting paid). Sometimes people don't care about getting paid and enjoy what they do (then it is *really* good).
That's not hard to believe at all. Bacteria have almost no mass, getting hit by an object going very fast would only result in a tiny amount of energy being released as a result of the collision, certainly not enough to kill the bacteria.
Only division (and plain right shift) actually works differently on signed vs unsigned types.
The Java designers correctly thought that having 1 extra bit so you can store a slightly bigger number was not worth having unsigned types for. Just use a bigger type then.
It saves millions of Java programmers of having to deal with all the issues that arise when dealing signed and unsigned integer conversion, for example when dealing with float types, which are always signed (but I'm sure there are whiners that want unsigned float types for some obscure reason).
I've used JNA often enough to interact with C libraries, and having to deal with unsigned stuff is a mere small annoyance when compared to the clumsiness of what C library writers refer to as an "API". Certainly not excruciatingly painful.
Except there're not so smart. They're about as smart as first generation garbage collectors which used ref counting, meaning they can't deal with cyclic references.
Yes, and as the government isn't getting its fair share, it will just have to raise taxes for all those people that do pay taxes. End result: Apple executives get richer, you get poorer.
Yeah... I said no when they asked me to be on call 24/7 (for a pittance). I stand behind the product, but I won't be exploited.
Our shop did their own QA (although with dedicated testers as apart of the team), our own loadtests, had solid unit test coverage (all code was reviewed, including tests), and integration tests. It was rare something would go live uncaught, and if it did, we could rollback to the previous setup at a touch of a button.
It's to reduce the fraction of verification emails that bounce. Some email smarthosts penalize senders for excessive bounces.
I doubt it will help much at all. Any significant percentage of bounces is probably coming from bots, and I'm sure they're experts at creating valid email addresses.
It's also to ensure that the user didn't inject command-line options or other security-compromising garbage into the address that the form's action code is about to feed to the MSA.
I hope you're trying to be funny. That's about as stupid as saying that we add verification to the "surname" field to make sure you're not entering an SQL statement. Obviously whatever is entered is escaped and quoted. It almost seems like you are suggesting this field is copy pasted on a shell command without quotes and escaping... you have bigger problems then.
You'd be surprised at how many non-technical users fat-finger their email addresses, causing the chosen username to be unavailable because the verification mail was never received.
I have no doubt this happens, but if THAT'S your reason, then all fields should have this redundancy.
There is also the group that doesn't want to be treated like criminals.
No need to be paranoid to watch over your privacy. Frankly, it is nothing short of amazing how much stuff already happens behind your back and is innocently sending data back home... any application that can send data, can set up a reverse tunnel to do whatever it likes.
Therefore I went back to the way internet was accessed before the turn of century: you access it by proxy (socks5 or otherwise), and if you donot know the proxy, then no internet for you. The amount of stuff that gets blocked this way is amazing, and what's more amazing, there's is no complaining... just sneakily use the internet, but if it is not there, let's not alert the user about it.
If you are a developer, with the current market, show some backbone and tell them they can do it themselves if they think they can do it quicker.
But I guess it all depends on the way your job market is structured. Apparently in some countries the reason you were fired or left the previous company is somehow considered relevant, and a good recommendation from your previous boss is mandatory if you ever want to work in the industry again. Experience is less relevant, all that matters is that you conform to the system.
In other countries however, we see those things for what they are: a way to keep you, and your wage, under control. Step out of line, and you'll never find a job again. Don't want to do overtime or work weekends? You'll get a bad recommendation.
If you live in a country where these practices are outlawed, you will find that you can actually talk to your boss like he/she is a real person, have a beer with him/her (and only if you want to, not mandatory), and discuss things like adults as a team. Why? Because they donot have the power to ruin your life forever but only to the extend that you may have to look for another job in the presence of sufficient evidence that you are underperforming.
In such countries you can, when you're treated like a replaceable cog, stand up for yourself and if necessary find a better company with a better culture. If you are a *really* good developer, you may even have offers lined up already. A mediocre developer may actually have to click apply somewhere and have to wait a few days to get a new job. Crappy developers may have to bluff a bit but will likely find a new spot within a few weeks...
Email addresses either work or not (that's what the verification mail is for). Why software bothers to "parse" these at all I never quite understood -- there is nothing to parse, nothing to extract, it is a piece of text that when fed to an SMTP program may or may not result in a mail to whoever is filling in your form.
If I want to give you a wrong email address there is nothing you can do about it anyway. If you want to be sure, you send a verification mail, no parsing needed. The mail either works or not, and therefore your account either works or not.
It's about as stupid as asking to "retype" your email address... it is not like it is hidden like a password, I can see whether I typed it correct or not without typing it twice. Some forms even go as far as not allowing copy/paste for the 2nd time you need to type your email address...
I wrote a simple DI framework, it does take a bit more than that for even basic functionality. However, I'm interested so if you have some link or code. Perhaps it will offer some inspiration.
I would have used an existing framework, but none of the ones I found supported changing dependencies at runtime (when loading a plugin or something). Both Guice and Spring are very much static
However, we weren't talking about a random piece of code, but some of the most used frameworks (in any language) on the planet.
What do you think is a more likely source of security bugs?
a) Closed source code written by your team / company, used by only your team and maybe a few others in the company, with a small end-user base (a few hundred thousand) in a maybe half a dozen apps or websites?
b) Open source framework code, with regular releases used by millions of developers, serving 10's of millions of users in thousands of apps or websites?
Also remember that the people writing frameworks are usually the more experienced developers who are highly likely more security minded than your team will ever be (or the framework wouldn't be such a success).
I will place my bets on your closed source code any time -- and the more of it you write, the more attack surface you create.
It's also a fallacy that importing a huge framework will somehow expose you to all security flaws it may have if you only use a small part. That's about as accurate as saying that the 12 million lines of code in Linux kernel drivers need to be all checked for security flaws whether the driver is loaded or not.
The example given was Guice, which is a DI framework. To implement DI you need to write at least a couple of thousand lines of code, using not every day concepts like annotation scanning, reflection, thread safety, etc. That's a non-trivial amount of work requiring a solid test suite to boot.
Other than that I totally agree with you. I cringe every time I see some huge framework imported just to use one of its utility functions... Sure, a framework is great if over half the code needs it and it saves a lot of work, but adding a new huge framework to a huge existing code base without thought to save writing a dozen lines of code? I reject those commits when I'm leading the project.
The real mistake is that people think you can teach people how to write proper software with a couple of hundred contact hours as a small part of a 4 year university program. Many of these people didn't have enough prior interest in building software to even have tried writing some software before attending these classes.
It is about as delusional as thinking that you can become a star athlete having done nothing but sitting on a couch for years eating chips and then doing 4 years of aerobics and spinning classes for a few days a week.
Every decent software engineer I know is passionate about their *hobby* -- it isn't even work to them, it is like getting paid for the thing you like to do anyway. Without fail, they learned to build software on their own, self educated, often in their teens before schools even touched the subject. They have years of experience that go far beyond the experience they obtained doing "work" -- they often toy on side projects, in their spare time, and will fiddle with designs and code until it is just right, deadlines be damned.
There are precious few of those people, and while some no doubt will be able to become decent engineers through education, they'll never be as good or as those curious people that made software their lives early on.
Those few are the ones you want to keep. However, you won't be able to keep them if you don't pay them well, or make their lives difficult/annoying with stupid management decisions. They'll be the first to leave as they have many options and don't have to deal with stupidity -- leaving your company with those that seem unable to learn from their mistakes, or just don't give a shit.
I'm considered a decent developer, and if you want to keep me you better be prepared to pay me significantly more than that fresh CS graduate that just joined the team, don't give me any shit, trust what I'm doing and let me do my work unsupervised -- like how you would treat another person that you've come to respect and trust.
Do that, and I'll pro-actively come up with ideas and solutions for problems you didn't even know existed yet and will treat your software as my own making sure that no harm comes to it, not from inside or outside the team.
Failing that, I'll just rake in some money until something better comes along, while you only get maybe 50% of my best as the constant distractions/annoyances/stupidity just don't foster a good environment for creative work.
Quality? That's not quality. *OUR* software comes with its own Kernel, or are you gonna deny that Kernels aren't full of security issues? Some kernels consists of over 15 million lines of code! Did you check all those?
Sure, customers are surprised at first when none of their other software runs anymore on machines with ours installed, but it is guaranteed secure.
Slashdot Mirror
They're reasonable because they have competition. We'll see how long that lasts if that ever changes.
They do, in nature, just not in computers that treat every result as exact instead of fuzzing the results appropriately.
Perhaps this entire class of problem can be solved by not providing such accurate timers in the CPU or randomize them somehow, making them useless for measuring these kinds of tiny variations but still useful for measuring things on the order of microseconds.
I don't see how a different timing would allow you to deduce anything from something that was loaded into the cache. A cache load on modern CPU's consists of loading multiple bytes at a time (8, 16, 32) and a slight timing difference won't tell me the value of those --
just if something was loaded or not, not any of the individual hundreds of bits.
Now, *if* you could do a second read on the same location *after* it was loaded into the cache (perhaps bypassing the security check as it won't hit DRAM) then you could extract all the information.
Or potentially you could do some kind of comparison or and/or masking on the read value and deduce individual bits from the timing differences...
I'll let you in another secret.
Closed source code is just as bad. Software is written by people. Sometimes it is better (as people get paid to make it good) and sometimes it is worse (as there are people working on it that only care about getting paid). Sometimes people don't care about getting paid and enjoy what they do (then it is *really* good).
That's not hard to believe at all. Bacteria have almost no mass, getting hit by an object going very fast would only result in a tiny amount of energy being released as a result of the collision, certainly not enough to kill the bacteria.
Only division (and plain right shift) actually works differently on signed vs unsigned types.
The Java designers correctly thought that having 1 extra bit so you can store a slightly bigger number was not worth having unsigned types for. Just use a bigger type then.
It saves millions of Java programmers of having to deal with all the issues that arise when dealing signed and unsigned integer conversion, for example when dealing with float types, which are always signed (but I'm sure there are whiners that want unsigned float types for some obscure reason).
I've used JNA often enough to interact with C libraries, and having to deal with unsigned stuff is a mere small annoyance when compared to the clumsiness of what C library writers refer to as an "API". Certainly not excruciatingly painful.
Yeah, smart pointers...
Except there're not so smart. They're about as smart as first generation garbage collectors which used ref counting, meaning they can't deal with cyclic references.
It's not less readable. Your Pascal is way too verbose, giving you the illusion that just because it sounds like English you actually understand it.
These are not the issues C/C++ programmers are having trouble with, because these are beginner problems.
The scenario is obstacle on the road, large enough to cause serious damage. It won't even bother to classify it as a deer, bear, wolf, whatever.
Yes, and as the government isn't getting its fair share, it will just have to raise taxes for all those people that do pay taxes. End result: Apple executives get richer, you get poorer.
Yeah... I said no when they asked me to be on call 24/7 (for a pittance). I stand behind the product, but I won't be exploited.
Our shop did their own QA (although with dedicated testers as apart of the team), our own loadtests, had solid unit test coverage (all code was reviewed, including tests), and integration tests. It was rare something would go live uncaught, and if it did, we could rollback to the previous setup at a touch of a button.
I doubt it will help much at all. Any significant percentage of bounces is probably coming from bots, and I'm sure they're experts at creating valid email addresses.
I hope you're trying to be funny. That's about as stupid as saying that we add verification to the "surname" field to make sure you're not entering an SQL statement. Obviously whatever is entered is escaped and quoted. It almost seems like you are suggesting this field is copy pasted on a shell command without quotes and escaping... you have bigger problems then.
I have no doubt this happens, but if THAT'S your reason, then all fields should have this redundancy.
Of course, you have to boil the frog slowly.
There is also the group that doesn't want to be treated like criminals.
No need to be paranoid to watch over your privacy. Frankly, it is nothing short of amazing how much stuff already happens behind your back and is innocently sending data back home... any application that can send data, can set up a reverse tunnel to do whatever it likes.
Therefore I went back to the way internet was accessed before the turn of century: you access it by proxy (socks5 or otherwise), and if you donot know the proxy, then no internet for you. The amount of stuff that gets blocked this way is amazing, and what's more amazing, there's is no complaining... just sneakily use the internet, but if it is not there, let's not alert the user about it.
Am I the only one that thinks in 10 years time any fighter aircraft stupid enough to fly over a war zone will be shot done by fully automated drones?
If you are a developer, with the current market, show some backbone and tell them they can do it themselves if they think they can do it quicker.
But I guess it all depends on the way your job market is structured. Apparently in some countries the reason you were fired or left the previous company is somehow considered relevant, and a good recommendation from your previous boss is mandatory if you ever want to work in the industry again. Experience is less relevant, all that matters is that you conform to the system.
In other countries however, we see those things for what they are: a way to keep you, and your wage, under control. Step out of line, and you'll never find a job again. Don't want to do overtime or work weekends? You'll get a bad recommendation.
If you live in a country where these practices are outlawed, you will find that you can actually talk to your boss like he/she is a real person, have a beer with him/her (and only if you want to, not mandatory), and discuss things like adults as a team. Why? Because they donot have the power to ruin your life forever but only to the extend that you may have to look for another job in the presence of sufficient evidence that you are underperforming.
In such countries you can, when you're treated like a replaceable cog, stand up for yourself and if necessary find a better company with a better culture. If you are a *really* good developer, you may even have offers lined up already. A mediocre developer may actually have to click apply somewhere and have to wait a few days to get a new job. Crappy developers may have to bluff a bit but will likely find a new spot within a few weeks...
Email addresses either work or not (that's what the verification mail is for). Why software bothers to "parse" these at all I never quite understood -- there is nothing to parse, nothing to extract, it is a piece of text that when fed to an SMTP program may or may not result in a mail to whoever is filling in your form.
If I want to give you a wrong email address there is nothing you can do about it anyway. If you want to be sure, you send a verification mail, no parsing needed. The mail either works or not, and therefore your account either works or not.
It's about as stupid as asking to "retype" your email address... it is not like it is hidden like a password, I can see whether I typed it correct or not without typing it twice. Some forms even go as far as not allowing copy/paste for the 2nd time you need to type your email address...
I wrote a simple DI framework, it does take a bit more than that for even basic functionality. However, I'm interested so if you have some link or code. Perhaps it will offer some inspiration.
I would have used an existing framework, but none of the ones I found supported changing dependencies at runtime (when loading a plugin or something). Both Guice and Spring are very much static
For a random piece of code, I don't know.
However, we weren't talking about a random piece of code, but some of the most used frameworks (in any language) on the planet.
What do you think is a more likely source of security bugs?
a) Closed source code written by your team / company, used by only your team and maybe a few others in the company, with a small end-user base (a few hundred thousand) in a maybe half a dozen apps or websites?
b) Open source framework code, with regular releases used by millions of developers, serving 10's of millions of users in thousands of apps or websites?
Also remember that the people writing frameworks are usually the more experienced developers who are highly likely more security minded than your team will ever be (or the framework wouldn't be such a success).
I will place my bets on your closed source code any time -- and the more of it you write, the more attack surface you create.
It's also a fallacy that importing a huge framework will somehow expose you to all security flaws it may have if you only use a small part. That's about as accurate as saying that the 12 million lines of code in Linux kernel drivers need to be all checked for security flaws whether the driver is loaded or not.
Oh, another one of those "the language is your problem" people.
I suppose you also say stuff like:
"... if we had written it in X using this 3 month old framework then we wouldn't be in this mess."
"You don't need a compiler, just write unit tests with full coverage."
"... in language X you can write 30% less lines of code, resulting in 30% less mistakes!"
"My programming speed is bottlenecked by the amount of characters I need to type..."
Anyway, thanks I'll give your valuable opinion the attention it deserves.
The example given was Guice, which is a DI framework. To implement DI you need to write at least a couple of thousand lines of code, using not every day concepts like annotation scanning, reflection, thread safety, etc. That's a non-trivial amount of work requiring a solid test suite to boot.
Other than that I totally agree with you. I cringe every time I see some huge framework imported just to use one of its utility functions... Sure, a framework is great if over half the code needs it and it saves a lot of work, but adding a new huge framework to a huge existing code base without thought to save writing a dozen lines of code? I reject those commits when I'm leading the project.
The real mistake is that people think you can teach people how to write proper software with a couple of hundred contact hours as a small part of a 4 year university program. Many of these people didn't have enough prior interest in building software to even have tried writing some software before attending these classes.
It is about as delusional as thinking that you can become a star athlete having done nothing but sitting on a couch for years eating chips and then doing 4 years of aerobics and spinning classes for a few days a week.
Every decent software engineer I know is passionate about their *hobby* -- it isn't even work to them, it is like getting paid for the thing you like to do anyway. Without fail, they learned to build software on their own, self educated, often in their teens before schools even touched the subject. They have years of experience that go far beyond the experience they obtained doing "work" -- they often toy on side projects, in their spare time, and will fiddle with designs and code until it is just right, deadlines be damned.
There are precious few of those people, and while some no doubt will be able to become decent engineers through education, they'll never be as good or as those curious people that made software their lives early on.
Those few are the ones you want to keep. However, you won't be able to keep them if you don't pay them well, or make their lives difficult/annoying with stupid management decisions. They'll be the first to leave as they have many options and don't have to deal with stupidity -- leaving your company with those that seem unable to learn from their mistakes, or just don't give a shit.
I'm considered a decent developer, and if you want to keep me you better be prepared to pay me significantly more than that fresh CS graduate that just joined the team, don't give me any shit, trust what I'm doing and let me do my work unsupervised -- like how you would treat another person that you've come to respect and trust.
Do that, and I'll pro-actively come up with ideas and solutions for problems you didn't even know existed yet and will treat your software as my own making sure that no harm comes to it, not from inside or outside the team.
Failing that, I'll just rake in some money until something better comes along, while you only get maybe 50% of my best as the constant distractions/annoyances/stupidity just don't foster a good environment for creative work.
Quality? That's not quality. *OUR* software comes with its own Kernel, or are you gonna deny that Kernels aren't full of security issues? Some kernels consists of over 15 million lines of code! Did you check all those?
Sure, customers are surprised at first when none of their other software runs anymore on machines with ours installed, but it is guaranteed secure.