On Wed, 2021-07-28 at 00:24 +0200, Daniel Gustafsson wrote:
> > On 4 Mar 2021, at 01:03, Jacob Champion <pchampion@vmware.com> wrote:
> > Andrew pointed out elsewhere [1] that it's pretty difficult to add new
> > certificates to the test/ssl suite without blowing away the current
> > state and starting over. I needed new cases for the NSS backend work,
> > and ran into the same pain, so here is my attempt to improve the
> > situation.
>
> Thanks for working on this, I second the pain cited. I've just started to look
> at this, so only a few comments thus far.
>
> > The unused server-ss certificate has been removed entirely.
>
> Nice catch, this seems to have been unused since the original import of the SSL
> test suite. To cut down scope of the patch (even if only a small bit) I
> propose to apply this separately first, as per the attached.
LGTM.
> > - Serial number collisions are less likely, thanks to Andrew's idea to
> > use the current clock time as the initial serial number in a series.
>
> +my $serialno = `openssl x509 -serial -noout -in ssl/client.crt`;
> +$serialno =~ s/^serial=//;
> +$serialno = hex($serialno); # OpenSSL prints serial numbers in hexadecimal
>
> Will that work on Windows? We don't currently require the openssl binary to be
> in PATH unless one wants to rebuild sslfiles (which it is quite likely to be
> but there should at least be errorhandling covering when it's not).
Hm, that's a good point. It should be easy enough for me to add a
fallback if the invocation fails; I'll give it a shot tomorrow.
> > - I am making _heavy_ use of GNU Make-isms, which does not improve
> > long-term maintainability.
>
> GNU Make is already a requirement, I don't see this shifting the needle in any
> direction.
As long as the .SECONDARYEXPANSION magic is clear enough to others, I'm
happy.
Thanks!
--Jacob