My thinking is that it should be illegal to use any voting software unless the source code is available for inspection by anyone.
It still is not enough. You cannot know for sure that the code you audited is the one actually running on the hardware it is supposed to run on. A computer is too complex and opaque for a man to verify how it is working.
On the contrary, paper and pencil are verifiable and you can be quite confident that the person counting your vote will see the X you wrote the same way you think.
It's not a matter of speed, not in this case, at least. It's a matter of readability, reduction of redundancy and most of all maintainability.
Unfortunately, it's not easy to determine if this approach is good unless you have extensive coding experience. Several people involved in Linux kernel coding have such experience, I've learned this approach from them and my fair amount of experience convinced me it is a good approach.
It's obviously a proof of concept where the success case is not interesting. It is to show what happens in case of ERROR. Is it too hard to understand?
I don't think I'm undestanding you, sorry, I'm not a native english speaker.
I, of course, use that approach when I write C code, that's why I wrote that code snippet in C.
And I, of course, write C code in kernel land and when writing critical code in userland
Oh... and yes... memory allocation failures may well happen on modern machines in kernel land... and if you like to write robust code, you have to cope with those
to prevent horrors like OP. Did you notice how the "free(b)" call was after an unconditional return? Somebody didn't.
Yes, the compiler will happily optimize it away, however, when you are adding another allocation you don't have to remember to add the deallocation code you left out before. You may well comment it if the compiler doesn't like it but only if you licensed the comments patent:)
This is a famous urban legend, it is not a remotely controlled plane but a demonstration at an airshow badly planned and with some technical problem. There were 130 passengers on board (and luckily there were "only" three deaths).
http://en.wikipedia.org/wiki/Air_France_Flight_296
They are quite good if you don't need frequent encryptions and signatures, well supported by openssh, opensc and openssl, less with gnupg, and firefox but I didn't experiment much.
Just be sure to use the 32K version as the 64K version lacks support.
You may think it is the fscking truth, but what you say denotes a complete lack of understanding of the reasons for which FOSS people code. Choosing the license which better represents the programmer will is IMPORTANT. Otherwise we would all put our code in the public domain, which most of us do NOT want.
License WARS serve no purpose, I agree, but you will likely not see "one license to bind them all".
I'm sorry to contradict you but most laptop power supplies are not doubly insulated because the laptop itself is not doubly insulated and you really need to have it grounded in case a fault in the power supply transformer leads mains voltage to the laptop's ground.
If you disconnect the ground or your wiring doesn't have the ground, the EMI filter capacitors will bring mains voltage (albeit with a fairly big impedance) on the laptop's ground. It is not dangerous, but it may create some problem when the laptop is connected to other devices.
The guy should simply ground his laptop power supply.
Wrong. For God's sake, you dweeby little junior programmers need to do some research before you open your damn mouths.
Oh please... if you really were a "senior programmer" you wouldn't do this kind of jokes, let alone of writing the stuff you wrote.
Escaping values only brings up new vulnerabilities. In database servers these are known as SQL truncation
A DBMS which silently truncates an SQL statement is simply buggy. The vulnerability is in the DBMS, not in the interface. If the SQL statements is bigger than the maximum allowed size it HAS to fail.
You're advice about "escaping" values is just as bad as those computer science professors in college that say "re-writing your conditional statements to automatically exclude bad data will eliminate the need to validate the data that makes it through."
Validating data serves to... ehm.... validate data; in other words you want that only valid data goes into the database. It doesn't have anything to do with the possibility that the data emulates the metadata which is the issue with SQL injection. You stop data becoming metadata with escaping, no more, no less.
Goddammit. Comments (and articles) like this make me so fucking mad.
Crazyness plus incompetence is a dangerous combination. Please stop reading them.
The only real way to defend against all malicious code injection attacks is to validate every input from every user.
Seems simple enough, but it's amazing how often this is ignored or implemented badly.
...but unfortunately it's mostly WRONG. In many cases, the real way to defend against injections is to ESCAPE values before composing strings, this is mostly the case with SQL (where prepared queries and the help of a good prepare/execute API is very much helpful) but it's not limited to it.
If your parameter is a VALUE, it must remain a VALUE when you compose a command and proper escaping is the correct, reliable way.
Validating input may be helpful as another layer of security, but it's not the "only right way", it's not even the *right* way (in most cases).
Slashdot Mirror
I mean... the correlation was between "closeness to the mast" and "illness". *This* correlation led to start the study and it's very real.
But there already is a correlation, it's just the cause that is debated :)
You can say that under pressure people would not be able to detect the effect under study but in this case the symptoms were very present!
You can say that under pressure people may develop those symptoms, but, again, in other tests people under pressure do not develop such symptoms.
The obvious way to conduct such studies is NOT by trying to find a correlation, because correlation does not prove a cause->effect relation.
It still is not enough. You cannot know for sure that the code you audited is the one actually running on the hardware it is supposed to run on. A computer is too complex and opaque for a man to verify how it is working.
On the contrary, paper and pencil are verifiable and you can be quite confident that the person counting your vote will see the X you wrote the same way you think.
Oh fsck... they were DC-8s... now I have to sue myself, bastard!
They were DC-9s. Now I'm gonna SUE YOU!
It's not a matter of speed, not in this case, at least. It's a matter of readability, reduction of redundancy and most of all maintainability.
Unfortunately, it's not easy to determine if this approach is good unless you have extensive coding experience. Several people involved in Linux kernel coding have such experience, I've learned this approach from them and my fair amount of experience convinced me it is a good approach.
It's obviously a proof of concept where the success case is not interesting. It is to show what happens in case of ERROR. Is it too hard to understand?
I don't think I'm undestanding you, sorry, I'm not a native english speaker.
I, of course, use that approach when I write C code, that's why I wrote that code snippet in C.
And I, of course, write C code in kernel land and when writing critical code in userland
Oh... and yes... memory allocation failures may well happen on modern machines in kernel land... and if you like to write robust code, you have to cope with those
Yes, the compiler will happily optimize it away, however, when you are adding another allocation you don't have to remember to add the deallocation code you left out before. You may well comment it if the compiler doesn't like it but only if you licensed the comments patent :)
Oh... why don't you direct your statement to the people at linux-kernel?
If you know where and how to use them, they actually are a sensible choice.
They are very good in implementing the function rollback code, that is code which has to undo everything the function has done in case of an error.
For example:
Oh... but since they ARE the new generation, guess how much your clue will be useful when 95% of the business will use ANOTHER OS :)
Anyway... don't worry... there is always market for "legacy systems support"
Are you really sure? Because unless you live in a microwave oven, the opposite is much more plausible :)
This is a famous urban legend, it is not a remotely controlled plane but a demonstration at an airshow badly planned and with some technical problem. There were 130 passengers on board (and luckily there were "only" three deaths). http://en.wikipedia.org/wiki/Air_France_Flight_296
So, why do you think the general public has to think that one kb is 1024 bytes instead of 1000?
They are quite good if you don't need frequent encryptions and signatures, well supported by openssh, opensc and openssl, less with gnupg, and firefox but I didn't experiment much.
Just be sure to use the 32K version as the 64K version lacks support.
You may think it is the fscking truth, but what you say denotes a complete lack of understanding of the reasons for which FOSS people code. Choosing the license which better represents the programmer will is IMPORTANT. Otherwise we would all put our code in the public domain, which most of us do NOT want.
License WARS serve no purpose, I agree, but you will likely not see "one license to bind them all".
I'm sorry to contradict you but most laptop power supplies are not doubly insulated because the laptop itself is not doubly insulated and you really need to have it grounded in case a fault in the power supply transformer leads mains voltage to the laptop's ground.
If you disconnect the ground or your wiring doesn't have the ground, the EMI filter capacitors will bring mains voltage (albeit with a fairly big impedance) on the laptop's ground. It is not dangerous, but it may create some problem when the laptop is connected to other devices.
The guy should simply ground his laptop power supply.
I call bullshit on this:
/dev/random > /dev/mem
cat
So, is linux buggy?
Something from userland? Here it is:
int main()
{
while(1) {
fork();
}
}
Neither a virus.
Oh please... if you really were a "senior programmer" you wouldn't do this kind of jokes, let alone of writing the stuff you wrote.
A DBMS which silently truncates an SQL statement is simply buggy. The vulnerability is in the DBMS, not in the interface. If the SQL statements is bigger than the maximum allowed size it HAS to fail.
Validating data serves to... ehm.... validate data; in other words you want that only valid data goes into the database. It doesn't have anything to do with the possibility that the data emulates the metadata which is the issue with SQL injection. You stop data becoming metadata with escaping, no more, no less.
Crazyness plus incompetence is a dangerous combination. Please stop reading them.
If your parameter is a VALUE, it must remain a VALUE when you compose a command and proper escaping is the correct, reliable way.
Validating input may be helpful as another layer of security, but it's not the "only right way", it's not even the *right* way (in most cases).