> The DMCA would make the CDs that he is selling your text on illegal as they are being used to circumvent your copyright.
No. What ?? The CDs are just a vanilla copyright infringement. The anti-circumvention clauses in the DMCA are totally irrelevant here. (Guys, please read the DMCA anti-circumvention text. You can search for "17 USC 1201" on google to find it. A lot of people on slashdot totally misunderstand what that law says!)
The relevance of the DMCA is the takedown ("safe-harbor") provisions, by which a copyright holder can notify an ISP of an infringement and that ISP can get safe harbor from being party to the infringement if it does some stuff, like take down the site. This is a pretty odious law, and can be abused badly, but it is nowhere near as bad as the anti-circumvention stuff. I don't think there's any particular shame in using that part of the law here (after all, the GPL uses copyright law in order to enforce its "copyleft"), though I think that practically the author should just direct his concerns to something more productive.
Re:Why signed binaries are not allowed by the GPL
on
Linus on DRM
·
· Score: 1
I should have said that the derivative work is "linux with signatures". If this particular version of linux is distributed only with the signatures and requires them to run, then I think the whole thing could rightly be considered a derivative work.
If someone just goes around signing kernels and distributing the signatures separately, that's probably fair use, as you say.
However, I do agree that this argument would probably not do too well in court. I think this is a failing of the GPL because it is one of several sneaky ways that people can probably get away with distributing binaries that you can't modify and still use.
Why signed binaries are not allowed by the GPL
on
Linus on DRM
·
· Score: 2, Interesting
Under a strict interpretation of the GPL, signed binaries would be illegal to distribute, unless you distribute the private key that you use to sign them (making the signatures worthless, obviously). Here's my reasoning.
Let's assume you're using a standard signing algorithm like RSA, which signs a hash of the message (the binary).
Such a hash is a derivative work -- it's created directly from the binary through a hash function. (This is the biggest stretch of the argument, but at least in a mathematical sense this is very accurate. Note that it is not simply a re-expression of the work, but really reassembly of the bits in the original copyrighted expression). A signed hash is a derivative work of the hash of the binary, for the same reason.
Therefore, the signature has to be distributed under the terms of the GPL as well. That means that if you give it out, you need to give the source to it as well. The source code is defined in the GPL: "The source code for a work means the preferred form of the work for making modifications to it.... However, as a special exception, the source code distributed need not include anything that is normally distributed..." The source for this hash is the program that does the hashing and the signing (probably exempt by the second sentence) and of course the private key used to sign it.
Of course, this is a little tongue-in-cheek. But I think it's important to remember the clause in the GPL that requires you to provide not just source code but all of your build tools. Imagine if you created a new wacky language extension to C, (like a new primitive called do_my_secret_stuff) then used that to compile a program and gave out only the source code in C_with_secret_stuff? Those clauses are in the GPL for a reason, so don't forget what "source" means!
Yeah, well, my point is that their editor seems designed to only make that style of page. (Long vertical scroll, [H1] [H2] stuff, and the CVS tags and standards compliance buttons at the bottom, etc.) I don't claim that their page isn't navigable in a utilitarian sort of way, but it's certainly not how I'd want my web page to look. It's not really fair to compare the two based on navigability, since they have totally different purposes--snoot.org is not there for informational purposes, it's supposed to be fun, confusing, and exploratory. If I was making a page for some web design software, I'd make it a lot more clear, but then again, I'd also make it actually look good.
> > Encryption algorithms don't usually control access > > Considering that the only reason to use an encryption algorithm is to control access to a message, I have to say you don't > have a clue what you're talking about. Not only that, your humor detection circuit seems to be on the fritz.
"Technological measure that controls access to a work" is defined in the DMCA. They are not talking about the english word "control" or "access," though the meaning is similar. Read the law if you want to understand what is going on; then I would love to hear your legal argument for why this book is--by some stretch of the imagination--a DMCA violation.
In this case, encryption wouldn't qualify unless it is supposed to be decrypted as part of the normal process of making use of a copyrighted work. That was true of CSS, perhaps, but not of the encryption algorithms in this book.
Furthermore, it has to apply to a copyrighted work -- since encryption is often (if not primarily) used to encrypt non-copyrightable content (requests sent by web browsers, ssh sessions), it can hardly be considered a DMCA access control measure anyway.
I don't use Amaya because their own web page is ugly as hell. Standards compliance is great and all, but if you can't even create the design you want to create, what's the point?
Right on. Though I don't really believe in calling things "natural," (an obvious weasel word) I don't think that tresspassing counts even in the sense that most people talk about natural law. Tresspassing does not remove your ability to use the land, nor does it take any scarce resource from you. If, while I'm there, I smash up your crops or steal your sheep, then obviously that does.
The problem *is* insecure systems. When a 14 year-old can download a script and root a hundred computers in an evening, that's a problem. There will always be 14 year-olds who think they are immune from the law (and, in many senses they are today), no matter how many hackers we prosecute. It is pretty damn easy to make systems that are much more secure so that there are many fewer scripts for kiddies to get. One easy way is to use a modern safe language, where the common security bugs that cause your and my boxes to get rooted are impossible to make. If you're still in love with cowboy C programming, there are things like Stackguard and the Pax kernel patches (address randomization, etc.) that make even C code a whole lot less exploitable.
For my money, Millennium has interpreted the article right, and the article makes a good point: the most cost effective way to improve security is to make and use more secure systems, not to try to deter 14-year olds from downloading scripts by imposing draconian laws. Of course, destructive cracking will remain illegal, and people should be prosecuted when they do it, but at least those people will have had to go through a lot more trouble to do so.
OK, sure, but I think that most mediocre programmers these days are creating applications that fall into the "safety and correctness first, speed second category."
Also, I don't think that C really gets you closer to the "bare metal," unless you're thinking about 20 or 30 year old computers. Computers these days really don't fit the model that C purports: they are parallel, out of order, with a significant memory performance hierarchy. It's a real shame the kinds of games we play with our compilers as a result -- trying to coax the compiler into realizing that I am writing a parallelizable (or pipelineable) loop, for instance. Such things could be explicit in a real modern high-performance language, and some languages have such things (O'Caml, for instance) in addition to safety. It makes your life and the compiler's life easier, so hooray!
Anyway, you can probably tell that I think C is pretty crummy for application development. Of course, practically speaking it is simply the most well-supported tool, so I'm only able to make this argument if I take an idealist stance. Nonetheless, I do still think we'd be better off if people said, "I use C because it's what everyone else uses," rather than the misleading "I use it because it gets me closer to the bare metal" (or other common lines).
> Oh, and I believe one of my female friends in CS grad school said that the ratio of men to women gets more even up there.
No-ho-ho... at least at CMU, there are definitely fewer women in the grad program than the undergrad. (Our undergrad program is pretty good now, something like 30%-40% women). I don't know about other schools, but certainly the students that visit us (and from my visits to other grad schools) indicate similar numbers.
No. What possibly could be a violation? He's *describing* a book that *describes* encryption algorithms. The DMCA bans *devices* that *circumvent* *technologies* that *control access* to *copyrighted works*. Encryption algorithms don't usually control access, and there's no copyrighted work here (aside from the book itself and the review), discussions and pseudocode don't constitute devices, and there's no circumvention.
Do yourself a favor and read the DMCA. http://www4.law.cornell.edu/uscode/17/1201.html I t is a lot more specific than you think. It doesn't outlaw encryption, and especially not reviews about discussions of encryption.
Why not just take an alumnium case and cut out the panels? You could paint what remains black and then build the stained glass around the frame.
If I were you, I'd worry about not just cooling but dust -- after a year of running dust will collect all over the inside of your glass and in the little unreachable parts. You might want to look at air filters for the fans.
I do think we should rewrite the legacy net applications. They are old, bloated, and full of security holes. Cyclone is a cool language that no low-level security nut can ignore, but I also don't think it's necessary to write network apps in low-level languages. That's really tedious.
For instance, I rewrote ftpd in SML because I got sick of buffer overflows. It only took me a few days and the result was much leaner (wu_ftpd is 30,000 lines, mine was about 800) and definitely has fewer buffer overflows / heap overflows / double-frees / integer overflows / printf-exploits (SML, like other safe languages, makes it impossible to write such code). If I was able to rewrite that by myself in such a short amount of time, I don't think it would be so much work to reimplement the standard services with a talented team of programmers. Such services would be optimal for the kind of user who wants, say, a working ssh daemon that he doesn't need to update so often, which has support for all of the standard features but nothing fancy (hardware-based authentication, etc.).
You don't need to register trademarks, you just need to engage in trade using the mark. If the Firebird SQL folks haven't engaged in (interstate) commerce (since they are free software, maybe they haven't...), and haven't registered the mark, then it's possible they don't have any legal claim to the name at all.
However, you do need to defend a trademark (or else it can lose protection by becoming a generic term, like "kleenex"). To do this, they'd need to convince a court that there is likelihood for confusion among relevant consumers (are there any?) -- that a consumer might believe that the Firebird browser and the Firebird SQL engine come from the same place, or are somehow associated. Since they are both pieces of computer software, it's possible that a court would find them confusingly similar. (There is an actual list of types of trade for which you can register a trademark. I think you can get this from the PTO online. It's unlikely that "web browser" and "database" are on there!)
Sorry, but invoking the name of the DMCA here is ridiculous. It may have shown up in the C&D letter, but that doesn't really mean anything. Everyone who is complaining about how the DMCA stifles free speech and security research is right, but it's not relevant to this case--I suppose they are too busy to read the actual complaint. (The complaint doesn't mention the DMCA at all.)
The important phrase left out of the summary of 17 USC 1201 above is "... protected under this title." Title 17 is about copyright, and so the DMCA only applies to copyrighted works. There is no issue of copyright here!
I'll be the LAST person to defend the DMCA, and in a way it's good to have a 4-letter acronym we can all rally against, but misunderstanding it doesn't help anyone.
OK, I'm with you here. When I say Java I mean the source language (since it is so easy to separate from the rest, if you ignore things like class loaders and reflection), but I'm sure Sun would agree with you. But:
It's true that the safety in a program is often manifest somewhere in the "runtime" or "VM". A good example is garbage collection -- surely, even in natively compiled code, there is a runtime system that implements GC. But stuff like array bounds checks are not necessarily part of this. For instance, a compiler that compiles this code:
int x = 0; int arr[100]; arr[x] = 5;... is perfectly free to generate code without a bounds check, and now there really is no check, anywhere. The compiler has generated safe code without the help of any protection layers (including the virtual memory hardware). You can make a similar argument for other things that compilers can check for you, like integer overflow.
Now, it's true that compilers can be buggy, but in my experience it is pretty difficult to make a mistake in a compiler that leads to exploitable holes. It's really easy to write bounds-checking array accesses (when the language is amenable to it); usually only a few lines out of the entire compiler. (Also observe that C and C++ programmers must worry about compiler bugs *in addition* to their own bugs!) On the other hand, while a VM does add a second layer of checking, it also adds a second layer for potential mistakes.
> As I said in my original post, it is possible to compile any sufficiently constrained language to create a binary that was > safe from buffer overflows. From a security viewpoint this is a very limited statement. A buffer overflow is not the only way > to exploit buggy software...
That's true, of course, but I think that the class of bugs that safe languages make unexploitable (buffer overflows, double-frees, integer overflows) are extremely common--the most common--among security holes. I think it is well worth not having to worry about these, since (for one thing) it gives us more time to think about more insidious errors.
Anyway, I am all for the idea of using Java on a VM to write security-critical applications. I would definitely run these daemons over their C counterparts and sleep more soundly at night. But even the poster who suggested the idea had the knee-jerk reaction that doing so would impose a serious performance penalty, presumably because VMs are thought of as inefficient. The point of my post is to claim that safety (the property we're looking for here) is independent from Virtual Machines, and can be gotten without all of the performance penalty.
The VM is not what makes the *language* safe, unless by language you mean Java Bytecode. Java the language specifies array bounds checks and garbage collection, etc., and if you compile it natively, it is still safe. Why is this bullshit? (I happen to be resesarching programming languages for my PhD, so I do know what I'm talking about, here...)
> It is certainly quite possible to take any sufficiently constrained language and compile it to native code such that it is > not susceptible to buffer overflows. But this is quite different from a language-aware VM (like that of Java) where even a > malicious binary cannot cause a buffer overflow.
This is exactly my point. There is no need to be concerned with malicious binaries when I am running network daemons on my system. If I didn't trust them, I would already be in a lot more shit than I would be from an exploitable buffer-overflow: sshd could leak keys, and let anyone log on without a password, named could DoS-flood other name servers, etc. Rather, the scenario is that I download (or write) a program whose intent I trust but implementation I don't. Natively compiled code runs safely without the overhead of a VM -- it's faster and perhaps more secure (because we don't need to worry about bugs in the VM).
> As for C programmers having to live with the various problems you describe -- there are many techniques for avoiding these > problems.
Well, maybe I wouldn't have such a problem with C code if people actually did this. But all of the C/C++ network daemons I know of are filled with hand-coded parsing routines and manual memory management, and many have had exploitable holes as a result.
> If a machine can not generate a truly random number (not seed based)
That's true, a deterministic machine can't generate a "truly" random number by definition. On the other hand, we can generate numbers that are cryptographically strong (infeasible to distinguish from "true" random numbers) on a deterministic machine, and we can build nondeterministic machines. This is about a nondeterministic machine.
>... and is not turing complete
"Turing complete" refers to the computational power of a language or programming model -- that it can express any program that a turing machine can express. A turing machine can compute anything that we know how to compute, so saying that a machine is turing complete means that you can code any computable task on it. No machine is truly turing complete, because all machines are finite, but we think of basically everything that can compute (including humans) as turing complete.
So, what does this have to do with artificial intelligence? Do you mean turing test?
> can it be called Artificially Intelligent?
Probably not, since nobody has written a computer program yet that we would think of as "intelligent."
> Imagine a Java sendmail installation running on a JVM. I may be able to compromise jsendmail, and while this won't give me > local root, I may be able to use the compromised sendmailer to implement social engineering hacks.
How do you expect to compromise jsendmail? If sendmail were written in java, then the 2 most recent bugs would not have been exploitable. Part of the point is that safe languages like Java are not vulnerable to buffer overflows, double-frees, etc.
> Also, if the VM is designed to run "safe" languages that rely on static type checking for safety (such as java) a > non-too-impossible attach on the machine it is running to randomly corrupt memory could be used to compromise the underlying > system. See the recent paper by Appel and Govindavajhala.
This is a total red herring. The situation described in their paper is where the attacker gets to supply the program (and also has the ability to induce memory faults on the target). While I might buy the argument that memory faults happen randomly as well, the attacker surely doesn't get to install his own trojaned jsendmail on my computer. (If he did, he could do a lot more damage anyway!) A C program is equally dangerous on a computer with faulty memory--Appel's paper is irrelevant in this scenario.
> Also, don't forget that all those malformed-request attacks against poorly written PERL CGIs that fail to validate strings > passed to a subshell: perl runs in a VM, but does no good when the attack slips by the VM to the base hardware.
I'm with you here. perl is "safe" in some sense and is interpreted, but is still susceptible to easy security holes. I think this is mostly due to its interpreted and highly dynamic nature, as well as due to some misfeatures in the language (allowing "|/bin/rm" as a filename, etc.). In my (informed, but not substantiated) opinion, statically-typed compiled languages are not typically susceptible to easy-to-make security holes like these. (For instance, to spawn a process in SML, you give the path to the process, and a list of its arguments -- there is no shell globbing to screw up.) I really think that such languages would go a long long way towards making more secure computing environments, and in fact they don't need to run in a VM (see my other post), giving us the best of both worlds!
StackGuard is good, and it would be better if distros included stackguard-compiled binaries by default. Unfortunately, it only protects against a certain (common) kind of stack buffer-overflow. It does not protect against heap overflows, integer overflows of most sorts, double-frees, printf-style attacks, etc. Unfortunately, many of the recent exploitable bugs have been of this sort. StackGuard does help some, but it wouldn't help as much as a virtual machine, or simply a safe language.
I wish people didn't (for whatever reason) equate Virtual Machines with language-level safety. It's true that Java was the first mainstream OO language with C-like syntax, but is this really the only experience that anyone has with safe languages?
Let me try to set the record straight: The features of Java that make it good for writing secure code are independent from the VM. Those features are things like array bounds checking, lack of pointer arithmetic, checked casts, and garbage collection. All of these things can be, and are, done in native code. The VM is not what makes your code safe, it's what allows you to check a binary that you download to make sure it is safe. If you're compiling the code yourself, you can easily target native code and pay very little performance overhead.
For instance, mlton (mlton.org) is a high performance native code compiler for Standard ML. It doesn't use a virtual machine, but it's impossible to write code with exploitable buffer overflows, integer overflows, double-frees, etc.. (In my opinion, it's also a much cooler language than C or Java). O'caml is another good language in the same family that can target either bytecode or native code. There exist native compilers for Java, though I've never used them.
VM => portable byte code. safe language => secure code.
Be wary of people who tell you that all we need is properly written C code. The days of grepping for "strcpy" are long gone -- the new age of exploitable holes are trickier things, usually living in hand-written parsing routines. C programmers will always have to live with buffer overflows, integer overflows, and double-frees.
No. Really, guys, just go and read the DMCA -- it's not too complicated, and it will clear up a lot of these "can't we just..?" posts. Search for "17 USC 1201" on google.
The DMCA only applies to the circumvention of technological measures that control access to a copyrighted work. Where's the copyrighted work? Where's the access control mechanism? The DMCA does *not* ban circumvention of cryptography in general, nor does it ban circumvention of technology unless it is an *access control* (ie, DRM) scheme.
In any case, only the government is prohibited from gaining information illegally. As a private corporation, the RIAA can break laws, pay the price for that, and then still sue you using the information they discovered.
Slashdot Mirror
> The DMCA would make the CDs that he is selling your text on illegal as they are being used to circumvent your copyright.
No. What ?? The CDs are just a vanilla copyright infringement. The anti-circumvention clauses in the DMCA are totally irrelevant here. (Guys, please read the DMCA anti-circumvention text. You can search for "17 USC 1201" on google to find it. A lot of people on slashdot totally misunderstand what that law says!)
The relevance of the DMCA is the takedown ("safe-harbor") provisions, by which a copyright holder can notify an ISP of an infringement and that ISP can get safe harbor from being party to the infringement if it does some stuff, like take down the site. This is a pretty odious law, and can be abused badly, but it is nowhere near as bad as the anti-circumvention stuff. I don't think there's any particular shame in using that part of the law here (after all, the GPL uses copyright law in order to enforce its "copyleft"), though I think that practically the author should just direct his concerns to something more productive.
I should have said that the derivative work is "linux with signatures". If this particular version of linux is distributed only with the signatures and requires them to run, then I think the whole thing could rightly be considered a derivative work.
If someone just goes around signing kernels and distributing the signatures separately, that's probably fair use, as you say.
However, I do agree that this argument would probably not do too well in court. I think this is a failing of the GPL because it is one of several sneaky ways that people can probably get away with distributing binaries that you can't modify and still use.
Under a strict interpretation of the GPL, signed binaries would be illegal to distribute, unless you distribute the private key that you use to sign them (making the signatures worthless, obviously). Here's my reasoning.
... However, as a special exception, the source code distributed need not include anything that is normally distributed..." The source for this hash is the program that does the hashing and the signing (probably exempt by the second sentence) and of course the private key used to sign it.
Let's assume you're using a standard signing algorithm like RSA, which signs a hash of the message (the binary).
Such a hash is a derivative work -- it's created directly from the binary through a hash function. (This is the biggest stretch of the argument, but at least in a mathematical sense this is very accurate. Note that it is not simply a re-expression of the work, but really reassembly of the bits in the original copyrighted expression).
A signed hash is a derivative work of the hash of the binary, for the same reason.
Therefore, the signature has to be distributed under the terms of the GPL as well. That means that if you give it out, you need to give the source to it as well. The source code is defined in the GPL: "The source code for a work means the preferred form of the work for making modifications to it.
Of course, this is a little tongue-in-cheek. But I think it's important to remember the clause in the GPL that requires you to provide not just source code but all of your build tools. Imagine if you created a new wacky language extension to C, (like a new primitive called do_my_secret_stuff) then used that to compile a program and gave out only the source code in C_with_secret_stuff? Those clauses are in the GPL for a reason, so don't forget what "source" means!
Yeah, well, my point is that their editor seems designed to only make that style of page. (Long vertical scroll, [H1] [H2] stuff, and the CVS tags and standards compliance buttons at the bottom, etc.) I don't claim that their page isn't navigable in a utilitarian sort of way, but it's certainly not how I'd want my web page to look. It's not really fair to compare the two based on navigability, since they have totally different purposes--snoot.org is not there for informational purposes, it's supposed to be fun, confusing, and exploratory. If I was making a page for some web design software, I'd make it a lot more clear, but then again, I'd also make it actually look good.
> > Encryption algorithms don't usually control access
>
> Considering that the only reason to use an encryption algorithm is to control access to a message, I have to say you don't
> have a clue what you're talking about. Not only that, your humor detection circuit seems to be on the fritz.
"Technological measure that controls access to a work" is defined in the DMCA. They are not talking about the english word "control" or "access," though the meaning is similar. Read the law if you want to understand what is going on; then I would love to hear your legal argument for why this book is--by some stretch of the imagination--a DMCA violation.
In this case, encryption wouldn't qualify unless it is supposed to be decrypted as part of the normal process of making use of a copyrighted work. That was true of CSS, perhaps, but not of the encryption algorithms in this book.
Furthermore, it has to apply to a copyrighted work -- since encryption is often (if not primarily) used to encrypt non-copyrightable content (requests sent by web browsers, ssh sessions), it can hardly be considered a DMCA access control measure anyway.
I don't use Amaya because their own web page is ugly as hell. Standards compliance is great and all, but if you can't even create the design you want to create, what's the point?
Right on. Though I don't really believe in calling things "natural," (an obvious weasel word) I don't think that tresspassing counts even in the sense that most people talk about natural law. Tresspassing does not remove your ability to use the land, nor does it take any scarce resource from you. If, while I'm there, I smash up your crops or steal your sheep, then obviously that does.
The problem *is* insecure systems. When a 14 year-old can download a script and root a hundred computers in an evening, that's a problem. There will always be 14 year-olds who think they are immune from the law (and, in many senses they are today), no matter how many hackers we prosecute. It is pretty damn easy to make systems that are much more secure so that there are many fewer scripts for kiddies to get. One easy way is to use a modern safe language, where the common security bugs that cause your and my boxes to get rooted are impossible to make. If you're still in love with cowboy C programming, there are things like Stackguard and the Pax kernel patches (address randomization, etc.) that make even C code a whole lot less exploitable.
For my money, Millennium has interpreted the article right, and the article makes a good point: the most cost effective way to improve security is to make and use more secure systems, not to try to deter 14-year olds from downloading scripts by imposing draconian laws. Of course, destructive cracking will remain illegal, and people should be prosecuted when they do it, but at least those people will have had to go through a lot more trouble to do so.
OK, sure, but I think that most mediocre programmers these days are creating applications that fall into the "safety and correctness first, speed second category."
Also, I don't think that C really gets you closer to the "bare metal," unless you're thinking about 20 or 30 year old computers. Computers these days really don't fit the model that C purports: they are parallel, out of order, with a significant memory performance hierarchy. It's a real shame the kinds of games we play with our compilers as a result -- trying to coax the compiler into realizing that I am writing a parallelizable (or pipelineable) loop, for instance. Such things could be explicit in a real modern high-performance language, and some languages have such things (O'Caml, for instance) in addition to safety. It makes your life and the compiler's life easier, so hooray!
Anyway, you can probably tell that I think C is pretty crummy for application development. Of course, practically speaking it is simply the most well-supported tool, so I'm only able to make this argument if I take an idealist stance. Nonetheless, I do still think we'd be better off if people said, "I use C because it's what everyone else uses," rather than the misleading "I use it because it gets me closer to the bare metal" (or other common lines).
> Oh, and I believe one of my female friends in CS grad school said that the ratio of men to women gets more even up there.
No-ho-ho... at least at CMU, there are definitely fewer women in the grad program than the undergrad. (Our undergrad program is pretty good now, something like 30%-40% women). I don't know about other schools, but certainly the students that visit us (and from my visits to other grad schools) indicate similar numbers.
So perhaps it's better to use a language where the default easy thing to do is to use the checked version (say, Java)?
No. What possibly could be a violation? He's *describing* a book that *describes* encryption algorithms. The DMCA bans *devices* that *circumvent* *technologies* that *control access* to *copyrighted works*. Encryption algorithms don't usually control access, and there's no copyrighted work here (aside from the book itself and the review), discussions and pseudocode don't constitute devices, and there's no circumvention.
I t is a lot more specific than you think. It doesn't outlaw encryption, and especially not reviews about discussions of encryption.
Do yourself a favor and read the DMCA. http://www4.law.cornell.edu/uscode/17/1201.html
Why not just take an alumnium case and cut out the panels? You could paint what remains black and then build the stained glass around the frame.
If I were you, I'd worry about not just cooling but dust -- after a year of running dust will collect all over the inside of your glass and in the little unreachable parts. You might want to look at air filters for the fans.
I do think we should rewrite the legacy net applications. They are old, bloated, and full of security holes. Cyclone is a cool language that no low-level security nut can ignore, but I also don't think it's necessary to write network apps in low-level languages. That's really tedious.
For instance, I rewrote ftpd in SML because I got sick of buffer overflows. It only took me a few days and the result was much leaner (wu_ftpd is 30,000 lines, mine was about 800) and definitely has fewer buffer overflows / heap overflows / double-frees / integer overflows / printf-exploits (SML, like other safe languages, makes it impossible to write such code). If I was able to rewrite that by myself in such a short amount of time, I don't think it would be so much work to reimplement the standard services with a talented team of programmers. Such services would be optimal for the kind of user who wants, say, a working ssh daemon that he doesn't need to update so often, which has support for all of the standard features but nothing fancy (hardware-based authentication, etc.).
You don't need to register trademarks, you just need to engage in trade using the mark. If the Firebird SQL folks haven't engaged in (interstate) commerce (since they are free software, maybe they haven't...), and haven't registered the mark, then it's possible they don't have any legal claim to the name at all.
However, you do need to defend a trademark (or else it can lose protection by becoming a generic term, like "kleenex"). To do this, they'd need to convince a court that there is likelihood for confusion among relevant consumers (are there any?) -- that a consumer might believe that the Firebird browser and the Firebird SQL engine come from the same place, or are somehow associated. Since they are both pieces of computer software, it's possible that a court would find them confusingly similar. (There is an actual list of types of trade for which you can register a trademark. I think you can get this from the PTO online. It's unlikely that "web browser" and "database" are on there!)
Sorry, but invoking the name of the DMCA here is ridiculous. It may have shown up in the C&D letter, but that doesn't really mean anything. Everyone who is complaining about how the DMCA stifles free speech and security research is right, but it's not relevant to this case--I suppose they are too busy to read the actual complaint. (The complaint doesn't mention the DMCA at all.)
The important phrase left out of the summary of 17 USC 1201 above is "... protected under this title." Title 17 is about copyright, and so the DMCA only applies to copyrighted works. There is no issue of copyright here!
I'll be the LAST person to defend the DMCA, and in a way it's good to have a 4-letter acronym we can all rally against, but misunderstanding it doesn't help anyone.
Obviously it's not really for a blog, it's for a porn site.
How about there being essentially no working VST implementation on OSX and practically no working Audio Units to use?
OK, I'm with you here. When I say Java I mean the source language (since it is so easy to separate from the rest, if you ignore things like class loaders and reflection), but I'm sure Sun would agree with you. But:
... is perfectly free to generate code without a bounds check, and now there really is no check, anywhere. The compiler has generated safe code without the help of any protection layers (including the virtual memory hardware). You can make a similar argument for other things that compilers can check for you, like integer overflow.
It's true that the safety in a program is often manifest somewhere in the "runtime" or "VM". A good example is garbage collection -- surely, even in natively compiled code, there is a runtime system that implements GC. But stuff like array bounds checks are not necessarily part of this. For instance, a compiler that compiles this code:
int x = 0;
int arr[100];
arr[x] = 5;
Now, it's true that compilers can be buggy, but in my experience it is pretty difficult to make a mistake in a compiler that leads to exploitable holes. It's really easy to write bounds-checking array accesses (when the language is amenable to it); usually only a few lines out of the entire compiler. (Also observe that C and C++ programmers must worry about compiler bugs *in addition* to their own bugs!) On the other hand, while a VM does add a second layer of checking, it also adds a second layer for potential mistakes.
> As I said in my original post, it is possible to compile any sufficiently constrained language to create a binary that was
> safe from buffer overflows. From a security viewpoint this is a very limited statement. A buffer overflow is not the only way
> to exploit buggy software...
That's true, of course, but I think that the class of bugs that safe languages make unexploitable (buffer overflows, double-frees, integer overflows) are extremely common--the most common--among security holes. I think it is well worth not having to worry about these, since (for one thing) it gives us more time to think about more insidious errors.
Anyway, I am all for the idea of using Java on a VM to write security-critical applications. I would definitely run these daemons over their C counterparts and sleep more soundly at night. But even the poster who suggested the idea had the knee-jerk reaction that doing so would impose a serious performance penalty, presumably because VMs are thought of as inefficient. The point of my post is to claim that safety (the property we're looking for here) is independent from Virtual Machines, and can be gotten without all of the performance penalty.
The VM is not what makes the *language* safe, unless by language you mean Java Bytecode. Java the language specifies array bounds checks and garbage collection, etc., and if you compile it natively, it is still safe. Why is this bullshit? (I happen to be resesarching programming languages for my PhD, so I do know what I'm talking about, here...)
> It is certainly quite possible to take any sufficiently constrained language and compile it to native code such that it is
> not susceptible to buffer overflows. But this is quite different from a language-aware VM (like that of Java) where even a
> malicious binary cannot cause a buffer overflow.
This is exactly my point. There is no need to be concerned with malicious binaries when I am running network daemons on my system. If I didn't trust them, I would already be in a lot more shit than I would be from an exploitable buffer-overflow: sshd could leak keys, and let anyone log on without a password, named could DoS-flood other name servers, etc. Rather, the scenario is that I download (or write) a program whose intent I trust but implementation I don't. Natively compiled code runs safely without the overhead of a VM -- it's faster and perhaps more secure (because we don't need to worry about bugs in the VM).
> As for C programmers having to live with the various problems you describe -- there are many techniques for avoiding these
> problems.
Well, maybe I wouldn't have such a problem with C code if people actually did this. But all of the C/C++ network daemons I know of are filled with hand-coded parsing routines and manual memory management, and many have had exploitable holes as a result.
I don't understand what your post means...
... and is not turing complete
> If a machine can not generate a truly random number (not seed based)
That's true, a deterministic machine can't generate a "truly" random number by definition. On the other hand, we can generate numbers that are cryptographically strong (infeasible to distinguish from "true" random numbers) on a deterministic machine, and we can build nondeterministic machines. This is about a nondeterministic machine.
>
"Turing complete" refers to the computational power of a language or programming model -- that it can express any program that a turing machine can express. A turing machine can compute anything that we know how to compute, so saying that a machine is turing complete means that you can code any computable task on it. No machine is truly turing complete, because all machines are finite, but we think of basically everything that can compute (including humans) as turing complete.
So, what does this have to do with artificial intelligence? Do you mean turing test?
> can it be called Artificially Intelligent?
Probably not, since nobody has written a computer program yet that we would think of as "intelligent."
> Imagine a Java sendmail installation running on a JVM. I may be able to compromise jsendmail, and while this won't give me
> local root, I may be able to use the compromised sendmailer to implement social engineering hacks.
How do you expect to compromise jsendmail? If sendmail were written in java, then the 2 most recent bugs would not have been exploitable. Part of the point is that safe languages like Java are not vulnerable to buffer overflows, double-frees, etc.
> Also, if the VM is designed to run "safe" languages that rely on static type checking for safety (such as java) a
> non-too-impossible attach on the machine it is running to randomly corrupt memory could be used to compromise the underlying
> system. See the recent paper by Appel and Govindavajhala.
This is a total red herring. The situation described in their paper is where the attacker gets to supply the program (and also has the ability to induce memory faults on the target). While I might buy the argument that memory faults happen randomly as well, the attacker surely doesn't get to install his own trojaned jsendmail on my computer. (If he did, he could do a lot more damage anyway!) A C program is equally dangerous on a computer with faulty memory--Appel's paper is irrelevant in this scenario.
> Also, don't forget that all those malformed-request attacks against poorly written PERL CGIs that fail to validate strings
> passed to a subshell: perl runs in a VM, but does no good when the attack slips by the VM to the base hardware.
I'm with you here. perl is "safe" in some sense and is interpreted, but is still susceptible to easy security holes. I think this is mostly due to its interpreted and highly dynamic nature, as well as due to some misfeatures in the language (allowing "|/bin/rm" as a filename, etc.). In my (informed, but not substantiated) opinion, statically-typed compiled languages are not typically susceptible to easy-to-make security holes like these. (For instance, to spawn a process in SML, you give the path to the process, and a list of its arguments -- there is no shell globbing to screw up.) I really think that such languages would go a long long way towards making more secure computing environments, and in fact they don't need to run in a VM (see my other post), giving us the best of both worlds!
StackGuard is good, and it would be better if distros included stackguard-compiled binaries by default.
Unfortunately, it only protects against a certain (common) kind of stack buffer-overflow. It does not protect against heap overflows, integer overflows of most sorts, double-frees, printf-style attacks, etc. Unfortunately, many of the recent exploitable bugs have been of this sort. StackGuard does help some, but it wouldn't help as much as a virtual machine, or simply a safe language.
I wish people didn't (for whatever reason) equate Virtual Machines with language-level safety. It's true that Java was the first mainstream OO language with C-like syntax, but is this really the only experience that anyone has with safe languages?
Let me try to set the record straight: The features of Java that make it good for writing secure code are independent from the VM. Those features are things like array bounds checking, lack of pointer arithmetic, checked casts, and garbage collection. All of these things can be, and are, done in native code. The VM is not what makes your code safe, it's what allows you to check a binary that you download to make sure it is safe. If you're compiling the code yourself, you can easily target native code and pay very little performance overhead.
For instance, mlton (mlton.org) is a high performance native code compiler for Standard ML. It doesn't use a virtual machine, but it's impossible to write code with exploitable buffer overflows, integer overflows, double-frees, etc.. (In my opinion, it's also a much cooler language than C or Java). O'caml is another good language in the same family that can target either bytecode or native code. There exist native compilers for Java, though I've never used them.
VM => portable byte code.
safe language => secure code.
Be wary of people who tell you that all we need is properly written C code. The days of grepping for "strcpy" are long gone -- the new age of exploitable holes are trickier things, usually living in hand-written parsing routines. C programmers will always have to live with buffer overflows, integer overflows, and double-frees.
No. Really, guys, just go and read the DMCA -- it's not too complicated, and it will clear up a lot of these "can't we just..?" posts. Search for "17 USC 1201" on google.
The DMCA only applies to the circumvention of technological measures that control access to a copyrighted work. Where's the copyrighted work? Where's the access control mechanism? The DMCA does *not* ban circumvention of cryptography in general, nor does it ban circumvention of technology unless it is an *access control* (ie, DRM) scheme.
In any case, only the government is prohibited from gaining information illegally. As a private corporation, the RIAA can break laws, pay the price for that, and then still sue you using the information they discovered.