On May 3, 2006, at 3:09 PM, Raif S. Naffah wrote:
hello Casey,On Thursday 04 May 2006 07:22, Casey Marshall wrote:On May 3, 2006, at 5:33 AM, Raif S. Naffah wrote:hello all, 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.
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.
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.
PGP.sig
Description: This is a digitally signed message part
