Hi Blaine. Essentially, I think the -tls command line option is a hold over from a time when all of this was more in flux. Back then, it was apparently the common practice that frameworks wanting to embed an org.hsqldb.Server instance would have to invoke the main(String[]) signature from a Runnable in a Thread, in order to be able to start the Server in-process asynchronously (main used to invoke Server.run directly, which does not return until the server dies). Now Server has asynchronous start() and stop() service methods, as well as methods for setting and getting attributes, so basically main(String[]) is deprecated for starting Server in-process.
The short of it is that I completely agree with you: it now makes little sense to bother with the -tls command line option and it is indeed obsolete and misleading. If Fred agrees (which he very likely does), then of course: please remove it from the docs. //-- I don't think the issue at the time was having to turn TLS on to get SSL sockets working for Server when keystore was specified. I believe it was the opposite, which was the issue of being able to turn TLS off for some Server instances, even with keystore specified. IIRC, there were other considerations as well. For example, having read through the javax.net and javax.net.ssl javadocs, AFAICT, there is nothing preventing an installation from providing spi configuration/customization, such as for alternate implementations for managing keys. So, while I completely agree that the typical use-case now is likely to rely on the JDK 1.4.x+ built in support for SSL, configure system properties and let the JDK/JRE work its magic, OTOH, I believe there is nothing preventing the use of alternate implementations, including alternate key managers that do not necessarily use the built-in JDK keystore file plumbing (might, for example, hook up to a hardware "black box") or that do not use or wish to use system properties as the means of communicating keystore related information. Further, it is not impossible or unthinkable that there might exist the requirement to use TLS for, say, a Server instance made available at one address of a multi-NIC host, while using regular HSQL protocol for a Server instance made available at another. For example, an installation might wish to use HSQLS/HTTPS protocol for WAN/Internet routes, but plain HSQL for LAN routes (e.g. under JBOSS clustering). With HSQLDB 1.7.2, it is now possible to specify the InetAddress for each Server instance, as well as to host the same Database instance under multiple Server instances (i.e. can make a Database instance available under multiple protocols/addresses/ports/aliases). As such, I felt that in the interest of configurability, the default isTls() attribute for new Server instances should indeed be based on system property configuration, as per your original work, but that it should also be possible to be explicit on a per Server basis, for cases where it is desirable to be able to use any choice or combination of protocols, key management, etc. As mentioned above, one example might be where keystore system property configuration is not applicable to an installation providing custom key management through the KeyManagerFactorySpi. As another example, it might be desirable, say under JMX, to provide the ability to configure one database instance to be available via HSQL protocol but some other instance hosted by the same JVM process to be available only via HSQLS protocol. Finally, although it may well be quite uncommon now for applications to use anything but the built in JSSE implementation and default configuration facility (system properties), I'm not convinced that there is great harm to allow configuring the propery for individual Server instances. Indeed, given the discussion above, it appears (at least on the surface) to be artificially limiting to assume all-or-nothing TLS, based on JVM-wide system property configuration. OTOH, I suppose one must consider the risk that an HSQL connection to one database instance can, say, call a stored procedure that makes available data from another in-process database instance that would otherwise only be externally accessible via, say, HSQLS. But then again, regardless of protocol, we all know that a resource is only as secure as the least secure connection authorized to access it (i.e. a TLS connection comprimised at the client end can be used to retreive and then re-broadcast sensistive data in an unauthorized fashion just as easily as a plain socket connection). Cheers, Campbell ----- Original Message ----- From: "Blaine Simpson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: 16 May, 2004 4:02 PM Subject: [Hsqldb-developers] tls Server property > Please disregard my previous question about whether WebServer works with > TLS. I was mistaken. I had that working all along, which I remembered once > I saw the "https:" URLs in the docs. > > Campbell: I don't remember if I invented the "tls" property or if you did, > but it seems obsolete and misleading. The instructions at > http://hsqldb.sourceforge.net/alphadocs/guide/ch06.html have worked just > fine for about a year now, without using either the "-tls" argument to > Server, > nor the server.tls property. To use TLS, the user must specify the location > of the certificate file, and (for our first cut) we just use the > existing system > property for that purpose. Regardless of our setting of TLS mode, things > won't work unless the user sets the JVM keystore property. Therefore, it > seems most simple to just decide to use TLS based on whether the user has > set that property. I say that the tls property/arg is misleading because > Server runs TLS mode just fine when the property/arg is not turned on. > > I didn't know about the tls arg/property until today (if I knew before, I > have since forgotten). It is easy to forget since everything works great > without it, the property is documented nowhere (including the full > property list in the Advanced chapter), and the argument is documented > only in the Server javadocs (but not the WebServer javadocs). > Therefore, I have invested considerable time in > testing our UNIX init script using TLS as documented at > http://hsqldb.sourceforge.net/alphadocs/guide/ch06.html . For this > reason, I would very much prefer to just drop the tls argument/property. > > Is it ok with you if I just remove the Javadoc entry for the -tls argument > to Server? I don't think leaving the code in place will hurt anything, > and we don't want to hold up the RC by testing code changes. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: SourceForge.net Broadband > Sign-up now for SourceForge Broadband and get the fastest > 6.0/768 connection for only $19.95/mo for the first 3 months! > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click > _______________________________________________ > hsqldb-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hsqldb-developers > ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
