Mirror of BoringSSL (grpc依赖) https://boringssl.googlesource.com/boringssl
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

146 lines
5.5 KiB

/* v3_bitst.c */
/*
* Written by Dr Stephen N Henson (steve@openssl.org) for the OpenSSL project
* 1999.
*/
/* ====================================================================
* Copyright (c) 1999 The OpenSSL Project. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. All advertising materials mentioning features or use of this
* software must display the following acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
*
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
* endorse or promote products derived from this software without
* prior written permission. For written permission, please contact
* licensing@OpenSSL.org.
*
* 5. Products derived from this software may not be called "OpenSSL"
* nor may "OpenSSL" appear in their names without prior written
* permission of the OpenSSL Project.
*
* 6. Redistributions of any form whatsoever must retain the following
* acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
*
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
* ====================================================================
*
* This product includes cryptographic software written by Eric Young
* (eay@cryptsoft.com). This product includes software written by Tim
* Hudson (tjh@cryptsoft.com). */
#include <stdio.h>
#include <string.h>
#include <openssl/conf.h>
#include <openssl/err.h>
#include <openssl/obj.h>
#include <openssl/x509v3.h>
#include "internal.h"
static const BIT_STRING_BITNAME ns_cert_type_table[] = {
{0, "SSL Client", "client"},
{1, "SSL Server", "server"},
{2, "S/MIME", "email"},
{3, "Object Signing", "objsign"},
{4, "Unused", "reserved"},
{5, "SSL CA", "sslCA"},
{6, "S/MIME CA", "emailCA"},
{7, "Object Signing CA", "objCA"},
{-1, NULL, NULL}};
static const BIT_STRING_BITNAME key_usage_type_table[] = {
{0, "Digital Signature", "digitalSignature"},
{1, "Non Repudiation", "nonRepudiation"},
{2, "Key Encipherment", "keyEncipherment"},
{3, "Data Encipherment", "dataEncipherment"},
{4, "Key Agreement", "keyAgreement"},
{5, "Certificate Sign", "keyCertSign"},
{6, "CRL Sign", "cRLSign"},
{7, "Encipher Only", "encipherOnly"},
{8, "Decipher Only", "decipherOnly"},
{-1, NULL, NULL}};
Use the correct function types in X509V3_EXT_METHODs. While C allows function pointer casts, it is UB to call a function with a different type than its actual type signature. That is, even though `void f(int *)` and `void g(void *)` have the same ABI, it is UB to cast `f` to a `void(*)(void *)` and then call it through that pointer. Clang CFI will try to enforce this rule. The recent CL to call X509_print in tests revealed that all the i2? and ?2i callbacks in X509V3_EXT_METHODs were implemented with functions of the wrong type, out of some combination of missing consts and void* turned into T*. This CL fixes this. Where the function wasn't exported, or had no callers, I just fixed the function itself. Where it had extension callers, I added a wrapper function with a void* type. I'm not positive whether the wrappers are the right call. On the one hand, keeping the exported functions as-is is more type-safe and more OpenSSL-compatible. However, most (but not all) uses of these are in other code defining X509V3_EXT_METHODs themselves, so the void* signature is more correct for them too. And the functions have a type signature meant for X509V3_EXT_METHOD, complete with method pointer. I've gone with leaving the exported ones as-is for now. Probably the right answer anyway is to migrate the external callers, of either type signature. Change-Id: Ib8f2995cbd890221eaa9ac864a7e553cb6711901 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52686 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com>
3 years ago
static STACK_OF(CONF_VALUE) *i2v_ASN1_BIT_STRING(
const X509V3_EXT_METHOD *method, void *ext, STACK_OF(CONF_VALUE) *ret) {
const ASN1_BIT_STRING *bits = ext;
const BIT_STRING_BITNAME *bnam;
for (bnam = method->usr_data; bnam->lname; bnam++) {
if (ASN1_BIT_STRING_get_bit(bits, bnam->bitnum)) {
X509V3_add_value(bnam->lname, NULL, &ret);
}
}
return ret;
}
Use the correct function types in X509V3_EXT_METHODs. While C allows function pointer casts, it is UB to call a function with a different type than its actual type signature. That is, even though `void f(int *)` and `void g(void *)` have the same ABI, it is UB to cast `f` to a `void(*)(void *)` and then call it through that pointer. Clang CFI will try to enforce this rule. The recent CL to call X509_print in tests revealed that all the i2? and ?2i callbacks in X509V3_EXT_METHODs were implemented with functions of the wrong type, out of some combination of missing consts and void* turned into T*. This CL fixes this. Where the function wasn't exported, or had no callers, I just fixed the function itself. Where it had extension callers, I added a wrapper function with a void* type. I'm not positive whether the wrappers are the right call. On the one hand, keeping the exported functions as-is is more type-safe and more OpenSSL-compatible. However, most (but not all) uses of these are in other code defining X509V3_EXT_METHODs themselves, so the void* signature is more correct for them too. And the functions have a type signature meant for X509V3_EXT_METHOD, complete with method pointer. I've gone with leaving the exported ones as-is for now. Probably the right answer anyway is to migrate the external callers, of either type signature. Change-Id: Ib8f2995cbd890221eaa9ac864a7e553cb6711901 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52686 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com>
3 years ago
static void *v2i_ASN1_BIT_STRING(const X509V3_EXT_METHOD *method,
X509V3_CTX *ctx, STACK_OF(CONF_VALUE) *nval) {
CONF_VALUE *val;
ASN1_BIT_STRING *bs;
size_t i;
const BIT_STRING_BITNAME *bnam;
if (!(bs = ASN1_BIT_STRING_new())) {
OPENSSL_PUT_ERROR(X509V3, ERR_R_MALLOC_FAILURE);
return NULL;
}
for (i = 0; i < sk_CONF_VALUE_num(nval); i++) {
val = sk_CONF_VALUE_value(nval, i);
for (bnam = method->usr_data; bnam->lname; bnam++) {
if (!strcmp(bnam->sname, val->name) || !strcmp(bnam->lname, val->name)) {
if (!ASN1_BIT_STRING_set_bit(bs, bnam->bitnum, 1)) {
OPENSSL_PUT_ERROR(X509V3, ERR_R_MALLOC_FAILURE);
ASN1_BIT_STRING_free(bs);
return NULL;
}
break;
}
}
if (!bnam->lname) {
OPENSSL_PUT_ERROR(X509V3, X509V3_R_UNKNOWN_BIT_STRING_ARGUMENT);
X509V3_conf_err(val);
ASN1_BIT_STRING_free(bs);
return NULL;
}
}
return bs;
}
Use the correct function types in X509V3_EXT_METHODs. While C allows function pointer casts, it is UB to call a function with a different type than its actual type signature. That is, even though `void f(int *)` and `void g(void *)` have the same ABI, it is UB to cast `f` to a `void(*)(void *)` and then call it through that pointer. Clang CFI will try to enforce this rule. The recent CL to call X509_print in tests revealed that all the i2? and ?2i callbacks in X509V3_EXT_METHODs were implemented with functions of the wrong type, out of some combination of missing consts and void* turned into T*. This CL fixes this. Where the function wasn't exported, or had no callers, I just fixed the function itself. Where it had extension callers, I added a wrapper function with a void* type. I'm not positive whether the wrappers are the right call. On the one hand, keeping the exported functions as-is is more type-safe and more OpenSSL-compatible. However, most (but not all) uses of these are in other code defining X509V3_EXT_METHODs themselves, so the void* signature is more correct for them too. And the functions have a type signature meant for X509V3_EXT_METHOD, complete with method pointer. I've gone with leaving the exported ones as-is for now. Probably the right answer anyway is to migrate the external callers, of either type signature. Change-Id: Ib8f2995cbd890221eaa9ac864a7e553cb6711901 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52686 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com>
3 years ago
#define EXT_BITSTRING(nid, table) \
{ \
nid, 0, ASN1_ITEM_ref(ASN1_BIT_STRING), 0, 0, 0, 0, 0, 0, \
i2v_ASN1_BIT_STRING, v2i_ASN1_BIT_STRING, NULL, NULL, (void *)(table) \
}
const X509V3_EXT_METHOD v3_nscert =
EXT_BITSTRING(NID_netscape_cert_type, ns_cert_type_table);
Use the correct function types in X509V3_EXT_METHODs. While C allows function pointer casts, it is UB to call a function with a different type than its actual type signature. That is, even though `void f(int *)` and `void g(void *)` have the same ABI, it is UB to cast `f` to a `void(*)(void *)` and then call it through that pointer. Clang CFI will try to enforce this rule. The recent CL to call X509_print in tests revealed that all the i2? and ?2i callbacks in X509V3_EXT_METHODs were implemented with functions of the wrong type, out of some combination of missing consts and void* turned into T*. This CL fixes this. Where the function wasn't exported, or had no callers, I just fixed the function itself. Where it had extension callers, I added a wrapper function with a void* type. I'm not positive whether the wrappers are the right call. On the one hand, keeping the exported functions as-is is more type-safe and more OpenSSL-compatible. However, most (but not all) uses of these are in other code defining X509V3_EXT_METHODs themselves, so the void* signature is more correct for them too. And the functions have a type signature meant for X509V3_EXT_METHOD, complete with method pointer. I've gone with leaving the exported ones as-is for now. Probably the right answer anyway is to migrate the external callers, of either type signature. Change-Id: Ib8f2995cbd890221eaa9ac864a7e553cb6711901 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52686 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com>
3 years ago
const X509V3_EXT_METHOD v3_key_usage =
EXT_BITSTRING(NID_key_usage, key_usage_type_table);