Bug 2149064

+++ This bug was initially created as a clone of Bug #2143206 +++

Description of problem:
sscg started generating "dhparams.pem" in 8.7/9.1 and I think this is arguably a regression

It looks like it is breaking the httpd containers because the cwd isn't writable when sscg is invoked 

https://github.com/sclorg/httpd-container/issues/171#issuecomment-1315446275

even outside of the containers it is creating a "/dhparams.pem" which wasn't requested. For typical use-cases apps should use the OpenSSL builtin dhparams anyway.

Version-Release number of selected component (if applicable):
sscg-3.0.0-5.el8.x86_64

How reproducible:
always

Steps to Reproduce:
1. dnf install mod_ssl
2. systemctl start httpd-init

Actual results:
/dhparams.pem exists

Expected results:
no /dhparams.pem should be created

Additional info:

--- Additional comment from Stephen Gallagher on 2022-11-16 19:37:21 UTC ---

That's easy enough to change, but I'm concerned that altering it at this point might break consumers that are relying on the current behavior. How do you feel about it if I write the file "opportunistically". If the file can be opened for writing, do so. If not, skip it (rather than treating it as an error)?

--- Additional comment from Stephen Gallagher on 2022-11-16 20:32:55 UTC ---

I have a proposed patch at https://github.com/sgallagher/sscg/pull/62 which behaves as follows:

== Scenario 1 ==
User calls `sscg` without specifying `--dhparams-file`.

SSCG will attempt to write out the default location of `./dhparams.pem`. If it cannot do so, it will log it and continue on.


== Scenario 2 ==
User calls `sscg --dhparams-file /some/path`.

SSCG will attempt to write out the parameters to `/some/path`. If it cannot do so, it will throw an error and return nonzero.

--- Additional comment from Joe Orton on 2022-11-17 08:45:01 UTC ---

Make sense to me, thanks Stephen!

--- Additional comment from Joe Orton on 2022-11-23 17:08:56 UTC ---

It looks like we can workaround the new behaviour in the container scripts which will likely be the fastest way to ship fixes. PR here for review upstream: https://github.com/sclorg/httpd-container/pull/172

I think it's right to fix the sscg behaviour as suggested in comment 2 though.

--- Additional comment from Stephen Gallagher on 2022-11-28 15:01:33 UTC ---

I have a patch ready for sscg, I just haven't had a chance to land it yet and get it built for 8.8 yet. I'll do that today or tomorrow as time permits.