Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (482)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  "Sun Endorsed" extensions  (Read 8111 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Posted 2008-10-25 12:48:59 »

I wonder if there's any possibility we could have a programme where by Sun endorse specific libraries with a certificate that would allow said libraries to be used without having to sign code?

What I'm getting at is, it would be a great boon to LWJGL and JOGL developers to not have to sign their applets and therefore not introduce the (still-scary) security warning before running an applet that relies on such libraries.

Cas Smiley

Offline zammbi

JGO Coder


Medals: 4



« Reply #1 - Posted 2008-10-25 14:44:56 »

Yes I agree!

Current project - Rename and Sort
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #2 - Posted 2008-10-25 16:58:47 »

What I'm getting at is, it would be a great boon to LWJGL and JOGL developers to not have to sign their applets and therefore not introduce the (still-scary) security warning before running an applet that relies on such libraries.
(sidenote: you don't have to sign JOGL applets, JOGL is available as an already signed extension)

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline jojoh

JGO Knight


Medals: 5
Projects: 7


games4j.com


« Reply #3 - Posted 2008-10-25 18:38:58 »

Yes, that would be a improvement for java casual gaming. Nice loading screen and it would be leveled playing field with flash Wink. Sun don't care too much about web games, but that is a great idea and won't cost sun any money, so it should be really easy to make a great improvement. I would say that slick2d would be nice to include as well.

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2008-10-25 21:57:13 »

@bienator
Correct me if I'm wrong but if you use a correctly signed native DLL such as LWJGL or JOGL, you will get a security dialog anyway, saying "Are you sure?"

Cas Smiley

Offline bienator

Senior Member




OutOfCoffeeException


« Reply #5 - Posted 2008-10-25 22:51:28 »

sun signes the JOGL distribution with a certificate which is AFAIK on the whitelist of trusted certificates by default (I am not 100% sure but I can't remember that i added sun to the list).
Just start one of the jogl demos or the gears applet (https://jogl-demos.dev.java.net/) you shouldn't get a certificate warning dialog.

Offline Mr_Light

Senior Member




shiny.


« Reply #6 - Posted 2008-10-26 00:44:47 »

I'm getting a dialogue, guess at some point you decided to trust sun.

1  
2  
3  
4  
5  
6  
7  
8  
Version 3 
Serial 15702595680581883913778518093312549937
Signature Algorithm SHA1withRSA
Issuer CN=VeriSign Class 3 Code Signing 2004 CA, OU=Terms of use at https://www.verisign.com/rpa (c)04, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Validity Validity: [From: Thu Mar 30 02:00:00 CEST 2006,
               To: Fri May 01 01:59:59 CEST 2009]
Subject CN="sun microsystems, inc", OU=javasoft, OU=Digital ID Class 3 - Netscape Object Signing, O="sun microsystems, inc", L=cupertino, ST=california, C=US
Signature 0000: 91 09 EF 93 B9 EF 42 C5   3B 31 3C 45 D8 95 4D 81  ......B.;1<E..M.


Java is open source try adding a whitelist mechanism + default entries to webstart and have ppl accept it during install. T'is implementation specific after all.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #7 - Posted 2008-10-26 07:52:38 »

Anything within the JRE is automatically OK. JOGL is not part of JRE.
Despite JOGL being signed by Sun, it is still just a 3rd party application in the view of the JRE - and rightly so.

If Sun did have a certificate to sign jre-external applications with, that gets automatically signed, then that same certificate should be available to other providers than Sun - otherwise Sun gains an unfair advantage.
This however implies that Sun guarantees that this 3rd party application does not contain malicious code. Something I don't think that Sun ever will unless they handle the entire code base.

So, in conclusion, I don't see this happening.

Offline cylab

JGO Ninja


Medals: 43



« Reply #8 - Posted 2008-10-26 10:39:09 »

Am I the only one who things this security warning is a good idea and boosts the trust in applets and the java platform as a whole? Actually I start to shiver thinking about what the various other browser plugins are allowed to without even asking for...

Mathias - I Know What [you] Did Last Summer!
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2008-10-26 11:06:46 »

Well the security thing's a great idea but there's some rather common APIs that really don't need it. Like JOGL and LWJGL for example. They just do 3D rendering. Sun could take a release, pore of the source a little, and slap a cert over it to make it effectively another optional part of the JRE like Swing etc. in Update 10.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ewjordan

Junior Member





« Reply #10 - Posted 2008-10-26 11:25:35 »

Am I the only one who things this security warning is a good idea and boosts the trust in applets and the java platform as a whole? Actually I start to shiver thinking about what the various other browser plugins are allowed to without even asking for...
Well, I certainly don't agree - in fact, seeing a certificate that is signed by "sun microsystems, inc." (yes, in freaking lowercase!!!) makes me all but certain that the thing is untrustworthy, because if Sun made Java, and Sun made this plugin, why the hell would it need to ask my permission to do something?  Add to that the fact that the simple use of my graphics card is not the type of high risk operation that should require any sort of manual permission to be given.  Which, of course, is irrelevant, since the security model in Java is such that there's no way to fine-grain any sort of permissions to services (compare to, say, the Flash plug-in, which lets you allocate an applet a customizable amount of disk space, and decide specifically whether you want to give it microphone and camera access; and which, btw, in version 10, adds accelerated 3d graphics support to the player with - you guessed it - no warning at all, which is totally 100% reasonable and right).

Nobody should trust applets, ever, unless they specifically trust the people that made them, which for games is not generally going to be the case.  To me, the idea that people should need to give 100% pwnage access to their computer in order for the game to get access to accelerated graphics is ridiculous, and goes against the entire idea of computer security; even if they're just giving the OpenGL plugin access, they still should not be trained to click "Trust" whenever they play some random game.  And as we know from what's happened with Vista, people do get into the habit of just allowing everything when they're forced to do it too often, to the point where if there's an option, they'll turn off the checks altogether.

In other words, I am fiercely in favor of Cas' suggestion, I think it would significantly improve the user experience of Java games, and would leave trust dialogues to what should be their original purpose - pop up something when an application needs some unusual level of access to your computer, not when it just needs to draw some polygons.
Offline JuddMan

Senior Member


Medals: 1


Your Ad Here


« Reply #11 - Posted 2008-10-26 11:51:12 »

Java has never crashed my windows system with a BSOD.

Jogl has, on several occasions. Not due to malicious intent by the program using it, just buggy code that did something i'm sure JOGL wasn't expecting.

If it werent for that, i'd be strongly in favor of some of the more standard add-ons to be automtically accepted.
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #12 - Posted 2008-10-26 13:17:46 »

...I'm getting a dialogue, guess at some point you decided to trust sun.
ah, I see this is possible but I really can't remember that I did it.

 
Well, I certainly don't agree - in fact, seeing a certificate that is signed by "sun microsystems, inc." (yes, in freaking lowercase!!!) makes me all but certain that the thing is untrustworthy, because if Sun made Java, and Sun made this plugin, why the hell would it need to ask my permission to do something? ..
Remember doing 3d still involves graphics drivers and it is still possible to get a blue screen on some OSes under certain conditions. This has nothing to do with the quality of the 3d lib which does the native binding and even can change over time. Putting signed 3d libs on the whitelist is like trusting all current and future driver implementations.

Offline bienator

Senior Member




OutOfCoffeeException


« Reply #13 - Posted 2008-10-26 13:29:05 »

@LWJGL guys and others

why not doing a little bit lobby work and sign all graphics libraries with the same certificate? (aka signed by 3d Graphics Community) This would reduce the number of certificates the user would have to sign in his lifespan but would also increase the probability that he has to sign two certificates in the first app he launches.

... just an idea

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #14 - Posted 2008-10-26 13:34:14 »

a) it doesn't solve the issue - it just decreases the issue, but it will happen at least once for a user
b) the signing entity would have to guarantee the validity of all code bases ? - at least thats whats implied by a cert.
c) a *company* needs to be the signing entity

