JAR signing
10 views
Skip to first unread message
DRC
Feb 15, 2019, 3:26:44 PM2/15/19
to turbovn...@googlegroups.com, turbovn...@googlegroups.com
The code signing certificate that has been used for four years to sign
the TurboVNC JAR files for use with Java Web Start expired this week.
Since I used a timestamp authority when signing the JARs, JAR files for
existing releases should continue to work (please let me know if they
don't.)
Unfortunately Thawte no longer provides individual code signing
certificates, so there is no way to renew my certificate. In addition
to spending money that I don't have right now (2018 was a very bad year
financially for VirtualGL, TurboVNC, and libjpeg-turbo), the process of
getting on board with another certificate authority is painful enough to
give me pause, particularly given that Java Web Start is now a
deprecated feature. I would like to hear back (off-list is fine) from
any organizations that are currently using Java Web Start with TurboVNC:
1. How many users do you estimate use TurboVNC with Java Web Start
within your organization?
2. Do you re-sign the JAR files using your own certificate or keep them
signed with my certificate?
3. If you currently rely on my certificate, would your deployment
scenario allow you to white-list a self-signed certificate from The
VirtualGL Project? (This would generally involve importing the
certificate on the client side using the Java Control Panel.)
4. Would your company be willing to donate the money to this project
(about US$200) necessary for me to purchase a Comodo individual code
signing certificate for the next two years, thus ensuring that the
TurboVNC JAR files for the 2.2.2 and 3.0.x releases remain signed?
If I don't get feedback on this, my default course of action is going to
be generating a self-signed certificate for The VirtualGL Project, thus
requiring anyone who wishes to continue using TurboVNC with Java Web
Start to white-list our certificate.
DRC
the TurboVNC JAR files for use with Java Web Start expired this week.
Since I used a timestamp authority when signing the JARs, JAR files for
existing releases should continue to work (please let me know if they
don't.)
Unfortunately Thawte no longer provides individual code signing
certificates, so there is no way to renew my certificate. In addition
to spending money that I don't have right now (2018 was a very bad year
financially for VirtualGL, TurboVNC, and libjpeg-turbo), the process of
getting on board with another certificate authority is painful enough to
give me pause, particularly given that Java Web Start is now a
deprecated feature. I would like to hear back (off-list is fine) from
any organizations that are currently using Java Web Start with TurboVNC:
1. How many users do you estimate use TurboVNC with Java Web Start
within your organization?
2. Do you re-sign the JAR files using your own certificate or keep them
signed with my certificate?
3. If you currently rely on my certificate, would your deployment
scenario allow you to white-list a self-signed certificate from The
VirtualGL Project? (This would generally involve importing the
certificate on the client side using the Java Control Panel.)
4. Would your company be willing to donate the money to this project
(about US$200) necessary for me to purchase a Comodo individual code
signing certificate for the next two years, thus ensuring that the
TurboVNC JAR files for the 2.2.2 and 3.0.x releases remain signed?
If I don't get feedback on this, my default course of action is going to
be generating a self-signed certificate for The VirtualGL Project, thus
requiring anyone who wishes to continue using TurboVNC with Java Web
Start to white-list our certificate.
DRC
Rafael Guimaraes
Feb 16, 2019, 9:36:52 AM2/16/19
to turbovn...@googlegroups.com
Em sex, 15 de fev de 2019 18:26, DRC <d...@virtualgl.org escreveu:
The code signing certificate that has been used for four years to sign
the TurboVNC JAR files for use with Java Web Start expired this week.
Since I used a timestamp authority when signing the JARs, JAR files for
existing releases should continue to work (please let me know if they
don't.)
Unfortunately Thawte no longer provides individual code signing
certificates, so there is no way to renew my certificate. In addition
to spending money that I don't have right now (2018 was a very bad year
financially for VirtualGL, TurboVNC, and libjpeg-turbo), the process of
getting on board with another certificate authority is painful enough to
give me pause, particularly given that Java Web Start is now a
deprecated feature. I would like to hear back (off-list is fine) from
any organizations that are currently using Java Web Start with TurboVNC:
1. How many users do you estimate use TurboVNC with Java Web Start
within your organization?
About 500.
2. Do you re-sign the JAR files using your own certificate or keep them
signed with my certificate?
I re-sign it, since I make some little modifications in the code to better adapt it to our needs.
3. If you currently rely on my certificate, would your deployment
scenario allow you to white-list a self-signed certificate from The
VirtualGL Project? (This would generally involve importing the
certificate on the client side using the Java Control Panel.)
4. Would your company be willing to donate the money to this project
(about US$200) necessary for me to purchase a Comodo individual code
signing certificate for the next two years, thus ensuring that the
TurboVNC JAR files for the 2.2.2 and 3.0.x releases remain signed?
If I don't get feedback on this, my default course of action is going to
be generating a self-signed certificate for The VirtualGL Project, thus
requiring anyone who wishes to continue using TurboVNC with Java Web
Start to white-list our certificate.
DRC
--
You received this message because you are subscribed to the Google Groups "TurboVNC Developer Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-devel/aee9c184-80ea-544b-815b-35868c985c8f%40virtualgl.org.
For more options, visit https://groups.google.com/d/optout.
DRC
Feb 16, 2019, 7:58:29 PM2/16/19
to turbovn...@googlegroups.com
On 2/16/19 8:36 AM, Rafael Guimaraes wrote:
> I re-sign it, since I make some little modifications in the code to
> better adapt it to our needs.
Thanks for the feedback. I'm curious about the modifications you make.
> I re-sign it, since I make some little modifications in the code to
> better adapt it to our needs.
Rafael Guimaraes
Feb 18, 2019, 7:33:15 AM2/18/19
to turbovn...@googlegroups.com
My modifications are basically the following:
1) I have created a thread that periodically calls an URL to advertise
that the Java client is still connected (a keep alive / timeout
mechanism). I use this for logging sessions accesses, so that if the
client is closed abruptly, the server can notice this. I also use this
because I only allow users to have full control of the VNC session if
the owner (user who created the session) is online, also connected to
the session. If the owner goes offline, i.e., disconnects from the
session, the server receives a notification (or notice this after a
timeout) and sends a message for every other user accessing the
session to alter their accessing mode from full access to view only.
It's been working like this for a few years. Since it's a new thread,
the code is very independent from your implementation (only a few
hooks to call it), it's pretty easy to patch new TurboVNC releases.
2) A little modification changes the Java Viewer window title to show
the name of the session (users provide a name when creating a new
session) and a list of users who are currently accessing the session.
One may quickly know if other users are connected to the session and
who are these users.
As you may see, I don't think that these modifications could be widely
applied. They are very tied to my web portal implementation...
Best regards,
Rafael Guimarães
1) I have created a thread that periodically calls an URL to advertise
that the Java client is still connected (a keep alive / timeout
mechanism). I use this for logging sessions accesses, so that if the
client is closed abruptly, the server can notice this. I also use this
because I only allow users to have full control of the VNC session if
the owner (user who created the session) is online, also connected to
the session. If the owner goes offline, i.e., disconnects from the
session, the server receives a notification (or notice this after a
timeout) and sends a message for every other user accessing the
session to alter their accessing mode from full access to view only.
It's been working like this for a few years. Since it's a new thread,
the code is very independent from your implementation (only a few
hooks to call it), it's pretty easy to patch new TurboVNC releases.
2) A little modification changes the Java Viewer window title to show
the name of the session (users provide a name when creating a new
session) and a list of users who are currently accessing the session.
One may quickly know if other users are connected to the session and
who are these users.
As you may see, I don't think that these modifications could be widely
applied. They are very tied to my web portal implementation...
Best regards,
Rafael Guimarães
> --
> You received this message because you are subscribed to the Google Groups "TurboVNC Developer Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-deve...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-devel/ef2d9aef-fec5-e234-e5d1-b89414cf7a9d%40virtualgl.org.
> You received this message because you are subscribed to the Google Groups "TurboVNC Developer Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-deve...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages