Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[Jim Jagielski]

> On Oct 16, 2018, at 11:36 AM, William A Rowe Jr  wrote:
> 
> To button this issue up, it's clear to me that Jim had transposed the meaning 
> of result values from posix commands, and that was the origin of 
> irrationality in this discussion.
> 

Actually, I did not. But thanks for playing. I will ignore the implied insult.

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[William A Rowe Jr]

To button this issue up, it's clear to me that Jim had transposed the
meaning of result values from posix commands, and that was the origin of
irrationality in this discussion.

Beyond the misunderstanding, the actual behavior of openssl in 1.0.x and
prior was inane, and led to Jim's confusion, and my earlier hint to add
-help would not have improved the situation.

On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung  wrote:

> Am 14.10.2018 um 21:59 schrieb William A Rowe Jr:
> > On Sun, Oct 14, 2018 at 8:32 AM Jim Jagielski  > > wrote:
> >
> > All we are checking is the error code. Nothing else.
> >
> > % openssl version
> > OpenSSL 1.0.2p  14 Aug 2018
>

The result of this command, $? had returns a value 0, success.


> > % openssl ocsp 2>/dev/null
> > % print $?
> > 1
>

This result code is failure. A non-zero posix result code is failure.

See `man 3 system`.  (See also perldoc system, search for LIST to learn
that the result code is shifted 8 bits, returning 256 for '1'.)

> % openssl foo 2>/dev/null
> > % print $?
> > 0
>

This result code is success, return code 0, no error. An unrecognized verb
was not an error!?!


> > With 1.1.1, both return 1, but so what, we know that it has oscp.
>

With 1.1.0 and 1.1.1 the failure result code 1 is correct, as shown below.


> I can confirm this behavior for normal OpenSSL 1.0.2p.
>

I also confirm, and my apologies for presuming this was some fork's
behavior. OpenSSL 1.0.x behavior was truly incomprehensible as shown
below...

And worse, my suggested fix to jim was also erroneous, in 1.0.2 and prior
the ocsp -help flag is similarly treated as an error. Using 1.0.2 branch
(frozen/final) from git;

$ openssl version
OpenSSL 1.0.2l-dev  xx XXX 
$ echo $?
0
$ openssl foo
openssl:Error: 'foo' is an invalid command.

Standard commands
asn1parse caciphers   cms
[...]
$ echo $?
0
$ openssl ocsp
OCSP utility
Usage ocsp [options]
where options are
-out fileoutput filename
[...]
$ echo $?
1
$ openssl ocsp -help
OCSP utility
Usage ocsp [options]
where options are
-out fileoutput filename
[...]
$ echo $?
1

Success, success, failure, failure. Which makes no fricking sense, and this
was the case jim sought to solve for.

Once we are at 1.1.0, this all starts to right itself;

$ openssl version
OpenSSL 1.1.0i-fips  14 Aug 2018
$ echo $?
0
$ openssl foo
Invalid command 'foo'; type "help" for a list.
$ echo $?
1
$ openssl ocsp 2>&1
ocsp: Use -help for summary.
$ echo $?
1
$ openssl ocsp -help 2>&1
Usage: ocsp [options]
Valid options are:
 -help   Display this summary
 -out outfileOutput filename
[...]
$ echo $?
0

Success, failure, failure, success, as would be expected.

It's plainly obvious that the result code from openssl main() cannot be
trusted for evaluating features between 1.0.x and 1.1.x, and is the reason
Jim's patch was defective.

So we are back to testing the output of `openssl list -commands 2>&1`,
evaluating stdout on 1.1.x, and stderr on 1.0.x. Unless Jim's veto stands?

> On Mon, Oct 15, 2018 at 10:07 AM Jim Jagielski  wrote:
>>
>> -1 (veto)
>>
>> Please revert. 'list' is NOT a command and this causes OCSP to be
skipped.

On Mon, Oct 15, 2018 at 10:20 AM Jim Jagielski  wrote:
>
> Forget this. My patch works and is correct and handles the specific
situation which is noted in the test case itself related to older versions.
It is an IMPROVEMENT over what we currently have.

Your patch treated success as failure and failure as success.

Your patch had enabled ocsp always in 1.1.x because `openssl ocsp` always
returns failure. It was disabling the test when absent from 1.0.x because
`openssl ocsp` returned failure, while it enabled the test with 1.0.x
because `openssl {unknown}` returned success when unrecognized.

Your patch introduced a regression because ocsp in 1.1.x must not be tested
when configured no-ocsp; this was harmful.

My suggestion of `openssl ocsp -help` would not have fixed this, because
then the test would have been disabled in 1.1.x when ocsp was available,
and enabled when ocsp was absent. However, using a valid command would have
helped identify the underlying logic error.

Joe's original code enabled ocsp correctly in 1.1.x because `openssl list
-commands` works, and the /ocsp/ string is found. Joe's original code never
enabled the test in 1.0.2, which was mostly harmless, but less effective.

My patch to Joe's original code works because `openssl list -commands`
fails so the command list is emitted to stderr, where we now detect /ocsp/.

> The sole reason why Bill doesn't like it is because *I* committed it.

By now, we should agree that this tantrum was uncalled for, in light of
these multiple defective patches. The fact that you couldn't believe your
logic might be erroneous wasn't an excuse to have a meltdown or take a code
discussion personally.

> Whatever. I 

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[Dennis Clarke]

On 10/15/2018 01:25 PM, William A Rowe Jr wrote:
On Sun, Oct 14, 2018 at 4:38 PM Dennis Clarke > wrote:



As a red herring that illustrates how oddball the situation could get :

$ /usr/sfw/bin/openssl version 2>&1 | cut -f1 -d\(
OpenSSL 0.9.7d 17 Mar 2004
[...]
Segmentation Fault(coredump)


I think we can safely ignore OpenSSL 0.9.7 as the final release was over 
11 years ago.


Like I was saying it is a red^H^H^Hdead herring :-\

The 0.9.8 will only be encountered on rusting RHEL 5 (mainstream EOL a 
year ago in spring) and similarly ancient installations across other 
os/architectures.


*nod*

1.0.0 only saw the light of day in broad adoption via 
SLES 11 (mainstream EOL spring next year).


The Oracle folks pushed out 1.0.2 onto legacy Solaris a while ago :

$ which openssl
/usr/bin/openssl
$ /usr/bin/openssl version
OpenSSL 1.0.2n  7 Dec 2017


> There are a good number of 1.0.1 installations lingering around...

tons.

> Breaking 1.0.1 support would seem unwise

A disaster is what I am thinking.

> but we probably should start
> ignoring 0.9.8 and 1.0.0 for all practical purposes.

Anything pre 1.x.y should be considered rust.

Dennis

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[William A Rowe Jr]

On Sun, Oct 14, 2018 at 4:38 PM Dennis Clarke  wrote:

>
> As a red herring that illustrates how oddball the situation could get :
>
> $ /usr/sfw/bin/openssl version 2>&1 | cut -f1 -d\(
> OpenSSL 0.9.7d 17 Mar 2004
> [...]
> Segmentation Fault(coredump)
>

I think we can safely ignore OpenSSL 0.9.7 as the final release was over 11
years ago.

Right now, only 1.1.1, 1.1.0 (12 month EOL clock started), and 1.0.2
(through 2019) are recognized by the OpenSSL project.

The 0.9.8 will only be encountered on rusting RHEL 5 (mainstream EOL a year
ago in spring) and similarly ancient installations across other
os/architectures. 1.0.0 only saw the light of day in broad adoption via
SLES 11 (mainstream EOL spring next year). There are a good number of 1.0.1
installations lingering around... everything shipped between and including
RHEL 6 and RHEL 7 including SLES 12 and Ubuntu 12.04 and 14.04 shipped with
that flavor.

Breaking 1.0.1 support would seem unwise, but we probably should start
ignoring 0.9.8 and 1.0.0 for all practical purposes.

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[William A Rowe Jr]

On Wed, Oct 10, 2018 at 12:27 PM  wrote:

> Author: jim
> Date: Wed Oct 10 17:27:33 2018
> New Revision: 1843478
>
> @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp');
>  # support in earlier versions without messing around with stderr
>  my $openssl = Apache::TestSSLCA::openssl();
>  if (!have_min_apache_version('2.4.26')
> -or `$openssl list-standard-commands 2>/dev/null` !~ /ocsp/) {
> +or system("$openssl ocsp 2>/dev/null") == 0) {
>  print "1..0 # skip: No OpenSSL or mod_ssl OCSP support";
>  exit 0;
>  }
>

I think I know where the confusion is. system() returns 0 for success, and
the non-zero result code from invocation on failure.

You are testing whether `openssl ocsp` succeeds, skipping the test on
success and running the test on failure.

You meant to test whether `openssl ocsp` failed (non-zero), to skip the test

If you replace your test with system("$openssl ocsp -help 2>/dev/null") ==
0 you will observe that it goes haywire, because that command is valid when
ocsp is enabled.

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[William A Rowe Jr]

On Mon, Oct 15, 2018 at 10:10 AM Jim Jagielski  wrote:

> -1 (veto).
>

Correct. Your three commits against jorton's implementation are vetoed.
They were incorrect.


> 'list' is not a valid command.
>

You are wrong.

The list-standard-commands feature was dropped from OpenSSL 1.1.0 and
onwards.

https://www.openssl.org/docs/man1.1.0/apps/openssl.html

This doesn't cover OpenSSL 1.0.1 and 1.0.2, which exhibit the following
result;

$ LD_LIBRARY_PATH=./lib bin/openssl list -help 2>&1
openssl:Error: 'list' is an invalid command.

Standard commands
asn1parse caciphers   cms
crl   crl2pkcs7 dgst  dh
dhparam   dsa   dsaparam  ec
ecparam   enc   engineerrstr
gendh gendsagenpkey   genrsa
nseq  ocsp  passwdpkcs12
pkcs7 pkcs8 pkey  pkeyparam
pkeyutl   prime rand  req
rsa   rsautls_client  s_server
s_timesess_id   smime speed
spkac srp   tsverify
version   x509

Message Digest commands (see the `dgst' command for more details)
md4   md5   mdc2  rmd160
sha   sha1

