Re: [openssl.org #3333] [PATCH] Revert Make Makefiles OSF-make-friendly.
Hi, This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34. When gcc is given a .s file and told to preprocess it, it outputs nothing. Since gcc targets are more common/important than OSF, revert it and let the original submitter sort out the problem. URL: https://bugs.gentoo.org/499086 --- alphacpuid.s:alphacpuid.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) alphacpuid.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null Can you confirm that preproc=/tmp/.$@.S in original snippet solves the problem? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d1cf23ac86c05b22b8780e2c03b67230564d2d34 With cross-reference to http://rt.openssl.org/Ticket/Display.html?id= can you confirm that preproc=/tmp/.$@.S assignment works? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3525] CRL tool doesn't show leading 0's in output
From: owner-openssl-...@openssl.org On Behalf Of Kurt Roeckx via RT Sent: Thursday, September 11, 2014 13:12 On Thu, Sep 11, 2014 at 09:32:26AM -0400, Salz, Rich wrote: I think the bug is that we need to ouput a leading zero to avoid confusing the number as negative. *On the wire* yes. For human display we can use plus/minus chars and I think we do (but don't have some 5280-invalid data handy to test) It's my understanding that for the encoding of the number without the leading 00 we need to go and add the 00 in front of it because we would otherwise create a negative number and those aren't allowed by RFC5280, so we would write that one with the leading 00. But I don't see a reason why the encoding can't have multiple leading 00s in it, and for instance always have a fixed size. X.690 8.3.2. So the question is are serial numbers matched based on the number themself or on the binary form? I can't find anything currently that says how to compare them, but I would actually expect that the binary represenation should be the same. And if the binary represenation is important, I think we should print the leading 00s if there are any. Since they are defined in ASN.1 as integers, they should be compared as integers. asn1/x_crl.c does so. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] Adding GET support to ocsp app
(trying a resend, my email address has changed) Le 11/09/2014 19:45, Salz, Rich a écrit : The attached diff adds GET support to ocsp. I'd appreciate any feedback. I don't see where the OCSP request is de-base64-ified, and URL-decoded. In both cases, d2i_OCSP_REQUEST_bio is called to get the request, but it's done directly on the HTTP request line for a GET.
Linking error on Soalris x86 and sparc using fips capable openssl 1.0.1h
Hi All, While fips build on soalris, I am getting variour errors: Sun-Intel: FIPSLD_CC=gcc FIPSLD_LINK=g++ /unixhome/upg/Unix/SunOS/i386/OpenSource/ssl-1.0.1h/bin/fipsld -fPIC -shared -g -O2 -o libImpl.so.10.0.0 -lcrypto Text relocation remains referenced against symbol offset in file fips_openssl_cpuid_setup0x1 /unixhome/upg/Unix/SunOS/i386/OpenSource/ssl-1.0.1h/bin/../lib/fipscanister.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status after searching on net came to know that the option -fPIC should be used to fix this error and is used to build fipscanister.o as well as for the project where this is being used. Also read about using -Wl, -Bsymbolic, this removes above error, but fails for many other symbols. Any idea why the symbols are not being relocated? Sun-sparc: For the above same linking on sparc, I got following error: 4280524028:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(./objs/SunOS-5.10-sparc-32/libImpl.so.10.0.0): ld.so.1: fips_premain_dso: fatal: relocation error: file ./objs/SunOS-5.10-sparc-32/libImpl.so.10.0.0: symbol _ZNSt8__detail15_List_node_base7_M_hookEPS0_: referenced symbol not found 4280524028:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244: make: *** [objs/SunOS-5.10-sparc-32/libImpl.so.10.0.0] Error 1 Any help would be much appreciated. Regards, Mrunal
RE: [openssl-dev] Adding GET support to ocsp app
I don't see where the OCSP request is de-base64-ified, and URL-decoded. In both cases, d2i_OCSP_REQUEST_bio is called to get the request, but it's done directly on the HTTP request line for a GET. Doh! Right :( __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes
Hi Andy, On Fri, 2014 Sep 12 09:50+0200, Andy Polyakov via RT wrote: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d1cf23ac86c05b22b8780e2c03b67230564d2d34 With cross-reference to http://rt.openssl.org/Ticket/Display.html?id= can you confirm that preproc=/tmp/.$@.S assignment works? Thanks for following this up. The only issues I'm seeing on Tru64 V4 from OpenSSL now are code-related build errors; your makefile changes are good. Starting with a plain ./config (defaults for everything), I get two build errors, described below. Once those are fixed---and the attached patch has my changes---the build completes successfully, and the test suite passes. Error the first: cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS -pthread -DDSO_DLFCN -DHAVE_DLFCN_H -std1 -tune host -fast -readonly_strings -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DGHASH_ASM -c b_sock.c cc: Error: b_sock.c, line 630: The member sa_in6 has an incomplete type. (incompmem) struct sockaddr_in6 sa_in6; ^ cc: Error: b_sock.c, line 862: The member sa_in6 has an incomplete type. (incompmem) struct sockaddr_in6 sa_in6; ^ *** Exit 1 Stop. This is the same IPv6-support issue reported earlier in the ticket. Error the second: cc -I../crypto -I.. -I../include -DOPENSSL_THREADS -pthread -DDSO_DLFCN -DHAVE_DLFCN_H -std1 -tune host -fast -readonly_strings -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DGHASH_ASM -c s3_cbc.c cc: Error: ../crypto/constant_time_locl.h, line 79: Missing ;. (nosemi) static inline unsigned int constant_time_msb(unsigned int a); --^ cc: Error: ../crypto/constant_time_locl.h, line 84: Missing ;. (nosemi) static inline unsigned int constant_time_lt(unsigned int a, unsigned int b); --^ cc: Error: ../crypto/constant_time_locl.h, line 86: Missing ;. (nosemi) static inline unsigned char constant_time_lt_8(unsigned int a, unsigned int b); --^ cc: Error: ../crypto/constant_time_locl.h, line 91: Missing ;. (nosemi) static inline unsigned int constant_time_ge(unsigned int a, unsigned int b); --^ [several more instances and unrelated warnings elided] *** Exit 1 Stop. Reason: The compiler doesn't understand the inline keyword. Still needing a fix is randfile.c, though on Tru64 V4 it doesn't give me trouble. --Daniel -- Daniel Richard G. || sk...@iskunk.org My ASCII-art .sig got a bad case of Times New Roman. diff --git a/e_os.h b/e_os.h index 27b1825..6859d4a 100644 --- a/e_os.h +++ b/e_os.h @@ -479,6 +479,9 @@ static unsigned int _strlen31(const char *str) # define setvbuf(a, b, c, d) setbuffer((a), (b), (d)) typedef unsigned long clock_t; #endif +#if defined(__osf__) defined(__DECC) !defined(__cplusplus) +# define inline /* Tru64 V4 C compiler doesn't grok inline */ +#endif #ifdef OPENSSL_SYS_WIN32_CYGWIN # include io.h # include fcntl.h @@ -658,7 +661,7 @@ static unsigned int _strlen31(const char *str) * versions. */ # if !defined(OPENSSL_USE_IPV6) -#if defined(AF_INET6) !defined(OPENSSL_SYS_BEOS_BONE) !defined(NETWARE_CLIB) +#if defined(AF_INET6) defined(IPPROTO_IPV6) !defined(OPENSSL_SYS_BEOS_BONE) !defined(NETWARE_CLIB) # define OPENSSL_USE_IPV6 1 #else # define OPENSSL_USE_IPV6 0
