| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
Pull a number of invariants into variables, which avoids repeated loading
from memory on architectures where sufficient registers are available.
Also keep track of the per-iteration carry in a variable, rather than
unnecessarily reading from and writing to memory.
This gives a reasonable performance gain on some architectures (e.g. armv7)
|
| |
|
| |
|
|
|
|
|
| |
If you can initialize with functions, you can also initialize with
constants...
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Fix botched Xr and be more precise about errors by being less precise.
Add a BUGS section.
|
|
|
|
|
|
|
|
| |
These are in actual use, so their meaning should be documented.
The remaining commented codes are unused outside of x509_txt.c
except for X509_V_ERR_INVALID_NON_CA which looks used at first
glance, but it is actually in an unreachable path of the legacy
verifier.
|
|
|
|
|
|
|
|
|
|
| |
The documentation of the BN_MOD_CTX has been out of sync with reality
for decades. The structure is now opaque, so its members should not be
documented this way. They internals aren't important for the rest of
the page.
BN_MOD_CTX_init() will soon be removed. It's useless unless you like
leaks.
|
|
|
|
| |
ok otto@
|
| |
|
|
|
|
|
|
|
| |
The CRL extension handler is completely misplaced in x509_enum.c.
Move it to x509_bitst.c until we find a better home for it. This
way it is next to the other two extension methods that have the
extra usr_data contortion.
|
|
|
|
|
| |
These functions probably belong into asn1/ but they definitely don't
belong into separate files.
|
| |
|
|
|
|
|
|
| |
This is a public alias for the also public BIT_STRING_BITNAME. The
ENUMERATED_NAMES type is used exactly twice, namely on two lines in this
file. This is silly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
While it may have been reasonable to use VisibleString back when this
code was written, it's an anachronism nowadays. In particular, configuring
BoringSSL reports that they have seen malformed certificates with exactly
the issue caused by this unfortuante default.
Reported by Alex Gaynor in OpenSSL issue 20772
ok jsing
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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
|
|
|
|
| |
"go ahead" jsing
|
|
|
|
|
| |
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
|
| |
|