Signing and Digital Certificates

One more thing that’s different, although it really shouldn’t matter…:

mine => archive="unsigned.jar,signed.jar" yours => archive="signed.jar,unsigned.jar"

It was the package names.

Thank you it works

ps. Riven, I love you. Im thinking a wedding in the fall.

Pageflip applet works for me. (Windows 7 64 bit Java 1.6). Shows certificate warning when I press button.

Don’t take me down in the fall!

You might fancy this:


   @Override
   public File browse(final File dir, final String title, final int mode)
   {
      return AccessController.doPrivileged(new PrivilegedAction<File>()
      {
         @Override
         public File run()
         {
            return browseImpl(dir, title, mode);
         }
      });
   }

   @Override
   public Socket connect(final String host, final int port) throws IOException
   {
      try
      {
         return AccessController.doPrivileged(new PrivilegedAction<Socket>()
         {
            @Override
            public Socket run()
            {
               try
               {
                  return new Socket(host, port);
               }
               catch (IOException exc)
               {
                  throw new RuntimeException(exc);
               }
            }
         });
      }
      catch (RuntimeException exc)
      {
         throw (IOException) exc.getCause();
      }
   }

   File browseImpl(final File dir, String title, int mode)
   {
      final FileDialog dialog = new FileDialog((Dialog) null, title, mode);

      Runnable task = new Runnable()
      {
         @Override
         public void run()
         {
            String path = dir.getAbsolutePath();
            dialog.setDirectory(path);
            dialog.setVisible(true);
         }
      };

      try
      {
         if (SwingUtilities.isEventDispatchThread())
            task.run();
         else
            SwingUtilities.invokeAndWait(task);
      }
      catch (Exception exc)
      {
         exc.printStackTrace();
      }

      if (dialog.getFile() == null)
         return null;
      return new File(dialog.getDirectory(), dialog.getFile());
   }

yeah, its actually the sockets that were my main concern.

As of Java 6u19, Oracle effectively destroyed this technique >:(


http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html

:-\ this is soooo stupid… it was still a secured solution and was enabling a better user experiences… let see how it look …

Sun/Oracle have really a problem, why does they try to make user experience so poor when they cannot reach more than 60% computer after java 1.6 has been out for severals monthes ? I just update to 1.6-19-b4 … and I got :

1 - do you want to install google toolbar (checked)?
and
2 - do you know about openoffice ?
and
3 - you now need to reboot your computer to apply change
and
4 - after reboot ? java do not work anymore ! => need to install again from the website

and finally yes signed/unsigned does not work anymore ( after 3 years of using it… this is just ununderstandable & STUPID ! ) and always show a security dialog… bravo… clap clap to Sun to always bring to its users new Java versions always more broken and hard to install and always modifying the way old Applet run ensuring hyper-incompatibility between version, this way you are sure that java will always be stamped : Java programme once run nowhere the same or break after some monthes (when java is updated…), nice…

@Sun : you know what ? call Microsoft and ask them how you should do to maintain retro-compatibilty ? no ? because they are fareaway better for such things, even the very old 1.1 still work nearly as nice as the lastest sun release

Java has been the best language ever thinked but the lack of effort into the plugin/JRE to maintain retro-compatibility and even compatibility make it become useless for anything that requiere compatibility and especially over long periods

each plugin release Sun demonstrate the Murphy law …

Anybody got time to roll our own plugin? :-X ::slight_smile:

Actually, if you add “Trusted-Library: true” to the manifest, it does not immediately show the security dialog, but… once it does, it either hangs or Class.forName(“some.secure.package.SecureClass”) throws a ClassNotFoundException, because the classloaders are strictly separated.

There must be a way…

thanks, I am looking on this solution right now, I hope it will do the trick… at least until the 1.6-20 release get out …

LWJGL AppletLoader also broke due to this sudden update and change on how classloaders work with mixed signed/unsigned jars. However its fixed now and LWJGL 2.4 should be out soon.

Anyway since the loader shows the security dialog at initialisation its easy to work round any later issues due to the extra permissions, what you guys are trying to do is gonna be pretty tricky now due to the changes (i.e. get security dialog to show from an unsigned jar).

nice to know you manage to fix it for LWJGL, but does it apply for people having made Applet with older LWJGL ?

as a side note: 3DzzD Applets still works too ( either you press yes or no they will work ) but the problem, what make me angry is that you now get a scary popup at startup … how Sun can made such fundamental change !?

versions 6u14 (and up) were bad too:

only effects ppl using an older LWJGL who were using a mix of signed and unsigned jars (by that I mean only the lwjgl_util_applet.jar and lzma.jar), shouldn’t effect those that were signed all the jars.

I had all jars signed with the same certificate and it still happened to me. I think the reason was that some of the jars were also lzma compressed, causing java to consider them to be unsigned binary files.

Adding “Trusted-Library: true” to the manifest in the two jars directly loaded by java made all the problems go away.

I really cant understand how and who validate such change in the plugin… this seems so stupid & risky…

1 - it is incompatible with old Applet and make severals of them crash or display scary & confusing popup
2 - it DOES NOT make anything more secure and then it is only a useless & regressive change : I think about that using liveconnect, untrusted code can still command trusted code (via delayed or not javascript) without any warning but this is just more boring & complicated to do this way for real world project and so profesional wont use this way but hackers will … so it make real company work lot more complicate while it does not make hackers life harder…

how the hell Sun/Oracle validate such Genius new plugin ideas ?

Who knows.

I wonder how hard it is to write a plugin for browsers. Can’t be that difficult. I’ve got a LWJGL+JRE at about 3mb if anyone’s interested and it could probably be even smaller still.

Cas :slight_smile:

hmm, going the custom plugin route would be cool as it’d give us complete control over how the plugin works, runs and would finally give us a chance to get it right (something that Sun/Oracle have failed at for the last decade):slight_smile:

However going the custom plugin route is IMO a rather difficult task, especially as you’d have to get it right on all the platforms + different browsers. It’d also require doing C/C++ combined with Java (jni?) which is always a pain.

Also ppl don’t like installing plugins, just take the example of Unity3D, that is one plugin that IMO got almost everything right and nailed the user experience. However many ppl just avoid Unity3d games as they don’t want to install yet another plugin.

Its hard to ignore a present user base of about 60% of all computers already having the java plugin.

I think you can still get a decent user experience with the java plugin (provided you jump lots of hoops, bugs, limitations, issues, security dialogs, etc) still IMO easier then going the custom plugin route where its an uphill battle to get users to install it.