boringssl

172 Commits

61 Branches

23 Tags

511 MiB

Tag: Branch: Tree: a929e32746

Commit Graph

Author	SHA1	Message	Date
David Benjamin	c6ffcde8cd	Unwind M_ASN1_* macros for primitive types. At one point in the SSLeay days, all the ASN1_STRING typedefs were separate structs (but only in debug builds) and the M_ASN1_* macros included type casts to handle this. This is long gone, but we still have the M_ASN1_* macros. Remove the casts and switch code within the library to call the macros. Some subtleties: - The "MSTRING" types (what OpenSSL calls its built-in CHOICEs containing some set of string types) are weird because the M_FOO_new() macro and the tasn_new.c FOO_new() function behave differently. I've split those into a separate CL. - ASN1_STRING_type, etc., call into the macro, which accesses the field directly. This CL inverts the dependency. - ASN1_INTEGER_new and ASN1_INTEGER_free, etc., are generated via IMPLEMENT_ASN1_STRING_FUNCTIONS in tasn_typ.c. I've pointed M_ASN1_INTEGER_new and M_ASN1_INTEGER_free to these fields. (The free function is a no-op, but consistent.) - The other macros like M_ASN1_BIT_STRING_dup largely do not have corresponding functions. I've aligned with OpenSSL in just using the generic ASN1_STRING_dup function. But some others, like M_ASN1_OCTET_STRING_dup have a corresponding ASN1_OCTET_STRING_dup function. OpenSSL retained these, so I have too. Update-Note: Some external code uses the M_ASN1_* macros. This should remain compatible, but some type errors may have gotten through unnoticed. This CL restores type-checking. Change-Id: I8656abc7d0f179192e05a852c97483c021ad9b20 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44045 Reviewed-by: Adam Langley <agl@google.com>	4 years ago
David Benjamin	125a38fad9	Const-correct various X509 functions. Actually making crypto/asn1 and crypto/x509 const-correct will be a tall order, between all the hidden caches, non-const ASN.1 macros, and ambiguity between mutable and immutable getters. But upstream const-corrected a number of things, so align with them. (In particular, it is not currently possible to usefully use a non-const X509_NAME.) I think I've gotten most of x509.h. I started going through x509v3.h, but all the conf bits take non-const char* pointers, which shows up in the public (but probably unused) X509V3_CONF_METHOD, so I've left it alone in this CL. For some reason, OpenSSL made X509_get_subject_name a const-to-non-const function but kept X509_get_serialNumber uniformly non-const while adding a uniformly const X509_get0_serialNumber. I've just mirrored this for compatibility's sake. Change-Id: Ia33a7576165cf2da5922807fc065f1f114b0f84c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42584 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>	5 years ago
Adam Langley	fb0c05cac2	acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>	5 years ago

Author

SHA1

Message

Date

David Benjamin

c6ffcde8cd

Unwind M_ASN1_* macros for primitive types.

At one point in the SSLeay days, all the ASN1_STRING typedefs were
separate structs (but only in debug builds) and the M_ASN1_* macros
included type casts to handle this.

This is long gone, but we still have the M_ASN1_* macros. Remove the
casts and switch code within the library to call the macros. Some
subtleties:

- The "MSTRING" types (what OpenSSL calls its built-in CHOICEs
  containing some set of string types) are weird because the M_FOO_new()
  macro and the tasn_new.c FOO_new() function behave differently. I've
  split those into a separate CL.

- ASN1_STRING_type, etc., call into the macro, which accesses the field
  directly. This CL inverts the dependency.

- ASN1_INTEGER_new and ASN1_INTEGER_free, etc., are generated via
  IMPLEMENT_ASN1_STRING_FUNCTIONS in tasn_typ.c. I've pointed
  M_ASN1_INTEGER_new and M_ASN1_INTEGER_free to these fields. (The free
  function is a no-op, but consistent.)

- The other macros like M_ASN1_BIT_STRING_dup largely do not have
  corresponding functions. I've aligned with OpenSSL in just using the
  generic ASN1_STRING_dup function. But some others, like
  M_ASN1_OCTET_STRING_dup have a corresponding ASN1_OCTET_STRING_dup
  function. OpenSSL retained these, so I have too.

Update-Note: Some external code uses the M_ASN1_* macros. This should
remain compatible, but some type errors may have gotten through
unnoticed. This CL restores type-checking.

Change-Id: I8656abc7d0f179192e05a852c97483c021ad9b20
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44045
Reviewed-by: Adam Langley <agl@google.com>

4 years ago

David Benjamin

125a38fad9

Const-correct various X509 functions.

Actually making crypto/asn1 and crypto/x509 const-correct will be a tall
order, between all the hidden caches, non-const ASN.1 macros, and
ambiguity between mutable and immutable getters. But upstream
const-corrected a number of things, so align with them. (In particular,
it is not currently possible to usefully use a non-const X509_NAME.)

I think I've gotten most of x509.h. I started going through x509v3.h,
but all the conf bits take non-const char* pointers, which shows up in
the public (but probably unused) X509V3_CONF_METHOD, so I've left it
alone in this CL.

For some reason, OpenSSL made X509_get_subject_name a const-to-non-const
function but kept X509_get_serialNumber uniformly non-const while adding
a uniformly const X509_get0_serialNumber. I've just mirrored this for
compatibility's sake.

Change-Id: Ia33a7576165cf2da5922807fc065f1f114b0f84c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42584
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>

5 years ago

Adam Langley

fb0c05cac2

acvp: add CMAC-AES support.

Change by Dan Janni.

Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>

5 years ago

3 Commits (a929e327463bfa71b065111c0245c1599d39f99b)