hello Casey, On Thursday 04 May 2006 10:22, Casey Marshall wrote: > On May 3, 2006, at 3:09 PM, Raif S. Naffah wrote: > > On Thursday 04 May 2006 07:22, Casey Marshall wrote: > >> On May 3, 2006, at 5:33 AM, Raif S. Naffah wrote: > >>> the attached patch --already committed-- makes it possible to use > >>> the default keystore type and implementation to work with the > >>> keytool. > >> > >> Is that really necessary? I was under the impression that you > >> usually need one keyring type or the other, depending on what you > >> are doing with it. When does `keytool' need both? > > > > i'm afraid it is. consider the case where you first run the > > keytool with a -genkey command followed by an -import command of a > > trusted certificate; both with no -keystore option (to use a > > default .keystore file). with the 1st command the .keystore is > > created as a private keyring. it will fail for the 2nd because it's > > expecting a public one. > > But, it sounds like that equivalent to passing `-keystore > ~/.keystore' to both subcommands. I mean, it doesn't sound like > there's any technical limitation, just that a particular usage > pattern no longer works.
using a -keystore option does not address the issue. the problem is that the old implementation of the adapter was allowing certain methods of the KeyStore interface on a private keyring, and others on the public one; throwing an exception if it is not of the right type. to me this is a faulty implementation of the specs. > I'm not arguing against making that behavior (and being able to keep > public and private keys in one file) work, but I think you should > consider backwards compatibility. i think we should allow for such a construction since it seems to be the only way of offering a correct implementation of the KeyStore interface. as for backward compatibility, this can be addressed by offering an additional command to the keytool that reads a single-type keyring, or a pair of differently located private and public keyrings, and combines them into one file. users can then use this command to migrate their data and start using the keytool for their command-line operations. it should not be hard to write and document this new command, but do we have enough users out there to warrant this work? > >> This patch is breaking the format (you've changed it to always be > >> the concatenation of public and private keyrings, which is more or > >> less an entirely new file format), which we should avoid. You > >> should detect what it is you are loading, so you can still load > >> old keyring files. > >> > >> I'd suggest doing: > >> > >> if keyring has type 'private' > >> load private keyring > >> if end of file not reached > >> load public keyring > >> > >> ...so you can still load a file with only one type, instead of > >> requiring that the input always be a concatenation of two > >> keyrings. > > I'd still suggest doing this. Breaking file format compatibility > should be a no-no, especially since you can easily avoid it. > > Thanks. -- cheers; rsn
pgpbXiGZeVdio.pgp
Description: PGP signature
