On Thu, Aug 14, 2008 at 04:44:37PM +0100, Darren J Moffat wrote: > Garrett D'Amore wrote: > >Also, what are the "compatibility" concerns of the new configuration > >file directive? What will happen to other open source implementations > >of SSH when they see the same directive (such as when sharing a home > >directory via NFS with Linux or FreeBSD systems)? > > We already have that problem. The workaround is to use the per system > /etc/ssh/ssh_config.
Also, the default value is good enough that I doubt anyone will actually use this option. > >Finally, might it not be a better choice to avoid hardcoding the notion > >of OpenSSL into the configuration file syntax? Perhaps something more > >generic, such as "UseHardwareOffload" or somesuch might be better, > >especially if the software might one day be changed to use a different > >crypto backend (such as PKCS#11.) > > This was on purpose because it is about using the OpenSSL engine. If we > do a direct PKCS#11 interface in the future the configuration required > will be more than just a boolean. Also if we switch to direct PKCS#11 > then hardware vs software doesn't make much sense, what makes sense is > which PKCS#11 slot/token is being used. Of course, a switch to use PKCS#11 directly will render this option obsolete. So, what is the interface stability of this option? (I propose Obsolete Committed.) Nico --
