Re: [openssl.org #1725] OpenSSL-0.9.8h: Bug in Certificate Request generation
Hi,Sorry for the late reply, I did not subscrive to the mailing list (and therfore did not receive the replies from Rafael Kyle ) , so just to clarify I was using Apache HTTPd 2.2.9 and had issues with its bundled version of openSSL which was 0.9.8h , I understood correctly the issue is now fixed in the latest release 0.9.8i. The good news is that I see the latest Apache release 2.0.10 (see at http://httpd.apache.org/download.cgi) , is now including including OpenSSL 0.9.8i , so my issue should fixed in fact. See also : https://issues.apache.org/bugzilla/show_bug.cgi?id=45763 https://issues.apache.org/bugzilla/show_bug.cgi?id=43822 Kind regards, Steve Re: [openssl.org #1725] OpenSSL-0.9.8h: Bug in Certificate Request generation Kyle Hamilton Mon, 08 Sep 2008 17:18:27 -0700 ETA is Estimated Time of Arrival. Basically, he's asking when OpenSSL 0.9.8i is going to be released. -Kyle H On Mon, Sep 8, 2008 at 1:39 PM, Rafael Jorge Csura Szendrodi via RT [EMAIL PROTECTED] wrote: Hi, On Mon, 8 Sep 2008 16:44:43 +0200 (CEST), Steve Pincaud via RT wrote Hi, I have seen the issue will be fixed in the next release, do you have an ETA ? (0.9.8i or 0.9.9 ?) , I would then ask Apache team when such new OpenSSL milestone would be bundled in Apache2 HTTPd (2.3 ?!) Excuse-me... But I didn't understand anything... What's means ETA??? I came back to OpenSSL-0.9.8g and I am only waiting for a new release of OpenSSL (i.e. 0.9.8i). But, I generated all certificates using same the OpenSSL-0.9.8g. I only reported a bug in OpenSSL-0.9.8h (at Fri, 01 Aug 2008 05:24:58 -0700) and you answered (at Sun, 03 Aug 2008 05:55:19 -0700) that this bug was fixed in the 0.9.8 snapshots and will appear in the next OpenSSL release. Ok, I was satisfied with you response and I am waiting for the next stable version of OpenSSL. But, until the next version arrive, the OpenSSL-0.9.8g is working fine for me... Excuse-me, but I didn't understand what you are asking me now? I didn't hope you returned to that subject. Regards, Rafael Regards, Steve -- Atenciosamente, Rafael Jorge Csura Szendrodi Network Administrator - PADS/COPPE/UFRJ E-mail: [EMAIL PROTECTED] 2008/9/8 Steve Pincaud [EMAIL PROTECTED] Hi, I have seen the issue will be fixed in the next releasehttp://www.mail-archive.com/openssl-dev@openssl.org/msg24330.html, do you have an ETA ? (0.9.8i or 0.9.9 ?) , I would then ask Apache team when such new OpenSSL milestone would be bundled in Apache2 HTTPd (2.3 ?!) Regards, Steve Hi,Sorry for the late reply, I did not subscrive to the mailing list (and therfore did not receive the replies from Rafael Kyle ) , so just to clarify I was using Apache HTTPd 2.2.9 and had issues with its bundled version of openSSL which was 0.9.8h , I understood correctly the issue is now fixed in the latest release 0.9.8i. The good news is that I see the latest Apache release 2.0.10 (see at http://httpd.apache.org/download.cgi) , is now including including OpenSSL 0.9.8i , so my issue should fixed in fact. See also :https://issues.apache.org/bugzilla/show_bug.cgi?id=45763https://issues.apache.org/bugzilla/show_bug.cgi?id=43822 Kind regards,SteveRe: [openssl.org #1725] OpenSSL-0.9.8h: Bug in Certificate Request generation Kyle Hamilton Mon, 08 Sep 2008 17:18:27 -0700 ETA is Estimated Time of Arrival. Basically, hes asking whenOpenSSL 0.9.8i is going to be released.-Kyle HOn Mon, Sep 8, 2008 at 1:39 PM, Rafael Jorge Csura Szendrodi via RT [EMAIL PROTECTED] wrote: Hi, On Mon, 8 Sep 2008 16:44:43 +0200 (CEST), Steve Pincaud via RT wrote Hi, I have seen the issue will be fixed in the next release, do you have an ETA ? (0.9.8i or 0.9.9 ?) , I would then ask Apache team when such new OpenSSL milestone would be bundled in Apache2 HTTPd (2.3 ?!) Excuse-me... But I didnt understand anything... Whats means ETA??? I came back to OpenSSL-0.9.8g and I am only waiting for a new release of OpenSSL (i.e. 0.9.8i). But, I generated all certificates using same the OpenSSL-0.9.8g. I only reported a bug in OpenSSL-0.9.8h (at Fri, 01 Aug 2008 05:24:58 -0700) and you answered (at Sun, 03 Aug 2008 05:55:19 -0700) that this bug was fixed in the 0.9.8 snapshots and will appear in the next OpenSSL release. Ok, I was satisfied with you response and I am waiting for the next stable version of OpenSSL. But, until the next version arrive, the OpenSSL-0.9.8g is working fine for me... Excuse-me, but I didnt understand what you are asking me now? I didnt hope you returned to that subject. Regards, Rafael Regards, Steve -- Atenciosamente, Rafael Jorge Csura Szendrodi Network Administrator - PADS/COPPE/UFRJ E-mail: [EMAIL PROTECTED]2008/9/8 Steve Pincaud [EMAIL PROTECTED] Hi,I have seen the issue will be fixed in the next release, do you have an ETA ? (0.9.8i
Re: [openssl.org #1736] Enhancement Request: do away with error in chil engine in absence of dynamic locks
On Fri, Aug 29, 2008 at 08:45:12AM +0200, Sander Temme via RT wrote: 2) Have the engine provide its own callbacks that get set in case the application does not provide (presumably more suitable) alternatives: I think it would be entirely sensible for OpenSSL to offer a build-time configuration option to implement default locking/id callbacks using pthread functions like this. It would be necessary also to link libcrypto against -lpthread and/or use the -pthread compiler flag, to avoid only picking up dummy libc stubs on some platforms. That seems far better than requiring every single OpenSSL application to implement exactly the same code over and over again- and in fact for many to do so incompletely, omitting the dynamic lock support. joe __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1724] s_server does not escape HTML
Variables inserted in s_server -www output are not HTML-escaped. For example: $ mv server.key 'bhoiserver.key' $ openssl s_server -cert server.crt -key 'bhoiserver.key' -www ... $ curl -s -k https://localhost:4433/ | grep hoi s_server -cert server.crt -key bhoiserver.key -www When viewed in a browser, the whole page becomes bold from that point on. I expect the same issue to apply to the client certificate report in this output. Instead of b, someone could insert JavaScript-code here to do nasty things like steal cookies. Admittedly, getting into the right place to do this on a production system is hard - but it's better to be safe than sorry. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Andy Polyakov wrote: How do we know that these are not or should not be treated as mingw64 bugs? I mean it worked for mingw for years (I wonder how by the way), now ancestor is *being developed* and how come it's not its fault:-) I don't really understand that part about ancestor, but never mind ... Well, I can accept that pid_t could be treated better in OpenSSL (#ifdef there is nothing but strange), but I don't buy masking of alarm. It's impossible to implement Unix-ish alarm on Windows and it simply shouldn't be there (nor SIGALRM definition). Quick check reveals that alarm is nothing but return 0. What's more appropriate: to be honest or not to tell truth? I mean absence of alarm would be honest, while implementing it as return 0 would be not telling truth... Sounds convincing to me, so I took the liberty to forward this to the mingw-w64 mailing list in the hope that they'll do something about it. Thanks, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Hi, Please, could you propose a patch to the OpenSSL head. In the head -lwsock32 is replaced by -lws2_32. Will do.. I think that you has to compile with -DWIN32_LEAN_AND_MEAN in Configure before to do some undefs in openssl headers. Also see other win64 targets. But doesn't that mean that any user of openssl wanting to use e.g. X509_EXTENSIONS has to take care of that problem himself? Also, x509.h is already undefining 2 of the 3 problematic symbols anyway. IMO that's something that really should be fixed in the headers. Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Hi, Please, could you propose a patch to the OpenSSL head. In the head -lwsock32 is replaced by -lws2_32. Here's a patch against today's snapshot of head. I think that you has to compile with -DWIN32_LEAN_AND_MEAN in Configure before to do some undefs in openssl headers. I'm not really convinced, but for the time being, I've added that compile option to get rid of that more or less cosmetic issue. Apart from adding a line to configure, I needed a slight modification to apps/speed.c and engines/e_aep.c because mingw-w64 comes with definitions for pid_t and alarm and in crypto/mem_cmp.c, gcc complained about a (and b) being redefined as a different kind of symbol, so I renamed the local symbols to have different names from the parameters. Regards, Stefan openssl-HEAD.patch Description: Binary data
[openssl.org #1693] Compiling OpenSSL with mingw-w64
Hi, I just tried to compile OpenSSL-0.9.8h with mingw-w64 (see http://sourceforge.net/projects/mingw-w64/) and needed a couple of changes to the source code (see attached patch). Some notes: - I added a mingw64 line to Configure and (think I) told it to use .exe extension for compiling. Nothing surprising here, I think. Note that you currently need to Configure mingw64 no-asm no-hw. - windows.h apparently includes wincrypt.h (no idea whether that's specific to that compiler, but it seems so ...), so I needed to #undefine a couple of names messed up by wincrypt.h (patches to rand.h, x509.h and e_os.h). - It's using a very recent snapshot of gcc, so there also is the problem in e_os2.h, that has already been reported for gcc-4.3: the compiler complains about the same variable being declared as both extern and static - so I changed that to use static both times - but I'm not really sure what's the correct thing to do here. Regards, Stefan openssl-h.patch Description: Binary data
[openssl.org #1640] 'Configure' should double backslashes in 'buildinf.h'
Found a minor issue in 'Configure', especially when building under Windows. Backslashes (from -I pathnames) are not converted to double backslashes in the quoted string #define for CFLAGS in 'crypto/buildinf.h'. Problem also affects 'crypto/opensslconf.h' for the #defines ENGINESDIR and OPENSSLDIR. This results in warnings when 'crypto\cversion.c' is compiled. Since /WX switch is the default for WIN32, the build 'nmake' abends. Workaround is to edit files by hand after running 'Configure'. Found this while building 'openssl' 0.9.8g for VC-WIN32 and VC-WIN64A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1272] Problem with config 64 bits AIX 5.2
Please verify that http://cvs.openssl.org/chngview?cn=16812 fixes the problem. Confirming referenced patch fixes issue under newer AIX configuration and for newer version of 'openssl'. Probably everything in-between and AIX 6.1 w/ XLC9 as well. Patch format is not understood by AIX 'patch', 'diff' style equivalent attached. AIX 5.3 with recent TL7 SP1 patches and up-to-date XLC8 compiler: oslevel - 5300-07-01-0748 XLC version 8.0.0.17 OPENSSL version 0.9.8g Thank you for the fix!!! openssl_aix_issue_1272_fix.patch Description: Binary data
Re: Re: [openssl.org #1521] bug report
Hi Dmitri, I guess you have raised this issue. I am also facing the same issue with the x86_64 Linux. Did your problem got resolved? If yes please let me know the solution for it. Thanks!! With Best Regards Rahul -- This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com http://www.opensubscriber.com/message/openssl-dev@openssl.org/6758716.html __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1592] ms\do_masm.bat requires MASM v8
Adding a conditional declaration for XMMWORD allows either MASM 6, MASM 7, or MASM 8 to assemble OpenSSL 0.9.8g correctly, including the SSE2 instructions in sha512-sse2.asm: IF @Version LT 800 XMMWORD STRUCT 16 DQ 2 dup (?) XMMWORD ENDS ENDIF x86ms.pl could do this: --- crypto\perlasm\x86ms.orig 2007-10-19 12:34:37.208468200 -0400 +++ crypto\perlasm\x86ms.pl 2007-10-19 12:36:59.254664500 -0400 @@ -255,6 +255,11 @@ TITLE $file.asm .386 .modelFLAT +IF [EMAIL PROTECTED] LT 800 +XMMWORD STRUCT 16 +DQ 2 dup (?) +XMMWORD ENDS +ENDIF _TEXT\$ SEGMENT PAGE 'CODE' EOF Note that MASM 6 still must be version 6.15+ to assemble the SSE2 instructions, but VC6 users can upgrade with the Visual C++ 6.0 Processor Pack at http://msdn2.microsoft.com/en-us/vstudio/aa718349.aspx if necessary. -tom- Stephen Henson via RT wrote: [EMAIL PROTECTED] - Thu Oct 18 09:05:32 2007]: Starting with OpenSSL 0.9.8f, Windows builds using ms\do_masm.bat generate .asm files with the MASM directive XMMWORD. ... Some of the new assembly language modules which significantly improve performance require such support. MASM support isn't included at all in the HEAD (which will be 0.9.9). The free NASM can be used instead. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1592] ms\do_masm.bat requires MASM v8
Starting with OpenSSL 0.9.8f, Windows builds using ms\do_masm.bat generate .asm files with the MASM directive XMMWORD. XMMWORD was added to MASM 8 (Visual Studio C++ 2005). ref: http://msdn2.microsoft.com/en-us/library/cw0399sf(VS.80).aspx This prevents building OpenSSL via ms\do_masm.bat with MASM 6 (VC6) or MASM 7 (VC2003). -tom- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1592] ms\do_masm.bat requires MASM v8
MASM 6.15+ includes support for the SSE2 instructions, like movdqa, movdqu, etc. It is only the XMMWORD directive that forces the use of the Visual Studio 2005 assembler. If QWORD is substituted for XMMWORD, MASM 6 can assemble the .asm sources. Testing OpenSSL built with MASM 6 and this 'QWORD' substitution shows correct operation and retains the speed improvements. A disadvantage is that QWORD won't make the assembler check that the arguments are correctly 128-bit aligned, although they all are - so no problem. Unfortunately, this substitution makes MASM 8 report: error A2022: instruction operands must be the same size MASM 6 is still far more widely used than MASM 8. Also, the license for the free (Express Edition) of MASM 8 precludes commercial use of the binaries it produces. This is odd because the VS2005 Express Edition C++ compiler has no such restriction, nor does any version of MASM 6. Maybe separate do_masm6.bat and do_masm8.bat files to trigger different behavior in crypto\perlasm\x86ms.pl? Yes, NASM works. -tom- Stephen Henson via RT wrote: [EMAIL PROTECTED] - Thu Oct 18 09:05:32 2007]: Starting with OpenSSL 0.9.8f, Windows builds using ms\do_masm.bat generate .asm files with the MASM directive XMMWORD. XMMWORD was added to MASM 8 (Visual Studio C++ 2005). ref: http://msdn2.microsoft.com/en-us/library/cw0399sf(VS.80).aspx This prevents building OpenSSL via ms\do_masm.bat with MASM 6 (VC6) or MASM 7 (VC2003). Some of the new assembly language modules which significantly improve performance require such support. MASM support isn't included at all in the HEAD (which will be 0.9.9). The free NASM can be used instead. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1589] Resolved: OPENSSL_VERSION_NUMBER wrong in 0.9.8f release
I found this problem originally when trying to use OpenSSH linked against the new OpenSSL. I get the following error: $ ssh -V OpenSSL version mismatch. Built against 90805f, you have 908070 openssh-4.7p1/entropy.c has the following code: /* * OpenSSL version numbers: MNNFFPPS: major minor fix patch status * We match major, minor, fix and status (not patch) */ if ((SSLeay() ^ OPENSSL_VERSION_NUMBER) ~0xff0L) fatal(OpenSSL version mismatch. Built against %lx, you have %lx, OPENSSL_VERSION_NUMBER, SSLeay()); So OpenSSH stops working if you switch from a release build of OpenSSL to a development build. -- Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1591] get_session_cb callback invoked with no previous session in 0.9.8f
Starting with OpenSSL 0.9.8f, ssl3_get_client_hello() no longer tests whether the client proposed a previous session_id before trying to process it. In previous releases, a new session was always created if no previous session was proposed (i.e. if j==0 at ssl\s3_srvr.c:746) ssl3_get_client_hello() now calls ssl_get_prev_session(), which calls the user's get_session_cb() function if one was registered via SSL_CTX_sess_set_get_cb(). When no previous session_id is proposed, an empty session_id and a session_id length of zero is passed to get_session_cb(). This causes problems with existing callbacks. For example, Apache 2.2 will report: [error] unusably short session_id provided (0 bytes) for every new session when it is used with OpenSSL 0.9.8f. This is contrary to the docs at http://www.openssl.org/docs/ssl/SSL_CTX_sess_set_get_cb.html which say The get_session_cb() is only called on SSL/TLS servers with the session id proposed by the client. -tom- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1591] get_session_cb callback invoked with no previous session in 0.9.8f
Hi Lutz,
Apologies, I should have included a stack trace with the bug report.
FYI - attached is a Windows/Apache 2.2.6/OpenSSL 0.9.8f VC8 stack trace.
The problem is not Windows-specific. I observe it on several platforms.
This patch seems to correct the problem by checking for a zero-length previous
session_id:
=
--- ssl/s3_srvr.orig2007-09-30 14:56:00.0 -0400
+++ ssl/s3_srvr.c 2007-10-17 12:51:58.311934000 -0400
@@ -743,7 +743,7 @@
* might be written that become totally unsecure when compiled with
* an earlier library version)
*/
- if ((s-new_session (s-options
SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION)))
+ if (j == 0 || (s-new_session (s-options
SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION)))
{
if (!ssl_get_new_session(s,1))
goto err;
=
Regards,
-tom-
Lutz Jaenicke via RT wrote:
[EMAIL PROTECTED] - Wed Oct 17 18:11:27 2007]:
Starting with OpenSSL 0.9.8f, ssl3_get_client_hello() no longer tests
whether the client proposed a
previous session_id before trying to process it. In previous releases,
a new session was always
created if no previous session was proposed (i.e. if j==0 at
ssl\s3_srvr.c:746)
The problem is being worked upon.
Best regards,
Lutz
Windows Apache 2.2.6 OpenSSL 0.9.8f Visual Studio 2005 SP1
[Wed Oct 17 12:11:39 2007] [error] unusably short session_id provided (0
bytes)
libhttpd.dll!log_error_core(const char * file=0x6fd22d54, int
line=0x02d3, int level=0x0003, int status=0x, const
server_rec * s=0x0093bf40, const conn_rec * c=0x, const request_rec *
r=0x, apr_pool_t * pool=0x, const char * fmt=0x6fd22d24, char
* args=0x048afa90) Line 658 C
libhttpd.dll!ap_log_error(const char * file=0x6fd22d54, int
line=0x02d3, int level=0x0003, int status=0x, const server_rec
* s=0x0093bf40, const char * fmt=0x6fd22d24, ...) Line 677 + 0x27 bytes C
mod_ssl.so!shmcb_retrieve_session(server_rec * s=0x0093bf40, void *
shm_segment=0x00b80008, unsigned char * id=0x009e69df, int idlen=0x)
Line 724 + 0x21 bytes C
mod_ssl.so!ssl_scache_shmcb_retrieve(server_rec * s=0x0093bf40,
unsigned char * id=0x009e69df, int idlen=0x) Line 432 + 0x18 bytes
C
mod_ssl.so!ssl_scache_retrieve(server_rec * s=0x0093bf40, unsigned char
* id=0x009e69df, int idlen=0x) Line 115 + 0x11 bytes C
mod_ssl.so!ssl_callback_GetSessionCacheEntry(ssl_st * ssl=0x009ddfd0,
unsigned char * id=0x009e69df, int idlen=0x, int * do_copy=0x048afb50)
Line 1670 + 0x11 bytesC
ssleay32.dll!ssl_get_prev_session(ssl_st * s=0x009ddfd0, unsigned char
* session_id=0x009e69df, int len=0x, const unsigned char *
limit=0x009e69f9) Line 352 + 0x34 bytes C
ssleay32.dll!ssl3_get_client_hello(ssl_st * s=0x009ddfd0) Line 753 +
0x18 bytesC
ssleay32.dll!ssl3_accept(ssl_st * s=0x009ddfd0) Line 282 + 0x9 bytes
C
ssleay32.dll!SSL_accept(ssl_st * s=0x009ddfd0) Line 850 + 0xf bytes
C
ssleay32.dll!ssl23_get_client_hello(ssl_st * s=0x009ddfd0) Line 568 +
0x9 bytesC
ssleay32.dll!ssl23_accept(ssl_st * s=0x009ddfd0) Line 203 + 0x9 bytes
C
ssleay32.dll!SSL_accept(ssl_st * s=0x009ddfd0) Line 850 + 0xf bytes
C
mod_ssl.so!ssl_io_filter_connect(ssl_filter_ctx_t *
filter_ctx=0x009db488) Line 1047 + 0xb bytes C
mod_ssl.so!ssl_io_filter_input(ap_filter_t * f=0x009e36a8,
apr_bucket_brigade * bb=0x009e5560, ap_input_mode_t mode=AP_MODE_GETLINE,
apr_read_type_e block=APR_BLOCK_READ, __int64 readbytes=0x)
Line 1292 + 0xf bytes C
libhttpd.dll!ap_get_brigade(ap_filter_t * next=0x009e36a8,
apr_bucket_brigade * bb=0x009e5560, ap_input_mode_t mode=AP_MODE_GETLINE,
apr_read_type_e block=APR_BLOCK_READ, __int64 readbytes=0x)
Line 490 + 0x22 bytes C
libhttpd.dll!ap_rgetline_core(char * * s=0x009e4788, unsigned int
n=0x2000, unsigned int * read=0x048afeb4, request_rec * r=0x009e4770, int
fold=0x, apr_bucket_brigade * bb=0x009e5560) Line 232 + 0x1b bytes
C
libhttpd.dll!read_request_line(request_rec * r=0x009e4770,
apr_bucket_brigade * bb=0x009e5560) Line 597 + 0x27 bytes C
libhttpd.dll!ap_read_request(conn_rec * conn=0x009dafd8) Line 891 +
0xd bytes C
libhttpd.dll!ap_process_http_connection(conn_rec * c=0x009dafd8) Line
177 + 0x9 bytes C
libhttpd.dll!ap_run_process_connection(conn_rec * c=0x009dafd8) Line
43 + 0x50 bytes C
libhttpd.dll!ap_process_connection(conn_rec * c=0x009dafd8, void *
csd=0x009d5f60) Line 180C
libhttpd.dll!worker_main(void * thread_num_val=0x00f0)
Re: [openssl.org #1591] get_session_cb callback invoked with no previous session in 0.9.8f
Yes - the patch at http://cvs.openssl.org/chngview?cn=16691 corrects the problem. Tested with Apache 2.2.6 on Windows and Debian 4.0. -tom- Stephen Henson via RT wrote: The code was changed when TLS ticket support was added. In that case a zero length session ID can result in a resumed session based on the ticket. It didn't catch the case where ticket resumtion failed and the session legth was zero. This patch should fix it: http://cvs.openssl.org/chngview?cn=16691 Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1589] OPENSSL_VERSION_NUMBER wrong in 0.9.8f release
include/openssl/opensslv.h has: #define OPENSSL_VERSION_NUMBER 0x00908070L Shouldn't this be: #define OPENSSL_VERSION_NUMBER 0x0090806fL since this is the 6th patch _release_, not dev? -- Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1500] Resolved: 0.9.8 bug report
thanks! but a little bit more info wouldn't hurt ;-) Andy Polyakov via RT wrote: According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. -- ah-consulting.net Götz Fischer Senior Consultant Phone: +49(0)7225/98 98 79 Fax: +49(0)7225/28 64 eMail: [EMAIL PROTECTED] http://www.ah-consulting.net http://www.ah-webhosting.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1560] rsautl man page bug
http://www.openssl.org/docs/apps/rsautl.html ... The certificate public key can be extracted with: openssl x509 -in test/testx509.pem -pubout -noout pubkey.pem ... the same is in my rsautl man page on ubuntu 7.04 (feisty) with 0.9.8c-4build1 the correct syntax is not -pubout but -pubkey, as openssl x509 -help will show you. Regards, Andreas Jellinghaus __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1500] Resolved: 0.9.8 bug report
thanks! haven't heard anything about it so far. is there a patch or something? thanks again On Sat, 7 Jul 2007 20:45:28 +0200 (CEST) Andy Polyakov via RT [EMAIL PROTECTED] wrote: According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. -- ah-consulting.net Götz Fischer Senior Consultant Phone: +49(0)7225/98 98 79 Fax: +49(0)7225/28 64 eMail: [EMAIL PROTECTED] http://www.ah-consulting.net http://www.ah-webhosting.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1500] Resolved: 0.9.8 bug report
i see. too bad. Andy Polyakov via RT wrote: thanks! there is nothing to be thankful about, sorry. haven't heard anything about it so far. is there a patch or something? if you would have checked the ticket, you'd see that there unfortunately no resources to pursue the issue. i can't reproduce it and have no time to interrogate you to figure out what's wrong with your environment. sorry, you're on your own. you should be able to figure it out. a. -- ah-consulting.net Götz Fischer Senior Consultant Phone: +49(0)7225/98 98 79 Fax: +49(0)7225/28 64 eMail: [EMAIL PROTECTED] http://www.ah-consulting.net http://www.ah-webhosting.com i see. too bad. Andy Polyakov via RT wrote: > thanks! there is nothing to be thankful about, sorry. > haven't heard anything about it so far. > is there a patch or something? if you would have checked the ticket, you'd see that there unfortunately no resources to pursue the issue. i can't reproduce it and have no time to interrogate you to figure out what's wrong with your environment. sorry, you're on your own. you should be able to figure it out. a. -- ah-consulting.net Gtz Fischer Senior Consultant Phone: +49(0)7225/98 98 79 Fax: +49(0)7225/28 64 eMail: [EMAIL PROTECTED] http://www.ah-consulting.net http://www.ah-webhosting.com
[openssl.org #1434] Bug report - link error when openssl-0.9.7l compiled with no-ssl2 flag
I tried building OpenSSL 0.9.8e on windows with the no-ssl2 and it still creates ms\ssleay32.def with the ssl2 and ssl23 functions. From reading the logs this was supposed to be fixed in both 0.9.7l and 0.9.8 (bug report 1434). Am I missing a step or a switch? Thanks, George Starting from a fresh download. Perl Configure VC-WIN32 no-ssl2 Ms\do_nasm Ms\ssleay32.def now contains the functions for SSL2 and SSL23. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1511] A possible bug when compiling openSSL with minGW
Hi, I am having a bit of a trouble compiling the openSSL release 0.9.8e under WinXP SP2. The version of minGW's the gcc compiler I am using is 3.4.5-20060117-1 and the minGW32-make is 3.80.0-1. For some reason the build tools use malformed file names such as .\crypto\/cryptlib.h (pay attention to the \/ -- it's not V, but \ and / concatenated) and the compilation fails with the final message being mingw32-make: *** [tmp\cryptlib.o] Error 1. I included the compile log with my letter. Any ideas what might be the issue here? best regards, Maleamat88r C:\openssl-0.9.8ems\mingw32 C:\openssl-0.9.8eperl Configure mingw Configuring for mingw no-camellia [default] OPENSSL_NO_CAMELLIA (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-mdc2 [default] OPENSSL_NO_MDC2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-shared [default] no-zlib [default] no-zlib-dynamic [default] IsMK1MF=1 CC=gcc CFLAG =-DOPENSSL_THREADS -DDSO_WIN32 -mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall -D_WIN32_WINNT=0x333 -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DM EX_LIBS =-lwsock32 -lgdi32 CPUID_OBJ =x86cpuid-cof.o BN_ASM=bn86-cof.o co86-cof.o DES_ENC =dx86-cof.o yx86-cof.o AES_ASM_OBJ =ax86-cof.o BF_ENC=bx86-cof.o CAST_ENC =cx86-cof.o RC4_ENC =rx86-cof.o RC5_ENC =r586-cof.o MD5_OBJ_ASM =mx86-cof.o SHA1_OBJ_ASM =sx86-cof.o s512sse2-cof.o RMD160_OBJ_ASM=rm86-cof.o PROCESSOR = RANLIB=true ARFLAGS = PERL =perl THIRTY_TWO_BIT mode DES_PTR used DES_RISC1 used DES_UNROLL used BN_LLONG mode RC4_INDEX mode RC4_CHUNK is undefined Configured for mingw. Generating x86 for GNU assember Bignum DES crypt Blowfish CAST5 RC4 MD5 SHA1 RIPEMD160 RC5\32 CPUID Generating makefile Generating DLL definition files Building the libraries Building OpenSSL copy .\crypto\buildinf.h tmp\buildinf.h 1 file(s) copied. copy .\crypto\opensslconf.h outinc\openssl\opensslconf.h 1 file(s) copied. gcc -o tmp\cryptlib.o -Ioutinc -Itmp -DL_ENDIAN -DDSO_WIN32 -fomit-frame-pointer -O3 -march=i486 -Wall -DBN_ASM -DMD5_ASM -DSHA1_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_NO_CAMELLIA -DOPENSSL_N In file included from .\crypto\cryptlib.c:117: .\crypto\/cryptlib.h:62:20: stdlib.h: No such file or directory .\crypto\/cryptlib.h:63:20: string.h: No such file or directory In file included from .\crypto\/cryptlib.h:65, from .\crypto\cryptlib.c:117: tmp/e_os.h:265:25: windows.h: No such file or directory tmp/e_os.h:267:23: errno.h: No such file or directory tmp/e_os.h:279:24: malloc.h: No such file or directory tmp/e_os.h:281:18: io.h: No such file or directory tmp/e_os.h:282:21: fcntl.h: No such file or directory In file included from .\crypto\/cryptlib.h:72, from .\crypto\cryptlib.c:117: outinc/openssl/crypto.h:125:19: stdio.h: No such file or directory In file included from .\crypto\/cryptlib.h:72, from .\crypto\cryptlib.c:117: outinc/openssl/crypto.h:511: error: syntax error before '*' token In file included from .\crypto\/cryptlib.h:73, from .\crypto\cryptlib.c:117: outinc/openssl/buffer.h:71:23: sys/types.h: No such file or directory In file included from .\crypto\/cryptlib.h:74, from .\crypto\cryptlib.c:117: outinc/openssl/bio.h:567: error: syntax error before '*' token outinc/openssl/bio.h:644: error: syntax error before '*' token outinc/openssl/bio.h:645: error: syntax error before '*' token In file included from outinc/openssl/err.h:74, from .\crypto\/cryptlib.h:75, from .\crypto\cryptlib.c:117: outinc/openssl/lhash.h:185: error: syntax error before FILE outinc/openssl/lhash.h:186: error: syntax error before FILE outinc/openssl/lhash.h:187: error: syntax error before FILE In file included from .\crypto\/cryptlib.h:75, from .\crypto\cryptlib.c:117: outinc/openssl/err.h:279: error: syntax error before '*' token .\crypto\cryptlib.c: In function `CRYPTO_thread_id': .\crypto\cryptlib.c:436: warning: implicit declaration of function `GetCurrentThreadId' .\crypto\cryptlib.c: In function `OPENSSL_cpuid_setup': .\crypto\cryptlib.c:559: warning: implicit declaration of function `getenv' .\crypto\cryptlib.c:559: warning: assignment makes pointer from integer without a cast .\crypto\cryptlib.c:560: warning: implicit declaration of function `strtoul' .\crypto\cryptlib.c:624:19: tchar.h: No such file or directory .\crypto\cryptlib.c: In function `OPENSSL_isservice': .\crypto\cryptlib.c:628: error: `HWINSTA' undeclared (first use in this function) .\crypto\cryptlib.c:628: error: (Each undeclared identifier is reported only once .\crypto\cryptlib.c:628: error: for each
[openssl.org #1498] OpenSSL 0.9.8e Fatal Error on make
This transaction appears to have no content Hi,I am trying to install openssl-0.9.8e on Solaris v10 12/06. I got Fatal error when I build OpenSSL by running make command.I attached the output of ./config and make (config_log.txt and make_log.txt).Could you please advice me what should I do?Shouldyouhaveanyqueries,pleasefeelfreetocallmeat2608-6220.Regards,EmersSoftwareSpecialistAutomatedSystems(HK)LimitedTel.:(852)2608-6220Fax:(852)2608-6566Add.:15/F,TopsailPlaza,11OnSumStreet,Shatin,NT,HongKongVisitusat:http://www.asl.com.hkThis is a PRIVATE message. If you are not the intended recipient please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. config_log.txt Description: Binary data make_log.txt Description: Binary data
[openssl.org #1494] Re: Openssl Installation Error
To Whom It May Concern: I tried to install the Openssl and failed on the make test step. Would you help me with the error message? Thanks, Lisa Tan, Lead Systems Integrator eServices Strategic Technologies Computing Information Technology Wayne State University 5925 Woodward Ave. Rm# 313 Detroit, MI 48202 Phone: 313-577-2561 Fax: 313-577-0431 Email: [EMAIL PROTECTED] To Whom It May Concern: I tried to install the Openssl and failed on the make test step. Would you help me with the error message? Thanks, Lisa Tan,Lead Systems Integrator eServices Strategic Technologies Computing Information Technology Wayne State University 5925 Woodward Ave. Rm# 313 Detroit, MI 48202 Phone: 313-577-2561 Fax: 313-577-0431 Email: [EMAIL PROTECTED] testlog Description: Binary data
Re: [openssl.org #1493] -march=ultrasparc doesn't work on Solaris 9
According to http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Option- Summary.html#Option-Summary: SPARC Options -mcpu=cpu-type -mtune=cpu-type -mcmodel=code-model -m32 -m64 -mapp-regs -mno-app-regs -mfaster-structs -mno-faster-structs -mfpu -mno-fpu -mhard-float -msoft-float -mhard-quad-float -msoft-quad-float -mimpure-text -mno-impure-text -mlittle-endian -mstack-bias -mno-stack-bias -munaligned-doubles -mno-unaligned-doubles -mv8plus -mno-v8plus -mvis -mno-vis -threads -pthreads -pthread -mcpu wasn't deprecated on SPARC. I think it was only deprecated on i386. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1493] -march=ultrasparc doesn't work on Solaris 9
Can you upgrade to a newer version of gcc? More recent versions of gcc give endless warnings about the -mcpu option being deprecated. I'm running gcc 4.1.2, the latest release according to http:// gcc.gnu.org/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1493] -march=ultrasparc doesn't work on Solaris 9
Seems that some platforms support -mcpu and others -march, ugh. I've reverted the sparc changes to the Configure script. Please try this patch: http://cvs.openssl.org/chngview?cn=15967 or the next snapshot. Works great. Thanks! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1463] Testing
On Wed, Jan 31, 2007, via RT wrote: This is a test, please ignore. Testing a reply, please ignore. -- Lutz Jaenicke [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1463] Testing
On Wed, Jan 31, 2007, via RT wrote: This is a test, please ignore. Reply test, please ignore. -- Lutz Jaenicke [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1463] Testing
On Wed, Jan 31, 2007, via RT wrote: This is a test, please ignore. Reply test, please ignore. -- Lutz Jaenicke [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1463] Testing
On Wed, Jan 31, 2007, [EMAIL PROTECTED] via RT wrote: On Wed, Jan 31, 2007, via RT wrote: This is a test, please ignore. Reply test, please ignore. One more test. -- Lutz Jaenicke [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1463] Testing
On Wed, Jan 31, 2007, [EMAIL PROTECTED] via RT wrote: On Wed, Jan 31, 2007, via RT wrote: This is a test, please ignore. Reply test, please ignore. One more test. -- Lutz Jaenicke [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1454] RSA key exponents different from 3 and F4
Dear all,
these are 4 lines should be corrected in the proposed patch to exclude
Nils' unsecure choice of an exponent 1:
+ if ( (!BN_is_odd(bn)) || BN_is_one(bn) )
+{
+BIO_printf(bio_err,Error, exponent must be an odd integer
and greater than 1\n);
+goto bad;
+}
Regards,
Ann.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #980] -starttls smtp not standard compliant and leads to misleading unknown protocol error
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1431] bug in setting ECDH and ECDSA methods
Setting ECDH and ECDSA methods in ENGINE interface does not
work properly. I can not set up ENGINE ECDH and ECDSA methods
as default.
In the file crypto/engine/tb_ecdh we have
int ENGINE_set_default_ECDH(ENGINE *e)
{
if(e-ecdh_meth)
return engine_table_register(ecdh_table,
engine_unregister_all_ECDH, e, dummy_nid, 1,
0);
return 1;
}
and should be
int ENGINE_set_default_ECDH(ENGINE *e)
{
if(e-ecdh_meth)
return engine_table_register(ecdh_table,
engine_unregister_all_ECDH, e, dummy_nid, 1,
1);
return 1;
}
In the file crypto/engine/tb_ecdsa we have
int ENGINE_set_default_ECDSA(ENGINE *e)
{
if(e-ecdsa_meth)
return engine_table_register(ecdsa_table,
engine_unregister_all_ECDSA, e, dummy_nid, 1,
0);
return 1;
}
and should be
int ENGINE_set_default_ECDSA(ENGINE *e)
{
if(e-ecdsa_meth)
return engine_table_register(ecdsa_table,
engine_unregister_all_ECDSA, e, dummy_nid, 1,
1);
return 1;
}
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1043] Updated 0.9.7g NetWare Patch for the Contribution page
Hi Walker, Sorry to write you personally. I couldn't get any help in OpenSSL dev forums. Could you help me to resolve Link Error: Undefined symbol: RunningProcess in rand_nw.obj? I do not see any error while comiling and got this when tried to link to my application. I do not see RunningProcess defined in any part of the code. I used Codewarrior to build SSL. I'm almost blocked with this issue. Your respone will be greatly aprecited... Thanks in advance, Regards,any Hem -- This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com http://www.opensubscriber.com/message/openssl-dev@openssl.org/1125054.html __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1414] OpenSSL for X86_64
Hi! I have a simple query. When I try to create a x32 library on a x64 bit Linux using the -m32 flag which refers to OpenSSL I receive an error opensslconf-i386.h: Not found. I tried locating the problem but was not able to find one. Is this related to something I did not do while installing the OpenSSL? Or did I miss out on some configuration option while installing? Thanks and Regards, Saurabh. The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1401] Proxy module
Hi, I'm submitting this patch as suggested below. This patch adds the x509_proxy module to openssl which can create and printout proxy certificates. I don't know if the licensing in the patch adheres to OpenSSL requirements, If there are any problems please email me and I'll figure out how to modify it appropriately. Thank you, --Ivan PS -- the command used to create this (from two cvs trees) was: diff -u -N -r -x CVS -x certs clean proxy, so it can be applied to a clean cvs tree with: (from within the checked out dir) patch -p1 -u patchfile. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kyle Hamilton Sent: Friday, September 29, 2006 1:40 PM To: openssl-dev@openssl.org Subject: Re: Proxy module First off, you need to get rid of the all rights reserved copyright clause. Changing it so that it states you grant usage and distribution rights with OpenSSL under its license would be a good start. (Licensing, licensing, we all have to worry about it. :( ) Next, create a diff -c (contextual diff) against the current CVS, including changes to the makefiles. Then, submit that diff as a patch against the current CVS to [EMAIL PROTECTED] (At least this is how I presume things should be done. This module may need to go into the contrib/ directory, as it does affect validation and thus security.) -Kyle H On 9/29/06, Ivan R. Judson [EMAIL PROTECTED] wrote: Hi, Awhile ago I mentioned wanting to get proxy support (RFC 3280, yes it's expired, but in use) into openssl as simply as possible. I've built the attached module, that does what I wanted. What's the best way to try and get this integrated into the standard distribution? Thanks, --Ivan -- -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1401] AutoReply: Proxy module
Attached are the two additional requirements, as specified by Jeffrey Altman. Thanks, --Ivan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of OpenSSL-Bugs Sent: Thursday, October 05, 2006 3:22 AM To: [EMAIL PROTECTED] Subject: [openssl.org #1401] AutoReply: Proxy module Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: Proxy module, a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #1401]. Please include the string: [openssl.org #1401] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Also, please note that all attachments to your message have been stored in the database, but are not included in any outgoing mail. Thank you, -- --- Hi, I'm submitting this patch as suggested below. This patch adds the x509_proxy module to openssl which can create and printout proxy certificates. I don't know if the licensing in the patch adheres to OpenSSL requirements, If there are any problems please email me and I'll figure out how to modify it appropriately. Thank you, --Ivan PS -- the command used to create this (from two cvs trees) was: diff -u -N -r -x CVS -x certs clean proxy, so it can be applied to a clean cvs tree with: (from within the checked out dir) patch -p1 -u patchfile. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kyle Hamilton Sent: Friday, September 29, 2006 1:40 PM To: openssl-dev@openssl.org Subject: Re: Proxy module First off, you need to get rid of the all rights reserved copyright clause. Changing it so that it states you grant usage and distribution rights with OpenSSL under its license would be a good start. (Licensing, licensing, we all have to worry about it. :( ) Next, create a diff -c (contextual diff) against the current CVS, including changes to the makefiles. Then, submit that diff as a patch against the current CVS to [EMAIL PROTECTED] (At least this is how I presume things should be done. This module may need to go into the contrib/ directory, as it does affect validation and thus security.) -Kyle H On 9/29/06, Ivan R. Judson [EMAIL PROTECTED] wrote: Hi, Awhile ago I mentioned wanting to get proxy support (RFC 3280, yes it's expired, but in use) into openssl as simply as possible. I've built the attached module, that does what I wanted. What's the best way to try and get this integrated into the standard distribution? Thanks, --Ivan -- -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1398] 0.9.7k: documentation typo
Just a minor typo in the CHANGES file: s/deactive/deactivate/ --- CHANGES 2006-09-05 08:34:04.0 + +++ CHANGES.new 2006-09-23 10:30:41.0 + @@ -22,7 +22,7 @@ draft-ietf-tls-56-bit-ciphersuites-0[01].txt, but do not really appear there. - Also deactive the remaining ciphersuites from + Also deactivate the remaining ciphersuites from draft-ietf-tls-56-bit-ciphersuites-01.txt. These are just as unofficial, and the ID has long expired. [Bodo Moeller] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1390] Patch for test/Makefile 0.9.8
With the current stable snapshot of 0.9.8, make test fails under DJGPP because of a typo in test/Makefile, which only affects platforms where $(EXE_EXT) is not null. This should fix it. Doug --- openssl-0.9.8/test/Makefile.ori 2006-08-28 03:05:56.0 -0800 +++ openssl-0.9.8/test/Makefile 2006-09-14 01:08:12.0 -0800 @@ -283,7 +283,7 @@ # @echo test Rijndael # ../util/shlib_wrap.sh ./$(AESTEST) -test_ige: $(IGETEST) +test_ige: $(IGETEST)$(EXE_EXT) @echo Test IGE mode ../util/shlib_wrap.sh ./$(IGETEST) -- Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1381] [PATCH] set rpath on shared library for openssl command proper loading
Platform: NetBSD 1.6.1 x86 (full ./testlog attached below) OpenSSL: 0.9.8b openssl command fails to load, when built with libssl and libprypto as both shared, and the OS tries a good job on finding shared library dependencies on runtime. [EMAIL PROTECTED] /usr/ssl/bin/openssl Shared object libcrypto.so.0.9.8 not found Standard problems, such as missing RPATH in the executable, is already eliminated. What is happening: 1) openssl executable is built with RPATH=/usr/ssl/lib, and NEEDED libssl.so.0.9.8, libcrypto.so.0.9.8, libc.so.12 . 2) The dynamic loader first pulls in libssl.so.0.9.8 and libcrypto.so.0.9.8, using the executable's RPATH=/usr/ssl/lib as the search path, which succeeds in loading /usr/ssl/lib/libssl.so.0.9.8 and /usr/ssl/lib/libcrypto.so.0.9.8 . 3) The pulled in libssl.so.0.9.8 is built with NEEDED libcrypto.so.0.9.8, and no RPATH. 4) The dynamic loader thus tries to load libcrypto.so.0.9.8, this time using the default search path only, which tries for only /usr/lib/libcrypto.so.0.9.8, and fails. (This particular loader seems not try to compare filename or signature for already loaded library) Setting LD_DEBUG=1 will reveal the steps: [EMAIL PROTECTED] env LD_DEBUG=1 /usr/ssl/bin/openssl version processing mapping libm.so.0 machdep.fpu_present 1:libm387.so.0,libm.so.0 library libm.so.0 sysctl machdep.fpu_present sysctl 7, 1 sysctl 7, 2 library libm387.so.0 library libm.so.0 key 1 /usr/libexec/ld.elf_so is initialized, base address = 0x480a2000 processing main program's program header added path /usr/ssl/lib RPATH of openssl preloading objects loading needed objects load by name libssl.so.0.9.8 0x480af000 Searching for libssl.so.0.9.8 (0x480af200) request by openssl Trying /usr/ssl/lib/libssl.so.0.9.8 0x480b5000 .. 0x480eefff: /usr/ssl/lib/libssl.so.0.9.8 load by name libcrypto.so.0.9.8 0x480af000 Searching for libcrypto.so.0.9.8 (0x480af200) request by openssl Trying /usr/ssl/lib/libcrypto.so.0.9.8 0x480ef000 .. 0x48212fff: /usr/ssl/lib/libcrypto.so.0.9.8 load by name libc.so.12 0x480af000 Searching for libc.so.12 (0x480af200) request by openssl Trying /usr/ssl/lib/libc.so.12 Trying /usr/lib/libc.so.12 added path /usr/lib 0x48213000 .. 0x482b2fff: /usr/lib/libc.so.12 load by name libcrypto.so.0.9.8 0x480af000 Searching for libcrypto.so.0.9.8 (0x480af400) request by libssl.so Trying /usr/lib/libcrypto.so.0.9.8 tries only default path, as RPATH of libssl.so is unset Shared object libcrypto.so.0.9.8 not found The attached patch will always add the $(LIBRPATH) to RPATH, also when building a shared library. Workaround without the patch: Build with make SHARED_LDFLAGS=-Wl,-rpath,/usr/ssl/lib Note that the method of recursive searching the dependent shared library is different on each OS; - some os just ignores RPATH on *.so and only use the executable's RPATH (Solaris) - some will use RPATH on the *.so individually for each loaded library (NetBSD) - some will MERGE the current RPATH with the loaded *.so (IRIX) so some platforms are, as the result, unaffected whether there's RPATH on *.so or not. There seems a debate many times on the list about setting RPATH on the shared library, but it should NOT be a problem using ELF platform on normal circumstances. The Normal Circumstances: - When compiling yourselves, you set the correct --prefix, install where it should and off you go. - When the Distributor wants the package to go to different directory, he should first compile with --prefix with that directory. - When the Administrator wants to install the package into directory different from which the package defaults, he should setup LD_LIBRARY_PATH himself. That's what the environ is for. It could be a problem when the admin wants a twisted setup like - the OS has /usr/lib/libz, /usr/lib/libssl and /usr/lib/libcrypto - admin compiled the latest OpenSSL on /usr/local/lib - he has another libz on /usr/local/lib/libz, which may or may not be new (not unrealistic when you had built X11R* yourself) - he wants the executables to use /usr/local/lib/libssl, /usr/local/lib/libcrypto with /usr/lib/libz but the admin already needs to grok with Makefile to properly link with libs he wants. OpenSSL does't have to support that far. OpenSSL self-test report: OpenSSL version: 0.9.8b Last change: When applying a cipher rule check to see if string matc... Options: --prefix=/usr/ssl --openssldir=/usr/ssl enable-shared enable-zlib-dynamic no-asm no-gmp no-idea no-krb5 no-mdc2 no-rc5 OS (uname): NetBSD vega.sra-tohoku.jp 1.6.1 NetBSD 1.6.1 (QQQ) #10: Thu Jun 19 18:21:56 JST 2003 [EMAIL PROTECTED]:/export/NetBSD/sys/arch/i386/compile/QQQ i386 OS (config): i686-whatever-netbsd Target (default): BSD-x86-elf Target: BSD-x86-elf Compiler:
Re: [openssl.org #1187] Openssl - unable to load from /usr/local/ssl/openssl.cnf on win nt
1st step : c:\openssl\binopenssl genrsa -out myprvkey.pem 1024 2nd step : i think this solves the problem to create the pulic certificate using openssl. jus type this c:\openssl\binopenssl req -config c:\openssl\bin\openssl.cnf -new -key myprvkey.pem -x509 -days 365 -out mypubcert.pem -- This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com http://www.opensubscriber.com/message/openssl-dev@openssl.org/1945280.html __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1356] a make test problme of openssl
Hi,I am making openssl0.9.8 now,but the system always hung when do make test,the last output in the follow: The following command should have some OK's and some failures There are definitly a few expired certificates ../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs ../certs/*.pem ../certs/argena.pem: OK ../certs/argeng.pem: OK ../certs/eng1.pem: OK ../certs/eng2.pem: OK ../certs/eng3.pem: OK ../certs/eng4.pem: OK ../certs/eng5.pem: OK ../certs/RegTP-5R.pem: /C=DE/O=Regulierungsbeh\xC8orde f\xC8ur Telekommunikation und Post/0.2.262.1.10.7.20=1/CN=5R-CA 1:PN error 10 at 0 depth lookup:certificate has expired OK ../certs/RegTP-6R.pem: /C=DE/O=Regulierungsbeh\xC8orde f\xC8ur Telekommunikation und Post/0.2.262.1.10.7.20=1/CN=6R-Ca 1:PN error 10 at 0 depth lookup:certificate has expired OK ../certs/thawteCb.pem: OK ../certs/thawteCp.pem: OK ../certs/vsign1.pem: OK ../certs/vsign3.pem: OK ../certs/vsignss.pem: OK ../certs/wellsfgo.pem: OK then the system hung in here! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1281] 'make report' output
[EMAIL PROTECTED] via RT schrieb: Hello Steffen, I have the same problem. Is there a solution? Thank you in advance, Wolf-Dietrich Filss Hallo, ja es gibt eine Loesung. Schau mal zwei Betraege weiter oben, da steht: The fix is trivial; in the solaris-x86-cc line of Configure, you must replace -fast -xO5 with -fast -xdepend=no (note: -xO5 was implied by the -fast argument.) The implicit -xdepend=yes implied by -fast was causing this failure. There may be further code fixes in the evp code to ensure that data dependencies in the loops can be unrolled and optimized. Gruesse, Steffen Unger -- Steffen Unger [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1337] Bug: Crash in openssl0.9.8b in obj_name_cmp
I am using Openssh 3.8.1p1 on Solaris 2.8 compiled with gcc 3.2.3. I have
nsswitch configured to use file and PADLs ldap module.
When I use nss_ldap without SSL In can login without problem, but with SSL
enabled sshd crashes. When I use openssl 0.9.8b sshd crashes in
obj_name_cmp(line
101):
87 static int obj_name_cmp(OBJ_NAME *a, OBJ_NAME *b)
88 {
89 int ret;
90
91 ret=a-type-b-type;
92 if (ret == 0)
93 {
94 if ((name_funcs_stack != NULL)
95 (sk_NAME_FUNCS_num(name_funcs_stack)
a-type))
96 {
97
ret=sk_NAME_FUNCS_value(name_funcs_stack,a-type)
98 -cmp_func(a-name,b-name);
99 }
100 else
101 ret=strcmp(a-name,b-name);
102 }
103 return(ret);
104 }
#35;0 0xff132d58 in strcmp () from /usr/lib/libc.so.1
#35;1 0x96660 in obj_name_cmp (a=0x121788, b=0x142290) at o_names.c:101
#35;2 0x950d8 in getrn (lh=0x120c50, data=0x142290, rhash=0x142278) at
lhash.c:418
#35;3 0x94d40 in lh_insert (lh=0x120c50, data=0x142290) at lhash.c:189
#35;4 0x96208 in OBJ_NAME_add (name=0x0, type=2, data=0xfee7163c ) at
o_names.c:175
#35;5 0x6d978 in EVP_add_cipher (c=0xfee7163c) at names.c:71
#35;6 0xfeeb4f70 in SSL_library_init () from /opt/DBssllib/lib/libssl.so.0.9.8
#35;7 0xff04478c in ldap_pvt_tls_init () at tls.c:169
#35;8 0xff046298 in ldap_int_tls_start (ld=0x12cb00, conn=0x12cb90,
srv=0x12dbe8) at tls.c:1332
#35;9 0xff02906c in ldap_int_open_connection (ld=0x12cb00, conn=0x12cb90,
srv=0x12cbf0, async=0) at open.c:365
#35;10 0xff038a3c in ldap_new_connection (ld=0x12cb00, srvlist=0x12cbf0,
use_ldsb=1, connect=1231856, bind=0x0) at request.c:315
#35;11 0xff028af0 in ldap_open_defconn (ld=0x12cb00) at open.c:30
#35;12 0xff0385c0 in ldap_send_initial_request (ld=0x12cb00, msgtype=96,
dn=0xff08c1a3 uid=unixclient,dc=group,dc=com, ber=0x12cc20) at
request.c:98
#35;13 0xff02ef60 in ldap_sasl_bind (ld=0x12cb00, dn=0xff08c1a3
uid=unixclient,dc=group,dc=com, mechanism=0x0, cred=0xffbebe58,
sctrls=0x0, cctrls=0x12cc20, msgidp=0xffbebe54) at sasl.c:148
#35;14 0xff02f720 in ldap_simple_bind (ld=0x12cb00, dn=0xff08c1a3
uid=unixclient,dc=group,dc=com, passwd=0xff08c1f8 dummy) at sbind.c:81
#35;15 0xff072c90 in do_bind (ld=0x12cb00, timelimit=5, dn=0xff08c1a3
uid=unixclient,dc=group,dc=com, pw=0xff08c1f8 dummy, with_sasl=0) at
ldap-nss.c:1420
#35;16 0xff07292c in do_open () at ldap-nss.c:1277
#35;17 0xff073ad0 in _nss_ldap_search_s (args=0xffbec860,
filterprot=0xff08e798
((objectclass=posixGroup)(memberUid=%s)),
sel=LM_GROUP, sizelimit=0, res=0xffbec85c) at ldap-ns.c:2285
#35;18 0xff074f68 in _nss_ldap_getgroupsbymember_r (be=0x12db88,
args=0xffbecd5c) at ldap-grp.c:305
#35;19 0xff1498c4 in nss_search () from /usr/lib/libc.so.1
#35;20 0xff1986a0 in _getgroupsbymember () from /usr/lib/libc.so.1
#35;21 0xff140f08 in initgroups () from /usr/lib/libc.so.1
#35;22 0x30314 in temporarily_use_uid (pw=0x12b320) at uidswap.c:88
#35;23 0x37b54 in user_key_allowed2 (pw=0x12b320, key=0x12db70, file=0x12f280
/home/moelma/.ssh/authorized_keys2) at auth2-pubkey.c:179
#35;24 0x37eb0 in user_key_allowed (pw=0x12b320, key=0x12db70) at
auth2-pubkey.c:264
#35;25 0x37aa4 in userauth_pubkey (authctxt=0x123408) at auth2-pubkey.c:142
#35;26 0x320b4 in input_userauth_request (type=50, seq=6, ctxt=0x123408) at
auth2.c:195
#35;27 0x5119c in dispatch_run (mode=0, done=0x123408, ctxt=0x123408) at
dispatch.c:93
#35;28 0x31cf0 in do_authentication2 (authctxt=0x123408) at auth2.c:94
#35;29 0x2ac3c in main (ac=11, av=0x2a) at sshd.c:1481
It seems sshd calls ldap with ssl in the main process and in a forked process.
And I think one process might delete the others pointers, but couldn't confirm
it
yet.
BTW If I use an older opesnssl version I get the error in err_cmp and it has
been also reported on RedHat
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121734 for pam_ldap.
and I think it is similar to the open ticket #35;678
Regards
Markus
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1329] Insecure shared libraries in openssl-0.9.8b
Insecure creation of shared libraries in openssl-0.9.8b. The following problem exists for the AIX platform (and maybe others). CC=xlc ./config --prefix=/usr/local shared make CC=xlc make install creates libcrypto.so, libssl.so and engines/*.so with relative paths (. and .. respectively) in the loader section of the libraries. dump -H libssl.so for instance shows the following: libssl.so: ***Loader Section*** Loader Header Information VERSION# #SYMtableENT #RELOCentLENidSTR 0x0001 0x0299 0x0bf4 0x003c #IMPfilIDOFFidSTR LENstrTBLOFFstrTBL 0x0003 0xcde8 0x3197 0xce24 ***Import File Strings*** INDEX PATH BASEMEMBER 0 .:/usr/vac/lib:/usr/lib:/lib 1libcrypto.so 2libc.a shr.o Having relative paths in the library search path is generaly regarded as a security issue. The problem can be circumvented by using the following commands: CC=xlc ./config --prefix=/usr/local shared make CC=xlc EX_LIBS='-blibpath:$(INSTALLTOP)/lib:/usr/lib:/lib' make install As it is now the generated applications (i.e openssl command) are linked to the static libraries (lib*.a) so make test still works but does not test the shared libraries. It is possible to trick make into linking to the shared libraries, but then make test is no longer valid because it either fails (if the openssl libraries have never been installed before) or use the libraries of the previously installed version. A proper solution would require make to link without -blibpath: and make install, instead of copying, to link using the proper -blibpath: option. Paul Tedaldi __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1298] OpenSSL bug in libcrypto.so:RAND_poll() crashes apache2 @ startup
Hello,
I have found a bug in libcrypto.so which causes Apache2 to crash or
deadlock when a few hundred virtual hosts are configured in a
SSL-enabled Apache2 instance.
The problem is Apache2 opens a number of files per virtual host before
initializing libcrypto.so's random seed, given enough virtual hosts the
file descriptor the RAND_poll() open() gets when it opens its entropy
source will exceed FD_SETSIZE. This is a serious problem because RAND_poll()
internally uses select() to watch for data ready to be read from the
entropy source. When the fd exceeds FD_SETSIZE (1024 on modern linux
systems) this will cause deadlocks / segfaults.
I have created a patch to convert this to use poll() which does not have
this limitation and is much better suited for watching a single file
descriptor. The patch is included below. I'm not sure if you guys need
to make this check if poll() is available in the system to keep things
portable, but if the select() call needs to be kept when poll() is
unavailable, it has to deal with fd = FD_SETSIZE and not give it to
select().
This was using 0.9.7e-3sarge1 from debian stable as the original source tree, I
checked the 0.9.7i source on openssl.org and the related code is the same.
It's a relatively high priority because it makes apache2 flip out when it gets
hit, might wanna get a fixed version out soon.
Thanks for the OpenSSL project,
Vito Caputo
Hostway Linux Systems Developer
--- rand_unix.c.orig2006-03-21 17:01:24.0 -0600
+++ rand_unix.c 2006-03-21 21:58:12.0 -0600
@@ -114,6 +114,7 @@
#include cryptlib.h
#include openssl/rand.h
#include rand_lcl.h
+#include sys/poll.h
#if !(defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_WIN32) ||
defined(OPENSSL_SYS_VMS) || defined(OPENSSL_SYS_OS2) ||
defined(OPENSSL_SYS_VXWORKS))
@@ -124,6 +125,7 @@
#include unistd.h
#include time.h
+
#ifdef __OpenBSD__
int RAND_poll(void)
{
@@ -165,53 +167,37 @@ int RAND_poll(void)
* have this. Use /dev/urandom if you can as /dev/random may block
* if it runs out of random entries. */
- for (randomfile = randomfiles; *randomfile n ENTROPY_NEEDED;
randomfile++)
- {
+ for (randomfile = randomfiles; *randomfile n ENTROPY_NEEDED;
randomfile++) {
if ((fd = open(*randomfile, O_RDONLY|O_NONBLOCK
#ifdef O_NOCTTY /* If it happens to be a TTY (god forbid), do not make it
our controlling tty */
- |O_NOCTTY
+ |O_NOCTTY
#endif
#ifdef O_NOFOLLOW /* Fail if the file is a symbolic link */
- |O_NOFOLLOW
+ |O_NOFOLLOW
#endif
- )) = 0)
- {
- struct timeval t = { 0, 10*1000 }; /* Spend 10ms on
- each file. */
+ )) = 0) {
int r;
- fd_set fset;
+ struct pollfd rfd = {fd, POLLIN, 0};
+ int t = 10; /* Spend 10ms on each file. */
+
+ /* Patched to use poll() instead of select(), sometimes
this gets called
+* with = FD_SETSIZE files opened already (apache2).
+* When fd is = FD_SETSIZE the behavior is undefined
(likely a buffer
+* overflow...), I observed segfaults deadlocks.
+* 3/21/2006 - Vito Caputo - [EMAIL PROTECTED] */
- do
- {
- FD_ZERO(fset);
- FD_SET(fd, fset);
+ do {
r = -1;
- if (select(fd+1,fset,NULL,NULL,t) 0)
- t.tv_usec=0;
- else if (FD_ISSET(fd, fset))
- {
- r=read(fd,(unsigned char *)tmpbuf+n,
- ENTROPY_NEEDED-n);
- if (r 0)
- n += r;
- }
-
- /* Some Unixen will update t, some
- won't. For those who won't, give
- up here, otherwise, we will do
- this once again for the remaining
- time. */
- if (t.tv_usec == 10*1000)
- t.tv_usec=0;
+ if((poll(rfd, 1, t) 0) (rfd.revents
POLLIN)) {
+ r = read(fd, (unsigned char *)tmpbuf +
n, ENTROPY_NEEDED - n);
+ if(r 0) n += r;
}
-
[openssl.org #1292] SSL_add_dir_cert_subjects_to_stack does not check for read access of file, breaking TLS enabled LDAP clients
Hi,
initial report at:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185080
Imho it's more a OpenSSL than a OpenLDAP client problem.
Regards,
Peter
Description of problem:
During tracking down, why a LDAP enabled postfix cannot lookup via TLS
enabled
LDAP client I found that openssl function SSL_add_dir_cert_subjects_to_stack
is
very optimistic relating to the files found in a specified directory.
Version-Release number of selected component (if applicable):
openssl-0.9.7a-43.4
also openssl-0.9.7.i (latest 0.9.7 release)
also openssl-0.9.8.a (latest 0.9.8 release)
in conjunction with
openldap-2.2.13-4
also openldap-2.2.30 (latest 2.2 release)
also openldap-2.3.20 (latest 2.3 release)
How reproducible:
Always
Steps to Reproduce:
1. Create a directory for local PKI storage, e.g.
/etc/pki
2. Store local CA, local server certificates and local keys into this
directory
3. Set proper permissions to keys, e.g.
chmod o-rwx *.key.pem
# ll /etc/pki/
total 120
lrwxrwxrwx 1 root root 23 Sep 14 15:42 592fcc04.0 - ca.crt
-r--r--r-- 1 root root 1834 Sep 14 15:39 ca.crt
-r--r--r-- 1 root root 2529 Sep 14 15:39 AE-CA-Class4-2005-A.crt
-r 1 root root 5875 Sep 14 15:45 ca+cert+key.pem
-r--r--r-- 1 root root 4196 Sep 14 16:07 ca+cert.pem
-r--r--r-- 1 root root 2362 Sep 14 15:37 cert.crt
-r--r- 1 root root 4041 Sep 14 15:50 cert+key.pem
-r--r- 1 root ldap 1679 Sep 14 15:37 key.pem (note: group=ldap for LDAP
server, which reads key file for server TLS after changing the user to
ldap)
4. Configure /etc/openldap/slapd.conf for TLS like
TLSCACertificateFile/etc/pki/ca.crt
TLSCACertificatePath/etc/pki
TLSCertificateFile /etc/pki/crt.crt
TLSCertificateKeyFile /etc/pki/key.pem
5. Configure /etc/openldap/ldap.conf related
URI ldaps://ldapserver/
#URIldap://ldapserver/
BASE dc=example,dc=com
TLS_CACERTDIR /etc/pki# - important!
6. Try ldapsearch usig TLS as root:
ldapsearch -x -H ldaps://ldapserver/
Result: working
7. Try ldapsearch using TLS as normal user:
$ ldapsearch -x -v -H ldaps://ldapserver
Result: not working, message:
ldap_initialize( ldaps://ldapserver )
ldap_bind: Can't contact LDAP server (-1)
Using strace shows me:
open(/etc/pki/key.pem, O_RDONLY) = -1 EACCES (Permission denied)
close(4)= 0
write(2, ldap_bind: Can\'t contact LDAP server (-1)\n, 42ldap_bind: Can't
contact LDAP server (-1)
) = 42
exit_group(1) = ?
Process 15652 detached
Ooops, why will ldapsearch open this key file??? Ok, thanks to opensource we
are
now now digging through the code:
A) openldap: openldap-2.2.13/libraries/libldap/tls.c
(same code in newer/latest versions)
static STACK_OF(X509_NAME) *
get_ca_list( char * bundle, char * dir )
{
STACK_OF(X509_NAME) *ca_list = NULL;
if ( bundle ) {
ca_list = SSL_load_client_CA_file( bundle );
}
#if defined(HAVE_DIRENT_H) || defined(dirent)
if ( dir ) {
int freeit = 0;
if ( !ca_list ) {
ca_list = sk_X509_NAME_new_null();
freeit = 1;
}
if ( !SSL_add_dir_cert_subjects_to_stack( ca_list, dir )
freeit ) {
sk_X509_NAME_free( ca_list );
ca_list = NULL;
}
}
#endif
return ca_list;
}
Ok, openldap calls an openssl functions to read all certificates in dir
and
add to ca_list.
Note that here is also an opportunity for improvements to be more graceful,
if
SSL_load_client_CA_file works but SSL_add_dir_cert_subjects_to_stack fails.
Currently, the whole ca_list ist dropped.
B) openssl: openssl-0.9.7a/ssl/ssl_cert.c
(same code in newer/latest versions)
/*!
* Add a directory of certs to a stack.
* \param stack the stack to append to.
* \param dir the directory to append from. All files in this directory will
be
* examined as potential certs. Any that are acceptable to
* SSL_add_dir_cert_subjects_to_stack() that are not already in the stack
will be
* included.
* \return 1 for success, 0 for failure. Note that in the case of failure
some
* certs may have been added to \c stack.
*/
#ifndef OPENSSL_SYS_WIN32
#ifndef OPENSSL_SYS_VMS /* This may be fixed in the future */
#ifndef OPENSSL_SYS_MACINTOSH_CLASSIC /* X: Better scheme needed! */
int SSL_add_dir_cert_subjects_to_stack(STACK_OF(X509_NAME) *stack,
const char *dir)
{
DIR *d;
struct dirent *dstruct;
int ret = 0;
CRYPTO_w_lock(CRYPTO_LOCK_READDIR);
d = opendir(dir);
/* Note that a side effect is that the CAs will be sorted by name */
if(!d)
{
SYSerr(SYS_F_OPENDIR, get_last_sys_error());
ERR_add_error_data(3, opendir(', dir, '));
Re: [openssl.org #1281] Solaris9: 'make test' failure in evp_test
via RT schrieb: The fix is trivial; in the solaris-x86-cc line of Configure, you must replace -fast -xO5 with -fast -xdepend=no (note: -xO5 was implied by the -fast argument.) The implicit -xdepend=yes implied by -fast was causing this failure. There may be further code fixes in the evp code to ensure that data dependencies in the loops can be unrolled and optimized. excellent! now it works fine thanks a lot ! best regards, Steffen -- Steffen Unger [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1281] Solaris9: 'make test' failure in evp_test
via RT schrieb: Confirming identical results on Solaris 10 x86 patchlevel 118844_28, built with Sun C 5.8 2005/10/13. Any word or suggestions to help debug? gcc compilation does not exhibit this issue. Some info follows: - env output _=/bin/env MANPATH=/usr/man:/usr/local/man:/usr/openwin/man:/opt/csw/man SSH_TTY=/dev/pts/8 PATH=/bin:/usr/bin:/usr/sbin:/opt/csw/bin:/opt/csw/sbin:/usr/ccs/bin:/opt/SUNWspro/bin EDITOR=vi LOGNAME=sunger USER=sunger SHELL=/bin/ksh HOME=/export/home/sunger FCEDIT=vi SSH_CLIENT=172.16.10.75 1267 22 TERM=xterm PWD=/export/home/sunger/software/build/openssl-0.9.8a TZ=Europe/Berlin ENV=/export/home/sunger/.kshrc - ./config output attached as file - warning from make output attached as file - make output without warnings attached as file - make test output and now my speculations :-) 1) compiler options - during make -xtarget=ultra -xarch=v8plus is used - on http://developers.sun.com/prodtech/cc/articles/options.html SUN descripted -xtarget=ultra3 -xarch=v8plusa 2) may be it helps to use some GNU tools during make test I saw some messages about bc - may be there are some problems during make with some other SUN tools 3) compiler optimisation May be the SUN compiler will use optimisation a little bit to intensiv. May be it helps to recompile the package with lower optimisation. Unfortunatly my expirience with c-programming is to short to well interpret this error. But my favorit is No. 2 and No. 3 . Hopefully that helps. best regards, Steffen Unger -- Steffen Unger [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1281] Solaris9: 'make test' failure in evp_test
attached you can find the 'make report' output from one of my Solaris9 maschines. I used the SunStudio11 compiler on Solaris9 (SUN Fire V890) Is there any fix available for this problem ? thanks in advance ! regards, Steffen -- Steffen Unger [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1274] Possible bug in sha512
I have used openssl in an application for the first time, so this might be my code, but there is strong evidence that it is not. I linked Electric Fence in my application and when I use the sha512 digest, I get a Bus Error, when I use the md5 digest, I do not. I am running on a sparc Ultra-2 with Solaris 8, and using OpenSSL 0.9.8. The backtrace from the core dump is: #0 0xff0d95d8 in SHA512_Init () from /usr/local/lib/libcrypto.so.0.9.8 #1 0xff134798 in EVP_DigestInit_ex () from /usr/local/lib/libcrypto.so.0.9.8 #2 0xff0dd724 in HMAC_Init_ex () from /usr/local/lib/libcrypto.so.0.9.8 #3 0x0001113c in main (argc=1, argv=0xffbef7a4) at hmac.c:33 I have attached the source of the test file that gets this error. Thanks. Jim Sansing __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204]: bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Hi, ... see below Christiane -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kurt Roeckx via RT Sent: Thursday, January 19, 2006 10:06 PM To: Kämpfe, Christiane Cc: openssl-dev@openssl.org Subject: [openssl.org #1204]: bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling Hi, It seems to me that tls1_enc() is setting SSL_OP_TLS_BLOCK_PADDING_BUG, while the other side does not have that bug. this is my opinion too. The code looks like this: /* First packet is even in size, so check */ if ((memcmp(s-s3-read_sequence, \0\0\0\0\0\0\0\0,8) == 0) !(ii 1)) s-s3-flags|=TLS1_FLAGS_TLS_PADDING_BUG; The 0.9.8 code seems to compress by default in case that zlib compression has been added, while 0.9.7 doesn't. aaaha. I have only 0.9.8 - so I didn't know this detail. This seems to generate a (compressed) package of size 45 in most cases, but 44 in some cases, depending on the message being send. In case it's 45, ii is set to 2 and i to 3, like it should, but the flags get set to TLS1_FLAGS_TLS_PADDING_BUG, and i gets decreased to 2. So the lenth gets sets to 46 instead of 45. correct - I've got this effect. I can not find a good way to always make sure this workaround for that bug works proplery, but I think we should assume there is no bug. So I propose the attached patch to fix it. This should have as effect that in most case that the bug is present, it still sets the flag, but it won't in the case were the last byte just happens to be the same as the padding byte. This patch fixes it for me, so that two versions with 0.9.8 with zlib compression support can talk to each other without errors. Kurt ... hmmm, where is the patch ? I didn't know how to verify the existence or not-existence of the BUG inside the data ... Any ideas about compatibility with older versions including the BUG. Christiane __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Hmm, I want to use this for an multi usable web service independent of apache and no restrictions (or so) for the users or user scenarios about openssl usage ... If the caller has an certificate generated by an not-restricted openssl using whatever he want to to ... how can I=web service handle this certificate without getting an bad record mac error ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of via RT Sent: Saturday, January 07, 2006 3:22 AM To: Kämpfe, Christiane Cc: openssl-dev@openssl.org Subject: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling For Subversion, which goes through apache, I found that one workaround is to disable all SSLv3 ciphers except RC4. My apache config now has: SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA and subversion appears to work again. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204]: bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
I have found that there might be a different length computing in zlib V1.2.3 (or may be even in 1.2.2). In my opinion the length field set by zlib is ok. But openssl changes this length field in the SSL_OP_TLS_BLOCK_PADDING_BUG handling = ERROR (I traced the problem in openssl and zlib under openssl) Until now I've got only one mail that the error might happen also with 1.2.2 (4) and 1.2.3 under apache. I've got also an hint on a restriction on RC4 which might help. But the restriction might be a problem with my usage scenario. Nothing more. I have produced openssl libs without zlib used by my program. This works fine. And with flexible ZLIB usage around Openssl and zlib level 1 and HTTP-chunking I've got best performance --- better than zlib level 6 (default) inside Openssl. - Christiane -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kurt Roeckx via RT Sent: Sunday, December 25, 2005 11:35 AM To: Kämpfe, Christiane Cc: openssl-dev@openssl.org Subject: [openssl.org #1204]: bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling Hi, Has there been any progress on finding what the cause of this is? There is also a bug open about this in the Debian bug tracking at: http://bugs.debian.org/338006 There might be some more useful information in it. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1256] bug in crypto/pqueue/pqueue.c
A bug in pqueue_find() causes the priority of the last item to get clobbered. Patch included in next email. Only DTLS is(was) affected. nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1255] about S/MIME sign code.
Hi. I'm using 0.9.8a on NetBSD 1.x. crypto/pkcs7/pk7_smime.c In case, user selected type is signed and detached, never setting type pkcs7 object, in time PKCS7_dataInit() called. crypto/pkcs7/pk7_doit.c in that's case, 293 line call and make BIO_mem buffer, because 287 line never called. thanks. H.Furukawa __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
--- see below -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of via RT Sent: Friday, December 02, 2005 2:17 PM To: Kämpfe, Christiane Cc: openssl-dev @openssl.org Subject: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling [EMAIL PROTECTED] - Mon Sep 19 10:05:09 2005]: Hello, I have traced again and found out that c_zlib.c::zlib_compress_block() is responsible that wrec-length is sometimes 44 (korrect value) and sometimes 45 (troublesome value) I'm using zlib 1.2.3 !!! for length 45 I'm getting the trouble with the SSP_OP_TLS_BLOCK_PADDING_BUG handling. Korrekt handling requestor side: length is 44; augmented to 48; -data[47] = 3 provider side: length is 48; decremented with 3+1 = 44 Wrong handling requestor side: length is 45; augmented to 48; -data[47] = 2 provider side: length is 48; decremented with (2+1-1/* PADDING_BUG '\0...' FLAGS..PADDING_BUG */) = 46 !!! I hope this helps - to find out whats going wrong. The bug seems to be reproduced without compression (s_client reports than both Compression and Expansion are equal to 'NONE'). I'm sorry, I don't understand your remark. I was stepping also inside the compression handling called by openssl ! I have now made the same tests with an openssl produced without compression abilities (no-zlib). This works fine. openssl with compression still doesn't work with zlib 1.2.3. By the way, why couldn't I change the compression level for openssl compression ? ... we'v got via gSOAP the best performance results with level 1 in combination with HTTP chunking. - c.kae __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Greetings back ! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry Belyavsky via RT Sent: Friday, December 02, 2005 2:45 PM To: Kämpfe, Christiane Cc: openssl-dev@openssl.org Subject: RE: [openssl.org #1204] bug report - 0.9.8 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling Greetings! On Fri, 2 Dec 2005, [EMAIL PROTECTED] via RT wrote: The bug seems to be reproduced without compression (s_client reports than both Compression and Expansion are equal to 'NONE'). I'm sorry, I don't understand your remark. I was stepping also inside the compression handling called by openssl ! ... snip/ I've reproduced this bug with s_client and apache as server requesting page which requires client certificate. So I'm not sure that this bug is completely zlib-related. -- SY, Dmitry Belyavsky (ICQ UIN 6575) Aah, now I understand a little bit more. .. requires client certificates ... so both sides use OpenSSL ?. OpenSSL is normaly produced using compression even if you don't notice this - beginning with the handshakes ! So I'm not sure if your bug is completely unconnected with zlib. By the way - do you know the versions of zlib used on both sides ? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1247] Broken DJGPP build
Sometime in the last few months, changes were made to e_os2.h in the stable 0.9.8 series, which broke the DJGPP build. It looks like a cleanup was made, removing OPENSSL_SYSNAME_WIN16, but the OPENSSL_SYSNAME_MSDOS code appears to have been accidentally removed. I see that none of the platforms generate OPENSSL_SYSNAME_WIN16 in Configure, but there are still lots of places in the code that refer to it. Do we really want to remove OPENSSL_SYSNAME_WIN16 from e_os2.h? Is it clear that no on is going to use that part of the code again? The patch reverts e_os2.h to what it was a few months ago. If you only want to put the MSDOS code back in, rather than restore it all, I don't object. I just wasn't sure what the point was in making the changes. When reviewing my log files, I noted two directories where make depend doesn't use the CFLAG. It looked like something to be fixed. Is there a reason to omit CFLAG only in these two directories? I haven't had a chance to try to compile the current HEAD code yet. The above comments and patches apply to 0.9.8-stable branch. Doug P.S. Since I am in the US, I will also submit this to the usual government authorities. -- Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1241] apps/s_client.c: 2 changes in initial handshake
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1191] [PATCH] Pre-Shared Key Ciphersuites for OpenSSL
What is the status of the PSK patch ? Is any of the OpenSSL developers looking at it now or going to look at it in the near future ? At least the request tracker page http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1191 does not seem to show any recent activity. If the developers need any help regarding the patch feel free to comment. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1240] make test failure [0.9.8a]
Dear Support, I tried to install openssl on my system and got an error in 'make test'. The last lines of the protocoll are: ... ../util/shlib_wrap.sh ./sha512t Testing SHA-512 . TEST 2 of 3 failed. make[1]: *** [test_sha] Fehler 1 make[1]: Verlassen des Verzeichnisses »/root/openssl-0.9.8a/test« make: *** [tests] Fehler 2 By looking in sha512t.c I think that EVP_Digest() is not delivering the correct data. What can I do to fix the problem? Thank you. Best regards Rüdiger Kessel testlog: OpenSSL self-test report: OpenSSL version: 0.9.8a Last change: Remove the functionality of SSL_OP_MSIE_SSLV2_RSA_PADDI... Options: -mcpu=pentium no-gmp no-krb5 no-mdc2 no-rc5 no- shared no-zlib no-zlib-dynamic OS (uname): Linux puma 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i586 unknown OS (config): i586-whatever-linux2 Target (default): linux-elf Target: linux-elf Compiler: Configured with: ../configure --enable-threads=posix - -prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info -- mandir=/usr/share/man --libdir=/usr/lib --enable- languages=c,c++,f77,objc,java,ada --enable-libgcj --with-gxx-include- dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable- shared --enable-__cxa_atexit i486-suse-linux Thread model: posix gcc version 3.2 Failure! - make[1]: Wechsel in das Verzeichnis »/root/openssl-0.9.8a« making all in crypto... make[2]: Wechsel in das Verzeichnis »/root/openssl-0.9.8a/crypto« making all in crypto/objects... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/objects« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/objects« making all in crypto/md2... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/md2« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/md2« making all in crypto/md4... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/md4« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/md4« making all in crypto/md5... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/md5« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/md5« making all in crypto/sha... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/sha« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/sha« making all in crypto/hmac... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/hmac« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/hmac« making all in crypto/ripemd... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/ripemd« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/ripemd« making all in crypto/des... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/des« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/des« making all in crypto/aes... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/aes« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/aes« making all in crypto/rc2... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/rc2« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/rc2« making all in crypto/rc4... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/rc4« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/rc4« making all in crypto/idea... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/idea« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/idea« making all in crypto/bf... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/bf« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/bf« making all in crypto/cast... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/cast« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/cast« making all in crypto/bn... make[3]: Wechsel in das Verzeichnis »/root/openssl- 0.9.8a/crypto/bn« make[3]: Für das Target »all« gibt es nichts zu tun. make[3]: Verlassen des Verzeichnisses »/root/openssl- 0.9.8a/crypto/bn« making all in crypto/ec... make[3]:
[openssl.org #1052]
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
re: [openssl.org #1218] Status
andy, (2) after install, note: for v0.9.8a: otool -L libssl.dylib: libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/local/lib/libgmp.3.dylib (compatibility version 7.0.0, current version 7.3.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.0) v098x builds, for whatever reason, are MISSING the /usr/local/ssl/lib install_name prefixes to the libssl/libcrypto libs. this causes all SORTS of downstream probs ... If you want better response time be more specific describing problems. Even if appears selfobvious to you. Point is that without [daily] access to MacOS X and massive hands-on experiense all SORTS have very little [if any] meaning. Describe at least one problem in more tangible terms. Check tomorrow snapshots as they become available. The case is being dismissed. A. the problem is that applications i'm attempting to link to openssl 0.9.8 -- without these install_name prefixes -- either (a) do not 'find' the lib, despite an LDFLAGS/CPPFLAGS specification, or (b) incorrectly select the Apple-bundled libs on /usr. as a results, make repeatedly fails, complaining about symbols not found / undefined. again, the point is this is changed behavior ... different from the 0.9.7x branch, and different from every other app i have/build on my mac. a relevant discussion with Apple engineering is here: any insights? upgrade from OpenSSL v0.9.7 -- 0.9.8 changes linking behavior on OSX http://lists.apple.com/archives/darwin-dev/2005/Jul/msg00056.html and a PRIOR unanswered post to openssl-dev (from July), with more detail, was here: http://marc.theaimsgroup.com/?l=openssl-devm=112179962925027w=2 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1218] bug reports, OS(Mac OSX 10.4.2), OpenSSL ver(0.9.8a)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 hi all, i'd reported both of these when 0.9.8 first came out. as of the 098a release, they're still, apparently, unresolved. (1) building 0.9.8a on OSX 10.4.2, 'make install' fails @ ... making install in engines... installing 4758cca cp: lib4758cca.so: No such file or directory ... make[1]: *** [install] Error 1 make: *** [install_sw] Error 1 since ... ls ./engines/*.dylib ./engines/lib4758cca.dylib ./engines/libaep.dylib ./engines/libatalla.dylib ./engines/libchil.dylib ./engines/libcswift.dylib ./engines/libgmp.dylib ./engines/libnuron.dylib ./engines/libsureware.dylib ./engines/libubsec.dylib the workaround is to: perl -pi -e 's/lib\$\$l.so/lib\$\$l.dylib/g' /usr/ports/openssl-0.9.8a/engines/Makefile *then* 'make install' completes successfully. (2) after install, note: for 0.9.7g otool -L libssl.dylib: /usr/local/ssl/lib/libssl.0.9.7.dylib (compatibility version 0.9.0, current version 0.9.7) /usr/local/ssl/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.0, current version 0.9.7) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.0) for v0.9.8a: otool -L libssl.dylib: libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/local/lib/libgmp.3.dylib (compatibility version 7.0.0, current version 7.3.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.0) v098x builds, for whatever reason, are MISSING the /usr/local/ssl/lib install_name prefixes to the libssl/libcrypto libs. this causes all SORTS of downstream probs ... thx! richard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iEYEAREDAAYFAkNPNfEACgkQGnqMy4gvZ6H8YwCfeLnRPuej6B5lrATehUgiQISe ZtwAn3flVCQBe8H0MeRyi7+1/qiI0uqK =g4Je -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1191] [PATCH] Pre-Shared Key Ciphersuites for OpenSSL
On Mon, 2005-10-03 at 12:30 +0200, ext via RT wrote: I am working with the patch and I noticed that the psk hint and id are asciiz. This is not in the spec. Also, there is no way to specify no psk_id_hint/psk_id. According to the spec, the pure psk suites can omit the key exchange. There is no way to do this right now, and this is precisely how I intend to work. Using NULL-terminated strings was just a design choice; it is highly unlikely that anyone would use PSK identities or hints containing NULLs, so this simplifies the API (a lot less length fields to pass around in various places; this also means less opportunities for bugs when someone gets the lengths wrong...). Omitting the PSK identity (or ClientKeyExchange message) is not allowed by the spec (but sending zero-length identity is). The PSK hint (and in certain cases, the whole ServerKeyExchange message) can be omitted by setting the hint to NULL. Also see the manual pages for the functions SSL_CTX_use_psk_identity_hint and SSL_use_psk_identity_hint, and then the modified test programs how the functions are used. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1206] FTP USER Authentication
Hi
I have narrowed down the problem now.
This function { des_ede3_cbc_encrypt(input,output1,...) } will encrypt
and update the encrypted output in the array output1.
While printing the array values ,the array value at the end of
encryption before returning back to the place where it is called and the
array value after this encrypt function call are the same.
The array value is updated to a file from where I read the encrypted
data and this is fed to
des_ede3_cbc_encrypt(, , , ...,DES_DECRYPT) function call.
While decrypting the array output1 is fetched and used as input for
decryption. While printing the array values before decryption, it is
same as the encrypted password array for all inputs except for the
number sequence 12345678. For this sequence alone, the encrypted
values and the input to decryption are different and hence the junk
password is printed as output.
I am not sure why for this sequence alone, the encrypted values are
corrupted before decryption.
Hope you can help me at this point of time.
Regards,
Swathika
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nils Larsch via
RT
Sent: Friday, September 23, 2005 2:39 PM
To: Swathika Subramaniam (WT01 - Embedded Systems)
Cc: openssl-dev@openssl.org
Subject: Re: [openssl.org #1206] FTP USER Authentication
[EMAIL PROTECTED] via RT wrote:
We use DES encryption algorithm.When the user try to add an user with
the password 12345678 ,user couldn't login. So itried printing the
DES decrypted password, it returns junk password. Since it is junk
user couldn't login. Basically we maintain a file which will have the
list of users added and their password, this is a junk user couldn't
login
as I still don't know what you are doing (an example source code showing
the bug would be very helpful !) = it's still not really possible to
help you. Anyway this sounds more like a bug in your application than a
bug in the openssl code.
Cheers,
Nils
PS: you need to reply to [EMAIL PROTECTED] as otherwise the message
is not appended to the ticket.
Confidentiality Notice
The information contained in this electronic message and any attachments to
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or [EMAIL
PROTECTED] immediately
and destroy all copies of this message and any attachments.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1206] FTP USER Authentication
We use DES encryption algorithm.When the user try to add an user with the password 12345678 ,user couldn't login. So itried printing the DES decrypted password, it returns junk password. Since it is junk user couldn't login. Basically we maintain a file which will have the list of users added and their password, this is a junk user couldn't login -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nils Larsch via RT Sent: Friday, September 23, 2005 5:15 AM To: Swathika Subramaniam (WT01 - Embedded Systems) Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #1206] FTP USER Authentication [EMAIL PROTECTED] via RT wrote: Hi We have ported the openSSL code for our project.We use SSL to authenticate the users who use FTP to the controller(which is basically a printer). We have different groups such as developer, user, designer etc. each will have access permissions I am facing a problem with the DES encryption for a particular password. perhaps you should tell us what kind of problem do you have (otherwise it's more less impossible to help you) ... Nils Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1206] FTP USER Authentication
Hi We have ported the openSSL code for our project.We use SSL to authenticate the users who use FTP to the controller(which is basically a printer). We have different groups such as developer, user, designer etc. each will have access permissions I am facing a problem with the DES encryption for a particular password. Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1204] bug report - 0.9.8 + zlib 1.2.3 and bad record mac because of wrong SSL_OP_TLS_BLOCK_PADDING_BUG handling
Hello, I have traced again and found out that c_zlib.c::zlib_compress_block() is responsible that wrec-length is sometimes 44 (korrect value) and sometimes 45 (troublesome value) I'm using zlib 1.2.3 !!! for length 45 I'm getting the trouble with the SSP_OP_TLS_BLOCK_PADDING_BUG handling. Korrekt handling requestor side: length is 44; augmented to 48; -data[47] = 3 provider side: length is 48; decremented with 3+1 = 44 Wrong handling requestor side: length is 45; augmented to 48; -data[47] = 2 provider side: length is 48; decremented with (2+1-1/* PADDING_BUG '\0...' FLAGS..PADDING_BUG */) = 46 !!! I hope this helps - to find out whats going wrong. Christiane Kämpfe mailto:[EMAIL PROTECTED] EP SW SM 4 Telephone: +49 (0) 89 636 49941 Fujitsu Siemens Computers GmbH Otto Hahn Ring 6 D-81739 München __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1191] [PATCH] Pre-Shared Key Ciphersuites for OpenSSL
We have implemented a part of a new Intenet Draft called Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) [1], and we would like to contribute it to the OpenSSL project. According to the Abstract section of the draft: This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys. These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key; and the third set combines public key authentication of the server with pre-shared key authentication of the client. The draft has been publicially developed at the IETF Transport Layer Security (tls) Working Group [2]. The draft is currently in the RFC Editor queue [3]. Status of the patch --- The patch is made against the latest stable version 0.9.8 of OpenSSL taken from [4]. The attached file is compressed into the ZIP format. The uncompressed package has three files containing separate patch files for documentation, test cases and required modifications to the existing SSL libraries to support PSK cipher suites. The patch contains currently support only for the plain PSK cipher suites described in the chapter 2 of [1]. The rest of the remaining cipher suites (DHE_PSK and RSA_PSK, chapters 3 and 4 correspondingly) are under development and expected to be sent to the OpenSSL project when they are finished. Contact persons related to the patch are: Mika Kousa ([EMAIL PROTECTED] / [EMAIL PROTECTED]) Pasi Eronen ([EMAIL PROTECTED]) (one of the authors of the draft) [1] http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-09.txt [2] http://www.ietf.org/html.charters/tls-charter.html [3] https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag= 11875rfc_flag=0 [4] http://www.openssl.org/source/openssl-0.9.8.tar.gz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1186] make test problem with openssl 0.9.7g on solaris 10
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
html
head
meta content=text/html;charset=ISO-8859-1 http-equiv=Content-Type
title/title
/head
body bgcolor=#ff text=#00
ttThis may be a false alarm, but I have just builtbr
OpenSSL 0.9.7g on Solaris 10 (sparc). Everythingbr
appears o.k. until I run make test and I get this.br
I regret that I am not expert enough to pin downbr
what the exact problem might be. Here is the outputbr
of make report, however.br
br
Regardsbr
br
Ray Hillmanbr
br
anser{root}83: make reportbr
Checking compiler...br
ar: creating cctest.abr
Running make...br
making all in crypto...br
making all in crypto/objects...br
making all in crypto/md2...br
making all in crypto/md4...br
making all in crypto/md5...br
making all in crypto/sha...br
making all in crypto/mdc2...br
making all in crypto/hmac...br
making all in crypto/ripemd...br
making all in crypto/des...br
making all in crypto/rc2...br
making all in crypto/rc4...br
making all in crypto/rc5...br
making all in crypto/idea...br
making all in crypto/bf...br
making all in crypto/cast...br
making all in crypto/bn...br
making all in crypto/ec...br
making all in crypto/rsa...br
making all in crypto/dsa...br
making all in crypto/dh...br
making all in crypto/dso...br
making all in crypto/engine...br
making all in crypto/aes...br
making all in crypto/buffer...br
making all in crypto/bio...br
making all in crypto/stack...br
making all in crypto/lhash...br
making all in crypto/rand...br
making all in crypto/err...br
making all in crypto/evp...br
making all in crypto/asn1...br
making all in crypto/pem...br
making all in crypto/x509...br
making all in crypto/x509v3...br
making all in crypto/conf...br
making all in crypto/txt_db...br
making all in crypto/pkcs7...br
making all in crypto/pkcs12...br
making all in crypto/comp...br
making all in crypto/ocsp...br
making all in crypto/ui...br
making all in crypto/krb5...br
making all in fips...br
making all in ssl...br
if [ -n ]; then \br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; (cd ..; make libssl.so.0.9.7); \br
fibr
making all in apps...br
making all in test...br
making all in tools...br
Running make test...br
testing...br
making all in apps...br
../util/shlib_wrap.sh ./destestbr
Doing cbcmbr
Doing ecbbr
Doing ede ecbbr
Doing cbcbr
Doing desx cbcbr
Doing ede cbcbr
Doing pcbcbr
Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() donebr
Doing ofbbr
Doing ofb64br
Doing ede_ofb64br
Doing cbc_cksumbr
Doing quad_cksumbr
input word alignment test 0 1 2 3br
output word alignment test 0 1 2 3br
fast crypt test br
../util/shlib_wrap.sh ./ideatestbr
ecb idea okbr
cbc idea okbr
cfb64 idea okbr
../util/shlib_wrap.sh ./shatestbr
test 1 okbr
test 2 okbr
test 3 okbr
../util/shlib_wrap.sh ./sha1testbr
test 1 okbr
test 2 okbr
test 3 okbr
if egrep 'define OPENSSL_FIPS' ../include/openssl/opensslconf.h gt;
/dev/null; then \br
nbsp; ../util/shlib_wrap.sh ./fips_sha1test sha1vectors.txt | sed
s/Strings/Hashes/ | cmp sha1hashes.txt - ; \br
fibr
../util/shlib_wrap.sh ./md4testbr
test 1 okbr
test 2 okbr
test 3 okbr
test 4 okbr
test 5 okbr
test 6 okbr
test 7 okbr
../util/shlib_wrap.sh ./md5testbr
test 1 okbr
test 2 okbr
test 3 okbr
test 4 okbr
test 5 okbr
test 6 okbr
test 7 okbr
../util/shlib_wrap.sh ./hmactestbr
test 0 okbr
test 1 okbr
test 2 okbr
test 3 okbr
../util/shlib_wrap.sh ./md2testbr
test 1 okbr
test 2 okbr
test 3 okbr
test 4 okbr
test 5 okbr
test 6 okbr
test 7 okbr
../util/shlib_wrap.sh ./mdc2testbr
pad1 - okbr
pad2 - okbr
../util/shlib_wrap.sh ./rmdtestbr
error calculating RIPEMD160 on ''br
got c12836ad0d061da6ccde02fb0b5be87f0c62a4a5 instead of
9c1185a5c5e9fc54612808977ee8f548b2258d31br
error calculating RIPEMD160 on 'a'br
got 9aa1049aec0363ac0a5895c44bb2fa79a49a20aa instead of
0bdc9d2d256b3ee9daae347be6f4dc835a467ffebr
error calculating RIPEMD160 on 'abc'br
got 534dbff56cbaa431356ed97de140a03e30cea7ca instead of
8eb208f7e05d987a9b044a8e98c6b087f15a0bfcbr
error calculating RIPEMD160 on 'message digest'br
got 572996fa268de87f2ff80ec9050b691c3e3aff7e instead of
5d0689ef49d2fae572b881b123a85ffa21595f36br
error calculating RIPEMD160 on 'abcdefghijklmnopqrstuvwxyz'br
got 1519de8a83138c8b44a50b5b6d646af5a2c0e063 instead of
f71c27109c692c1b56bbdceb5b9d2865b3708dbcbr
error calculating RIPEMD160 on
'abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq'br
got 1b0a8adbb9a030cdf11fd4315de1d10ab37d37de instead of
12a053384a9c0c88e405a06c27dcf49ada62eb2bbr
error calculating RIPEMD160 on
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'br
got 2dc6dba4503947c15ca0737ae8dcc0522d7da6a0 instead of
b0e20b6e3116640286ed3a87a5713079b21f5189br
error calculating RIPEMD160 on
'12345678901234567890123456789012345678901234567890123456789012345678901234567890'br
got 29e419abee1d0bc8cc700b4cf702594a8f73f931 instead of
9b752e45573d4b39f4dbd3323cab82bf63326bfbbr
*** Error code 8br
make: Fatal error: Command failed for target `test_rmd'br
Current working directory /export/home/rkh/openssl-0.9.7g/testbr
***
[openssl.org #1184] Open SSL error during make
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [Fwd: Re: [openssl.org #1171] Unable to pass make test 2]
Original Message
Subject: Re: [openssl.org #1171] Unable to pass make test 2
Date: Mon, 25 Jul 2005 00:39:36 +0200 (METDST)
From: Andy Polyakov via RT [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: openssl-dev@openssl.org
test BN_sqr
make[2]: *** [test_bn] Error 139
Could you examine
https://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1146 and see if
you confirm that it's identical problem. A.
I am sorry but I cannot reproduce the problem any more. I did these steps after
reporting the problem till now:
- instaled openssl 0.9.7g instead of 0.9.7e and relinked lib{crypto,ssl}.so and
dtto.so.0 to this version,
- instaled openssh 4.1 instead of 4.0,
- instaled latest binutils,
- and instaled gcc 3.4.4.
And now it (make make test for openssl 0.9.8) works fine.
Regards,
marcel Svitalský
--
**
tlf: (+420) 245 005 546 ... po-pá 8:00-16:30
tlf: (+420) 606 439 651
e-mail: [EMAIL PROTECTED]
e-mail: [EMAIL PROTECTED]
Nebojte se ¹ifrování - ¹ifra je jako obálka na dopise.
Osobní a dùvìrné vìci také nepí¹ete na pohlednici.
GPG public key (ID 0xD98EC83A) fingerprint:
3BEB 4658 A998 B9B3 3476 AD64 EF87 D0A5 D98E C83A
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [Fwd: Re: [openssl.org #1171] Unable to pass make test 2]
Andy Polyakov via RT wrote:
test BN_sqr
make[2]: *** [test_bn] Error 139
Could you examine
https://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1146 and see if
you confirm that it's identical problem.
I am sorry but I cannot reproduce the problem any more. I did these steps
after
reporting the problem till now:
- instaled openssl 0.9.7g instead of 0.9.7e and relinked lib{crypto,ssl}.so
and
dtto.so.0 to this version,
- instaled openssh 4.1 instead of 4.0,
- instaled latest binutils,
- and instaled gcc 3.4.4.
And now it (make make test for openssl 0.9.8) works fine.
Working theory in #1146 is that it's a bug in binutils, either linker or
assembler. And the fact that binutils update helped in your case does
not refute it, on the contrary confirms. Can you tell wich binutils
version did you upgrade from? And which version to? A.
To version is 2.16.1.
About from version I am not quite sure -- it could be either 2.11.93 (as
deployed with RedHat 7.3) or some a bit newer version from the former
RedHat up2date system.
Marcel Svitalský
--
**
tlf: (+420) 245 005 546 ... po-pá 8:00-16:30
tlf: (+420) 606 439 651
e-mail: [EMAIL PROTECTED]
e-mail: [EMAIL PROTECTED]
Nebojte se ¹ifrování - ¹ifra je jako obálka na dopise.
Osobní a dùvìrné vìci také nepí¹ete na pohlednici.
GPG public key (ID 0xD98EC83A) fingerprint:
3BEB 4658 A998 B9B3 3476 AD64 EF87 D0A5 D98E C83A
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [Fwd: Re: [openssl.org #1171] Unable to pass make test 2]
Andy Polyakov via RT wrote:
test BN_sqr
make[2]: *** [test_bn] Error 139
Could you examine
https://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1146 and see if
you confirm that it's identical problem.
I am sorry but I cannot reproduce the problem any more. I did these steps
after
reporting the problem till now:
- instaled openssl 0.9.7g instead of 0.9.7e and relinked lib{crypto,ssl}.so
and
dtto.so.0 to this version,
- instaled openssh 4.1 instead of 4.0,
- instaled latest binutils,
- and instaled gcc 3.4.4.
And now it (make make test for openssl 0.9.8) works fine.
Working theory in #1146 is that it's a bug in binutils, either linker or
assembler. And the fact that binutils update helped in your case does
not refute it, on the contrary confirms. Can you tell wich binutils
version did you upgrade from? And which version to? A.
I wrote:
To version is 2.16.1.
About from version I am not quite sure -- it could be either 2.11.93 (as
deployed with RedHat 7.3) or some a bit newer version from the former
RedHat up2date system.
and now, trying rpm -q binutils command (as the new version was the first one
compiled from the source code, previous was/were instaled from RPM(s)), I can
say that from version was binutils-2.11.93.0.2-11.
Marcel Svitalský
--
**
tlf: (+420) 245 005 546 ... po-pá 8:00-16:30
tlf: (+420) 606 439 651
e-mail: [EMAIL PROTECTED]
e-mail: [EMAIL PROTECTED]
Nebojte se ¹ifrování - ¹ifra je jako obálka na dopise.
Osobní a dùvìrné vìci také nepí¹ete na pohlednici.
GPG public key (ID 0xD98EC83A) fingerprint:
3BEB 4658 A998 B9B3 3476 AD64 EF87 D0A5 D98E C83A
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1171] Unable to pass make test
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1171] Unable to pass make test 2
Hi, to my former mail (sent to you few hours ago) with text: I was unable to pass the make test command when building openssl 0.9.8. I tried it first with some optimization flags (-O3 -march=pentium4 -mtune=pentium4) with gcc 3.4.1, again without them and at last with default flags as they are in Makefile and gcc 2.96 and it always ended the same way: ... test BN_rshift1 test BN_rshift test BN_sqr make[2]: *** [test_bn] Error 139 make[2]: Leaving directory `/tmp/vivi/openssl-0.9.8/openssl-0.9.8/test' make[1]: *** [tests] Error 2 make[1]: Leaving directory `/tmp/vivi/openssl-0.9.8/openssl-0.9.8' I attach the testlog file made with make report after the last try. I use RedHat Linux 7.3 with kernel 2.4.20-28.7. I can add now that it only happens when shared option is passed to ./configure command; without that option make test passes OK. Unfortunately, I need shared libraries. Marcel Svitalský -- ** tlf: (+420) 245 005 546 ... po-pá 8:00-16:30 tlf: (+420) 606 439 651 e-mail: [EMAIL PROTECTED] e-mail: [EMAIL PROTECTED] Nebojte se ¹ifrování - ¹ifra je jako obálka na dopise. Osobní a dùvìrné vìci také nepí¹ete na pohlednici. GPG public key (ID 0xD98EC83A) fingerprint: 3BEB 4658 A998 B9B3 3476 AD64 EF87 D0A5 D98E C83A __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1160] openssl 0.9.8 build problem on Linux/dietlibc
For some reason, openssl suddenly wants to add -ldl when linking the test programs. That is uncalled for, I specifically added no-dso to the Configure options. Please reverse this. Felix __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1153] Mingw patch for OpenSSL 0.9.8
When built under Cygwin, with the -mno-cygwin option, OpenSSL 0.9.8 builds, tests, and installs fine (only tested with no-idea no-shared). I noticed, however, that I was getting 5 warnings from gcc. The attached patch should fix the warnings. When tested against 0.9.8-stable-SNAP-20050709, with the patch applied, it builds without any warnings under cygwin for mingw. I also tested for DJGPP, and it builds fine on that platform with the patch. I hope that no other platforms will be adversely affected. Since I am in the US, I am also sending a copy of the patch to the usual US government addresses. Doug -- Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1150] 0.9.8 bug report
hello,
tried to compile 0.9.8 and got the following errors:
/gmake -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS=openssl.o verify.o asn1pars.o req.o
dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o
crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o
genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o
s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o
pkcs8.o spkac.o smime.o rand.o engine.o ocsp.o prime.o \
LIBDEPS= $LIBRARIES \
link_app.${shlib_target}
gmake[4]: Entering directory `/mnt/3/temp/openssl-0.9.8/apps'
ld32: ERROR 33 : Unresolved text symbol HMAC_CTX_init -- 1st
referenced by speed.o.
Use linker option -v to see when and which objects, archives and
dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol HMAC_Init_ex -- 1st
referenced by speed.o.
Use linker option -v to see when and which objects, archives and
dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol HMAC_Update -- 1st
referenced by speed.o.
Use linker option -v to see when and which objects, archives and
dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol HMAC_Final -- 1st referenced
by speed.o.
Use linker option -v to see when and which objects, archives and
dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol HMAC_CTX_cleanup -- 1st
referenced by speed.o.
Use linker option -v to see when and which objects, archives and
dsos are loaded.
ld32: INFO152: Output file removed because of error.
gmake[4]: *** [link_app.irix] Error 2
/
i've used *irix 6.5.27, mipspro 7.43* and started with:
./Configure --prefix=/usr/local irix-mips3-cc shared
my second try was:
./Configure --prefix=/usr/local irix-mips3-cc threads shared
but i got:
/gmake -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS=openssl.o verify.o asn1pars.o req.o
dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o
crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o
genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o
s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o
pkcs8.o spkac.o smime.o rand.o engine.o ocsp.o prime.o \
LIBDEPS= $LIBRARIES \
link_app.${shlib_target}
gmake[2]: Entering directory `/mnt/3/temp/openssl-0.9.8/apps'
ld32: ERROR 33 : Unresolved text symbol idea_set_encrypt_key -- 1st
referenced by speed.o.
Use linker option -v to see when and which objects, archives and
dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol idea_set_decrypt_key -- 1st
referenced by ../libcrypto.a(e_idea.o).
Use linker option -v to see when and which objects, archives and
dsos are loaded.
ld32: ERROR 33 : Unresolved text symbol BF_ofb64_encrypt -- 1st
referenced by ../libcrypto.a(e_bf.o).
Use linker option -v to see when and which objects, archives and
dsos are loaded.
ld32: INFO152: Output file removed because of error.
gmake[2]: *** [link_app.irix] Error 2/
thanks in advance
--
AH Computer-Systeme
Götz Fischer
Senior Consultant
Phone: +49(0)7225/98 98 79
Fax: +49(0)7225/28 64
eMail: [EMAIL PROTECTED]
http://www.ah-online.com
http://www.ah-webhosting.com
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1109] Ticket Resolved
Would You please apply the second DIFF file in sead of the first one ? - Original Message - From: Stephen Henson via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 05, 2005 2:14 AM Subject: [openssl.org #1109] Ticket Resolved According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1109] Ticket Resolved
I mean this one: - Original Message - From: Stephen Henson via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 05, 2005 2:14 AM Subject: [openssl.org #1109] Ticket Resolved According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command
The one with additional config options was the first one. The one without config options is better (according to me) and is the second one. Both are working. Just the second one does not need config options. Do You need a diff file between the latest ca.c - version 1.150 and my second diff file in order not to use config options? If yes - where to send it ? - Original Message - From: Stephen Henson via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Sent: Wednesday, July 06, 2005 2:17 AM Subject: [openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command [EMAIL PROTECTED] - Wed Jul 6 01:10:41 2005]: Would You please apply the second DIFF file in sead of the first one ? According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. I thought I had applied the second diff. The one you mention below seems to be the first one (the one without additional config file options). Is there a problem with the second diff? Since 0.9.8 has been released now it will have to wait until 0.9.8a if there is a problem. Steve. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command
I just checked. As I see there are actually 3 diff files there (http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1109): 1. File difference report generated by CSDiff by ComponentSoftware on 13.6.2005 Ç. 13:19 - 3.3KB 2. --- openssl-0.9.8-beta5/apps/ca.c.oldFri Apr 15 21:29:34 2005 - 8,7KB 3. --- openssl-0.9.8-beta5\apps\ca.c.old2005-04-15 21:29:33.0 - 8.3k You applied the 2nd one in stead of the 3rd one. I just forgot about the 1st one. What should I do now in order to apply the 3rd one? - Original Message - From: Stephen Henson via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Sent: Wednesday, July 06, 2005 2:17 AM Subject: [openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command [EMAIL PROTECTED] - Wed Jul 6 01:10:41 2005]: Would You please apply the second DIFF file in sead of the first one ? According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. I thought I had applied the second diff. The one you mention below seems to be the first one (the one without additional config file options). Is there a problem with the second diff? Since 0.9.8 has been released now it will have to wait until 0.9.8a if there is a problem. Steve. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command
If You think so Ok then ;) Let's leave it as it is. Thank You very much and once again sorry for the inconvenience. Best regards Stefan - Original Message - From: Stephen Henson via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Sent: Wednesday, July 06, 2005 3:26 AM Subject: [openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command [EMAIL PROTECTED] - Wed Jul 6 01:40:04 2005]: You applied the 2nd one in stead of the 3rd one. I just forgot about the 1st one. What should I do now in order to apply the 3rd one? Personally I prefer the patch that has been applied over the 3rd one. The applied patch allow the string mask to be set independently of whether UTF8 format is used for characters. This is consistent with the way 'req' operates. The 3rd one always sets the UTF8 only mask at the same time as using UTF8 format. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1105] DTLS HelloVerifyRequest PATCH
So the bug report can be removed, right? Yes, the report can be removed. It is not a bug. (and *please* keep [EMAIL PROTECTED] among the recipients. It's quite hard to follow history in the database when people keep skipping that address) Apologies. nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1135] 0.9.8-beta7-dev and DJGPP
The OpenSSL 0.9.8-stable snapshot from 24 June 2005 configures, builds, tests, and installs without problem on DJGPP. The default cert file and directory also work as expected, whether or not SSL_CERT_FILE and SSL_CERT_DIR are defined in the environment. Thanks. Doug -- Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1136] 0.9.8-beta6 on DJGPP
I sent the following on 21 June, but I don't see where it actually made it to the list or to the archives. Sorry if it turns out to be a duplicate. The beta6 of openssl 0.9.8 compiles, tests, and installs on DJGPP without any problems that I see. There is just one warning during the compilation, at apps/passwd.c: gcc -DMONOLITH -I.. -I../include -I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -c -o passwd.o passwd.c passwd.c: In function `do_passwd': passwd.c:477: warning: unsigned int format, long unsigned int arg (arg 3) Doug -- Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1131] Patch for 0.9.8beta6 by_dir.c
On April 24th, I wrote to openssl-dev:
Also, the function dir_ctrl in crypto/x509/by_dir.c looks wrong to
me. Shouldn't it be checking for the environment variable first, then
getting the default if no environment variable is specified (the way
by_file_ctrl does in crypto/x509/by_file.c)? Sorry if I am misreading
what that function is doing. The code looks the same in 0.9.7 and
0.9.8.
I have done some more testing, and openssl is indeed using certs from
the default directory, even if a different directory is specified
by SSL_CERT_DIR. This patch changes the logic to what we have in
by_file.c. That is, if SSL_CERT_DIR is defined in the environment,
openssl uses it exclusively for the directory of hashed certs. If
SSL_CERT_DIR is not defined, then the default directory is used.
Since I am in the US, a copy of the patch is being forwarded to the
appropriate US government agencies.
Doug
--- crypto/x509/by_dir.c.ori2004-01-22 14:36:46.0 -0800
+++ crypto/x509/by_dir.c2005-06-22 12:09:00.0 -0800
@@ -122,19 +122,19 @@
{
case X509_L_ADD_DIR:
if (argl == X509_FILETYPE_DEFAULT)
+ dir=(char *)Getenv(X509_get_default_cert_dir_env());
+ if (dir)
+ ret=add_cert_dir(ld,dir,X509_FILETYPE_PEM);
+ else
{
ret=add_cert_dir(ld,X509_get_default_cert_dir(),
X509_FILETYPE_PEM);
+ }
if (!ret)
{
X509err(X509_F_DIR_CTRL,X509_R_LOADING_CERT_DIR);
}
- else
- {
- dir=(char
*)Getenv(X509_get_default_cert_dir_env());
- ret=add_cert_dir(ld,dir,X509_FILETYPE_PEM);
- }
- }
+
else
ret=add_cert_dir(ld,argp,(int)argl);
break;
--
Doug Kaufman
Internet: [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1127] openssl-0.9.8-beta6: two minor problem man pages during install
During installation: installing man3/OPENSSL_Applink.3 ../../util/pod2man.pl: Improper man page - no dash in NAME header in paragraph 3 of OPENSSL_Applink.pod .3 = OPENSSL_Applink.3 installing man3/OPENSSL_ia32cap.3 ../../util/pod2man.pl: Improper man page - no dash in NAME header in paragraph 3 of OPENSSL_ia32cap.pod .3 = OPENSSL_ia32cap.3 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1103] bug: openssl-0.9.8-beta4 make depend fails in separate tree configuration
This problem was reported as fixed in beta5, but it is neither fixed in beta5 nor in beta6. Please reopen this problem report. snip --- Since you've disabled or enabled at least one algorithm, you need to do the following before building: make depend Configured for solaris-sparcv8-cc. % make depend making dependencies crypto... [ -z depend -o -f buildinf.h ] || touch buildinf.h # fake buildinf.h if it does not exist [ -z depend ] || ../util/domd .. -MD makedepend -- -KPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -R/usr/local/ssl/lib -xarch=v8 -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -I. -I.. -I../include -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_GMP -DOPENSSL_NO_IDEA -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -- cryptlib.c mem.c mem_clr.c mem_dbg.c cversion.c ex_data.c tmdiff.c cpt_err.c ebcdic.c uid.c o_time.c o_str.c o_dir.c [ -z depend -o -s buildinf.h ] || rm buildinf.h making depend in crypto/objects... ../util/domd .. -MD makedepend -- -g -I.. -I../.. -I../../include -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_GMP -DOPENSSL_NO_IDEA -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -- o_names.c obj_dat.c obj_lib.c obj_err.c sh: ../util/domd: not found *** Error code 1 make: Fatal error: Command failed for target `depend' Current working directory /import-writable/import-pkgs/openssl-0.9.8/sparc-sun-solaris2/crypto/obje cts *** Error code 1 make: Fatal error: Command failed for target `depend' Current working directory /import-writable/import-pkgs/openssl-0.9.8/sparc-sun-solaris2/crypto *** Error code 1 make: Fatal error: Command failed for target `depend' % ls -l README lrwxrwxrwx 1 user group 71 Jun 21 16:33 README - /import/openssl-0.9.8/openssl-0.9.8-beta6/./README end snip --- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1110] DEVRAMDOM define in rand_unix.c
On Sat, 18 Jun 2005, Richard Levitte via RT wrote: The real issue was the backslahes in the configuration definition for DJGPP and how those interacted with the handling of a build environment in the Makefiles. I resolved the issue by moving the definition of DEVRANDOM for DJGPP from Configure to e_os.h. I tried compiling with DJGPP using your patch applied to beta5. It compiles OK, but there are a lot of warnings, since there is a default definition of DEVRANDOM earlier in the e_os.h file. I applied this patch. --- e_os.h.ori 2005-06-18 23:50:38.0 -0800 +++ e_os.h 2005-06-19 04:07:10.0 -0800 @@ -227,6 +227,7 @@ #define _setmode setmode #define _O_TEXT O_TEXT #define _O_BINARY O_BINARY +#undef DEVRANDOM #define DEVRANDOM /dev/urandom\x24 # endif /* __DJGPP__ */ Doug -- Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1113] openssl-0.9.8-beta5 - install fails on ../../util/pod2man.pl: Invalid man page
making all in tools...
./pod2mantest: pod2man: not found
pod2man does not work properly ('BasicTest' failed). Looking for another
pod2man ...
No working pod2man found. Consider installing a new version.
As a workaround, we'll use a bundled old copy of pod2man.pl.
installing man1/CA.pl.1
installing man1/asn1parse.1
installing man1/ca.1
installing man1/ciphers.1
installing man5/config.5
../../util/pod2man.pl: Invalid man page - 1st pod line is not NAME in config.pod
*** Error code 255
make: Fatal error: Command failed for target `install_docs'
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1111] Test passed: OpenSSL 0.9.8 beta 5 on SuSE 9.3
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1103] Ticket Resolved
It's not fixed in Beta5. Nick Briggs PARC __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
