[openssl.org #1987] Definition of STRING conflicts with ntsecapi.h

[Charlie Savage via RT]

 From safestack.h, line 113, in 1.0 beta 3:

typedef char *STRING;

typedef const char *CSTRING;

Using such generic names seems like a really bad idea - its asking for 
conflicts.  And they do happen, at least on windows.  The problem is 
that one of the windows headers, ntsecapi.h around line 134, also define 
STRING:

typedef struct _STRING {
   USHORT Length;
   USHORT MaximumLength;
   PCHAR Buffer;
} STRING, *PSTRING;

To see this blow up, compile postgresql 8.4 setting the --with-openssl 
flag, using mingw.  You'll get this error:

gcc -O2 -g -mms-bitfields -Wall -Wmissing-prototypes -Wpointer-arith 
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing 
-fwrapv -I../../../../src/include -I/usr/local/include 
-I./src/include/port/win32 -DEXEC_BACKEND -I/usr/local/include/libxml2 
-I../../../../src/include/port/win32 -DBUILDING_DLL  -c
-o printtup.o printtup.c
In file included from ../../../../src/include/libpq/libpq-be.h:51,
  from ../../../../src/include/libpq/libpq.h:21,
  from printtup.c:19:
c:\development\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/ntsecapi.h:137:
 
error: conflicting types for 'STRING'
C:/Development/msys/local/include/openssl/safestack.h:113: note: 
previous declaration of 'STRING' was here


I assume other programs that use openssl and ntsecapi will also fail to 
compile.  Any chance these generic typedefs can be changed to something 
like OPENSSL_STRING and OPENSSL_CSTRING?

Thanks,

Charlie Savage
http://cfis.savagexi.com







Specifically, when building postgresql 8.4 these names mingw,




Thanks,

Charlie



smime.p7s
Description: S/MIME cryptographic signature

Re: UTF8 in certificate DN via OpenSSL's x.509 API

[Roumen Petrov]

Thor Lancelot Simon wrote:

Can I assume that any data returned when I access the DN of a peer's
certificate using OpenSSL are ASCII or UTF8?  


No, see Howards posts.


If not, how do I tell
the difference?

I think I understand that DNs not encoded as UTF8String should not
have high-bit characters in them -- so if I do this:

X509_NAME_oneline(X509_get_subject_name(peer), buf, BUFSIZ), suffix)


What about X509_NAME_print_ex ?
You may check different outputs with openssl x509 ... -nameopt [flags] .



I should be able to tell any application using the data that the
character set for the data is UTF8, or, if I don't find any Unicode
sequences in it, ASCII.  Is that right?  I don't see a way to find
out what ASN.1 type X509_get_subject_name actually fetched the data
from...



Roumen
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org