| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These functions convert strings to internal objects and vice versa.
This is a best effort, probably with a lot of room for improvement,
which can happen in tree if anyone cares. It's better than nothing.
Nothing in turn would be significantly better than the utter garbage
a related project has managed to land as part of their efforts towards
significant documentation improvements in a recent major relase.
This leaves a dangling reference to the misnamed X509V3_METHOD_get_nid(3)
which I may or may not fill in the future.
I am unsure about the HISTORY section's precision, but that's what I got
from cvs history. All these functions are about a quarter century old
(and it shows), so I don't think it matters very much.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A few years back beck introduced REGRESS_SKIP_SLOW dances with the idea
that this should speed up the interop tests for us devs because this also
checked interop between opensslX and opensslY, which we don't particularly
care about. This never really worked. On a mac m1 mini the result is this:
REGRESS_SKIP_SLOW unset
9m56.69s real 3m42.24s user 3m00.70s system
REGRESS_SKIP_SLOW=yes
11m04.61s real 7m29.61s user 1m40.29s system
The problem is that REGRESS_SKIP_SLOW simply wasn't designed to handle
the huge number of tests we have here. There are many nested .for loops
resulting in several thousand tests. Each test has a name of length ~80.
REGRESS_SKIP_SLOW concatenates them into a several hundred kilobytes
long string in REGRESS_SKIP_TARGETS, iterates over all regress targets and
tests with ".if ${REGRESS_SKIP_TARGETS:M${RT}}" if it should skip them.
This means that during a regress run, make spends a lot of time linearly
scanning a huge string.
I ran into this when I added OpenSSL 3.0 tests to the already existing
1.0.2 and 1.1 tests with the result that with REGRESS_SLOW_TARGTS set
it took the better part of an hour while without it it took about 15 min.
The hack here is simply to avoid using REGRESS_SLOW_TARGTES here and
handle the situation differently.
patch, REGRESS_SKIP_SLOW=yes
5m42.32s real 2m09.98s user 1m45.21s system
The real solution would be to fix this in bsd.regress.mk, which someone
who understands make well is very welcome to do. For now, I'm happy with
this.
Debugged with jsing a few months ago
|
| | |
|
| |
|
|
| |
ok tb@
|
| |
|
|
| |
ok tb@
|
| | |
|
| |
|
|
| |
No functional change.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This removes a bunch of incomplete and scary code, which potentially leaks
secrets and is not constant time. A performance gain is achieved on arm64
for sizes that we care about, while a minimal decrease in performance is
noted for larger sizes on some other platforms.
While we will potentially reimplement Karatsuba (or Toom-Cook) at a later
date, it will be easier and safer to do it from a clean slate.
ok tb@
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The code was deleted a while back, the prototypes remained. We had
OPENSSL_NO_EC_NISTP_64_GCC_128 in opensslfeatures.h since forever.
discussed with jsing
|
| | |
|
| |
|
|
| |
Requested by jsing
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Some headers were included conditionally on OPENSSL_NO_DEPRECATED in hopes
that eventually the mess of everything includes everything will magically
resolve itself. Of course everyone would end up building openssl with
OPENSSL_NO_DEPRECATED over time... Right.
Surprisingly, the ecosystem has come to rely on these implicit inclusions,
so about two dozen ports would fail to build because of this. Patching this
would be easy but really not worth the effort.
ok jsing
|
| |
|
|
|
| |
This places a point at infinity and then fails. Fix some wacky indentation
in the vicinity.
|
| |
|
|
| |
Maybe it should be replaced by another test, although P-256 seems enough.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This only requires very minor changes and simplifies testing quite a bit.
Some of the changes can be undone after the next bump.
|
| | |
|
| |
|
|
| |
The code they test will go away soon.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
While base bc is great, it uses libcrypto's BIGNUM implementation.
This implies that the independent verification of the bn_test isn't
as independent as it should be.
With this commit, run-bc picks up bn-gh if it is installed. This appears
to work on amd64, arm64 and sparc64 (where gbc is busted). I will send
PRs to the regress maintainers once I will have tested this a bit more
thoroughly. Committing this early since I juggle way too many diffs
already.
|
| | |
|
| |
|
|
| |
"go ahead" jsing
|
| |
|
|
|
| |
GF2m curves will go away soon. This reduces the pile of diffs in my jungle
a tiny little bit.
|
| |
|
|
|
| |
Apparently nobody tried to compile libcrypto with ZLI since Jan 2022.
Maybe this means that we can unifdef -U ZLIB or maybe not...
|
| |
|
|
| |
No functional change.
|
| |
|
|
| |
ok tb@
|
| | |
|
| | |
|
| |
|
|
| |
ok jsing
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
As usual with the fp suffix, the former wraps the latter with a file BIO.
There is no reason for this function to be in a separate file.
|
| |
|
|
| |
(sorry, otto, for not spotting in the updated diff)
|
| | |
|
| |
|
|
|
| |
except for bootblocks. This way we have built-in leak detecction
always (if enable by malloc flags). See man pages for details.
|
| | |
|
| |
|
|
|
|
|
| |
sk_OPENSSL_STRING_pop_free() is much more explicit and isn't that much
more complicated. x509_util.c can also use it directly...
No binary change
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
ok tb@
|
