Mimi, On Wed, Jun 30, 2021 at 12:39:02PM -0400, Mimi Zohar wrote: > On Tue, 2021-06-29 at 04:32 +0300, Vitaly Chikunov wrote: > > On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote: > > > > > > Thank you for the detailed explanation. > > > > > > On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote: > > > > > > > > Requiring the optarg value to be prefixed with "0x" would > > > > > simplify the strlen test. > > > > > (The subsequent patch wouldn't need a contrived prefix.) > > > > > > > > (I do not understand this remark at the moment.) > > > > > > > > Base 16 will let user pass keyid just as a string, copy-pasting from > > > > somewhere else. > > > > > > strtoul() supports prefixing the ascii-hex string with "0x". To > > > differentiate between a keyid and pathname, why not require the keyid > > > be prefixed with "0x", as opposed to requiring the pathname to be > > > prefixed with '@', like "--keyid @/path/to/cert.pem". > > > > I wanted to avoid (filename vs keyid) ambiguity of the argument to > > `--keyid' - if user have file named "0x00112233" they would have hard > > time passing it to `--keyid'. But, it's impossible to have keyid string > > starting with "@". So, "@" perfectly distinguish type of `--keyid' > > argument but "0x" isn't. > > > > Also, in some software (zip, rar) "@" is common prefix meaning value > > should be taken from the specified file. But, yes, "@" is not common > > in Unix environments. Do you want me to create separate option like > > `--keyid-from-file'? > > It's highly unlikely that both the filename and pathname would be > prefixed with "0x". Defining a new option might be a good idea. > Possibly naming it --extract-cert-keyid, ---cert-keyid, or --keyid- > from-cert. It's not unlikely, because people may want to keep cert files named or symlinked by keyid. (For example, local cert database keep cert files symlinked like `f30dd6ad.0'.) I will add an option, most understandable, perhaps, is `--keyid-from-cert'. Also, I will remove base 16 from --keyid argument. Thanks, > > thanks, > > Mimi
