ASN1_ENCODING has a 'modified' bit, but every time it is set, the
contents are both ignored and never filled in again (we don't fill in
the encoding except on parse). That means keeping the underlying buffer
around is just wasting memory. Remove the bit and use the len != 0 to
determine if there's a saved encoding. Replace all the modified bits
with a helper function that drops the encoding.
I don't think we need a separate "present" boolean and can just treat
empty as not saved; a cached value always has a tag and length, so it
cannot be empty. (Even if it could be empty, that would imply the
value's encoding is trivial enough that we probably don't need the saved
encoding to preserve the value.)
Change-Id: I6beda94d33f3799daf85f1397818b9a41e7dd18a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55267
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We didn't actually have a test that would have caught
https://github.com/openssl/openssl/issues/19388. This fixes this by
further generalizing the signing tests to run through all combinations
of {new object, reused object} x {X509_sign, X509_set_signature_value}.
In doing so, align X509_REQ_sign and X509_REQ_sign_ctx, which were
missing the TBS invalidation.
Change-Id: I5028aa2a00e71da0ebc7a03b23823b1337a56fca
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54726
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
There's a lot of these, so toss them into a corner somewhere.
I've added a note to note to discourage using them with memory BIOs.
Memory BIOs are, by far, the most common use I've seen for i2d_*_bio and
d2i_*_bio. It works, but it's unnecessary.
Bug: 426
Change-Id: I8645207a4ac9f1223d0739b5351c99a55400195f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53331
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This CL runs the same command as in the preceding CL, but with
'IncludeBraces: true' added to .clang-format. I've split this out
separately because the documentation says:
> Setting this option to true could lead to incorrect code formatting
> due to clang-format’s lack of complete semantic information. As such,
> extra care should be taken to review code changes made by this option.
I've also kept InsertBraces out of .clang-format for now because it's a
fairly recent option, and clang-format fails when it sees unrecognized
options.
Change-Id: I305ea7bb2633704053a1f8de1e11b037b9fc8a76
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53086
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Previously, we did not clang-format a few directories because we had
left them largely untouched. clang-format them now so we're finally more
uniform.
This CL is the result of the following commands:
for d in asn1 x509 x509v3 pem; do
clang-format -i crypto/$d/*.h
clang-format -i crypto/$d/*.c
done
(Written in this funny way because crypto/pem/*.h doesn't match
anything.)
Change-Id: I7f4ca9b3a9c8f07d6556e00e9e84b3c0880ee12e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53085
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@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>
We can unexport the X509_REQ_INFO type entirely. (NB: OpenSSL hasn't
done this, but has unexported so much of X509_REQ_INFO that it is
impossible to use what remains anyway.)
Update-Note: Callers that reach into X509_REQ and X509_REQ_INFO must use
accessors instead.
Change-Id: I1eea5207b9195c8051d5e467acd63ad5f0caf89d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47564
Reviewed-by: Adam Langley <agl@google.com>