On Tue, Feb 16, 2021 at 01:16:21PM +0100, Jan Klemkow wrote:
> On Tue, Feb 16, 2021 at 04:36:59AM +1100, Joel Sing wrote:
> > On 21-02-15 14:49:46, Jan Klemkow wrote:
> > > On Sat, Feb 13, 2021 at 03:53:48PM +0100, Theo Buehler wrote:
> > > > On Sat, Feb 13, 2021 at 11:58:04AM +0100, Jan Klemkow wrote:
> > > > > A coworker of mine has made tests with LibreSSL [1] and found some
> > > > > regressions.  I took his test descriptions and created the following
> > > > > automated regression test.  In the repository he described his 
> > > > > findings
> > > > > in detail.  I kept the numbers of the files and subtests in the target
> > > > > names for now.  So, its easier to match it with his files.
> > > > > 
> > > > > I don't know how to handle the result of "test-01-ssl".  Thats why its
> > > > > just a comment.  Someone may have an idea to handle this properly.
> > > > > 
> > > > > Any comments, wishes or OK's?
> > > > > 
> > > > > [1]: https://github.com/noxxi/libressl-tests
> > > > 
> > > > First of all thanks for the effort!
> > > > 
> > > > The perl script and probably also the Makefile should have a license.
> > > > 
> > > > Please add a check that tests whether the required perl modules are
> > > > installed (p5-IO-Socket-SSL and p5-Net-SSLeay) and otherwise prints
> > > > SKIPPED and their names, so I can install them if they're not present.
> > > > I never remember their exact capitalization and hyphenation...
> > > > 
> > > > Various comments inline, and a patch for openssl(1) at the end that may
> > > > simplify some things.
> > > 
> > > This is an updated version of the test including comments and wishes
> > > from tb@ and bluhm@.
> > > 
> > > OK?
> > 
> > This currently drives openssl(1) for tests, which means that it is
> > testing openssl(1), libssl and libcrypto, when what you're really
> > wanting to test is libcrypto's verifier. While this works, the
> > problem is that a change or breakage in libssl or openssl(1) results
> > in a regress failure for libcrypto. If this is to land in its
> > current form it really should be in regress/usr.bin/openssl -
> > alternatively, it could be reworked to explicitly test libcrypto's
> > APIs and remain here.
> > 
> > Some additional comments inline.
> 
> So, the following diff should hit all needs.
> 
> OK?

Yes, it's ok.  Thanks.

I played a bit with it, and it is a bit more fragile than I would like,
but we may fix that in tree or redo some of it without using openssl(1)
later.  The ground covered is definitely worthwhile to have in regres,
so please go ahead.  (jsing has no objection).

Reply via email to