Offline bienator

Senior Member




OutOfCoffeeException


« Reply #15 - Posted 2008-10-26 13:54:10 »

a) it doesn't solve the issue - it just decreases the issue, but it will happen at least once for a user
yes, thats what i said + there is no perfect solution. Trusting foreign implementations by default is no option (the 3d libs on whitelist proposal).
b) the signing entity would have to guarantee the validity of all code bases ? - at least thats whats implied by a cert.
yes the community would maintain the code bases
c) a *company* needs to be the signing entity
by law? I often sign self signed-stuff with my name. Nothing prevents you to sign with '3d Community' or similar.

but yes it was just an idea...

Offline ewjordan

Junior Member





« Reply #16 - Posted 2008-10-27 15:01:01 »

Remember doing 3d still involves graphics drivers and it is still possible to get a blue screen on some OSes under certain conditions. This has nothing to do with the quality of the 3d lib which does the native binding and even can change over time. Putting signed 3d libs on the whitelist is like trusting all current and future driver implementations.
IMO, this is a risk you're signing on for any time you open a game.  And if Flash is doing it anyways, Java can easily get away with it, since everyone will be assailed by sites and Flash ads that use their 3d drivers on a daily basis anyhow.  Might as well follow along in Flash's wake is what I'm thinking...  The upshot is that if people have drivers that are really so bad that they are BSOD-ing their computers, they'll need to be fixed ASAP or these people won't even be able to go to Youtube without a crash.  But again, this is going to happen with or without Java deciding to do it, so we might as well reap some of the benefits, no?

