Hi Vitaly, On Tue, 2021-06-29 at 04:32 +0300, Vitaly Chikunov wrote: > Mimi, > > 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. thanks, Mimi
