[openssl.org #438] SCEP
Hi, its been quite a while since we heard last time, I hope you remember me. I have (quite) ended support for the SCEP messages for our project and I think it could be a useful addon to OpenSSL. The code is quite clean and could be added to the command line utility as 'openssl scep .. '. What do you think about it ? As integrating the work into OpenSSL will require some additional work I would like to know if you were interested in it before cleaning up the code. Let me know. -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED] Tel.: +39 (0)59 270 094 http://www.openca.orgFax:+39 178 221 8225 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #439] OpenSSL Bug(?) - make test (SHA) failure
Attached is the result of OpenSSL 'make report', following a failure of 'make test', as requested in the INSTALL file, section 3. At this point, all I have done is downloaded the source code, and run configure, make, and make test. As you will be able to see from the log the reported failure is with SHA. I have not removed the optimisations as suggested, since the INSTALL file requested a bug report anyway, but I'll try that next. -- Steve Sutton - [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #439] OpenSSL Bug(?) - make test (SHA) failure (fwd) (Additional)
Having rebuild with no optimisation (changed -O3 to -O0) the tests have now passed. One other minor issue to note: The INSTALL document (section 3) make test refers to the CFLAGS line in Makefile.ssl - The makefile actually contains CFLAG (note no 'S'), which meant that searching for it failed. -- Forwarded message -- Date: Sat, 4 Jan 2003 19:16:08 + (GMT) From: root [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: OpenSSL Bug(?) - make test (SHA) failure Attached is the result of OpenSSL 'make report', following a failure of 'make test', as requested in the INSTALL file, section 3. At this point, all I have done is downloaded the source code, and run configure, make, and make test. As you will be able to see from the log the reported failure is with SHA. I have not removed the optimisations as suggested, since the INSTALL file requested a bug report anyway, but I'll try that next. -- Steve Sutton - [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #440] AutoReply: wrong read() protype
Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: wrong read() protype, 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 #440]. Please include the string: [openssl.org #440] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, - Some test-files include a protype for read(). Unfortunately this protype doesn't match the one in djgpp's unistd.h. Can we not removed this prototype? The required system headers are included already I think. Here is a patch to make it compile for djgpp: --- --- ./crypto/md4/md4.c.org Wed Nov 13 16:00:50 2002 +++ ./crypto/md4/md4.c Tue Dec 31 18:45:54 2002 @@ -64,7 +64,7 @@ void do_fp(FILE *f); void pt(unsigned char *md); -#ifndef _OSD_POSIX +#if !defined(_OSD_POSIX) !defined(__DJGPP__) int read(int, void *, unsigned int); #endif --- ./crypto/md5/md5.c.org Fri Jun 4 22:00:22 1999 +++ ./crypto/md5/md5.c Tue Dec 31 18:49:44 2002 @@ -64,7 +64,7 @@ void do_fp(FILE *f); void pt(unsigned char *md); -#ifndef _OSD_POSIX +#if !defined(_OSD_POSIX) !defined(__DJGPP__) int read(int, void *, unsigned int); #endif --- ./crypto/ripemd/rmd160.c.orgFri Jun 4 22:00:28 1999 +++ ./crypto/ripemd/rmd160.cTue Dec 31 18:51:50 2002 @@ -64,7 +64,7 @@ void do_fp(FILE *f); void pt(unsigned char *md); -#ifndef _OSD_POSIX +#if !defined(_OSD_POSIX) !defined(__DJGPP__) int read(int, void *, unsigned int); #endif --- Gisle V. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #22] [PATCH] to dev build 20020428 for Win64 on Itanium
... or does size_t matter:-) I had a look at BRANCH_WIN64 last night and here're some thoughts. First of all I want to point out that I had rather fast look so that this is probably not a final judgment:-) As discussed earlier Win64 implements P64 programming model and so the discussion started ignited at casting size_t (which is 64-bit) to int vs. real size_t-ification. But for some reason the question if it's a Win64-specific problem or a generic OpenSSL deficiency didn't get proper attention. At least in my opinion. And the simple fact is that it appears to be a *generic* OpenSSL deficiency. Indeed! Most of those casts from size_t were proposed to be made to int, meaning that if there're any bits lost in on P64 platform, same bits will be lost even on LP64 platform! Now having figured this I wonder how come did Win64 deserve so special treatment? I mean being effectively mobbed by branching it to a separate branch basically without any specified release schedule? Do note that I personally have no special feelings for Win64 and emotionally I'm fine with Win64 being mobbed:-) It's just that I see that by putting Win64 support to prime line development line, we can use Win64 developers [or their tools] to eliminate [yet another] *generic* OpenSSL deficiency. In other words. The way I see it is this. *If* OpenSSL compiles on Win64 with possible loss of data warning off (/wd4267 and /wd4244 to be specific, and it does compile!) and passes the test (no hardware, can't tell), it means exactly the same thing as on any other LP64 *supported* platform and therefore might as well be supported. Moreover, it's possible to support it a little better actually, because we have the option to denote the fact that support is in fact limited by branding the object modules with #pragma comment(linker,/largeaddressaware:no) which provides for ILP32 run-time option (as was discussed earlier in another context). But the above does *not* mean that I'm suggesting to skip the size_t-ification of the toolkit! All I'm saying is that it's not a Win64 specific issue and shouldn't be treated as one. As for size_t-ification itself. My feeling after looking at the BRANCH_WIN64 was do prioritize. There're two ways to tackle the problem. 1. Promote types. 2. Recognize legitimate casts and cast. Take BN code for example. Original code from HEAD and 0.9.7 compiles without a single warning. Code from BRANCH_WIN64 is filled with warnings. Can HEAD break on [L]P64? Yes. What one can do? 1. Promote relevant variables/structure members. 2. Insert couple of assertions which would make BN [gracefully] fail, thus ensuring that casts are legitimate (well, it compiles without a single warning, so that casts are legitimate). I believe there're assertions in place already, one has to verify it. In either case I'd go for 2, because it also effectively protects users from DoS. Indeed, if BN is actually asked to operate on 128Gbit numbers, it's *definitely* a mistake and the library should fail, not start consuming hours of CPU time. Symmetric algorithms on the contrary has to be type promoted, and it has to be done in first hand, they apparently not... What to do? I have promoted message digests and few symmetric algorithms already and the question I'm facing now is which branch to commit to. Of course there is BRANCH_WIN64, but I fear that it ends up one bit too different from HEAD to maintain the situation under control. I mean I fear that synching BRANCH_WIN64 to HEAD might become as time consuming as implementation. Cheers. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: crypto/perlasm/x86unix.pl
On Fri, 3 Jan 2003, Tim Rice wrote: On Fri, 3 Jan 2003, Andy Polyakov wrote: [snip] The assembler modules compile fine on UnixWare. I'll try and test SCO OpenServer 5 this weekend. The assembler modules compile fine on SCO OpenServer 5 too. A couple of problems. The cc on UnixWare 2.x doesn't handle -o asm/xx86-elf.o It just creates it in the curent directory. Linking openssl, UX:ld: ERROR: ../libcrypto.a(bn_mul.o): fatal error: symbol `bn_sub_part_words` multiply-defined, also in file ../libcrypto.a(bn86-elf.o) It looks like bn_sub_part_words was removed from bn_mul.c in 0.9.7 so it's not a problem there. I had this same error in early 0.9.7 betas. I'll #if 0 that chunk of code in the morning and make sure make test passes. Cheers. A. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
