| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ok sthen
New Roots for existing CA:
/CN=Atos TrustedRoot Root CA ECC TLS 2021/O=Atos/C=DE
/CN=Atos TrustedRoot Root CA RSA TLS 2021/O=Atos/C=DE
New CA:
BEIJING CERTIFICATE AUTHORITY
/C=CN/O=BEIJING CERTIFICATE AUTHORITY/CN=BJCA Global Root CA1
/C=CN/O=BEIJING CERTIFICATE AUTHORITY/CN=BJCA Global Root CA2
Two E-Tugra roots were removed due to a breach:
/C=TR/L=Ankara/O=E-Tugra EBG A.S./OU=E-Tugra Trust Center/CN=E-Tugra Global Root CA ECC v3
/C=TR/L=Ankara/O=E-Tugra EBG A.S./OU=E-Tugra Trust Center/CN=E-Tugra Global Root CA RSA v3
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/C-HrP1SEq1A
Removed expired root:
/C=HK/O=Hongkong Post/CN=Hongkong Post Root CA 1
Removed expired CA:
SECOM Trust.net
/C=JP/O=SECOM Trust.net/OU=Security Communication RootCA1
New CA:
Sectigo Limited
/C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication Root E46
/C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication Root R46
New roots for existing CA:
/C=US/O=SSL Corporation/CN=SSL.com TLS ECC Root CA 2022
/C=US/O=SSL Corporation/CN=SSL.com TLS RSA Root CA 2022
|
|
|
|
|
|
|
|
|
|
| |
x509_prn.c r1.6 changed the output of 'openssl -in foo.pem -noout -text'
by removing trailing whitespace from non-critical certificate extensions.
Committing the difference now to reduces noise in an upcoming diff.
There's some trailing whitespace remaining. That's because we try to print
a BMPString in an User Notice's Explicit Text with "%*s". That doesn't work
so well with an encoding full of NULs...
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of printing to a temporary buffer with weird gymnastics, we can
simply write things out to the BIO using proper indent. This still isn't
perfect since we have a CBS version of this in ecx_buf_print(), which is
basically what used to be ASN1_buf_print(). Annotate this with an XXX for
future cleanup.
ok beck
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the offset is > 124, this function would overwrite between 1 and 5 bytes
of stack space after str[128]. So for a quick fix extend the buffer by 5
bytes. Obviously this is the permanent fix chosen elswehere. The proper fix
will be to rewrite this function from scratch.
Reported in detail by Masaru Masuda, many thanks!
Fixes https://github.com/libressl/openbsd/issues/145
begrudging ok from beck
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This is mechanical apart from a few manual edits to avoid doubled empty
lines.
ok jsing
|
|
|
|
|
|
|
| |
This includes a manual intervention for the call to EVP_PKEY_meth_find()
which ended up in the middle of nowhere.
ok jsing
|
|
|
|
|
|
|
| |
Also rip out all the gross, useless comments. There's still too much
garbage in here...
ok jsing
|
| |
|
| |
|
| |
|
|
|
|
| |
They document functionality that no longer exists.
|
| |
|
|
|
|
|
| |
There's probably more that needs to be updated here, but that can be done
another day.
|
| |
|
|
|
|
| |
remove two Xr to ENGINE manuals.
|
| |
|
| |
|
|
|
|
| |
In particular, do not use an uninitialized engine, simply pass NULL.
|
|
|
|
| |
CID 468015
|
|
|
|
|
|
|
|
|
|
|
|
| |
A recent change in EVP_CIPHER_CTX_iv_length() made it possible in principle
that this function returns -1. This can only happen for an incorrectly set
up EVP_CIPHER. Still it is better form to check for negative lengths before
stuffing it into a memcpy().
It would probably be desirable to cap the iv_length to something large
enough. This can be done another time.
ok beck
|
|
|
|
| |
where that information was missing.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
I was told not to look since it will magically get fixed. Fine. I'd still
have expected a minimal amount of care so that the manpage isn't totally
dysfunctional and missing text in the right places. Sigh.
|
| |
|
|
|
|
| |
These use static helper functions which don't need prototypes this way.
|
|
|
|
|
|
|
| |
This converts to proper single exit and undoes a number of unnecessarily
silly muppet antics.
ok beck
|
|
|
|
|
|
|
|
|
|
|
|
| |
Contrast "#define EVP_PKT_EXP 0x1000 /* <= 512 bit key */" with the diff:
- /* /8 because it's 1024 bits we look for, not bytes */
- if (EVP_PKEY_size(pk) <= 1024 / 8)
- ret |= EVP_PKT_EXP;
EVP_PKT_EXP will be nuked at the next opportunity.
discussed with jsing
|
| |
|
|
|
|
| |
ok beck jsing
|
|
|
|
|
|
|
| |
This doesn't do much right now, but is part of the tangle that is adding
RSA-PSS support.
ok beck jsing
|
|
|
|
|
|
|
|
|
|
|
| |
This matches when BoringSSL has done, and allows for getting
rid of the dependency on system timegm() and gmtime() in libtls.
which will make life easier for portable, and remove our
dependency on the potentially very slow system versions.
ok tb@ - tb will handle the minor bump bits and expose
on the next minor bump
CVS :----------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
timegm(3) is not available on some operating systems we support in
portable. We currently use musl's implementation, for which gcc-13
decided to emit warnings (which seem incorrect in general and are
irrelevant in this case anyway). Instead of patching this up and
diverge from upstream, we can avoid reports about compiler warnings
by simply not depending on this function.
Rework the caching of notBefore and notAfter by replacing timegm(3)
with asn1_time_tm_to_time_t(3). Also make this API properly error
checkable since at the time x509v3_cache_extensions(3) is called,
nothing is known about the cert, in particular not whether it isn't
malformed one way or the other.
suggested by and ok beck
|
|
|
|
| |
ok tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These 'builder' functions, usually used together, can result in corrupt
ASIdentifiers on failure. In general, no caller should ever try to recover
from OpenSSL API failure. There are simply too many traps. We can still
make an effort to leave the objects in unmodified state on failure. This
is tricky because ownership transfer happens. Unfortunately a really
clean version of this seems impossible, maybe a future iteration will
bring improvements...
The nasty bit here is that the caller of X509v3_asid_add_id_or_range()
can't know from the return value whether ownership of min and max was
transferred or not. An inspection of (*choice)->u.range is required.
If a caller frees min and max after sk_ASIdOrRange_push() failed, there
is a double free.
All these complications could have been avoided if the API interface
had simply used uint32_t instead of ASN1_INTEGERs. The entire RFC 3779
API was clearly written without proper review. I don't know if there
ever was an actual consumer before rpki-client. If it existed, nobody
with the requisite skill set looked at it in depth.
ok beck for the general direction
with a lot of input and ok jsing
|