If applets are vulnerable, that's not FUD, it's serious.
Of course it's serious. That doesn't mean that it affects everything from mobile devices to servers! That was just plain FUD on the part of the article. They made it sound like every implementation of Java ever was now vulnerable and there is nothing we can do about it. In reality, it's a serious problem, but far less so than advertised. In fact, nearly all desktops should be updated by now thanks to the Java autoupdater.
Unfortunately, Java sucks for writing that kind of code.
Oh, don't start. I've written plenty of image and datafile loading routines in Java. You don't get nice "struct" features* for memory management, but that doesn't materially impact the ability to load and parse the data. The biggest thing to remember is that some formats use endians in something other than network order. (I'm looking at you Ronald Rivest! Do you know how much it would have saved me if MD5 used the same byte order as every other RFC under the sun? Grr...)
* I did write a proof-of-concept "struct" pre-processor once in an attempt to make a colleague happier. It basically added a new form of class type other than "class" and "interface". When parsed, it would be transformed into a ByteBuffer object with getX()/setX() accessors/mutators that accessed the correct locations of the buffer.
JNode does exactly that by using the JVM's JIT to pre-compile the JVM. A bit strange, but it works.
In any case, that's not the point. When you're building something like a virtual machine, you usually want as small of a cross-section for exposure to native code as possible. ImageIO routines have been done in pure Java many, many, many times over. JIMI, for example, was written by Javalobby's founder Rick Ross and sold to Sun. Rather than extending it to meet their needs, Sun ignored their purchase (Lord only knows why) and linked in a native library for loading images.
I'm only guessing, but I believe this vulnerability directly relates to ImageIO. The Toolkit only supported the load of PNG, GIF, and JPG the last time I checked. This vulnerability has to do with BMPs and ICC profiles in JPGs and BMPs.
My answer: "No." You granted the specific right for me to distribute by way of website and included no requirement that I have my downloaders agree to any license.
I would say the GPL is clearly a different situation: 1) It does not say I can distribute by website, and leave silent the right for downloaders to copy 2) Because it is not silent on the right for downloaders to copy, but explicitly gives downloaders the right to copy, provided they agree to the GPL, there is no need to assume that the copyright owner granted an implied license for downloaders to copy, and 3) the GPL specifically requires that as a distributor, you impose the GPL on others who wish to exercise any of the three rights of copy, modify or distribute.
Again, section 5:
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. (Emphasis added.) Let's extend that to a thought experiment:
1. You hear about a great GPLed program, so you search for it on the internet.
2. You find several different download sites, all appearing to be legitimate owners of the GPLed software. (Perhaps it was forked a few times?)
3. You download one of those copies and read the license. The license says that you are not required to accept the license, but that you will not be able to modify or distribute if you do not accept it. Ok, so you decide not to accept it. According to section 5, you can still use the program since the text is explicit about not covering the running of the software (Section 0 paragraph 2) and the information does not ask you to return or destroy the software. (You cannot retroactively apply terms now that the file has already been downloaded, so the law *requires* that such licenses have an escape if the user does not agree. Usually this means returning the product or destroying the download file.)
Under your interpretation, you are only legally clear if you download from the copyright holder. But is it a reasonable burden for the downloader to weave through someone else's agreements to determine what his obligations are?
Of course not! The downloader is not party to those agreements!
Does the GPL require anyone other than the copyright holder to provide alternate terms stating that they are not authorized to give you a copy under standard copyright law?
Not that I can see. A transaction between the copyright holder and a downloader is indistinguishable from a transaction between a distributor and a downloader. Without those extra terms, the burden is not on the downloader.
The GPLv3 tries to clarify this. I've emphasized the relevant text:
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
The GPL FAQ goes into detail about the confusion over "distribution" and the need to change the wording for v3. I should hope this finally settles the matter?
We agree on this. OTOH, if you put that disk onto a server, hooked up a 100 PCs to play it and advertised a "game parlor
No, it's not hype. Problems like this actually highlight Java's features all that much more.
The problem in this case is that Sun used a native library to do the image parsing rather than writing a pure-Java equivalent. This shortcut ended up being a costly mistake that has resulted in a variety of holes caused by that library. If Sun simply rewrote the code in Java (which wouldn't be hard; only time consuming), the problems would go away.
Looks to me like the major problem is for embedded devices, where the update isn't easy.
No, it doesn't. First off, I guarantee you that J2ME implementations do NOT use the same parsing library as the desktop JVM. It's far too heavyweight. Add to that fact that the embedded implementations are written by the phone vendor, significantly decreasing the risk.
Secondly, J2ME does not support JPEGs or BMPs. The standard only supports PNGs. If you want to open JPEGs, you have to use a pure-Java decoder. (Which would not be vulnerable.)
Thirdly, Java applet support is extremely limited in Symbian devices; the only devices I'm aware of that support applets. It's basically Java ME + a few extra APIs to bring it up to Java 1.1 standards. It's doubtful that these VMs even contain the APIs that are being exploited here.
First of all, thanks to the OP for the link to AusCERT. Very, very helpful!
Oh dear, where are my manners? I'd also like to thank the poster for finding the relevant AusCERT article. Without it, we'd still be at the FUD level.:-)
It appears to be referring to the GIF exploit, which was patched a couple of months ago.
No, as others have pointed out it's a flaw in JPEGs and BMP files. PNGs (pretty much the only format used in J2ME in cell phones and PDAs) are safe. Here are the advisories:
The biggest concern is that arbitrary applets could be pushed to user's machines. This is mitigated by the fact that the latest JVM's have already been repaired. Thanks to the Java autoupdater, there should not be many desktops at risk.
A secondary concern is servers that accept image uploads. BMPs are usually not accepted anyway, but JPEGs could be a concern. So it is best to upgrade these. Which brings us around to your concern...
The problem is that most Java enterprise software winds up becoming tightly coupled with a specific JVM. (In Oracle's case, a good half-dozen *different* JVMs!) You can't upgrade the JVM without breaking the enterprise app (trust me, I tried, they really work only with the specific JVM shipped), so you're left with vulnerable JVMs and no way to upgrade them. I don't have a solution to that problem.
For one, it is possible to upgrade these JVMs. It's a bit trickier than a standard install, but it can be done, at least inside the same VM version. (e.g. Java 1.4 apps will usually not suffer from an upgrade to 1.4.1, but a Java 5 upgrade would be disasterous.)
Secondly, I *DO* have a solution. Yell at the vendor! If they're going to stupidly integrate the JVM for no reason other than to make your life difficult (ostensibly to make it easier, yeah right) then they can take the burden of getting you a patch. Don't let the vendor off the hook until they get the problem fixed! That's just good practice, nothing to do with Java.
(Of course, a better practice is to find a vendor who doesn't stupidly integrate JVMs, but I digress.)
BTW, are you talking about Oracle AS or Oracle Database? Oracle AS would need to be patched for situations like this just in case you handle or will handle image uploads. Oracle Database would not be at risk since there is almost no chance of the database being made to parse images in its procedural code. Desktop applications are similarly unaffected unless they download arbitrary images from the internet.
Oh good grief, is that all it is? A buffer overflow in images that only affects desktops and servers supporting image uploads that are not running the latest version of a given JVM? What happened to the spreading to PDAs and cell phones, the problem for all users worldwide, the end of things and mankind himself!?!
Bunch of FUD-spreading fear-mongers. Hrumph.
Oh, and Sun wouldn't have had this problem if they'd used pure Java code rather than relying on an existing library.
That last line should read, "serious security risk through port 80."
I find it interesting that this team is supposedly reporting a major flaw, yet manually running the Java updater finds no new JVM versions to download. Didn't they contact Sun first? Shouldn't there be a patch already? Meh. The whole thing stinks.
If you want to run the updater yourself, you can either right-click on the Java icon in your taskbar and select "Control Panel", or you can run the "javacpl.exe" file in the "c:\Program Files\Java\jre\bin" directory. Look under the "Update" tab to see the update schedule. Click "Update Now" to check for the lastest release.
Mac users do not need to access a separate updater. Java updates are pushed through the standard system updates, accessible through the control panel. These are also scheduled to run on a regular basis. Only Linux/Unix users should need to manually update their JVMs if and when a patch becomes available. Some of these OSes do have a Java updater, but I don't know the current details about these.
Australia's Computer Emergency Response Team (AusCERT) analyst, Robert Lowe, warned that anyone using the Java Runtime Environment or Java Development Kit is at risk. "Java runs on everything: cell phones, PDAs, and PCs. This is the problem when you have a vulnerability in something so modular--it affects so many different devices.," said Gatford.
No offsense, but that's a rather incredible claim. They're saying that no matter if you're running a JVM on the server, cell phone, applet, desktop, or just about any other environment, you're vulnerable? I'm sorry, I can't accept that without extraordinary proof to back up such extraordinary claims.
Java was designed from the beginning with security in mind. Its security infrastructure has been tested for over a decade now. Any and all exploits have always been a flaw in the specific JVM or interface between the JVM and the OS. (Something which has been plauging browsers and other network-aware applications.) Now some security expert is saying that it doesn't matter what you're doing because Java as a whole is flawed?
It seems more likely to me that they're blowing the whole thing out of proportion and thereby spreading FUD. It's more likely that it's yet another security hole in specific JVMs and someone here is expanding that to all of Java. I'll happily look at the evidence to the contrary as soon as it becomes available.
Oh, and upgrades for Desktops is not too big of a deal. Java currently includes an autoupdater that should take care of the issue. All that's left is to deploy updates to servers, should these fellows actually prove that the language you're using somehow conveys a serious security through port 80.:-/
Comparing Java to Flash won't win you any friends. Especially since you're assuming that Java == Applets. Why don't you go play some Java games instead?
Doh! That was the wrong routine. I need to remember to take out my old, unused routines from source files. THAT is the nearest neighbor. THIS is the Bilinear. Sorry 'bout that:
public static BufferedImage createHeadlessSmoothBufferedImage(BufferedImage source, int type, int width, int height) {
if (type == ImageUtils.IMAGE_PNG && hasAlpha(source)) {
type = BufferedImage.TYPE_INT_ARGB;
}
else {
type = BufferedImage.TYPE_INT_RGB;
}
BufferedImage dest = new BufferedImage(width, height, type);
Last time I ran across that issue, I cheated. Since the server was headless and you can't resize images in Java on a truly headless machine (it's a problem with the JVM requiring X11 libraries in the path), I just wrote my own Bilinear Scaling routine. The results were nice in comparison to the nearest neighbor results we had been getting out of the default libs. Of course, no one had tuned the original code, so a lot of improvement would have been possible. It just made more sense to use a custom routine considering that headless support was a serious issue.
In case anyone else ever needs it, here's the routine in its entirety:
public static BufferedImage createHeadlessBufferedImage(BufferedImage image, int type, int width, int height)
{
if (type == ImageUtils.IMAGE_PNG && hasAlpha(image)) {
type = BufferedImage.TYPE_INT_ARGB;
}
else {
type = BufferedImage.TYPE_INT_RGB;
}
BufferedImage bi = new BufferedImage(width, height, type);
for(int y=0; y < height; y++)
{
for(int x=0; x < width; x++)
{
bi.setRGB(x, y, image.getRGB(x * image.getWidth() / width, y * image.getHeight() / height));
}
}
the website owner typically gives you the right to copy when he makes it available. Of course, he needs to have the right to let you make the copy, which is no problem if he's the copyright owner. In the case of the GPL, however, he's not. A downloader can only get the right to make the downloaded copy directly from the GPL.
This is incorrect. The copyright holder can allow someone else to distribute the software. Time for thought experiment #2:
I am the copyright holder of that file. (Seriously, I am.) I hereby grant you a non-exclusive, royalty-free license to distribute the software on a website of your choosing. (No, I'm not kidding. Go right ahead.) You may not apply any additional terms to the software when you offer it for download.
Ok, let's follow this through. Visitor comes to your site. The file is available for download because you have the rights to make it available for download. However, there is no license in the file, near the file, or referencing the file. The visitor downloads the file.
Question: Is the visitor now in violation of copyright law?
That is known as "innocent infringement" under the copyright law. It's still infringment, but the penalties are reduced.
Ah yes, thank you. Innocent infringement was the term I was looking for. And the penalties aren't reduced for the situation. According to the letter of copyright law, the penalties are $750-$30,000 and increase if the infringement can be shown to be "willing" infringement. The specific term "innocent infringement" is not used in copyright law save for a special exception for semiconductor products (Title 17 Section 907) which mentions "innocent purchaser".
So technically you are correct about it still being a crime. Practically, it's not so cut and dry. This is an area where the letter and the implementation of law tend to diverge. Take this example:
My father-in-law brought me a computer game from Russia when he came to visit us. The game was a localized version of a game that is sold here in the states. As far as I could tell, it was perfectly legitimate. The artwork was professional and the CD was pressed. However, it only had a Crystal Case for packaging. No box. While that happens here in the states as well, it's not very common with games of this type. So the possibility exists that the game is a pirate copy. The only way to be sure would be for the game's publisher to examine the article and see if it differs from what they actually publish.
Under Title 17 Section 504, I could be dragged in front of a judge for infringement if it is indeed a pirate copy. The question is, will the judge seriously hold a victim accountable for a gift? Especially when it appears so close to a legitimate copy as to indistinguishable? Doubtful. Judges create legal theories around these issues all the time, and thus set them in precedent when they do. For example, VCRs were almost ruled illegal by the Supreme Court in the so-called "Betamax case". It was only through a bit of wrangling with legal theory that we now have the right to "time-shift" television. This concept was not codified at the time, and is not (to my knowledge) currently codified in the law. It's all precedent.
Furthermore, a copyright holder would normally dislike bringing a case like this forward as suing the recipient would tend to preclude them from suing the party that offered them the infringing copy. ("Double-dipping" as it's called, is disliked by judges. They prefer that you get your pound of flesh only once.)
Buying a black market CD is not copyright infringement, but it may violate non-copyright statutes.
Oh, but it is. As you pointed out, being in posses
You might want to reread the article. It says specifically that Apple "acquired ownership [of] the CUPS source code and hired me (Michael R Sweet), the creator of CUPS." (Emphasis added.)
The bottom of the page says, "All other content is copyright 2007 by Apple Inc. CUPS, the Common UNIX Printing System, and the CUPS logo are the trademark property of Apple Inc. All other trademarks are the property of their respective owners."
It seems to me that Apple does indeed own the CUPS software.
As he was the primary developer he had rights to license his code it in multiple ways as he saw fit.
Actually, the primary developer does not have that right. The reason why CUPS has that right is because they required that the copyright to code modifications be transferred to Easy Software Products before the modification will be accepted into the main branch.
Someone already beat me on the trademark FAQ explicitly stating that Apple now owns the marks, so I'll add this bit to back up my claim of special rights on contributions:
To contribute code to the base CUPS distribution, please contact us via email at cups-info at cups dot org. Because we also provide CUPS under a binary distribution license, we will require that all ownership of the code be transferred to Easy Software Products, or that Easy Software Products be granted unlimited distribution rights to the code, possibly via payment of a fee to the contributor.
It says right there in the post. "Apple Inc. acquired ownership the CUPS source code." So they are now the copyright holder rather than Michael Sweet. This allows them to provide the code under other licenses, and does not bind Apple's use of the code. To prevent issues with contributions interfering with this, they hired Mr. Sweet to maintain the source code, thus making it a work-for-hire arrangement.
Open Source projects are usually encumbered from this sort of aquisition because of the large number of contributors. In the case of CUPS, it was originally developed by Sweet's company: Easy Software Products. Since he had a company set up around it, it's likely that he ensured that any accepted contributions were provided with special rights to his company.
Trademarks aren't mentioned.
According to the USPTO, the trademark registration for "Common UNIX Printing System" has expired. I was unable to find a registration for "CUPS". Thus my guess is that the unregistered trademark will follow the code as that is simply its name. It *is* Common Unix Printing System. So unless they change the name now (which it doesn't sound like they will) Apple will probably own the mark as well.
It's simpler to use longs, but good point. However, I do question the criticality of division in this case. In the decade I've been doing graphics in Java I've never found this to be a problem. Most of your working values are smaller than an integer, and you don't do math on bit-packed values. The values where sign matters (e.g. coordinates) *should* actually support negative values. I did up a couple of 2D rendering engines in Java 1.1 and 1.3 back when Java Applet gaming was still hot. It just wasn't an issue.
The truth is that the signed/unsigned whining by the AC is exactly that: whining. Computer Graphics *is* a mathematically intense field, but the rendering part of it is all just bitmapped data. And as any programmer worth his salt knows, there are plenty of ways to skin bitmapped data.;-)
Slashdot Mirror
Embedded implementations [of the J2ME virtual machine], not embedded applications. Two different things there, chief. ;-)
Of course it's serious. That doesn't mean that it affects everything from mobile devices to servers! That was just plain FUD on the part of the article. They made it sound like every implementation of Java ever was now vulnerable and there is nothing we can do about it. In reality, it's a serious problem, but far less so than advertised. In fact, nearly all desktops should be updated by now thanks to the Java autoupdater.
Oh, don't start. I've written plenty of image and datafile loading routines in Java. You don't get nice "struct" features* for memory management, but that doesn't materially impact the ability to load and parse the data. The biggest thing to remember is that some formats use endians in something other than network order. (I'm looking at you Ronald Rivest! Do you know how much it would have saved me if MD5 used the same byte order as every other RFC under the sun? Grr...)
* I did write a proof-of-concept "struct" pre-processor once in an attempt to make a colleague happier. It basically added a new form of class type other than "class" and "interface". When parsed, it would be transformed into a ByteBuffer object with getX()/setX() accessors/mutators that accessed the correct locations of the buffer.
JNode does exactly that by using the JVM's JIT to pre-compile the JVM. A bit strange, but it works.
In any case, that's not the point. When you're building something like a virtual machine, you usually want as small of a cross-section for exposure to native code as possible. ImageIO routines have been done in pure Java many, many, many times over. JIMI, for example, was written by Javalobby's founder Rick Ross and sold to Sun. Rather than extending it to meet their needs, Sun ignored their purchase (Lord only knows why) and linked in a native library for loading images.
So yeah, this really is a snafu on Sun's part.
I'm only guessing, but I believe this vulnerability directly relates to ImageIO. The Toolkit only supported the load of PNG, GIF, and JPG the last time I checked. This vulnerability has to do with BMPs and ICC profiles in JPGs and BMPs.
Again, section 5:
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
(Emphasis added.) Let's extend that to a thought experiment:
1. You hear about a great GPLed program, so you search for it on the internet.
2. You find several different download sites, all appearing to be legitimate owners of the GPLed software. (Perhaps it was forked a few times?)
3. You download one of those copies and read the license. The license says that you are not required to accept the license, but that you will not be able to modify or distribute if you do not accept it. Ok, so you decide not to accept it. According to section 5, you can still use the program since the text is explicit about not covering the running of the software (Section 0 paragraph 2) and the information does not ask you to return or destroy the software. (You cannot retroactively apply terms now that the file has already been downloaded, so the law *requires* that such licenses have an escape if the user does not agree. Usually this means returning the product or destroying the download file.)
Under your interpretation, you are only legally clear if you download from the copyright holder. But is it a reasonable burden for the downloader to weave through someone else's agreements to determine what his obligations are?
Of course not! The downloader is not party to those agreements!
Does the GPL require anyone other than the copyright holder to provide alternate terms stating that they are not authorized to give you a copy under standard copyright law?
Not that I can see. A transaction between the copyright holder and a downloader is indistinguishable from a transaction between a distributor and a downloader. Without those extra terms, the burden is not on the downloader.
The GPLv3 tries to clarify this. I've emphasized the relevant text:
The GPL FAQ goes into detail about the confusion over "distribution" and the need to change the wording for v3. I should hope this finally settles the matter?
No, it's not hype. Problems like this actually highlight Java's features all that much more.
The problem in this case is that Sun used a native library to do the image parsing rather than writing a pure-Java equivalent. This shortcut ended up being a costly mistake that has resulted in a variety of holes caused by that library. If Sun simply rewrote the code in Java (which wouldn't be hard; only time consuming), the problems would go away.
No, it doesn't. First off, I guarantee you that J2ME implementations do NOT use the same parsing library as the desktop JVM. It's far too heavyweight. Add to that fact that the embedded implementations are written by the phone vendor, significantly decreasing the risk.
Secondly, J2ME does not support JPEGs or BMPs. The standard only supports PNGs. If you want to open JPEGs, you have to use a pure-Java decoder. (Which would not be vulnerable.)
Thirdly, Java applet support is extremely limited in Symbian devices; the only devices I'm aware of that support applets. It's basically Java ME + a few extra APIs to bring it up to Java 1.1 standards. It's doubtful that these VMs even contain the APIs that are being exploited here.
Oh dear, where are my manners? I'd also like to thank the poster for finding the relevant AusCERT article. Without it, we'd still be at the FUD level.
No, as others have pointed out it's a flaw in JPEGs and BMP files. PNGs (pretty much the only format used in J2ME in cell phones and PDAs) are safe. Here are the advisories:
http://www.auscert.org.au/render.html?it=7664
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
The biggest concern is that arbitrary applets could be pushed to user's machines. This is mitigated by the fact that the latest JVM's have already been repaired. Thanks to the Java autoupdater, there should not be many desktops at risk.
A secondary concern is servers that accept image uploads. BMPs are usually not accepted anyway, but JPEGs could be a concern. So it is best to upgrade these. Which brings us around to your concern...
For one, it is possible to upgrade these JVMs. It's a bit trickier than a standard install, but it can be done, at least inside the same VM version. (e.g. Java 1.4 apps will usually not suffer from an upgrade to 1.4.1, but a Java 5 upgrade would be disasterous.)
Secondly, I *DO* have a solution. Yell at the vendor! If they're going to stupidly integrate the JVM for no reason other than to make your life difficult (ostensibly to make it easier, yeah right) then they can take the burden of getting you a patch. Don't let the vendor off the hook until they get the problem fixed! That's just good practice, nothing to do with Java.
(Of course, a better practice is to find a vendor who doesn't stupidly integrate JVMs, but I digress.)
BTW, are you talking about Oracle AS or Oracle Database? Oracle AS would need to be patched for situations like this just in case you handle or will handle image uploads. Oracle Database would not be at risk since there is almost no chance of the database being made to parse images in its procedural code. Desktop applications are similarly unaffected unless they download arbitrary images from the internet.
Oh good grief, is that all it is? A buffer overflow in images that only affects desktops and servers supporting image uploads that are not running the latest version of a given JVM? What happened to the spreading to PDAs and cell phones, the problem for all users worldwide, the end of things and mankind himself!?!
Bunch of FUD-spreading fear-mongers. Hrumph.
Oh, and Sun wouldn't have had this problem if they'd used pure Java code rather than relying on an existing library.
That last line should read, "serious security risk through port 80."
I find it interesting that this team is supposedly reporting a major flaw, yet manually running the Java updater finds no new JVM versions to download. Didn't they contact Sun first? Shouldn't there be a patch already? Meh. The whole thing stinks.
If you want to run the updater yourself, you can either right-click on the Java icon in your taskbar and select "Control Panel", or you can run the "javacpl.exe" file in the "c:\Program Files\Java\jre\bin" directory. Look under the "Update" tab to see the update schedule. Click "Update Now" to check for the lastest release.
Mac users do not need to access a separate updater. Java updates are pushed through the standard system updates, accessible through the control panel. These are also scheduled to run on a regular basis. Only Linux/Unix users should need to manually update their JVMs if and when a patch becomes available. Some of these OSes do have a Java updater, but I don't know the current details about these.
No offsense, but that's a rather incredible claim. They're saying that no matter if you're running a JVM on the server, cell phone, applet, desktop, or just about any other environment, you're vulnerable? I'm sorry, I can't accept that without extraordinary proof to back up such extraordinary claims.
Java was designed from the beginning with security in mind. Its security infrastructure has been tested for over a decade now. Any and all exploits have always been a flaw in the specific JVM or interface between the JVM and the OS. (Something which has been plauging browsers and other network-aware applications.) Now some security expert is saying that it doesn't matter what you're doing because Java as a whole is flawed?
It seems more likely to me that they're blowing the whole thing out of proportion and thereby spreading FUD. It's more likely that it's yet another security hole in specific JVMs and someone here is expanding that to all of Java. I'll happily look at the evidence to the contrary as soon as it becomes available.
Oh, and upgrades for Desktops is not too big of a deal. Java currently includes an autoupdater that should take care of the issue. All that's left is to deploy updates to servers, should these fellows actually prove that the language you're using somehow conveys a serious security through port 80.
Yes I did. Sorry, another one of my brain farts.
Comparing Java to Flash won't win you any friends. Especially since you're assuming that Java == Applets. Why don't you go play some Java games instead?
o rt=5&order=1&screen=0&max=25 -- (Make sure you try Miners, Xero, and fuzetsu. Those are my favorites. Amazing that they fit in a mere 4K, isn't it?)
http://www.puppygames.net/
http://www.wurmonline.com/
http://www.javaunlimited.net/games/db.php?min=0&s
If you're going to make unfair comparisons, at least get your competition right:
http://www.wurmonline.com/
I presume you're looking for a software implementation? If so, then you might try this:
http://www.cmlab.csie.ntu.edu.tw/~robin/JavaGL/
I've never used it, so I can't vouch for it, but it's supposedly a software implementation of the OpenGL API and renderer in Java.
And here are the supporting methods:
private static double scale(int point, double scale)
{
return point/scale;
}
private static int getRGBInterpolation(int value1, int value2, double distance)
{
int alpha1 = (value1 & 0xFF000000) >>> 24;
int red1 = (value1 & 0x00FF0000) >> 16;
int green1 = (value1 & 0x0000FF00) >> 8;
int blue1 = (value1 & 0x000000FF);
int alpha2 = (value2 & 0xFF000000) >>> 24;
int red2 = (value2 & 0x00FF0000) >> 16;
int green2 = (value2 & 0x0000FF00) >> 8;
int blue2 = (value2 & 0x000000FF);
int rgb = ((int)(alpha1 * (1.0-distance) + alpha2 * distance) << 24) |
((int)(red1 * (1.0-distance) + red2 * distance) << 16) |
((int)(green1 * (1.0-distance) + green2 * distance) << 8) |
(int)(blue1 * (1.0-distance) + blue2 * distance);
return rgb;
}
Doh! That was the wrong routine. I need to remember to take out my old, unused routines from source files. THAT is the nearest neighbor. THIS is the Bilinear. Sorry 'bout that:
public static BufferedImage createHeadlessSmoothBufferedImage(BufferedImage source, int type, int width, int height)
{
if (type == ImageUtils.IMAGE_PNG && hasAlpha(source)) {
type = BufferedImage.TYPE_INT_ARGB;
}
else {
type = BufferedImage.TYPE_INT_RGB;
}
BufferedImage dest = new BufferedImage(width, height, type);
int sourcex;
int sourcey;
double scalex = (double)width / source.getWidth();
double scaley = (double)height / source.getHeight();
int x1;
int y1;
double xdiff;
double ydiff;
int rgb;
int rgb1;
int rgb2;
for(int y=0; y < height; y++)
{
sourcey = y * source.getHeight() / dest.getHeight();
ydiff = scale(y, scaley) - sourcey;
for(int x=0; x < width; x++)
{
sourcex = x * source.getWidth() / dest.getWidth();
xdiff = scale(x, scalex) - sourcex;
x1 = Math.min(source.getWidth()-1, sourcex+1);
y1 = Math.min(source.getHeight()-1, sourcey+1);
rgb1 = getRGBInterpolation(source.getRGB(sourcex, sourcey), source.getRGB(x1, sourcey), xdiff);
rgb2 = getRGBInterpolation(source.getRGB(sourcex, y1), source.getRGB(x1, y1), xdiff);
rgb = getRGBInterpolation(rgb1, rgb2, ydiff);
dest.setRGB(x, y, rgb);
}
}
return dest;
}
In case anyone else ever needs it, here's the routine in its entirety:
This is incorrect. The copyright holder can allow someone else to distribute the software. Time for thought experiment #2:
Here's the file again: http://games.datadino.com/wc1/wc1viewer-source.zip
I am the copyright holder of that file. (Seriously, I am.) I hereby grant you a non-exclusive, royalty-free license to distribute the software on a website of your choosing. (No, I'm not kidding. Go right ahead.) You may not apply any additional terms to the software when you offer it for download.
Ok, let's follow this through. Visitor comes to your site. The file is available for download because you have the rights to make it available for download. However, there is no license in the file, near the file, or referencing the file. The visitor downloads the file.
Question: Is the visitor now in violation of copyright law?
Ah yes, thank you. Innocent infringement was the term I was looking for. And the penalties aren't reduced for the situation. According to the letter of copyright law, the penalties are $750-$30,000 and increase if the infringement can be shown to be "willing" infringement. The specific term "innocent infringement" is not used in copyright law save for a special exception for semiconductor products (Title 17 Section 907) which mentions "innocent purchaser".
So technically you are correct about it still being a crime. Practically, it's not so cut and dry. This is an area where the letter and the implementation of law tend to diverge. Take this example:
My father-in-law brought me a computer game from Russia when he came to visit us. The game was a localized version of a game that is sold here in the states. As far as I could tell, it was perfectly legitimate. The artwork was professional and the CD was pressed. However, it only had a Crystal Case for packaging. No box. While that happens here in the states as well, it's not very common with games of this type. So the possibility exists that the game is a pirate copy. The only way to be sure would be for the game's publisher to examine the article and see if it differs from what they actually publish.
Under Title 17 Section 504, I could be dragged in front of a judge for infringement if it is indeed a pirate copy. The question is, will the judge seriously hold a victim accountable for a gift? Especially when it appears so close to a legitimate copy as to indistinguishable? Doubtful. Judges create legal theories around these issues all the time, and thus set them in precedent when they do. For example, VCRs were almost ruled illegal by the Supreme Court in the so-called "Betamax case". It was only through a bit of wrangling with legal theory that we now have the right to "time-shift" television. This concept was not codified at the time, and is not (to my knowledge) currently codified in the law. It's all precedent.
Furthermore, a copyright holder would normally dislike bringing a case like this forward as suing the recipient would tend to preclude them from suing the party that offered them the infringing copy. ("Double-dipping" as it's called, is disliked by judges. They prefer that you get your pound of flesh only once.)
Oh, but it is. As you pointed out, being in posses
You might want to reread the article. It says specifically that Apple "acquired ownership [of] the CUPS source code and hired me (Michael R Sweet), the creator of CUPS." (Emphasis added.)
The bottom of the page says, "All other content is copyright 2007 by Apple Inc. CUPS, the Common UNIX Printing System, and the CUPS logo are the trademark property of Apple Inc. All other trademarks are the property of their respective owners."
It seems to me that Apple does indeed own the CUPS software.
Nice catch! I seems the rest of us have learned to tune out the fine print. ;-)
Actually, the primary developer does not have that right. The reason why CUPS has that right is because they required that the copyright to code modifications be transferred to Easy Software Products before the modification will be accepted into the main branch.
Hope that settles it.
It says right there in the post. "Apple Inc. acquired ownership the CUPS source code." So they are now the copyright holder rather than Michael Sweet. This allows them to provide the code under other licenses, and does not bind Apple's use of the code. To prevent issues with contributions interfering with this, they hired Mr. Sweet to maintain the source code, thus making it a work-for-hire arrangement.
Open Source projects are usually encumbered from this sort of aquisition because of the large number of contributors. In the case of CUPS, it was originally developed by Sweet's company: Easy Software Products. Since he had a company set up around it, it's likely that he ensured that any accepted contributions were provided with special rights to his company.
According to the USPTO, the trademark registration for "Common UNIX Printing System" has expired. I was unable to find a registration for "CUPS". Thus my guess is that the unregistered trademark will follow the code as that is simply its name. It *is* Common Unix Printing System. So unless they change the name now (which it doesn't sound like they will) Apple will probably own the mark as well.
It's simpler to use longs, but good point. However, I do question the criticality of division in this case. In the decade I've been doing graphics in Java I've never found this to be a problem. Most of your working values are smaller than an integer, and you don't do math on bit-packed values. The values where sign matters (e.g. coordinates) *should* actually support negative values. I did up a couple of 2D rendering engines in Java 1.1 and 1.3 back when Java Applet gaming was still hot. It just wasn't an issue.
;-)
The truth is that the signed/unsigned whining by the AC is exactly that: whining. Computer Graphics *is* a mathematically intense field, but the rendering part of it is all just bitmapped data. And as any programmer worth his salt knows, there are plenty of ways to skin bitmapped data.