It's a bit of a mess, but BIO-like APIs typically return -1 on error and
0 for EOF.
Change-Id: Ibdcb70e1009ffebf6cc6df40804dc4a178c7199e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48845
Reviewed-by: Adam Langley <agl@google.com>
I noticed this while I was reading through the encoder. OpenSSL's ASN.1
library is very sloppy when it comes to reusing enums. It has...
- Universal tag numbers. These are just tag numbers from ASN.1
- utype. These are used in the ASN1_TYPE type field, as well as the
ASN1_ITEM utype fields They are the same as universal tag numbers,
except non-universal types map to V_ASN1_OTHER. I believe ASN1_TYPE
types and ASN1_ITEM utypes are the same, but I am not positive.
- ASN1_STRING types. These are the same as utypes, except V_ASN1_OTHER
appears to only be possible when embedded inside ASN1_TYPE, and
negative INTEGER and ENUMERATED values get mapped to
V_ASN1_NEG_INTEGER and V_ASN1_NEG_ENUMERATED. Additionally, some
values like V_ASN1_OBJECT are possible in a utype but not possible in
an ASN1_STRING (and will cause lots of problems if ever placed in
one).
- Sometimes one of these enums is augmented with V_ASN1_UNDEF and/or
V_ASN1_APP_CHOOSE for extra behaviors.
- Probably others I'm missing.
These get mixed up all the time. asn1_ex_i2c's MSTRING path converts
from ASN1_STRING type to utype and forgets to normalize V_ASN1_NEG_*.
This means that negative INTEGERs and ENUMERATEDs in MSTRINGs do not get
encoded right.
The negative INTEGER case is unreachable (unless the caller passes
the wrong ASN1_STRING to an MSTRING i2d function, but mismatching i2d
functions generally does wrong things), but the negative ENUMERATED case
is reachable. Fix this and add a test.
Change-Id: I762d482e72ebf03fd64bba291e751ab0b51af2a9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48805
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
In writing the tests, I noticed that the documentation was wrong. First,
the maximum lengths are measured in codepoints, not bytes.
Second, the TODO was wrong. We actually do handle this correctly,
*almost*. Rather, the bug is that the function assumes |mask| contains
no extraneous bits. If it does, all extraneous bits are interpreted as
B_ASN1_UTF8STRING. This seems like a bug, so I've gone ahead and fixed
that, with a test.
Change-Id: I7ba8fa700a8e21e6d25cb7ce879dace685eecf7e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48825
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
ASN1_TFLG_SET_ORDER was used in OpenSSL's CMS and PKCS#7
implementations, which we've removed. Fields that use it not only get
the DER SET sorting but, when serialized, go back and mutate the
original object to match.
This is unused, so remove it. This removes one of the sources of
non-const behavior in i2d functions.
Bug: 407
Change-Id: I6b2bf8d11c30a41b53d14ad475c26a1a30dfd31f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48786
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
ASN1_STRING and ASN1_TYPE type values almost line up, but not quite.
Negative INTEGERs are not possible in X509_NAME (tag2bit maps INTEGER to
0), but negative ENUMERATEDs are (tag2bit maps ENUMERATED to
B_ASN1_UNKNOWN). See https://crbug.com/boringssl/412 for some notes on
this mess. Either way, the library will freely produce ASN1_STRING
INTEGERs and ENUMERATEDs in non-MSTRING contexts, so get this case
right.
Change-Id: Ica537f4d683e7a6becc96e2eee3cb66e53372124
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48785
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Also use the simpler single-call variant.
Change-Id: I3834a798549f12a9dcdec6a357d2380085baf940
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48777
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
ASN1_STRING_print_ex is extremely complex and attempting to implement
RFC2253, so write some tests for it. Along the way, unexport
CHARTYPE_*, which are internal book-keeping used in
ASN1_STRING_print_ex.
Change-Id: Idb27cd40fb66dc099d1fd6d039a00404608c2063
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48776
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
For some reason, ASN1_STRING_print was not in the same file as
ASN1_STRING_print_ex, but X509_print. Although it also behaves very
differently from ASN1_STRING_print_ex, so that's a little interesting.
Change-Id: I3f88f8943c8e36426eedafa7e350a787881d0c74
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48775
Reviewed-by: Adam Langley <agl@google.com>
With io_ch unwound, X509_NAME_print_ex just calls ASN1_STRING_print_ex,
so we can put all the code in the right directories. We need to
duplicate maybe_write, but it's a one-line function.
Change-Id: Ifaa9f1a24ee609cbaa24f93eb992f7d911f1b4a0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48774
Reviewed-by: Adam Langley <agl@google.com>
No sense in implementing a BIO/FILE abstraction when BIO is itself a
FILE abstraction. Follow-up CLs will unwind the char_io abstraction and
then split the ASN1 and X509 bits of this file.
Change-Id: I00aaf2fbab44abdd88252ceb5feb071ad126a0b2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48772
Reviewed-by: Adam Langley <agl@google.com>
We've never tested this and plenty of files depend on FILE* APIs without
ifdefs.
Change-Id: I8c51c043e068b30bdde1723c3810d3e890eabfca
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48771
Reviewed-by: Adam Langley <agl@google.com>
This matches OpenSSL and the name. Also accessors like X509_ALGOR_get0
are in x509.h.
Change-Id: Ic7583edcf04627cbfae822df11e75eebdd9ad7aa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48770
Reviewed-by: Adam Langley <agl@google.com>
These constants aren't suitably namespaced and, moreover, are redefined
in a_strnid.c. (The constants aren't especially useful because an
X509_NAME doesn't check the upper bound.)
Update-Note: Removed some unnamespaced constants.
Change-Id: I7d15ae731628d3665119081289947600e7f38065
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48768
Reviewed-by: Adam Langley <agl@google.com>
ASN1_STRING_set_by_NID is very complex and depends on a "global mask"
for most NIDs. (Some NIDs use a single type and use STABLE_NO_MASK to
disable the global mask.) Historically, it defaulted to allowing all
types, but it switched to UTF8String in OpenSSL 1.0.2.
Updating the global mask is not thread-safe, and it's 2021. Let's just
always use UTF-8. The only callers I found set it to UTF-8 anyway (with
the exception of some test script we don't use, and some code that
wasn't compiled). No-op writes in the C/C++ memory model are still race
conditions, so this CL fixes some bugs in those callers.
Update-Note: The global mask for ASN1_STRING_set_by_NID is now always
UTF-8. Callers that want another type should reconsider and, if UTF-8 is
still unsuitable, just pass the actual desired type into
ASN1_mbstring_copy, X509_NAME_ENTRY_set_data, etc
Change-Id: I679e99c57da9a48c805460abcb3af5b2f938c93f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48766
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This syncs this file up to e7ff223a20697e5a401d2d9bb7a75e699ed46633 from
upstream's OpenSSL_1_1_1-stable branch. The main change of note is the
4x loop from upstream's 7ff2fa4b9281232f0ca1db03d42a954c462ef77d,
9ee020f8dc7813db82a119058d8f57e70e7e8904,
aa7bf316980259a11dcbaf6128ed86d33dc24b97, and
603ebe03529101424670051aa0c616dc6e037b28.
Benchmarks on a Pixel 4a.
Before:
Did 14069000 AES-128-GCM (16 bytes) seal operations in 2000042us (112.5 MB/sec)
Did 6768000 AES-128-GCM (256 bytes) seal operations in 2000182us (866.2 MB/sec)
Did 1902000 AES-128-GCM (1350 bytes) seal operations in 2000479us (1283.5 MB/sec)
Did 359000 AES-128-GCM (8192 bytes) seal operations in 2003942us (1467.6 MB/sec)
Did 182000 AES-128-GCM (16384 bytes) seal operations in 2002245us (1489.3 MB/sec)
Did 13388000 AES-256-GCM (16 bytes) seal operations in 2000144us (107.1 MB/sec)
Did 6069000 AES-256-GCM (256 bytes) seal operations in 2000276us (776.7 MB/sec)
Did 1638000 AES-256-GCM (1350 bytes) seal operations in 2001076us (1105.1 MB/sec)
Did 305000 AES-256-GCM (8192 bytes) seal operations in 2000040us (1249.3 MB/sec)
Did 155000 AES-256-GCM (16384 bytes) seal operations in 2009398us (1263.8 MB/sec)
After:
Did 13837000 AES-128-GCM (16 bytes) seal operations in 2000131us (110.7 MB/sec) [-1.7%]
Did 7506000 AES-128-GCM (256 bytes) seal operations in 2000197us (960.7 MB/sec) [+10.9%]
Did 2289000 AES-128-GCM (1350 bytes) seal operations in 2000734us (1544.5 MB/sec) [+20.3%]
Did 443000 AES-128-GCM (8192 bytes) seal operations in 2000321us (1814.2 MB/sec) [+23.6%]
Did 225000 AES-128-GCM (16384 bytes) seal operations in 2002308us (1841.1 MB/sec) [+23.6%]
Did 13280000 AES-256-GCM (16 bytes) seal operations in 2000011us (106.2 MB/sec) [-0.8%]
Did 6630000 AES-256-GCM (256 bytes) seal operations in 2000229us (848.5 MB/sec) [+9.2%]
Did 1916000 AES-256-GCM (1350 bytes) seal operations in 2000373us (1293.1 MB/sec) [+17.0%]
Did 365000 AES-256-GCM (8192 bytes) seal operations in 2001519us (1493.9 MB/sec) [+19.6%]
Did 185000 AES-256-GCM (16384 bytes) seal operations in 2006588us (1510.5 MB/sec) [+19.5%]
(See cl/387919990 for some notes I made in reviewing, though likely
future me will find them incomprehensible anyway.)
Change-Id: Id386e80143611487e07b2fbfda15d0abc54ea145
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48726
Reviewed-by: Adam Langley <agl@google.com>
CMake's language is rather fragile and unsound. For the most part, it is
a shell script with more parentheses. That is, it simply expands command
arguments into a list of strings and then evaluates it, complete with
shell-style differences between "${FOO}" and ${FOO}.
The if() command is special and internally also expands variables. That
is why things like if(FOO STREQUAL "BAR") work. CMake interprets "FOO"
as a variable if it can find a variable, or a string otherwise. In
addition to getting very confused on typos, it means that
if("${FOO}" STREQUAL "BAR") will double-expand, and it will do strange
things if BAR is a variable.
CMP0054 patches this (which we set by minimum version) so that if() only
expands if the token was unquoted. This fixes
if("${FOO}" STREQUAL "BAR"). However, if(${FOO} STREQUAL "BAR")
continues to double-expand FOO.
We had a mix of all three of FOO, ${FOO}, and "${FOO}". It's not clear
which is the canonical spelling at this point, but CMake own files
(mostly) use FOO, as do most of our lines, so I've standardized on that.
It's a little unsatisfying if we typo a variable, but I suppose ${FOO}
also silently ignores unset variables.
Bug: 423
Change-Id: Ib6baa27f4065eed159e8fb28820b71a0c99e0db0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48705
Reviewed-by: Adam Langley <agl@google.com>
They would previously output syntax errors.
Change-Id: I7817a91d0c8ed8d6ac6a5a1fd9c9ed1223c5960e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48667
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This flag is set when an ASN1_STRING is created from a codepath that is
aware it is an "mstring" (CHOICE of multiple string or string-like
types). With setters like X509_set_notBefore, it is very easy to
accidentally lose the flag on some field that normally has it.
The only place the flag is checked is X509_time_adj_ex. X509_time_adj_ex
usually transparently picks UTCTime vs GeneralizedTime, as in the X.509
CHOICE type. But if writing to an existing object AND if the object
lacks the flag, it will lock to whichever type the object was
previously. It is likely any caller hitting this codepath is doing so
unintentionally and has a latent bug that won't trip until 2050.
In fact, one of the ways callers might accidentally lose the
ASN1_STRING_FLAG_MSTRING flag is by using X509_time_adj_ex!
X509_time_adj_ex(NULL) does not use an mstring-aware constructor. This
CL avoids needing such a notion in the first place.
Looking through callers, the one place that wants the old behavior is a
call site within OpenSSL, to set the producedAt field in OCSP. That
field is a GeneralizedTime, rather than a UTCTime/GeneralizedTime
CHOICE. We dropped that code, but I'm making a note of it to remember
when filing upstream.
Update-Note: ASN1_STRING_FLAG_MSTRING is no longer defined and
X509_time_adj_ex now behaves more predictably. Callers that actually
wanted to lock to a specific type should call ASN1_UTCTIME_adj or
ASN1_GENERALIZEDTIME_adj instead.
Change-Id: Ib9e1c9dbd0c694e1e69f938da3992d1ffc9bd060
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48668
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This covers most of the ASN.1 time functions and a handful more of
x509.h. Also remove some code under #if 0.
I'm running out of a easy ones to do, which is probably a good thing.
Change-Id: I085b1e2a54d191a7a5f18c801b3c135cfda7bd88
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48665
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
It is not obvious from "It does not take ownership of |buf|" whether the
function makes a copy or not. It does not make a copy (maybe it
should...), so callers are obligated to manage their lifetimes.
Change-Id: I7df9a5814321fd833fcb8d009d9e0318d6668dd4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48669
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I04c8bb68801aeb0938e5b038b98811ca4ffe50f0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48685
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The polynomials have 701, 16-bit values. But poly_Rq_mul was reading 32
bytes at offset 1384 in order to get the last 18 of them. This silently
worked for a long time, but when 7153013019 switched to keeping
variables on the stack it was noticed by Valgrind.
This change fixes the overread. Setting watchpoints at the ends of the
two inputs (and one output) now shows no overreads nor overwrites.
BUG=424
Change-Id: Id86c1407ffce66593541c10feee47213f4b95c5d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48645
Reviewed-by: David Benjamin <davidben@google.com>
Some JSON files have a header, but without a URL. Thus consider a block
that doesn't contain an algorithm to also be a header.
Change-Id: Ic35a827843e9d0169ba8398df69c46a5baeffb44
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48605
Reviewed-by: David Benjamin <davidben@google.com>
This reverts commit be9a86f459. Let's try
this again.
Bug: 375
Change-Id: Ie01cced8017835b2cc6d80e5e81a4508a37fbbaf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48625
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The tool generates three files: an ECHConfig, its corresponding private
key, and the ECHConfig wrapped in an ECHConfigList.
For example, the following invocation generates the files:
bssl generate-ech \
-out-ech-config-list ech_config_list.data \
-out-ech-config ech_config.data \
-out-private-key ech.key \
-public-name foo.example \
-config-id 0
Now, we can pass the ECHConfig and private key into the 'server' and
'client' commands:
bssl server -accept 4430 \
-ech-config ech_config.data \
-ech-key ech.key
bssl client -connect localhost:4430 \
-ech-config-list ech_config_list.data
Bug: 275
Change-Id: Id4342855483fb01aa956f9aff356105c4a8ca4f6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48466
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
In configurations without threads, we're not thread-safe anyway. Instead
use the refcount_lock.c implementation which, in turn, calls into
thread_none.c, so this turns into a plain refcount.
This avoids a build issue on platforms which define NO_THREADS, use C11,
lack C11 atomics, and are missing a __STDC_NO_ATOMICS__ definition. The
platforms ought to define __STDC_NO_ATOMICS__ or implement them, but
atomics are also unnecessary overheard in NO_THREADS configurations
anyway.
Change-Id: I927e1825dd6474d95226b93dad704594f120450a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48565
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Currently, GetUnsigned() calls strtoul and checks whether the resulting
unsigned long int is greater than UINT_MAX. This implicitly assumes that
UINT_MAX < ULONG_MAX.
Problematically, `unsigned long int` and `unsigned` have the same size
on Windows [0] and on 32-bit architectures.
For correctness, we now check whether strtoul failed because it would
overflow the unsigned long int before checking whether the value fits in
an unsigned type.
[0]: https://docs.microsoft.com/en-us/cpp/cpp/data-type-ranges?view=msvc-160
Change-Id: I49702febf4543bfb7991592717443e0b2adb954f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48545
Commit-Queue: Dan McArdle <dmcardle@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Some callers want the value to be heap-allocated. It's a little annoying
that this returns an empty value (if we only supported heap-allocated
ones, I'd have merged init into new), but since we have multiple
constructor functions, this is probably the least fuss.
Change-Id: I42f586e39850954fb6743f8be50a7cfffa0755ba
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48526
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Trusty wants to seed from a different RNG than the one that supplies
per-draw entropy. This is a no-op change unless you're substituting in
your own implementations of these functions.
To see that it's a no-op in urandom.c, note that it only changes the
|seed| argument to |fill_with_entropy|. That causes the value of
|extra_getrandom_flags_for_seed_bss_get| to be ORed into the flags,
but that value will always be zero unless it's an Android FIPS build.
Change-Id: Ic8d954df3074559cbf1bfee1ae91a4a2b7e14d9d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48485
Reviewed-by: David Benjamin <davidben@google.com>
The stack consumption of the HRSS functions is causing issues in
stack-constrained environments. Therefore allocate many variables on the
heap. This means that several HRSS_ functions now allocate, and thus can
fail, where they couldn't before. Callers that ignore the return value
and don't have crash-on-failure mallocs will still be safe, although
things will fail to decrypt later on.
Somehow, this actually makes key generation _faster_ on my machine. (I
don't know. Better alignment? Fewer L1 collisions?) The other operations
are slightly slower, as expected.
Before:
Did 17390 HRSS generate operations in 3054088us (5694.0 ops/sec)
Did 225000 HRSS encap operations in 3000512us (74987.2 ops/sec)
Did 87000 HRSS decap operations in 3014525us (28860.3 ops/sec)
After:
Did 21300 HRSS generate operations in 3026637us (7037.5 ops/sec)
Did 221000 HRSS encap operations in 3008911us (73448.5 ops/sec)
Did 84000 HRSS decap operations in 3007622us (27929.0 ops/sec)
Change-Id: I2312df8909af7d8d250c7c483c65038123f21ad9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48345
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
I've switched a few things to the accessors where it was easy, but
X509_EXTENSION is, in us and upstream, not const-correct right now, so
it's a little goofy.
Update-Note: Use X509_EXTENSION_get_* instead.
Change-Id: Ife9636051a924a950b1c739b7720baf12e35f9c7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48505
Reviewed-by: Adam Langley <agl@google.com>
Also use a slightly more conservative pattern. Instead of aligning the
pointer as a uintptr_t and casting back, compute the offset and advance
in pointer space. C guarantees that casting from pointer to uintptr_t
and back gives the same pointer, but general integer-to-pointer
conversions are generally implementation-defined. GCC does define it in
the useful way, but this makes fewer dependencies.
Change-Id: I70c7af735e892fe7a8333b78b39d7b1f3f1cdbef
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48405
Reviewed-by: Adam Langley <alangley@gmail.com>
This is not used anywhere inside or outside the library.
Update-Note: Removed unused field in struct.
Change-Id: I244d8af819e84412956fecb929678404fdfcc38f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48427
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
See also f8fc0e35e0b1813af15887d42e17b7d5537bb86c from upstream, though
our BN_divs have diverged slightly.
Change-Id: I49fa4f0a5c730d34e6f41f724f1afe3685470712
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48426
Reviewed-by: Adam Langley <agl@google.com>
Found by OSS-Fuzz. This comes up if you enable client certificates and
the draft ECH implementation on the server.
Bug: 275, oss-fuzz:35815
Change-Id: I0b4fcc994f7238f8a3cf1f1934672bac0cee0cfb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48425
Reviewed-by: Adam Langley <agl@google.com>
X509*_get_*_by_NID return -1 if the extension was not found, but -2 if
the NID was invalid. Looking through callers, many check index != -1,
rather than index < 0. That means, in theory, they'll do the wrong thing
in some cases.
Realistically, this case is impossible: most callers pass in a constant.
Even in those that don't, NIDs are a local enum, not standard constants.
That means hitting this path is almost certainly a programmer error. No
need to complicate the calling convention for it.
Update-Note: The return value convention of some functions was
simplified. This is not expected to affect any callers.
Change-Id: If2f5a45c37caccdbfcc3296ff2db6db1183e3a95
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48368
Reviewed-by: Adam Langley <agl@google.com>
This function's behavior differs from all the other lastpos functions.
It does not appear to be used anywhere, so remove it. (lastpos = -1
returns the first match, lastpos = -2 additionally fails if there are
duplicates, lastpos = -3 additionally fails if the attribute is
multiply-valued.)
Update-Note: X509at_get0_data_by_OBJ is removed. We found no callers of
this function.
Change-Id: I8547bac6626623e43827e2490f04850eb148e317
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48367
Reviewed-by: Adam Langley <agl@google.com>
The comments say that this should work, but it didn't. OpenSSL doesn't
have any documentation about this but from looking at the code it works
there. (Along with things like magic sections called “ENV” to get
environment variables, sigh.)
Change-Id: I538fbad57e6af37eee739de6d2643f554bfc5c79
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48386
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
lh_strhash mapped nullptr to zero. ec8c67dfbc switched CONF's use to
OPENSSL_strhash, which crashes on nullptr. But CONF depends on the
nullptr handling.
Change-Id: I131c752aa089fb99b01c9e406b6994f3a6236976
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48385
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
EVP_MD_nid, in OpenSSL, is the same as EVP_MD_type. EVP_MD_type seems to
be the preferred spelling, so put EVP_MD_nid in the deprecated bucket.
Also add an EVP_MD_do_all alias to EVP_MD_do_all_sorted.
Change-Id: I4e7b800902459ac5cb9ef0df65d73da94afdf927
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48365
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin
Adam Langley
Dan McArdle