> The options aren't particularly good, but you have some: > > 1) Create your own keystore that is compatible with this jarsigner, > and use that instead of the included one. > > Note that this jarsigning going on here in x11vnc has nothing to > do with security or authentication, in fact the opposite: it is > only to provide a signed jar that a user can accept and have it > run as an application rather than an applet to enable local file > saving or getting a socket connection through a web proxy. > > 2) Build (or borrow) the signed jar files built on a different > architecture that has sun's jarsigner. Or send them to another > machine to be signed. There is no intrinsic reason these > jars need to be built or signed on the platform they will be > deployed on (they are really just platform-independent 'data' > files that will be served and run on jvm's elsewhere, not hppa.) > I understand debian build rules may get in the way of this. > > 3) Don't ship the signed jars in the hppa package. It is not the > end of the world. Better to provide the regular and SSL-enabled > applets which I imagine are used much more often than the signed > ones. > > That's all I can think of.
I would opt for option 2 or maybe 3. About option 2, I could split x11vnc into x11vnc and x11vnc-data packages. x11vnc-data package will contain all jars (/usr/share/x11vnc/classes) and will be platform-independent (architecture all). About option 3, it means default-jdk build-dependency removal on hppa and hurd architectures so all jars won't be built/shipped on these architectures too. thoughts ? cheers, Fathi -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
