... if the software doesn't need the port to be open on the internal network then why is it open?
Firewalling the port on each indivudual system behind the main firewall would then imply that the software couldn't actually function (for any reasonable definition of the word "function").
lists and you'll find that most vulnerabilities are either buffer overflows or string format vulnerabilities. There are very few circumstances where fixing those with a one-liner patch would change behavior in a way that other code depends on. If there were any such code then that in itself indicate possible data corruption bugs in the currently running software.
In short: When you don't bundle fixes you typically have one-line fixes which don't break code which isn't already broken (by relying on buggy behavior). Hence, testing time is minimized.
but usually patches for OSS vulnerabilities are not bundled along with all sorts of other updates. This means that far less testing is usually needed for OSS security patches. (Or, that's the theory, anyway.)
Passwords are NOT vulnerable.
on
SHA-1 Broken
·
· Score: 1
Their method only guarantees two different plaintexts which hash to the same value. It does not, however, guarantee any particular hash value -- you need this for password breaking since you must obtain a value which hashes to the (fixed) hash value of the user's password.
1) Get real. Nobody in their right mind is going to write a word processor in assembler. Besides, what do you mean by a "good macro assembler"...? Something which can lend syntactic support for things like structs, objects, etc.? If you do, then you're basically talking about C anyway. Except you can't just retarget assembler and hope it will run efficiently/at all... so now each architecture has to have its own implementation disjoint from all the others. Even if you only have one architecture, each programmer still has to dedicate a lot of time becoming as proficient at assembly as your run-of-the-mill C compiler is today.
2) Yeah, so let's make it much harder to get something to work in 99% of all cases just to make it easier to get it to work in 1% of the cases where something goes wrong. (Percentages made up as always, but I'm probably being generous).
3) More portable? In which way? I'll bet you a beer that Tk runs on more platforms than any other text-based UI framework you can think of. (And don't say 'ncurses'... that's much lower level and doesn't implement even a tenth of the functionality).
There's no indication that the people working on HURD would work on Linux if they couldn't work on HURD. Although you might speculate that they would, they might equally well work on one of the BSDs.
And I doubt that Hurd would have any noticeable advantages over Linux.
Oh, it has lots of advantages, particularly for "kernel" developers and system administrators. For developers, implementing e.g. new file systems is much, much easier than in a monolithic kernel (although FUSE has helped here it still feels kind of like a hack). For sysadmins there is much less privileged code to worry about. (There's lots more but those are the ones that spring to mind).
I believe he was requesting
on
The CSS Anthology
·
· Score: 2, Insightful
and that applying <div class="bar"> would then set the bgcolor to red and the fgcolor to blue. In your example you still have to remember that.bar is based on.foo in every single place you use it. Much less useful.
shouldn't harm your disk in any way either. Reading/dev/null is like reading a zero-byte file, which means that dd won't actually write anything to/dev/hda. No, if you want destruction you need something like
Whenever I see people trying to pull something like this I tend to remind them of one thing (everbody seems to forget this whenever XML is brought up, I dunno why...):
Semantics matter!
It's great that you can read the syntax of a language (which is basically what this idea boils down to -- people just have to implement an XML parser instead of a $LANG-parser) without effert, but if you don't understand the semantics of what you're reading it's rather pointless, unless all you want to do trivial tree-based transforms. This applies to XML in general and it applies here. As you pointed out, the semantics of languages are different, and so your tools have to understand all the different languages anyway (or, as you say, reduce them all to some common denominator).
against this type of thing. Anyway, here's what could and should be done to protect against such an exploit:
Don't accept passwords from any external source (command-line/environment/file descriptor). This opens it up to the kind of exploit you're talking about.
Ensure input is coming from a real interactive terminal before asking for the password. There should be ways of detecting whether a program is running on a *true* interactive terminal (not just a pseudo-TTY). Being setuid this cannot be subverted by using LD_PRELOAD or similar mechanisms to fool sudo into thinking it's running on an interactive terminal (or to inject characters into the input).
Always show an attempt number at the password prompt. This (hopefully) alerts the user to the fact that a new sudo has been started (and is asking for the password) after the fake one ran. If they'd just entered the password incorrectly the first time, the attempt counter would increase. IOW, the user knows that the password was compromised and can make sure it's changed as soon as possible.
use some form of RAID-type setup where data is written to multiple flash cards according to some pattern optimized to minimize the chances of failures having an impact before you could replace the failed card(s). (You would not want to use the current RAID techniques because they would cause near-equal wear on all the cards, thus incresing the likelihood of simultaneous failures).
you would have to actually not self-encrypt the message
... which is exactly what I said. "Avoid self-encrypting" is pretty much the same as "not self-encrypting".:)
You are, of course, right that you don't gain deniability (because you still have to give away the passphrase and "they" can check whether the given passphrase/key can decrypt it), but you have effectively obscured the message from the authorities even with these provisions in place -- which just goes to show how silly they are, I guess.
It might also be possible to modify the PGP system slightly to "invisibly" embed multiple keys (with different passphrases) in one "superkey". This might actually give you the ability to encrypt one innocuous message to yourself while encrypting an entirely different message to the party you were communicating with. (Disclaimer: I haven't really thought this through, but it seems like it should work).
when you encrypt something with PGP you can just avoid self-encrypting it, ie. preventing yourself from decrypting it while still allowing the party you sent it to to decrypt it. (Not sure how this would interact with signing, though).
AFAIK there is no way to prove whether you did/didn't self-encrypted the message, effectively giving you plausible deniability.
Certainly I can't imagine anyone writing the software my colleagues and I write for a living just for fun, though it plays an essential part in many essential applications in the manufacturing business.
Such software will still be needed -- manufacturing, and the custom applications market in general, will always need custom applications (or customization of existing applications). Thus, people to write/customize such software will still be needed. Thus, someone will still pay people to write such software. It's just that people won't be paying for the software itself, but rather for the programmer effort to write it.
No. Hashes are typically much shorter than files (or even bits of files) and using hashes (or hash trees) is still much more efficient than sending all the data twice.
Also, it also allows network error detection which is essentially free and more robust than just sending data twice and comparing -- if the network for has a nasty habit of throwing bits away during long sequences of 0s, your method might not detect it, but a good hash would (with overwhelming likelihood).
For reference on how dangerous that can be, please research the primary reason that the native Aztecs and Incans perished. Hint: It wasn't at the tip of a Spanish spear.
Diseases had already adapted to infect humans when they were introduced to the Americas. Very different from the scenario the article is talking about.
3a : characterized by lack of consistency, regularity, or uniformity b : deviating from what is ordinary or standard
MySQL's behavior is erratic in that it is e.g. incredibly incosisitent when it comes to NULL-related behavior. Just admit it and move on with your life, you'll be a happier person.
It's just that you don't need to carpet-bomb every article about products you don't care for.
One post hardly consitutes carpet bombing. In fact, the only single person I see prolonging this thread (by responing to these so-called "anti-MySQL" people as you like to label them) is you.
I, for one, am happy that I know about that page in case I ever decide to deploy MySQL for anything. Much of the documented behavior is downright scary and absolutely necessary to know about if you care about correctness at all.
Methods can't be polymorphic (i.e. they have to take real types, not 'a)
Yes they can. You just have to declare them slightly differently:
method blah : 'c. f:('c -> 'c) -> 'c =...
will give you a polymorphic method (in the type 'c).
Unsigned 32bit int: While not representable directly, you can just use int32. Since all platforms which ocaml actually runs on are two's completement all operations except comparisons work as expected. If you need comparisons you can just use an int64 and make sure to (mod 2^32) it when needed.
Unfortunately, the core language hasn't seen any significant updates, and even camlp4 hacks are sort of petering out
Nonsense. Examples: the pa_macro camlp4 module was added in 3.07, and the object system had a few significant changes somewhere in the 3.05-3.08 timeframe (can't remember precisely, check the changelog if you care).
Besides, who says that stabilization is a bad thing?
Slashdot Mirror
but how hard is it to take over the IP of another machine? There's a reason people don't do authentication-by-IP (or MAC for that matter).
... if the software doesn't need the port to be open on the internal network then why is it open?
Firewalling the port on each indivudual system behind the main firewall would then imply that the software couldn't actually function (for any reasonable definition of the word "function").
lists and you'll find that most vulnerabilities are either buffer overflows or string format vulnerabilities. There are very few circumstances where fixing those with a one-liner patch would change behavior in a way that other code depends on. If there were any such code then that in itself indicate possible data corruption bugs in the currently running software.
In short: When you don't bundle fixes you typically have one-line fixes which don't break code which isn't already broken (by relying on buggy behavior). Hence, testing time is minimized.
but usually patches for OSS vulnerabilities are not bundled along with all sorts of other updates. This means that far less testing is usually needed for OSS security patches. (Or, that's the theory, anyway.)
Their method only guarantees two different plaintexts which hash to the same value. It does not, however, guarantee any particular hash value -- you need this for password breaking since you must obtain a value which hashes to the (fixed) hash value of the user's password.
1) Get real. Nobody in their right mind is going to write a word processor in assembler. Besides, what do you mean by a "good macro assembler"...? Something which can lend syntactic support for things like structs, objects, etc.? If you do, then you're basically talking about C anyway. Except you can't just retarget assembler and hope it will run efficiently/at all... so now each architecture has to have its own implementation disjoint from all the others.
Even if you only have one architecture, each programmer still has to dedicate a lot of time becoming as proficient at assembly as your run-of-the-mill C compiler is today.
2) Yeah, so let's make it much harder to get something to work in 99% of all cases just to make it easier to get it to work in 1% of the cases where something goes wrong. (Percentages made up as always, but I'm probably being generous).
3) More portable? In which way? I'll bet you a beer that Tk runs on more platforms than any other text-based UI framework you can think of. (And don't say 'ncurses'... that's much lower level and doesn't implement even a tenth of the functionality).
In short: You're wrong.
Oh, it has lots of advantages, particularly for "kernel" developers and system administrators. For developers, implementing e.g. new file systems is much, much easier than in a monolithic kernel (although FUSE has helped here it still feels kind of like a hack). For sysadmins there is much less privileged code to worry about. (There's lots more but those are the ones that spring to mind).
something along the lines of
.foo { background-color: red; color: green; }
.bar { inherits: .foo; color: blue}
.bar is based on .foo in every single place you use it. Much less useful.
and that applying <div class="bar"> would then set the bgcolor to red and the fgcolor to blue. In your example you still have to remember that
Whenever I see people trying to pull something like this I tend to remind them of one thing (everbody seems to forget this whenever XML is brought up, I dunno why...):
It's great that you can read the syntax of a language (which is basically what this idea boils down to -- people just have to implement an XML parser instead of a $LANG-parser) without effert, but if you don't understand the semantics of what you're reading it's rather pointless, unless all you want to do trivial tree-based transforms. This applies to XML in general and it applies here. As you pointed out, the semantics of languages are different, and so your tools have to understand all the different languages anyway (or, as you say, reduce them all to some common denominator).
PHP and ASP are both server-side technologies and have absolutely nothing to do with client-side scripting/execution (which you seem to think).
Being setuid this cannot be subverted by using LD_PRELOAD or similar mechanisms to fool sudo into thinking it's running on an interactive terminal (or to inject characters into the input).
I think that covers everything.
If he takes code from others he should expect others to take code from him (if it's any good, that is).
I have no idea what I meant by that. :)
use some form of RAID-type setup where data is written to multiple flash cards according to some pattern optimized to minimize the chances of failures having an impact before you could replace the failed card(s). (You would not want to use the current RAID techniques because they would cause near-equal wear on all the cards, thus incresing the likelihood of simultaneous failures).
IIRC it only publishes the private key(s) used to encrypt the messages, not the public key(s) which is/are needed to decrypt messages.
You are, of course, right that you don't gain deniability (because you still have to give away the passphrase and "they" can check whether the given passphrase/key can decrypt it), but you have effectively obscured the message from the authorities even with these provisions in place -- which just goes to show how silly they are, I guess.
It might also be possible to modify the PGP system slightly to "invisibly" embed multiple keys (with different passphrases) in one "superkey". This might actually give you the ability to encrypt one innocuous message to yourself while encrypting an entirely different message to the party you were communicating with. (Disclaimer: I haven't really thought this through, but it seems like it should work).
when you encrypt something with PGP you can just avoid self-encrypting it, ie. preventing yourself from decrypting it while still allowing the party you sent it to to decrypt it. (Not sure how this would interact with signing, though).
AFAIK there is no way to prove whether you did/didn't self-encrypted the message, effectively giving you plausible deniability.
Which part of "and" don't you understand? He was referring to using both encrypted communications and partitions.
Such software will still be needed -- manufacturing, and the custom applications market in general, will always need custom applications (or customization of existing applications). Thus, people to write/customize such software will still be needed. Thus, someone will still pay people to write such software. It's just that people won't be paying for the software itself, but rather for the programmer effort to write it.
No. Hashes are typically much shorter than files (or even bits of files) and using hashes (or hash trees) is still much more efficient than sending all the data twice.
Also, it also allows network error detection which is essentially free and more robust than just sending data twice and comparing -- if the network for has a nasty habit of throwing bits away during long sequences of 0s, your method might not detect it, but a good hash would (with overwhelming likelihood).
Diseases had already adapted to infect humans when they were introduced to the Americas. Very different from the scenario the article is talking about.
Must've been somebody else then. Sorry about that.
Oh, and I marked you a foe because you (IMO, of course) acted like an ass throughout the thread.
MySQL's behavior is erratic in that it is e.g. incredibly incosisitent when it comes to NULL-related behavior. Just admit it and move on with your life, you'll be a happier person.
One post hardly consitutes carpet bombing. In fact, the only single person I see prolonging this thread (by responing to these so-called "anti-MySQL" people as you like to label them) is you.
I, for one, am happy that I know about that page in case I ever decide to deploy MySQL for anything. Much of the documented behavior is downright scary and absolutely necessary to know about if you care about correctness at all.
Yes they can. You just have to declare them slightly differently:
method blah : 'c. f:('c -> 'c) -> 'c =
will give you a polymorphic method (in the type 'c).
Unsigned 32bit int: While not representable directly, you can just use int32. Since all platforms which ocaml actually runs on are two's completement all operations except comparisons work as expected. If you need comparisons you can just use an int64 and make sure to (mod 2^32) it when needed.
Nonsense. Examples: the pa_macro camlp4 module was added in 3.07, and the object system had a few significant changes somewhere in the 3.05-3.08 timeframe (can't remember precisely, check the changelog if you care).
Besides, who says that stabilization is a bad thing?