[openssl.org #1819] Calls to OBJ_txt2nid for a non-registered objects adds bogus first num too large errors from a2d_ASN1_OBJECT
This is a resubmission of the redhat bugzilla report https://bugzilla.redhat.com/show_bug.cgi?id=479767 to upstream developers. Description of problem: Calls to OBJ_txt2nid for a non-registered objects adds bogus first num too large errors from a2d_ASN1_OBJECT. Version-Release number of selected component (if applicable): 0.9.8b-14.fc6 0.9.8b-15.fc7 0.9.8b-17.fc8 0.9.8g-9.12.fc9 0.9.8g-12.fc10 0.9.8b-8.3.el5 How reproducible: Always Steps to Reproduce: 1. Compile and run the attached test as follows 2. g++ -o openssltest openssltest.cpp -lssl 3. ./openssltest Actual results: OBJ_txt2nid: 17 OBJ_txt2nid: 0 first num too large a2d_ASN1_OBJECT Expected results: OBJ_txt2nid: 17 OBJ_txt2nid: 0 Additional info: These versions do not have this issue: 0.9.7a-20.6.legacy (RH9) 0.9.7a-33.13.legacy (FC1) 0.9.7a-35.2.legacy (FC2) 0.9.7a-42.2 (FC3) 0.9.7f-7.10 (FC4) 0.9.8a-5.4 (FC5) 0.9.7a-33.23 (RHEL3) 0.9.7a-43.17.el4_6.1 It looks like the problems was introduced when transitioning from 0.9.8a to 0.9.8b. (See the attachment to the redhat bugzilla report for the test program) Compiling the test program against the 0.9.8j version compiled from the source tarball shows the same issue. smime.p7s Description: S/MIME cryptographic signature
[openssl.org #2123] Buggy openssl header causes compilation errors
Created from downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=543634 Description of problem: The openssl/asn1.h header file is buggy. For a C program this causes compiler warnings. For a C++ program this causes compiler errors, because C++ is a strongly typed language. Version-Release number of selected component (if applicable): openssl-devel-1.0.0-0.13.beta4.fc12.x86_64 How reproducible: Always. Steps to Reproduce: 1. Compile the attatched test program: https://bugzilla.redhat.com/attachment.cgi?id=375537 Actual results: 2. With gcc it compiles but gives warnings: [ell...@localhost ~]$ LANG=C gcc -o test test.c -lssl test.c: In function 'main': test.c:12: warning: passing argument 1 of 'i2d_ASN1_SET' from incompatible pointer type /usr/include/openssl/asn1.h:894: note: expected 'struct stack_st_OPENSSL_BLOCK *' but argument is of type 'struct _STACK *' test.c:14: warning: passing argument 1 of 'i2d_ASN1_SET' from incompatible pointer type /usr/include/openssl/asn1.h:894: note: expected 'struct stack_st_OPENSSL_BLOCK *' but argument is of type 'struct _STACK *' 3. With g++ it fails to compile, because the type mismatches are considered errors: [ell...@localhost ~]$ LANG=C g++ -o test test.c -lssl test.c: In function 'int main()': test.c:12: error: cannot convert '_STACK*' to 'stack_st_OPENSSL_BLOCK*' for argument '1' to 'int i2d_ASN1_SET(stack_st_OPENSSL_BLOCK*, unsigned char**, int (*)(void*, unsigned char**), int, int, int)' test.c:14: error: cannot convert '_STACK*' to 'stack_st_OPENSSL_BLOCK*' for argument '1' to 'int i2d_ASN1_SET(stack_st_OPENSSL_BLOCK*, unsigned char**, int (*)(void*, unsigned char**), int, int, int)' Expected results: No warnings in C, working compilation in C++. Additional info: There are 4 macros in openssl/asn1.h which are defined using STACK_OF(OPENSSL_BLOCK). However, by the time theses macros are being resolved all the arguments have been put through the CHECKED_xxx macros and been anonymized and are simply _STACK pointers. The 4 macros are: i2d_ASN1_SET, d2i_ASN1_SET, ASN1_seq_unpack, and ASN1_seq_pack. This is a rather clumsy workaround for the bug: https://bugzilla.redhat.com/attachment.cgi?id=375568 This compiles without warnings/error for C and C++: [ell...@localhost ~]$ gcc -o test test-wo.c -lssl [ell...@localhost ~]$ g++ -o test test-wo.c -lssl [ell...@localhost ~]$ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2278] Incomplete fix for type-checking/casting issue
The following commit fixes an type checking/casting issue in the SKM_ASN1_SET_OF_i2d macro http://cvs.openssl.org/filediff?f=openssl/crypto/stack/safestack.hv1=1.72.2.5v2=1.72.2.6 However, the SKM_ASN1_SET_OF_d2i needs a similar fix too: $ diff -u openssl/safestack.h.orig openssl/safestack.h --- openssl/safestack.h.orig2010-05-18 18:12:20.0 +0200 +++ openssl/safestack.h 2010-05-27 08:31:56.905596266 +0200 @@ -179,7 +179,7 @@ sk_is_sorted(CHECKED_STACK_OF(type, st)) #defineSKM_ASN1_SET_OF_d2i(type, st, pp, length, d2i_func, free_func, ex_tag, ex_class) \ - (STACK_OF(type) *)d2i_ASN1_SET(CHECKED_STACK_OF(type, st), \ + (STACK_OF(type) *)d2i_ASN1_SET((STACK_OF(OPENSSL_BLOCK) **)CHECKED_STACK_OF(type, st), \ pp, length, \ CHECKED_D2I_OF(type, d2i_func), \ CHECKED_SK_FREE_FUNC(type, free_func), \ --- openssl/safestack.h.orig 2010-05-18 18:12:20.0 +0200 +++ openssl/safestack.h 2010-05-27 08:31:56.905596266 +0200 @@ -179,7 +179,7 @@ sk_is_sorted(CHECKED_STACK_OF(type, st)) #define SKM_ASN1_SET_OF_d2i(type, st, pp, length, d2i_func, free_func, ex_tag, ex_class) \ - (STACK_OF(type) *)d2i_ASN1_SET(CHECKED_STACK_OF(type, st), \ + (STACK_OF(type) *)d2i_ASN1_SET((STACK_OF(OPENSSL_BLOCK) **)CHECKED_STACK_OF(type, st), \ pp, length, \ CHECKED_D2I_OF(type, d2i_func), \ CHECKED_SK_FREE_FUNC(type, free_func), \ smime.p7s Description: S/MIME cryptographic signature
[openssl.org #2336] SKM_ASN1_SET_OF_d2i macro is broken
Hi!
The attached test file does not compile:
$ gcc -o test.o -c test.c
test.c: In function 'd2i_X':
test.c:28: warning: pointer type mismatch in conditional expression
The problem can be tracked down to the SKM_ASN1_SET_OF_d2i in
safestack.h. If the macro is changed as in the attached patch the
compilation works.
Mattias
#include openssl/x509.h
#include openssl/asn1_mac.h
#include openssl/err.h
typedef struct X {
STACK_OF(X509_EXTENSION) *ext;
} X;
X *X_new() {
X* ret = NULL;
ASN1_CTX c;
M_ASN1_New_Malloc(ret, X);
M_ASN1_New(ret-ext, sk_X509_EXTENSION_new_null);
return(ret);
M_ASN1_New_Error(5018);
}
void X_free(X *x) {
if (!x) return;
sk_X509_EXTENSION_pop_free(x-ext, X509_EXTENSION_free);
OPENSSL_free(x);
}
X* d2i_X(X **x, const unsigned char **pp, long length) {
M_ASN1_D2I_vars(x, X*, X_new);
M_ASN1_D2I_Init();
M_ASN1_D2I_start_sequence();
M_ASN1_D2I_get_seq_opt_type(X509_EXTENSION, ret-ext, d2i_X509_EXTENSION, X509_EXTENSION_free);
M_ASN1_D2I_Finish(x, X_free, 5019);
}
--- /usr/include/openssl/safestack.h 2010-06-04 16:29:26.0 +0200
+++ include/openssl/safestack.h 2010-09-13 09:04:17.969550072 +0200
@@ -179,7 +179,7 @@
sk_is_sorted(CHECKED_STACK_OF(type, st))
#define SKM_ASN1_SET_OF_d2i(type, st, pp, length, d2i_func, free_func, ex_tag, ex_class) \
- (STACK_OF(type) *)d2i_ASN1_SET((STACK_OF(OPENSSL_BLOCK) **)CHECKED_STACK_OF(type, st), \
+ (STACK_OF(type) *)d2i_ASN1_SET((STACK_OF(OPENSSL_BLOCK) **)CHECKED_PTR_OF(STACK_OF(type)*, st), \
pp, length, \
CHECKED_D2I_OF(type, d2i_func), \
CHECKED_SK_FREE_FUNC(type, free_func), \
smime.p7s
Description: S/MIME cryptographic signature
Re: [openssl.org #2336] AutoReply: SKM_ASN1_SET_OF_d2i macro is broken
This issue is fixed in 1.0.0c: http://cvs.openssl.org/filediff?f=openssl/crypto/stack/safestack.hv1=1.72.2.9v2=1.72.2.10 smime.p7s Description: S/MIME cryptographic signature
Re: [openssl-dev] [openssl.org #4602] Missing accessors
tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT: > On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote: > > > > ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT: > > > > > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote: > > > > > > > > > > > > I guess having a more restrictive accessor that only sets the > > > > EXFLAG_PROXY bit could work. I suggested the more general > > > > solution > > > > of > > > > having set/clear accessors for arbitrary flags since it was - > > > > well > > > > more > > > > general. > > > > > > So let me ask this in a different manner, does OpenSSL 1.1 still > > > not > > > set the > > > EXFLAG_PROXY flag correctly? In what situations does that happen? > > > That may be > > > worth a bug report of its own. > > > > > > -- > > > Richard Levitte > > > levi...@openssl.org > > > > > > > The answer to this is related to Mischa's reply, which > > unfortunately > > was only sent to the Debian BTS and not the the OpenSSL RT. I quote > > it > > below. As indicated in the answer, setting the EXFLAG_PROXY allows > > handling non-RFC proxies in OpenSSL. > > > > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle: > > > > > > Hi Richard, Mattias, others, > > > > > > I agree with you that it would be nice if OpenSSL could figure > > > out > > > itself whether a cert needs to be treated as a proxy, but > > > currently > > > that > > > doesn't work reliably as far as I know. > > > The flag is certainly needed in the case of non-RFC3820 proxies, > > > also > > > known as legacy proxies. Unfortunately these are still very > > > widely > > > used > > > (majority of the proxies actually) and hence our code must be > > > able to > > > handle them correctly. > > > > > > Best wishes, > > > Mischa Sallé > > > > > Ok... From looking at the voms code that was linked to earlier, I can > see that > legacy proxy certs are recognised by an older OID (called > PROXYCERTINFO_V3 in > the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions > in that > version, whether they are critical or not and so on, that I can > reach? Or is > the OID the only actual difference? If it's easy enough (and it > currently does > look quite easy), I can certainly see adding some code in OpenSSL to > recognise > those... > > -- > Richard Levitte > levi...@openssl.org As far as I know there are three different kinds of proxies, usually called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4 respectively. For example see "grid-proxy-init -help": -draftCreates a draft (GSI-3) proxy -old Creates a legacy globus proxy -rfc Creates a RFC 3820 compliant proxy The really tricky one is the old legacy version 2 proxy I think. Mattias -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602 Please log in as guest with password guest if prompted smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4602] Missing accessors
ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT: > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote: > > > > I guess having a more restrictive accessor that only sets the > > EXFLAG_PROXY bit could work. I suggested the more general solution of > > having set/clear accessors for arbitrary flags since it was - well > > more > > general. > > So let me ask this in a different manner, does OpenSSL 1.1 still not set the > EXFLAG_PROXY flag correctly? In what situations does that happen? That may be > worth a bug report of its own. > > -- > Richard Levitte > levi...@openssl.org > The answer to this is related to Mischa's reply, which unfortunately was only sent to the Debian BTS and not the the OpenSSL RT. I quote it below. As indicated in the answer, setting the EXFLAG_PROXY allows handling non-RFC proxies in OpenSSL. mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle: > Hi Richard, Mattias, others, > > I agree with you that it would be nice if OpenSSL could figure out > itself whether a cert needs to be treated as a proxy, but currently that > doesn't work reliably as far as I know. > The flag is certainly needed in the case of non-RFC3820 proxies, also > known as legacy proxies. Unfortunately these are still very widely used > (majority of the proxies actually) and hence our code must be able to > handle them correctly. > > Best wishes, > Mischa Sallé > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602 Please log in as guest with password guest if prompted smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4602] Missing accessors
fre 2016-07-08 klockan 00:42 +0200 skrev Kurt Roeckx:
> On Thu, Jul 07, 2016 at 09:40:24PM +, Richard Levitte via RT
> wrote:
> > On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> > > /* Add to include/openssl/x509v3.h */
> > >
> > > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
> > >
> > >
> > > /* Add to crypto/x509v3/v3_purp.c */
> > >
> > > void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> > > {
> > > x->ex_flags |= ex_flags;
> > > }
> > >
> > > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> > > {
> > > x->ex_flags &= ~ex_flags;
> > > }
> >
> > This gives me the heebie jeebies. ex_flags is used a lot
> > internally, and I
> > can't begin to imagine the consequences of letting external code
> > manipulate
> > this. I understand that in some cases, it seems easy and quick,
> > but...
> >
> > So, if someone else wants to have a go at this and can make
> > something sensible,
> > please be my guest. Me, I'm backing off from this particular idea.
>
> Mattias,
>
> Can you explain why this is needed, what the code is trying to do?
>
>
> Kurt
>
Hi!
The modification of the extension flags happens in at least four
different packages. The modification they do is to add the EXFLAG_PROXY
bit to the flags.
https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L692
https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1665
https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1740
https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1655
https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1719
https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L184
I guess having a more restrictive accessor that only sets the
EXFLAG_PROXY bit could work. I suggested the more general solution of
having set/clear accessors for arbitrary flags since it was - well more
general.
Mattias Ellert
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted
smime.p7s
Description: S/MIME cryptographic signature
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4602] Missing accessors
fre 2016-07-08 klockan 06:08 + skrev Richard Levitte via RT: > On Thu Jul 07 21:29:09 2016, levitte wrote: > > On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote: > > > /* Add to include/openssl/x509_vfy.h : */ > > > > > > typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer, > > > X509_STORE_CTX > > > *ctx, X509 *x); > > > typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx, > > > X509 > > > *x, X509 *issuer); > > > > > > void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx, > > > X509_STORE_CTX_get_issuer > > > get_issuer); > > > X509_STORE_CTX_get_issuer > > > X509_STORE_CTX_get_get_issuer(X509_STORE_CTX > > > *ctx); > > > void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx, > > > X509_STORE_CTX_check_issued > > > check_issued); > > > X509_STORE_CTX_check_issued > > > X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx); > > > > For this part, https://github.com/openssl/openssl/pull/1294 > > So, looking at this again after some sleep, there's a part of this > solution > that I'm unsure of, and it all comes back to X509_STORE_CTX_init(), > where the > X509_STORE context gets initialised from the X509_STORE, including > all the > function pointers. This has me wonder if the X509_STORE_CTX setters > should > really be made available (perhaps with the exception of the verify > and > verify_cb ones). Doesn't it make more sense to set those function > pointers when > creating the X509_STORE itself? Why would those functions need to be > changed in > the context? > > Cheers, > Richard > > -- > Richard Levitte > levi...@openssl.org > Looking at the various places in the code where get_issuer and check_issued are accessed, they mostly use the context rather than the store. Here are the places I have found: https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71 https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581 https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588 https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367 https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059 https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997 And the following one actually uses the store and not the context: https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448 Mattias -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602 Please log in as guest with password guest if prompted smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