Unless maybe there's something different about the way Flash is doing accelerated graphics that somehow makes it more safe?  I don't see how that's possible, but...
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2008-10-27 16:55:04 »

I would like to also point out that this is not specifically in the realm of 3D drivers, which, btw, almost never ever bluescreen (in fact I haven't seen a BSOD for several years now). It's a way for Sun to extend Java's functionality with endorsed 3rd party extensions and allow developers to access these extensions to Java without having to grant all privileges just do to it.

In the time it takes Sun to come up with a great big new API for this and that, trundling as it does through the preposterous tedium of a JSR, companies like Adobe just say, hm, this is what we need to make Flash loads better, let's put it in the next release. Which is why Flash now dominates video delivery and shortly, 3D in the browser.

Cas Smiley

Offline bienator

Senior Member




OutOfCoffeeException


« Reply #18 - Posted 2008-10-27 17:34:26 »

I have to admit I haven't yet took a look flash but something tells me that you won't have direct access to apis like OpenGL - if yes sorry but than Flash is the next ActiveX which was almost a synonym for maleware.

BUT I never said hardware acceleration is not possible or risky in general (see Direct3d/OpenGL java2d pipeline or JavaFX with hw accel backend). If its an implementation detail everything is ok but libraries which bind-java-to-native-code-outside-the-control-of-the-java-community break still the sandbox and the user should be notified.

my 2c...

And don't forget, Sun is still a server && enterprise company possible security exploits in java would harm sun far more than security problems in adobe's flash.

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #19 - Posted 2008-10-27 19:09:20 »

I think the fact that some APIs are really absolutely benign - such as OpenGL for example - means they are quite capable of living within the sandbox and being entirely safe.

Cas Smiley

Offline ewjordan

Junior Member





« Reply #20 - Posted 2008-10-27 19:51:35 »

I have to admit I haven't yet took a look flash but something tells me that you won't have direct access to apis like OpenGL - if yes sorry but than Flash is the next ActiveX which was almost a synonym for maleware.
Ok, I looked into it a bit, and Flash's 3d support is, indeed, very limited; it sounds like it's just able to apply perspective correction to textured triangles, and this may be hardware accelerated, but they don't have a full 3d engine.  So you're right, no direct OpenGL API or anything like that.

I still don't think I agree, though, that providing OpenGL access would open up a security hole.  Is there something I don't know about JOGL's API that would permit system pwnage?  I've never heard of an exploit like that before.

Quote
BUT I never said hardware acceleration is not possible or risky in general (see Direct3d/OpenGL java2d pipeline or JavaFX with hw accel backend). If its an implementation detail everything is ok but libraries which bind-java-to-native-code-outside-the-control-of-the-java-community break still the sandbox and the user should be notified.
I guess I'm not entirely sure what you mean here.  To me, a Java wrapper around OpenGL does turn the underlying native code into an implementation detail.  That's kind of the point of OpenGL, to expose a useful graphics API without forcing you to interface directly with the graphics card.  I don't see any need to break out of the sandbox for that, especially if the native code at the interface is controlled by Sun (which it is, if we're talking about JOGL).

