RE: openssl apps; flags, parsing dates, etc.
The right thing to do is change opt_format to be generic, and specify exactly which types of formats are supported. Done and pushed. Some of the bit-settings are probably more loose than I'd like, but it works. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: openssl apps; flags, parsing dates, etc.
On Wed, Jul 16, 2014 at 10:56:03PM -0400, Salz, Rich wrote: I have a branch that adds pretty comprehensive option-checking to all the openssl commands: ; ./openssl x509 --CA /no/such/file x509: Cannot open input file /no/such/file, No such file or directory x509: Use -help for summary. ; ./openssl x509 -days 1.2 x509: Invalid number 1.2 for -days x509: Use -help for summary. ; ./openssl rsa -out /vmlinuz rsa: Cannot open output file /vmlinuz, Permission denied rsa: Use -help for summary. I know I broke some things; please try things out. The branch is here: https://github.com/akamai/openssl/tree/rsalz-monolith You've declared -days to take only positive numbers, it should allow negative numbers. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: openssl apps; flags, parsing dates, etc.
You've declared -days to take only positive numbers, it should allow negative numbers. Pushed, thanks. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: openssl apps; flags, parsing dates, etc.
On Thu, Jul 17, 2014 at 12:09:29AM -0400, Salz, Rich wrote: You've declared -days to take only positive numbers, it should allow negative numbers. Pushed, thanks. Also the keyform option definition string looks wrong: keyform, OPT_KEYFORM, 'f', Private key file format (PEM or ENGINE) while the valid choices seem to be PEM or DER, not PEM or ENGINE: doc/apps/ca.pod:[B-keyform PEM|DER] doc/apps/ca.pod:=item B-keyform PEM|DER doc/apps/dgst.pod:[B-keyform arg] doc/apps/dgst.pod:=item B-keyform arg doc/apps/pkeyutl.pod:[B-keyform PEM|DER] doc/apps/pkeyutl.pod:=item B-keyform PEM|DER doc/apps/req.pod:[B-keyform PEM|DER] doc/apps/req.pod:=item B-keyform PEM|DER doc/apps/s_client.pod:[B-keyform DER|PEM] doc/apps/s_client.pod:=item B-keyform format doc/apps/s_server.pod:[B-keyform DER|PEM] doc/apps/s_server.pod:[B-dkeyform DER|PEM] doc/apps/s_server.pod:=item B-keyform format doc/apps/s_server.pod:=item B-dcertform format, B-dkeyform format, B-dpass arg doc/apps/x509.pod:[B-keyform DER|PEM] doc/apps/x509.pod:[B-CAkeyform DER|PEM] doc/apps/x509.pod:=item B-keyform PEM|DER doc/apps/x509.pod:The format or Bkey can be specified using the B-keyform option. In any case avoid magic constants in function call arguments: opt_format(..., 1, ...) instead: #define ANY_FORMAT 0 #define PEMDER_FORMAT 1 and use these only, or use an enum instead of defines if you prefer. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: openssl apps; flags, parsing dates, etc.
keyform, OPT_KEYFORM, 'f', Private key file format (PEM or ENGINE) while the valid choices seem to be PEM or DER, not PEM or ENGINE: No, it depends on the command. Some, for example, expect keys to be stored in the ENGINE (presumably an HSM). The docs are often outdated. But pem/der is the majority of choices. The right thing to do is change opt_format to be generic, and specify exactly which types of formats are supported. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: openssl apps; flags, parsing dates, etc.
On 07/17/2014 12:03 AM, Viktor Dukhovni wrote: You've declared -days to take only positive numbers, it should allow negative numbers. why? Or at least: why accept these generally unacceptable options by default? I can understand wanting to be able to create perverse certificates to test validation stacks, but i don't think that the command line tool used by many people to create certs should be willing to create known bad certs without explicitly overriding a warning or something. --dkg signature.asc Description: OpenPGP digital signature
Re: openssl apps; flags, parsing dates, etc.
On Thu, Jul 17, 2014 at 12:56:40AM -0400, Daniel Kahn Gillmor wrote: You've declared -days to take only positive numbers, it should allow negative numbers. why? Or at least: why accept these generally unacceptable options by default? I can understand wanting to be able to create perverse certificates to test validation stacks, but i don't think that the command line tool used by many people to create certs should be willing to create known bad certs without explicitly overriding a warning or something. Command-line tools on unix systems do what they're told. The resulting certificate is well-formed, and never valid. However in some applications expiration checks are irrelevant (fingerprint checks and the like), and a deliberately pre-expired certificate may be a reasonable choice. Higher-level tools can check the days argument before invoking the openssl apps layer. It should not be necessary to write C code to generate well-formed if corner-case certificates. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: openssl apps; flags, parsing dates, etc.
On Thu, Jul 17, 2014 at 05:06:07AM +, Viktor Dukhovni wrote: Higher-level tools can check the days argument before invoking the openssl apps layer. It should not be necessary to write C code to generate well-formed if corner-case certificates. Also there is far more risk in generating a certificate that lasts too long, than one that is never valid. Should there also be warnings for 100-year certificates? 1 day certificates? The CLI is not an interface for naive users. It is a toolkit for shell scripts. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
