| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
ASN1_UTCTIME_cmp_tim_t() could be done similarly, but then I have to mess
with LIBRESSL_INTERNAL. Let's do this after unlock.
|
|
|
|
Sprinkle some (static) const and garbage collect an unused struct.
|
|
|
|
ASN1_TIME_compare() compares two times t1 and t2. Due to a copy-paste
error, we would do ASN1_time_parse(t1->data, t2->length, &tm2, t2->type)
Now if t1 is a UTCTime (length 13) and t2 is a GeneralizedTime (length 15),
the worst that could happen is a 2-byte out-of-bounds read. Fortunately, t1
will already have parsed as a UTCTime, so it will have a Z where there
should be the first digit of the seconds for a GeneralizedTime and we will
error out.
Now if both t1 and t2 have the same type, we will parse t1's data twice
and we will return an incorrect comparison. This could have some security
impact if anything relied on this function for security purposes. It is
unused in our tree and unused in our ports tree ports and the only consumer
I could find was some MongoDB things doing OCSP, so this won't be too bad.
Then of course there's also the language bindings.
Issue reported by Duncan Thomson at esri dot com via libressl-security
ok beck deraadt
|
|
We aligned with upstream behavior. Let's document it properly.
Surprisingly, OpenSSL 1.1 half-assed the docs: two parts of the manual
contradict each other. The part getting EVP_CIPHER_CTX_iv_length() right,
incorrectly documents possible -1 return value to EVP_CIPHER_iv_length().
OpenSSL 3 documentation improvement efforts seem to have tried to address
this issue with the result that the manual is now entirely wrong when it
comes to the EVP_CIPHER_CTX_iv_length() replacement. Par for the course.
|
|
crypto(3)
|
|
|
|
Mention sections 2.1.1 and 2.1.2 in STANDARDS
|
|
since it should be a prefix.
|
|
|
|
|
|
|
|
Apparently I should have used 2023 despite sharing versions of these
files with several people under this license (and thus permitting them
to redistribute and share with the public). It makes no sense to me,
but shrug.
|
|
|
|
where that feels potentially confusing,
and add one missing .Pp macro; no change of meaning
|
|
and fix whitespace on one text line; no change of meaning
|
|
and polish one wording; no change of meaning
|
|
that was also followed by a bogus argument,
and fix one grammatical error; no change of meaning
|
|
and capitalize "AFI" where is does not refer to the function argument;
no change of meaning
|
|
and some missing escaping of HYPHEN-MINUS; no text change
|
|
plus some minor markup and punctuation fixes
|
|
|
|
Our checking here was a bit too aggressive, and did not permit an
IP address in a URI. IP's in a URI are allowed for things like CRLdp's
AIA, SAN URI's etc.). The check for this was also slightly flawed as
we would permit an IP if memory allocation failed while checking for
an IP.
Correct both issues.
ok tb@
|
|
|
|
|
|
These were the last four RFC 3779 things that check_complete.pl x509v3
complained about. I will surely tweak and try to improve a few things
in the coming days, but the pages should now be stable enough that
review efforts will likely not be wasted. Any feedback appreciated.
|
|
This is a static pointer, so it ain't ever NULL, but shrug
|
|
|
|
|
