Re: Win32 OPENSSL_USE_APPLINK usage
On Tue, Apr 20, 2010 at 2:33 PM, Andy Polyakov ap...@fy.chalmers.se wrote: I actually ended up solving it by removing all uses of BIO_new_fp() in favor of my own custom BIO that I just finished writing earlier this week. Why not BIO_new_file? A. Yeah, I discovered while analyzing the code that using BIO_new_file() rather than BIO_new_fp() would disengage applink, however that was not an option for me because BIO_new_file() can't open a file whose name contains non-ANSI Unicode characters on Windows. I have to open the file myself using _wfopen(). Phillip __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2213] Unable to read Class 3 type CA certificates properly using EVP_EncodeUpdate EVP_EncodeFinal functions.
Hi All, I've looked for any fix for the below mentioned API's in the OpenSSL site. But my bad, could not find any. Let me know if anyone have faced similar issue with the EVP_EncodeUpdate() and EVP_EncodeFinal() API's or any pointer where I can find the fixes in OpenSSL releases from OpenSSL version 0.9.7d 17 Mar 2004 to the latest one. The API's are not working as expected for Class 3 type of CA certificates. Details are given in the mail thread how I've used the api's what is expected and what is the actual outcome. Any help is highly appreciated. -Thanks Regards Basi Reddy M -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Basireddy M via RT Sent: Wednesday, March 31, 2010 11:24 PM Cc: openssl-dev@openssl.org Subject: [openssl.org #2213] Unable to read Class 3 type CA certificates properly using EVP_EncodeUpdate EVP_EncodeFinal functions. Hi, I'm reading the CA Certificate file using OpenSSL API's EVP_EncodeUpdate EVP_EncodeFinal and writting the data to out file (say .pem). Issue: I'm able be read the CA Certificates properly except for Class 3 CA files. For Class 3 type of CA certificates, the API EVP_EncodeFinal reads the entire certificate body after reading the certificate data using EVP_EncodeUpdate, by which the certificate data is written twice to the out file. But for other CA files, after reading the certificate data using EVP_EncodeUpdate, the left out data is fetched by EVP_EncodeFinal. There by the certificate data is written properly to the out file How am I reading the CA file? 1.Creating cert (X509 * structure) for the certificate 2.Initialize the Base64 encoder, using EVP_EncodeInit(), an encoding context structure bctx which is used during all encoding operations. EVP_EncodeInit( bctx ); 3.DER encode the certificate i2d_X509() encodes the structure pointed to by cert into DER format. If out is not NULL is writes the DER encoded data to the buffer at derTmp, and increments it to point after the data just written. If the return value is negative an error occurred, otherwise it returns the length of the encoded data. derLen = i2d_X509( cert, derTmp ); 4.Base 64 encode the certificate DER EVP_EncodeUpdate copies derLen bytes of the input string der into a previously-initialized bctx; if any data was already stored in the bctx, it is base64-encoded first and the results written to encodeBuf. The number of bytes written to encodeBuf is placed in nBytesWritten. Note that the first time this function is called, the input string is copied into the bctx but since there is no input data already in bctx, no data is base64-encoded. In effect, output is always one function call behind the input. EVP_EncodeUpdate(bctx, encodeBuf, nBytesWritten, der, derLen ); 5.EVP_EncodeFinal() base64-encodes the data in a previously initialized and filled bctx and writes the results to encodeBuf. The number of bytes written is placed in nBytesWritten. EVP_EncodeFinal(bctx, encodeBuf, nBytesWritten ); What is the version of OpenSSL? OpenSSL 0.9.7d 17 Mar 2004 What is expected? 1.Is there anything incorrect in the reading the CA file, because of which I'm seeing the issue? 2.Wherther Class 3 CA certificates should be handled differently? If Yes, How? 3.Is it an OpenSSL API issue? If Yes, is it fixed in any of the future releases of the OpenSSL and in which version of OpenSSL. -Regards Basi Reddy M DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.
Re: Building Openssl on OpenVMS using extended parse-style
openssl-dev@openssl.org wrote on 16-APR-2010 17:14:47.36 From: Jouk Jansen jo...@hrem.nano.tudelft.nl [snip] [...] I put the corrected files on my web-page: http://nchrem.tnw.tudelft.nl/openvms/software2.html#OSSL 0.9.8l and 1.0.0-beta2 are hardly current. But don't worry. There are still plenty of problems with the current 0.9.8n and the 1.0.0 (official) kits. Newer kits including some of my sugested changes are available at: http://antinode.info/ftp/openssl I will try them. Jouk Pax, vel iniusta, utilior est quam iustissimum bellum. (free after Marcus Tullius Cicero (106 b.Chr.-46 b.Chr.) Epistularum ad Atticum 7.1.4.3) -- Jouk Jansen jo...@hrem.nano.tudelft.nl Technische Universiteit Delfttt uu uu ddd Kavli Institute of Nanoscience tt uu uu dddd Nationaal centrum voor HREM tt uu uu dd dd Lorentzweg 1 tt uu uu dd dd 2628 CJ Delfttt uu uu dd dd Nederlandtt uu uu dddd tel. 31-15-2782272 tt uuu ddd -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0a-dev on VMS (v. HP-UX ia64)
From: Andy Polyakov ap...@fy.chalmers.se Even if somebody does, doesn't reporting it with VMS in subject decrease the chance of being taken care of? Yes, you've added HP-UX, but can you guarantee that my mail client didn't truncate it? BTW, it did:-) 45 characters is too many? And I thought that _I_ had the lamest e-mail client in the world. Yikes. So, if I cared about your lame e-mail client, and if I cared about this stuff on HP-UX, then I might have tried harder, but ... Verify http://cvs.openssl.org/chngview?cn=19608. A. That seems to do the job. SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Building Openssl on OpenVMS using extended parse-style
Steven wrote on 16-APR-2010 17:14:47.36 From: Jouk Jansen jo...@hrem.nano.tudelft.nl When building OpenSSL on a OpenVMS machine, while extended parse style is on (i.e set proc/parse=extend) some of the tests fail. The solution is simple : add a few double quotes in the command procedures. [...] Because practically every OpenSSL release seems to fail pretty badly on VMS, it might help a little if you identified the OpenSSL kit you're using. I normally have SET PROCESS /PARSE_STYLE = EXTENDED when I build the stuff, so I suspect that fixes are already on the way (or currently being ignored -- it's often hard to tell which). [...] I put the corrected files on my web-page: http://nchrem.tnw.tudelft.nl/openvms/software2.html#OSSL 0.9.8l and 1.0.0-beta2 are hardly current. But don't worry. There are still plenty of problems with the current 0.9.8n and the 1.0.0 (official) kits. Newer kits including some of my sugested changes are available at: http://antinode.info/ftp/openssl I tested the 1.0.0-s1 set from your web-page, but it has exactly the same problem when running the tests: seed-ecb seed-ecb base64 seed-ofb seed-ofb base64 test normal x509v1 certificate testing X509 conversions p - d p - n p - p d - d n - d p - d d - n n - n p - n d - p n - p p - p %BACKUP-E-OPENIN, error opening $DISK8:[joukj.PUBLIC.ssh.OPENSSL.openssl-1^.0^.0 _s1.test]f.p;1 as input -RMS-E-FNF, file not found The reason is that the case of the argument x509 in the openssl command in command procedure tx509.com is wrong and thus the file is not created. Changing line 9 of tx509.com form $ cmd := mcr 'exe_dir'openssl x509 into $ cmd := mcr ''exe_dir'openssl x509 solves the problem. Similar changes should be applied to some other procedures. The changed procedures are on my web-page (for version 1.0.0) Jouk Pax, vel iniusta, utilior est quam iustissimum bellum. (free after Marcus Tullius Cicero (106 b.Chr.-46 b.Chr.) Epistularum ad Atticum 7.1.4.3) -- Jouk Jansen jo...@hrem.nano.tudelft.nl Technische Universiteit Delfttt uu uu ddd Kavli Institute of Nanoscience tt uu uu dddd Nationaal centrum voor HREM tt uu uu dd dd Lorentzweg 1 tt uu uu dd dd 2628 CJ Delfttt uu uu dd dd Nederlandtt uu uu dddd tel. 31-15-2782272 tt uuu ddd -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Building Openssl on OpenVMS using extended parse-style
From: Jouk Jansen jo...@hrem.nano.tudelft.nl http://antinode.info/ftp/openssl I tested the 1.0.0-s1 set from your web-page, but it has exactly the same problem when running the tests: [...] testing X509 conversions p - d p - n p - p d - d n - d p - d d - n n - n p - n d - p n - p p - p %BACKUP-E-OPENIN, error opening $DISK8:[joukj.PUBLIC.ssh.OPENSSL.openssl-1^.0^.0 _s1.test]f.p;1 as input -RMS-E-FNF, file not found The reason is that the case of the argument x509 in the openssl command in command procedure tx509.com is wrong and thus the file is not created. Changing line 9 of tx509.com form $ cmd := mcr 'exe_dir'openssl x509 into $ cmd := mcr ''exe_dir'openssl x509 solves the problem. Similar changes should be applied to some other procedures. The changed procedures are on my web-page (for version 1.0.0) I don't have this problem. show process /case_lookup /parse_style Are you having trouble because of /parse_style = extended or /case_lookup = sensitive? SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Stuck in France...
I assume that it'll all end badly, but I won't know for a while. Safe assumption, I suppose. ALP $ search [...]*.h OPENSSL_SYSTEM %SEARCH-I-NOMATCHES, no strings matched ALP $ search [...]*.c OPENSSL_SYSTEM ** ALP$DKA100:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-stable-SNAP-20100414.apps]app s.c;1 #elif defined(OPENSSL_SYSTEM_VXWORKS) #elif defined(OPENSSL_SYSTEM_VMS) The result of that (the OPENSSL_SYSTEM_VMS part, anyway) was a failure to compile apps/apps.c. Without the (defective) macro defined, you get the #else code, which is too modern for DEC C V6.0-001 on OpenVMS VAX V6.2. (There's no struct tms in time.h on VMS until __CRTL_VER = 7000, for example.) I assume that both of those OPENSSL_SYSTEM_xxx things in apps/apps.c should really be OPENSSL_SYS_xxx. Someone who cares may want to look at the code in those blocks to see if it still makes sense. Clearly, it hasn't been tested much recently. Steven M. Schweda s...@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2230] Resolved: [PATCH] DTLS reassembly
There is still a bug in the bitmask macros, reported by Daniel Mentz. While
checking if the message is complete a read might occur beyond the bitmask
array. This is fixed with this patch and the check is now also done backwards
which should be faster usually.
Regards,
Robin
--- ssl/d1_both.c 14 Apr 2010 00:41:01 - 1.14.2.20
+++ ssl/d1_both.c 21 Apr 2010 13:32:23 -
@@ -132,15 +132,16 @@
} else { \
unsigned long ii; \
bitmask[((start) 3)] |=
bitmask_start_values[((start) 7)]; \
- for (ii = (((start) 3) + 1); ii ((end)
3); ii++) bitmask[ii] = 0xff; \
- bitmask[((end) 3)] |=
bitmask_end_values[((end) 7)]; \
+ for (ii = (((start) 3) + 1); ii (((end -
1)) 3); ii++) bitmask[ii] = 0xff; \
+ bitmask[(((end) - 1) 3)] |=
bitmask_end_values[((end) 7)]; \
} }
#define RSMBLY_BITMASK_IS_COMPLETE(bitmask, msg_len, is_complete) { \
unsigned long ii; \
+ OPENSSL_assert((msg_len) 0); \
is_complete = 1; \
- if (bitmask[((msg_len) 3)] !=
bitmask_end_values[((msg_len) 7)]) is_complete = 0; \
- if (is_complete) for (ii = 0; ii ((msg_len) 3);
ii++) \
+ if (bitmask[(((msg_len) - 1) 3)] !=
bitmask_end_values[((msg_len) 7)]) is_complete = 0; \
+ if (is_complete) for (ii = (((msg_len) - 1) 3) - 1;
ii 0 ; ii--) \
if (bitmask[ii] != 0xff) { is_complete = 0; break; } }
#if 0
@@ -152,7 +153,7 @@
#endif
static unsigned char bitmask_start_values[] = {0xff, 0xfe, 0xfc, 0xf8, 0xf0,
0xe0, 0xc0, 0x80};
-static unsigned char bitmask_end_values[] = {0x00, 0x01, 0x03, 0x07, 0x0f,
0x1f, 0x3f, 0x7f};
+static unsigned char bitmask_end_values[] = {0xff, 0x01, 0x03, 0x07, 0x0f,
0x1f, 0x3f, 0x7f};
/* XDTLS: figure out the right values */
static unsigned int g_probable_mtu[] = {1500 - 28, 512 - 28, 256 - 28};
dtls-bitmask.patch
Description: Binary data
Re: Win32 OPENSSL_USE_APPLINK usage
I actually ended up solving it by removing all uses of BIO_new_fp() in favor of my own custom BIO that I just finished writing earlier this week. Why not BIO_new_file? Yeah, I discovered while analyzing the code that using BIO_new_file() rather than BIO_new_fp() would disengage applink, however that was not an option for me because BIO_new_file() can't open a file whose name contains non-ANSI Unicode characters on Windows. I have to open the file myself using _wfopen(). There was suggestion to fall back to wfopen from a vmware engineer a while ago, but he couldn't provide patch (not that it would be very complex) and it was not followed up. Idea must have been something similar to just committed http://cvs.openssl.org/chngview?cn=19610. Please note that it's *not* like I disapprove practice of custom BIO and suggest you to abandon it. It's *not* like that. On the contrary I can appreciate advantage and even say that it's better approach than one suggested in the beginning of the thread. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Win32 OPENSSL_USE_APPLINK usage
There was suggestion to fall back to wfopen from a vmware engineer a while ago, but he couldn't provide patch (not that it would be very complex) and it was not followed up. Idea must have been something similar to just committed http://cvs.openssl.org/chngview?cn=19610. Sounds like a good idea, but perhaps an even better idea would be to provide an alternate BIO_new_file() that takes a wchar_t*. It would call _wfopen() if supported by the compiler, and if not it would convert the wchar_t* to a char* using wcstombs() and call fopen(). Please note that it's *not* like I disapprove practice of custom BIO and suggest you to abandon it. It's *not* like that. On the contrary I can appreciate advantage and even say that it's better approach than one suggested in the beginning of the thread. A. Cool, thanks :) Yeah, I was quite happy with myself that I happened to write a custom BIO just in time to avoid the whole applink mess, even though that's not even the reason I wrote it. Phillip __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Win32 OPENSSL_USE_APPLINK usage
Hello Andy,
Thank you very much for answering
Andy Polyakov a écrit :
If I have correctly understood the FAQ about the OPENSSL_applink. It
applies only in the Win32 version:
* If OPENSSL_USE_APPLINK is not defined at the compilation stage of
OpenSSL, the snippet applink.c is not mandatory BUT I have to
build a debug and a release version of OpenSSL DLLs.
I don't know why but it seems to be related with FILE functions.
* If OPENSSL_USE_APPLINK is defined, the snippet applink.c is
mandatory in an application and the release version of OpenSSL
DLLs can be used in any case.
Well, OPENSSL_USE_APPLINK is always defined in Win32 builds. applink.c
is required if a) application uses certain subset of OpenSSL API and
b) application and DLL are compiled with different flags, debug vs.
non-debug, or different compilers.
I compile OpenSSL with Visual C++ 6, the same with which I build my DLL
and applications.
I've already used debug vs. non-debug, for example zlib.dll, I've never
had problems.
What is the obscure reason of this access violation ?
The OPENSSL_applink function is searched only in the application module,
Which is why it's called *app*link.
so it's necessary to add or include the snippet with any application
that use OpensSSL.
It should be noted that applink was introduced primarily in order to
facilitate migration for legacy applications. New code should rather
abstain from using above mentioned subset of OpenSSL API (whatever
using FILE *) and simply avoid applink.
Do you mean that BIO API using FILE* is deprecated ? I have not seen
this mention in the documentation.
I find that this API is clean and coherent.
Only Windows sucks. Why BIO should suffer of this ?
If the only way to have a DLL that uses OpenSSL as a wrapper is to
compile OpenSSL without OPENSSL_USE_APPLINK define and provide a debug
and a release version... no problem... I will do so.
In the case of a unique DLL that use OpenSSL, what do think about the
following way to define and use OPENSSL_applink
(I've tried this with success with 0.9.8.n but implement it in a
brute force manner) :
ms/uplink.h
Added the following declaration next to extern void
*OPENSSL_UplinkTable[]; :
extern void OPENSSL_SetApplink( void** (*foo)() );
ms/uplink.c
Added :
staticvoid** (*applink_foo)() = NULL;
void OPENSSL_SetApplink( void** (*foo)() )
{
applink_foo = foo;
}
and modifiy OPENSSL_Uplink(). Priority is given to OPENSSL_Applink if
it's found in the current module. If it's not, if applink_foo is not
set, give the error message else use applink_foo.
applink=(void**(*)())GetProcAddress(h,OPENSSL_Applink);
if (applink==NULL)
{if( applink_foo == NULL )
{apphandle=(HMODULE)-1;
_tcscpy (msg+len,_T(no OPENSSL_Applink));
break;
}
else applink = applink_foo;
}
In the user DLL that uses OpenSSL, add or include the snippet
applink.c in the DLL project and
Add the following declaration (I don't know where to put it in
OpenSSL include files)
extern C {
void **OPENSSL_Applink();
void OPENSSL_SetApplink( void **(*foo)() );
};
and add the following in the initialisation function or dllmain:
CRYPTO_malloc_init();
OPENSSL_SetApplink( OPENSSL_Applink );
SSL_library_init(); /* load encryption hash algorithms for SSL
*/ SSL_load_error_strings(); /* load the
error strings for good
error reporting */
This way, OPENSSL_Applink can be used inside DLLs, but I'm not sure
of implications so I need your advices.
As there is no way to ensure/know that there is only one DLL using
OpenSSL, it's not appropriate for main stream. If it helps to develop
and debug your application, there is nothing that prevents you from
doing so.
Of course ! but I don't especially want to do so !
This is the only way I' ve found to build a DLL using OpenSSL. I've
found impratical to add appilink.c in each application that uses the DLL.
I want to point to your attention that the call ERR_print_errors_fp(
stderr ) from the user DLL lead to an Access violation (0xc005).
This situation arises in mixing debug and release versions and
is probably due to the fact that ERR_print_errors_fp( stderr ) calls
fwrite directly. UP_fwrite should be used instead.
This is bug. It was fixed in development branch and is not present in
1.0.0. http://cvs.openssl.org/chngview?cn=19607 is committed even to
0.9.8. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Win32 OPENSSL_USE_APPLINK usage
Andy Polyakov schrieb: I actually ended up solving it by removing all uses of BIO_new_fp() in favor of my own custom BIO that I just finished writing earlier this week. Why not BIO_new_file? Yeah, I discovered while analyzing the code that using BIO_new_file() rather than BIO_new_fp() would disengage applink, however that was not an option for me because BIO_new_file() can't open a file whose name contains non-ANSI Unicode characters on Windows. I have to open the file myself using _wfopen(). There was suggestion to fall back to wfopen from a vmware engineer a while ago, but he couldn't provide patch (not that it would be very complex) and it was not followed up. Idea must have been something similar to just committed http://cvs.openssl.org/chngview?cn=19610. why not adding the following to BIO_new_file()? - BIO interface still uses char * (meaning latin ASCII 0x20..0x7F) - BIO implementation calls UTF8_to_UCS16() on all platforms supporting wfopen or _wfopen - BIO implementation then calls wfopen / _wfopen with this UCS16 value (sometimes known as WCHAR*) - For Win32 and Win32_WinCE the conversion can be done with FormatMessage() API. It's allways available. ... just my 5 cents. The Modem Man __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