We may just be arguing different points here, I'm not sure.  I agree with Cas, I don't see any conceivable security hole in exposing the OpenGL API, there's no route that I know of that allows an OpenGL call to do anything bad to your computer (modulo, of course, a real devious bug in the driver code that accesses the graphics card, which is a totally different issue that shouldn't be Sun's concern at all, since it would be someone else's bug).

At the risk of repeating myself: to force a complete break from the sandbox to achieve something that should be possible from within it is bad bad bad security practice.  Without a finer grained security mechanism (which would be all but impossible to phase in at this point in Java's evolution), the best solution is to directly allow access, even if only in limited form, to the safe bits of functionality that are most commonly used.
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #21 - Posted 2008-10-27 20:09:46 »

You could look at the argument this way: if LWJGL isn't safe, is Java2D?

Cas Smiley

Offline Mr_Light

Senior Member




shiny.


« Reply #22 - Posted 2008-10-28 16:43:00 »

You could look at the argument this way: if LWJGL isn't safe, is Java2D?

Cas Smiley

that boils down to "Did we or someone else build it"  Grin Roll Eyes


Security is only a part of the picture of "does it work?" I'm sure you could find a pragmatic solution to keeping everyone happy. Like having the user select a level of paranoia(PR-department needs to come up with a better word  Tongue) High/Strict - as it is now or medium/Lose - that adds a default list of certificates to the trusted list.

Seems to work for most consumer targeted firewall software...

The advantage of going this route is that you don't get a split between JVM implementations/distributions between ones that do and do not endorse.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline DzzD
« Reply #23 - Posted 2008-10-28 17:43:24 »

Quote
I still don't think I agree, though, that providing OpenGL access would open up a security hole.  Is there something I don't know about JOGL's API that would permit system pwnage?  I've never heard of an exploit like that before.

hum, I guess probably tens....  even being able to switch fullscreen without user agreement could be considered as a security hole. even if it is far to be perfect,  browser security have been improved a lot year by year by learning what can annoy the user, in a normal security you should not be able to :
- switch fullscreen
- control mouse
- use too much ressource memory/cpu
- open multiple window
- produce error by sending wrong instruction to device (can happen when enabling low level devide access)
- disable browser close
- produce fake screen/window => undecorated window
- change target of a drop (ex : moving a window when mouse up after a drag)
- etc... etc...

in short , most cool stuff can appear as security hole depending on how coder use it.

Quote
I have to admit I haven't yet took a look flash but something tells me that you won't have direct access to apis like OpenGL - if yes sorry but than Flash is the next ActiveX which was almost a synonym for maleware.
probably you will be able soon to get access to a secured interface to perform hardware accelerated stuff but this doesn't sound flash like to directly program opengl, but it will (it already..) use HW for 3D as for 2D in a secure (not direct) maner for sure.

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #24 - Posted 2008-10-28 19:39:20 »

Fullscreen is a privileged action currently but I notice that Flash doesn't ask permission to go fullscreen. But it's not part of the OpenGL bindings anyway.

All I'm saying is, if the source is submitted to Sun, they could give it a thorough security check and then endorse it by signing with a certificate which allows the JVM to load it without any security warnings popping up. As if they'd basically written the code themselves and made it part of the JRE. For something as simple as LWJGL it should be a doddle.

Cas Smiley

Offline DzzD
« Reply #25 - Posted 2008-10-28 20:11:55 »

Quote
Fullscreen is a privileged action currently but I notice that Flash doesn't ask permission to go fullscreen. But it's not part of the OpenGL bindings anyway.
yup seems it dont, also severals plugins dont too, but IMHO it should be requiered because if no, you can produce some kind of "phishing" application : fake window/linux login, fake desktop, it is up to the coders imagination

Quote
All I'm saying is, if the source is submitted to Sun, they could give it a thorough security check and then endorse it by signing with a certificate which allows the JVM to load it without any security warnings popping up. As if they'd basically written the code themselves and made it part of the JRE. For something as simple as LWJGL it should be a doddle.
ok that would be ofsourse really great (but I would really prefer that they make it loadable as an extrnal library not included in the base JRE, this one is already ..... toooo big also xternal libraries will work with older JVM as it wont requiere lastest JRE, I dont understand why java dont work more that way => provide external libraries and not always increase the base jre)

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #26 - Posted 2008-10-28 20:37:37 »

That phishing stuff... is basically utterly paranoid. If you find yourself visiting the sorts of sites that have applications that can do that - you're already flirting with trouble anyway. I think the whole issue has gotten out of hand, a bit like the supposed threats of terrorism - that is, the paranoia is now actually far more of a bloody hassle than the actual threat.

Cas Smiley

Offline DzzD
« Reply #27 - Posted 2008-10-28 20:58:27 »

Quote
That phishing stuff... is basically utterly paranoid. If you find yourself visiting the sorts of sites that have applications that can do that - you're already flirting with trouble anyway. I think the whole issue has gotten out of hand, a bit like the supposed threats of terrorism - that is, the paranoia is now actually far more of a bloody hassle than the actual threat.
not really you can fall on such website just by clicking on a result in google or by clicking on a link on a digg-like website, I am not paranoid but the money stolen using internet as bank account or credit card number and other is quite huge.... and probably a product that dont take care of that and can help doing such thing will get a very bad advertising/publicity for the futur if it happen only once and will be ofcourse forbidden in compagny..

EDIT:
Quote
the paranoia is now actually far more of a bloody hassle than the actual threat.
unfortunatly that's probably not wrong ....

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #28 - Posted 2008-10-28 22:02:01 »

You could look at the argument this way: if LWJGL isn't safe, is Java2D?

Cas Smiley

No, but even Java2D is also not considered strictly safe by java's standards as well (switching full screen will require code signing).
That said, I agree that OpenGL could be considered just as safe as Java2D: No code signing necessary as long as you don't switch to full screen.

But in principle I believe the security dialog is a Good Thing. It's good that there is some kind of user feedback that the application requests privileges outside of the sandbox. It has prevented java from becoming the tool of choice for malware and it got java the reputation of being safe, so considering exceptions should always be approached with the greatest care.

Offline ewjordan

Junior Member





« Reply #29 - Posted 2008-10-28 22:36:01 »

yup seems it dont, also severals plugins dont too, but IMHO it should be requiered because if no, you can produce some kind of "phishing" application : fake window/linux login, fake desktop, it is up to the coders imagination
The solution here is to do exactly what Flash does - show an overlay that says "Press ESC to exit full screen mode" and then hard code the escape key to do so, without the programmer having any choice in the matter.  Also, IIRC the fullscreen mode can only be entered as a result of a user interface action, not a pure programmatic one.  These are technical issues, not fundamental security ones.

Quote
ok that would be ofsourse really great (but I would really prefer that they make it loadable as an extrnal library not included in the base JRE, this one is already ..... toooo big also xternal libraries will work with older JVM as it wont requiere lastest JRE, I dont understand why java dont work more that way => provide external libraries and not always increase the base jre)
I think this problem is almost exactly what Cas is addressing - if there was a system in place for an optional second tier of official Sun libraries that didn't require full sandbox-breaking to run but also didn't need to be installed with the base JRE, it would allow a lot more modularity.

But in principle I believe the security dialog is a Good Thing. It's good that there is some kind of user feedback that the application requests privileges outside of the sandbox. It has prevented java from becoming the tool of choice for malware and it got java the reputation of being safe, so considering exceptions should always be approached with the greatest care.
Absolutely.  But not considering exceptions at all is a big problem, too, because it means that things that should be considered sandbox safe now need to be out of the sandbox, which is a security flaw - people should never need to grant permission to their entire system just to allow something to use their graphics card, but under the current model they do.
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (14 views)
2014-08-22 19:31:30

atombrot (28 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (61 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!