Cipher commands (see the `enc' command for more details)
aes-128-cbc   aes-128-ecb   aes-192-cbc   aes-192-ecb
aes-256-cbc   aes-256-ecb   base64bf
bf-cbcbf-cfbbf-ecbbf-ofb
camellia-128-cbc  camellia-128-ecb  camellia-192-cbc  camellia-192-ecb
camellia-256-cbc  camellia-256-ecb  cast  cast-cbc
cast5-cbc cast5-cfb cast5-ecb cast5-ofb
des   des-cbc   des-cfb   des-ecb
des-ede   des-ede-cbc   des-ede-cfb   des-ede-ofb
des-ede3  des-ede3-cbc  des-ede3-cfb  des-ede3-ofb
des-ofb   des3  desx  idea
idea-cbc  idea-cfb  idea-ecb  idea-ofb
rc2   rc2-40-cbcrc2-64-cbcrc2-cbc
rc2-cfb   rc2-ecb   rc2-ofb   rc4
rc4-40seed  seed-cbc  seed-cfb
seed-ecb  seed-ofb

While the result code is 1 (failure), using the `cmd` expression this
succeeds in providing the verb list.

It's helpful if we solve for all cases, and not one developer's specific
case.

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[Jim Jagielski]

Forget this. My patch works and is correct and handles the specific situation 
which is noted in the test case itself related to older versions. It is an 
IMPROVEMENT over what we currently have.

The sole reason why Bill doesn't like it is because *I* committed it.

Whatever. I have no desire or patience with him anymore. I could not care less 
what patch is included.

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[Jim Jagielski]

-1 (veto).

'list' is not a valid command.

> On Oct 15, 2018, at 11:04 AM, William A Rowe Jr  wrote:
> 
> On Mon, Oct 15, 2018 at 7:52 AM Jim Jagielski  > wrote:
> 
> And lest we forget, the orig version used:
> 
> $openssl list -commands
> 
> I have no idea what version of openssl supports 'list'. The result
> of which was that the ocsp testing was ALWAYS SKIPPED.
> 
> No, it wasn't skipped. We weren't looking at the result code, but examining 
> stdout, and jorton's original test was correct for everyone testing with 
> OpenSSL 1.1.0 and later.

Show me.

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[William A Rowe Jr]

On Mon, Oct 15, 2018 at 7:52 AM Jim Jagielski  wrote:

>
> And lest we forget, the orig version used:
>
> $openssl list -commands
>
> I have no idea what version of openssl supports 'list'. The result
> of which was that the ocsp testing was ALWAYS SKIPPED.
>

No, it wasn't skipped. We weren't looking at the result code, but examining
stdout, and jorton's original test was correct for everyone testing with
OpenSSL 1.1.0 and later.

It was also correct for 1.0.2 and prior if the perl implementation was
capturing stderr to stdout as a result of `openssl list`, because in these
versions, the entire command list is dumped to stderr for the unrecognized
verb 'list', until you redirected stderr to /dev/null. list -commands was
introduced in 1.1.0. Also 1.1.0 dropped the list-standard-commands.

A correct solution, now committed, uses the original implementation but now
lumps stderr into stdout. For all flavors of OpenSSL we have a verb list to
evaluate.

I still ask whether testing system("$openssl ocsp -help") for a positive
(0) result code makes sense, but that reintroduces a >/dev/null 2>&1 which
I'd pointed out earlier breaks win32 testing because NUL <> /dev/null on
that platform, so it seemed simpler just to revert to jorton's solve.

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[Jim Jagielski]

> On Oct 14, 2018, at 3:59 PM, William A Rowe Jr  wrote:
> 
> $ openssl xyz >/dev/null
> Invalid command 'xyz'; type "help" for a list.
> $ echo $?
> 1
> $ openssl version
> OpenSSL 1.1.0i-fips  14 Aug 2018
>  
> I have no idea which bastardization of the openssl command line tool you are 
> using which returns success for bad verbs.
> 

It looks like your version suffers from such "bastardization" as well

And lest we forget, the orig version used:

$openssl list -commands

I have no idea what version of openssl supports 'list'. The result
of which was that the ocsp testing was ALWAYS SKIPPED.

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[Dennis Clarke]

On 10/14/2018 05:45 PM, William A Rowe Jr wrote:

Dennis, just to confirm ...  is this build ocsp enabled..


Enabled and broken. At least on Solaris 10 sparc with recent patches.

OpenSSL 1.1.1 works just fine.  See below.

OpenSSL 1.0.2n also blows up :

$ /usr/bin/openssl version
OpenSSL 1.0.2n  7 Dec 2017
$ /usr/bin/openssl ocsp -issuer /tmp/foo_chain -cert /tmp/foo_cert -text 
-url http://ocsp.int-x3.letsencrypt.org

OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
  Hash Algorithm: sha1
  Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
  Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
  Serial Number: 039048428EE710E751C1EC96E355B05FADF7
Request Extensions:
OCSP Nonce:
041027F5719EF8A6D928B5A5AC8CC46BA10C
Error querying OCSP responder
4275879124:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response 
error:ocsp_ht.c:314:Code=400,Reason=Bad Request

$

Not really a blow up .. just an "oops .. don't touch me" result.

OpenSSL 1.1.1 is happy all day long :

$ openssl ocsp -issuer /tmp/foo_chain -cert /tmp/foo_cert -text -url 
http://ocsp.int-x3.letsencrypt.org

OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
  Hash Algorithm: sha1
  Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
  Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
  Serial Number: 039048428EE710E751C1EC96E355B05FADF7
Request Extensions:
OCSP Nonce:
0410AF283079082966EF04E8805C8D9215EB
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt 
Authority X3

Produced At: Oct 12 02:56:00 2018 GMT
Responses:
Certificate ID:
  Hash Algorithm: sha1
  Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
  Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
  Serial Number: 039048428EE710E751C1EC96E355B05FADF7
Cert Status: good
This Update: Oct 12 02:00:00 2018 GMT
Next Update: Oct 19 02:00:00 2018 GMT

Signature Algorithm: sha256WithRSAEncryption
 76:f4:7f:ff:4a:c5:26:c2:60:88:fe:ef:90:dd:c7:0a:39:fd:
 d0:df:fe:17:4b:71:78:08:60:e0:ee:14:4b:98:91:ef:77:59:
 81:51:ee:cc:b6:16:99:92:7d:98:64:e2:a7:be:f2:cb:24:61:
 47:67:0c:62:2c:06:95:4b:73:34:0c:7a:ce:ce:1c:27:85:14:
 97:f7:2e:76:3e:21:8b:83:ab:29:1f:55:48:25:f4:61:6a:d8:
 bf:65:10:90:71:04:10:45:4d:9a:37:84:02:9e:eb:06:45:3f:
 85:4c:e4:a4:b6:3f:54:fa:4d:4b:9e:d4:8f:1b:44:4f:fb:6c:
 e3:18:11:ba:3c:e1:21:64:97:4b:4a:28:d7:c5:b1:b3:46:fe:
 36:99:da:da:aa:e4:32:57:a1:14:d5:54:b9:6d:e4:49:59:a2:
 77:d4:87:97:95:8d:e6:7c:5b:64:db:60:ab:3e:e3:a7:a6:bc:
 00:0e:b8:dd:0c:42:a0:18:f8:d5:73:16:80:50:3c:b3:24:d0:
 01:da:3d:09:29:4e:93:d7:81:27:91:39:9c:67:99:53:d4:5f:
 ab:6a:42:67:1e:ca:9d:4c:40:a7:f8:71:e4:bf:43:e8:a0:20:
 62:9c:d5:25:16:8a:41:f5:70:85:c4:e4:45:9d:b6:95:4f:4f:
 79:3f:84:53
WARNING: no nonce in response
Response verify OK
/tmp/foo_cert: good
This Update: Oct 12 02:00:00 2018 GMT
Next Update: Oct 19 02:00:00 2018 GMT
$
$

Ye old old OpenSSL 0.9.7d 17 Mar 2004 tries and then dumps core :

$
$ /usr/sfw/bin/openssl ocsp -issuer /tmp/foo_chain -cert /tmp/foo_cert 
-text -url http://ocsp.int-x3.letsencrypt.org

OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
  Hash Algorithm: sha1
  Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
  Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
  Serial Number: 039048428EE710E751C1EC96E355B05FADF7
Request Extensions:
OCSP Nonce:
04109FDC7D814DC7A57BFDB2ACB6C906247B
Error querying OCSP responsder
1035:error:27070072:OCSP routines:OCSP_sendreq_bio:server response 
error:/on10/build-nd/ON10_P042/usr/src/common/openssl/crypto/ocsp/ocsp_ht.c:147:Code=400,Reason=Bad 
Request

Segmentation Fault(coredump)
$

So the feature is there ... just broken.




How I tested this was :

$ openssl version
OpenSSL 1.1.1  11 Sep 2018

$ openssl s_client -connect node000.genunix.com:443 < /dev/null 2>&1
CONNECTED(0005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = *.genunix.com
verify return:1
---
Certificate chain
 0 s:CN = *.genunix.com
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-BEGIN CERTIFICATE-
MIIGBDCCBOygAwIBAgISA5BIQo7nEOdRweyW41WwX633MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[William A Rowe Jr]

Dennis, just to confirm ...  is this build ocsp enabled, or entirely absent
and yet presenting the ocsp help in absence of the feature?

On Sun, Oct 14, 2018 at 4:38 PM Dennis Clarke  wrote:

> On 10/14/2018 05:14 PM, Rainer Jung wrote:
> > Am 14.10.2018 um 22:58 schrieb William A Rowe Jr:
> >> On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung  >> > wrote:
> >>
> >>
> >> And Jim already set "With 1.1.1, both return 1, but so what, we know
> >> that it has oscp."
> >>
> >>
> >> That, of course, is nonsense.
> >>
> >> OpenSSL is malleable... with numerous no-{feature} choice, we really
> >> shouldn't
> >> presume presence of features by OpenSSL version. Otherwise, why wouldn't
> >> we simply use a regex against `openssl version`?
> >
> > Agreed, looking at the code it seems that starting with 1.1.0 (I only
> > checked 1.1.0i) ocsp can be disabled with no-ocsp.
> >
>
> As a red herring that illustrates how oddball the situation could get :
>
> $ /usr/sfw/bin/openssl version 2>&1 | cut -f1 -d\(
> OpenSSL 0.9.7d 17 Mar 2004
>
> $ /usr/sfw/bin/openssl ocsp > /dev/null
> OCSP utility
> Usage ocsp [options]
> where options are
> -out file  output filename
> -issuer file   issuer certificate
> -cert file certificate to check
> -serial n  serial number to check
> -signer file   certificate to sign OCSP request with
> -signkey file  private key to sign OCSP request with
> -sign_other file   additional certificates to include in signed request
> -no_certs  don't include any certificates in signed request
> -req_text  print text form of request
> -resp_text print text form of response
> -text  print text form of request and response
> -reqout file   write DER encoded OCSP request to "file"
> -respout file  write DER encoded OCSP reponse to "file"
> -reqin fileread DER encoded OCSP request from "file"
> -respin file   read DER encoded OCSP reponse from "file"
> -nonce add OCSP nonce to request
> -no_nonce  don't add OCSP nonce to request
> -url URL   OCSP responder URL
> -host host:n   send OCSP request to host on port n
> -path  path to use in OCSP request
> -CApath dirtrusted certificates directory
> -CAfile file   trusted certificates file
> -VAfile file   validator certificates file
> -validity_period n maximum validity discrepancy in seconds
> -status_age n  maximum status age in seconds
> -noverify  don't verify response at all
> -verify_other file additional certificates to search for signer
> -trust_other   don't verify additional certificates
> -no_intern don't search certificates contained in response for
> signer
> -no_signature_verify don't check signature on response
> -no_cert_verifydon't check signing certificate
> -no_chain  don't chain verify response
> -no_cert_checksdon't do additional checks on signing certificate
> -port numport to run responder on
> -index file  certificate status index file
> -CA file CA certificate
> -rsigner fileresponder certificate to sign responses with
> -rkey file   responder key to sign responses with
> -rother file other certificates to include in response
> -resp_no_certs don't include any certificates in response
> -nmin n  number of minutes before next update
> -ndays n number of days before next update
> -resp_key_id   identify reponse by signing certificate key ID
> -nrequest nnumber of requests to accept (default unlimited)
> Segmentation Fault(coredump)
> $
>
> So, the situation can get out of hand quickly.
>
> Dennis
>
> ps: I am on the sidelines reading *all* of this and wondering ...
>

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[Rainer Jung]

Am 14.10.2018 um 22:58 schrieb William A Rowe Jr:
On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung > wrote:



And Jim already set "With 1.1.1, both return 1, but so what, we know
that it has oscp."


That, of course, is nonsense.

OpenSSL is malleable... with numerous no-{feature} choice, we really 
shouldn't

presume presence of features by OpenSSL version. Otherwise, why wouldn't
we simply use a regex against `openssl version`?


Agreed, looking at the code it seems that starting with 1.1.0 (I only 
checked 1.1.0i) ocsp can be disabled with no-ocsp.


Regards,

Rainer

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[William A Rowe Jr]

On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung  wrote:

>
> And Jim already set "With 1.1.1, both return 1, but so what, we know
> that it has oscp."
>

That, of course, is nonsense.

OpenSSL is malleable... with numerous no-{feature} choice, we really
shouldn't
presume presence of features by OpenSSL version. Otherwise, why wouldn't
we simply use a regex against `openssl version`?

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[Rainer Jung]

Am 14.10.2018 um 21:59 schrieb William A Rowe Jr:
On Sun, Oct 14, 2018 at 8:32 AM Jim Jagielski > wrote:


All we are checking is the error code. Nothing else.

    % openssl version
    OpenSSL 1.0.2p  14 Aug 2018
    % openssl ocsp 2>/dev/null
    % print $?
    1
    % openssl foo 2>/dev/null
    % print $?
    0

With 1.1.1, both return 1, but so what, we know that it has oscp.


I can confirm this behavior for normal OpenSSL 1.0.2p.


$ openssl ocsp >/dev/null
ocsp: Use -help for summary.[wrowe@hub test-httpd]$ echo $?
$ echo $?
1
$ openssl xyz >/dev/null
Invalid command 'xyz'; type "help" for a list.
$ echo $?
1
$ openssl version
OpenSSL 1.1.0i-fips  14 Aug 2018


I can also confirm this behavior for normal OpenSSL 1.1.0i.

And Jim already set "With 1.1.1, both return 1, but so what, we know 
that it has oscp."



This doesn't tell us whether ocsp is compiled in.
I have no idea which bastardization of the openssl command line tool you 
are using which returns success for bad verbs.


Please refrain from such wil guessing (bastardization).

So checking the status code seems OK for 1.0.2 and newerversions as well 
(for different reasons), but it doesn't look understandable either 
(because it only works for 1.1.0+ due to a change in behavior). If 
Bill's suggestion "`$openssl ocsp -help` !~ /Usage:/" it would be easier 
to understand.



Complaining about /dev/null : orig code had this. Why was that OK?


But I think you (Jim) introduced /dev/null in an attempt to fix another 
problem in r1832567.



Never suggested it was OK.


I guess that's not what Jim meant, instead he might have asked why there 
was no complaint when it was originally introduced. But i think that 
doesn't lead us anywhere.


  Asking about finding potential *solutions* instead of throwing more 
darts at the wall. Why the emotive tone to a technical discussion?


Probably because it was unclear at that point whether there was a problem.

Regards,

Rainer

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[William A Rowe Jr]

Copy paste missed a stderr line;

$ openssl ocsp >/dev/null
ocsp: Use -help for summary.
$ echo $?
1
$ openssl xyz >/dev/null
Invalid command 'xyz'; type "help" for a list.
$ echo $?
1
$ openssl version
OpenSSL 1.1.0i-fips  14 Aug 2018

This is from
# dnf list openssl
Installed Packages
openssl.x86_64 1:1.1.0i-1.fc27
@updates
# cat /etc/redhat-release
Fedora release 27 (Twenty Seven)

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[William A Rowe Jr]

On Sun, Oct 14, 2018 at 8:32 AM Jim Jagielski  wrote:

> All we are checking is the error code. Nothing else.
>
>% openssl version
>OpenSSL 1.0.2p  14 Aug 2018
>% openssl ocsp 2>/dev/null
>% print $?
>1
>% openssl foo 2>/dev/null
>% print $?
>0
>
> With 1.1.1, both return 1, but so what, we know that it has oscp.
>

$ openssl ocsp >/dev/null
ocsp: Use -help for summary.[wrowe@hub test-httpd]$ echo $?
$ echo $?
1
$ openssl xyz >/dev/null
Invalid command 'xyz'; type "help" for a list.
$ echo $?
1
$ openssl version
OpenSSL 1.1.0i-fips  14 Aug 2018

This doesn't tell us whether ocsp is compiled in.

I have no idea which bastardization of the openssl command line tool you
are using which returns success for bad verbs.

Complaining about /dev/null : orig code had this. Why was that OK?
>

Never suggested it was OK.

 Asking about finding potential *solutions* instead of throwing more darts
at the wall. Why the emotive tone to a technical discussion?

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[Jim Jagielski]

All we are checking is the error code. Nothing else.

   % openssl version
   OpenSSL 1.0.2p  14 Aug 2018
   % openssl ocsp 2>/dev/null
   % print $?
   1
   % openssl foo 2>/dev/null
   % print $?
   0

With 1.1.1, both return 1, but so what, we know that it has oscp.

Complaining about /dev/null : orig code had this. Why was that OK?


> On Oct 13, 2018, at 2:35 PM, William A Rowe Jr  wrote:
> 
> On Wed, Oct 10, 2018 at 12:27 PM mailto:j...@apache.org>> 
> wrote:
> Author: jim
> Date: Wed Oct 10 17:27:33 2018
> New Revision: 1843478
> 
> URL: http://svn.apache.org/viewvc?rev=1843478=rev 
> 
> Log:
> Better method... just check return status
> 
> Modified:
> httpd/test/framework/trunk/t/ssl/ocsp.t
> 
> Modified: httpd/test/framework/trunk/t/ssl/ocsp.t
> URL: 
> http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/ocsp.t?rev=1843478=1843477=1843478=diff
>  
> 
> ==
> --- httpd/test/framework/trunk/t/ssl/ocsp.t (original)
> +++ httpd/test/framework/trunk/t/ssl/ocsp.t Wed Oct 10 17:27:33 2018
> @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp');
>  # support in earlier versions without messing around with stderr
>  my $openssl = Apache::TestSSLCA::openssl();
>  if (!have_min_apache_version('2.4.26')
> -or `$openssl list-standard-commands 2>/dev/null` !~ /ocsp/) {
> +or system("$openssl ocsp 2>/dev/null") == 0) {
> 
> On Windows, /dev/null is invalid (output target nul, eg NUL). 
> 
> On every platform this is an always-fail noop, since `openssl ocsp` always 
> results in an error. Not enough arguments. You disabled this test on all 
> environments, please revert.
> 
> One test without extraneous stdout garbage might be to test ( `$openssl ocsp 
> -help` !~ /Usage:/ ) ... in theory this would both succeed (success 0), eat 
> stdout, and there should be no Usage: instructions if the ocsp verb doesn't 
> exist.
> 
> Thoughts?
> 
> 

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[William A Rowe Jr]

On Sat, Oct 13, 2018 at 1:35 PM William A Rowe Jr 
wrote:

> On Wed, Oct 10, 2018 at 12:27 PM  wrote:
>
>> Author: jim
>> Date: Wed Oct 10 17:27:33 2018
>> New Revision: 1843478
>>
>> URL: http://svn.apache.org/viewvc?rev=1843478=rev
>> Log:
>> Better method... just check return status
>>
>> Modified:
>> httpd/test/framework/trunk/t/ssl/ocsp.t
>>
>> Modified: httpd/test/framework/trunk/t/ssl/ocsp.t
>> URL:
>> http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/ocsp.t?rev=1843478=1843477=1843478=diff
>>
>> ==
>> --- httpd/test/framework/trunk/t/ssl/ocsp.t (original)
>> +++ httpd/test/framework/trunk/t/ssl/ocsp.t Wed Oct 10 17:27:33 2018
>> @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp');
>>  # support in earlier versions without messing around with stderr
>>  my $openssl = Apache::TestSSLCA::openssl();
>>  if (!have_min_apache_version('2.4.26')
>> -or `$openssl list-standard-commands 2>/dev/null` !~ /ocsp/) {
>> +or system("$openssl ocsp 2>/dev/null") == 0) {
>>
>
> On Windows, /dev/null is invalid (output target nul, eg NUL).
>
> On every platform this is an always-fail noop, since `openssl ocsp` always
> results in an error. Not enough arguments. You disabled this test on all
> environments, please revert.
>
> One test without extraneous stdout garbage might be to test ( `$openssl
> ocsp -help` !~ /Usage:/ ) ... in theory this would both succeed (success
> 0), eat stdout, and there should be no Usage: instructions if the ocsp verb
> doesn't exist.
>

e.g.

$ openssl xyz -help
Invalid command 'xyz'; type "help" for a list.
$ echo $?
1
$ openssl ocsp -help
Usage: ocsp [options]
Valid options are:
 -help   Display this summary
 -out outfileOutput filename
[...]
$ echo $?
0

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[William A Rowe Jr]

On Wed, Oct 10, 2018 at 12:27 PM  wrote:

> Author: jim
> Date: Wed Oct 10 17:27:33 2018
> New Revision: 1843478
>
> URL: http://svn.apache.org/viewvc?rev=1843478=rev
> Log:
> Better method... just check return status
>
> Modified:
> httpd/test/framework/trunk/t/ssl/ocsp.t
>
> Modified: httpd/test/framework/trunk/t/ssl/ocsp.t
> URL:
> http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/ocsp.t?rev=1843478=1843477=1843478=diff
>
> ==
> --- httpd/test/framework/trunk/t/ssl/ocsp.t (original)
> +++ httpd/test/framework/trunk/t/ssl/ocsp.t Wed Oct 10 17:27:33 2018
> @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp');
>  # support in earlier versions without messing around with stderr
>  my $openssl = Apache::TestSSLCA::openssl();
>  if (!have_min_apache_version('2.4.26')
> -or `$openssl list-standard-commands 2>/dev/null` !~ /ocsp/) {
> +or system("$openssl ocsp 2>/dev/null") == 0) {
>

On Windows, /dev/null is invalid (output target nul, eg NUL).

On every platform this is an always-fail noop, since `openssl ocsp` always
results in an error. Not enough arguments. You disabled this test on all
environments, please revert.

One test without extraneous stdout garbage might be to test ( `$openssl
ocsp -help` !~ /Usage:/ ) ... in theory this would both succeed (success
0), eat stdout, and there should be no Usage: instructions if the ocsp verb
doesn't exist.

Thoughts?