Re: [openssl.org #987] openssl-0.9.7e compiling problem on IRIX 5.3
This message addresses *all* users, rather than report originator alone. openssl-0.9.7e's Makefile contains -notall for do_irix-shared. This option is not understood by the SGI IRIX 5.3 IDO (IRIX development option) cc. Later versions (SGI MIPSPRO) might be different. Changing it into -none seems to solve the problem. Formally this puts us, OpenSSL developers, in rather tight situation. Indeed, as we can't possibly have access to *all* platforms OpenSSL can or *could* be compiled at, statements like this solves my problem in my out-of-date setup and I don't know how it affects others [who are most likely majority!] doesn't really make life easier, does it? So *please*, do some background research, provide pointers or information itself [like snippets from manual pages], etc. For example in this particular case request originator could have pointed at ld manual page at http://techpubs.sgi.com/library/ and ratiocinate that given that another major IRIX release is highly unlikely to appear and -none is still supported by 6.5, replacing -notall with -none resolves this backward compatibility issue and covers both up-to-date and legacy setups. One can argue what would be the point for him to do it, if an OpenSSL developer could do it [as we obviosuly see here]. Well, it's just that *I* *happened* to be familiar with IRIX, that's all. This is by no means guarantees that next time a similar matter will be left unattended or platform simply declared unsupported. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #987] openssl-0.9.7e compiling problem on IRIX 5.3
Proposed change passes regression tests on IRIX 6.5, fix is commited to 0.9.7 and HEAD branches. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #259] SHA-256, SHA-384, SHA-512
New SHA implementations were introduced in 0.9.8 development branch. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #514] Threading configuration for AIX
Threading support for AIX appears in latest 0.9.7 [and HEAD] snapshots. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #525] Bug in openssl-0.9.7a on HPUX IA64 platform
Support for hpux*-ia64-gcc appears first in 0.9.8 development branch. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #652] make test failure with AIXV5.2, C for AIXV6.
AIX support was fixed/refined in latest 0.9.7 and HEAD branches. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #672] make test problem
You're hitting compiler bug. It's not OpenSSL problem... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #717] Incorrect shared library suffix on HP-UX ia64
It's merely cosmetics: .sl works as well as .so. The issue is addressed in 0.9.8 development branch. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #717] Incorrect shared library suffix on HP-UX ia64
[Andy Polyakov] It's merely cosmetics: .sl works as well as .so. The issue is addressed in 0.9.8 development branch. Actually, when we try to get both hppa and ia64 binaries working, it is important that the hppa libraries are called .so, and the i164 libraries are using .so. If not, the program will not run as they should. It is not merely cosmetics. Sounds good that the problem is fixed in a development branch. I hope it will make it into a stable release soon. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #793] openssl 0.9.7c: Self test fail on IA64 HP-UX 11.22
It's an old [by now] compiler bug. If the problem persists, ask vendor for patch or drop optimization level according to instructions in INSTALL file. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #933] hpux64-parisc2 compile bug in crypto/bn/Makefile.ssl
This was fixed at some point... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #788] [PATCH] up to 1.4x RSA throughput using SSE2
Submitted code is incorporated into development branch. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #841] SSE
This problem was fixed at some point. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #864] aix 5.2 issues
AIX issues were addressed in later 0.9.7 and HEAD branches. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #982] BN_add failuire in tests for openssl-0.9.7e on Sun 5.8
Dismissed as non-reproducible. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #909] Build problems (with fix) on Digital Unix (Tru64) 5.1, Alpha
Dismissed as partially non-reproducible and partially as fixed at other occasions. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #985] Bug and Fix: _memmove in libcrypto.a / 0.9.7e / SunOS 4.1.4
Resolved as duplicate of #963. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #986] Issue while installing openssl
Fixed in latest 0.9.7 snapshots. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #978] AIX 5.1 openssl-0.9.7e does not install
Fixed in latest 0.9.7 snapshots. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #941] ./config error
Duplicate of #942. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #942] OpenSSL 0.9.7d ./config error
I'm sorry, but we can't possibly resolve local OS configuration problems. perl: cannot execute is such problem and you should bring it up with your system administator. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #915] openssl-0.9.7d
Resolved as non-OpenSSL issue. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #820] openssl 0.9.7c bug
Dismissed as duplicate of #963. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #717] Incorrect shared library suffix on HP-UX ia64
It's merely cosmetics: .sl works as well as .so. The issue is addressed in 0.9.8 development branch. Actually, when we try to get both hppa and ia64 binaries working, it is important that the hppa libraries are called .so, and the i164 libraries are using .so. If not, the program will not run as they should. Both pa-risc and ia64 linkers look for both .so and .sl and once program is linked with some shared object it will require that particular one. And at run-time shared object extension has no meaning whatsoever, it's the contents matching ABI for current process, which determines if any particular file is successfully loaded to address space. It is not merely cosmetics. Can you present evidence that it's not [in OpenSSL context]? A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #717] Incorrect shared library suffix on HP-UX ia64
[Andy Polyakov] Both pa-risc and ia64 linkers look for both .so and .sl and once program is linked with some shared object it will require that particular one. And at run-time shared object extension has no meaning whatsoever, it's the contents matching ABI for current process, which determines if any particular file is successfully loaded to address space. True. But this creates problem when compiling on one host, and distributing the binaries into other hosts. Can you present evidence that it's not [in OpenSSL context]? A. I discovered this problem because some of our hppa binaries had been distributed to our ia64 binaries, which also had ia64 openssl libraries with .sl extentions. These libraries were used instead of the correct hppa libraries, and the binaries broke. (This is a long time ago, so I do not remember the details.) You might argue that our setting is very special, but it is a real one. We maintain ~1700 unix machines the largest university in Norway, and discovered the problem when we introduced hp-ux/ia64 machines. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #717] Incorrect shared library suffix on HP-UX ia64
Both pa-risc and ia64 linkers look for both .so and .sl and once program is linked with some shared object it will require that particular one. And at run-time shared object extension has no meaning whatsoever, it's the contents matching ABI for current process, which determines if any particular file is successfully loaded to address space. True. But this creates problem when compiling on one host, and distributing the binaries into other hosts. I can't imagine any problems at binary distribution stage... Once again, once application is linked with any particular shared object it will require object with the same name without regard to extention. If you managed to distribute e.g. pa-risc shared object with ia64 application, extensions are hardly ones to blame... Can you present evidence that it's not [in OpenSSL context]? A. I discovered this problem because some of our hppa binaries had been distributed to our ia64 binaries, which also had ia64 openssl libraries with .sl extentions. Well, take it to the next step. HPUX supports two IA-64 ABIs: 32- and 64-bit ones. Both would have same extenstion and application would stop working if you try to link with mismatching object at run-time in exactly same way... I mean it looks like your procedures assume type of shared object solely by extension and it's not actually fool-proof... In other words I'm still not convinced that changing to .so would actually solve any problem. And I mean *actually* *solve* problem*s*, not just linger some particular one... These libraries were used instead of the correct hppa libraries, and the binaries broke. (This is a long time ago, so I do not remember the details.) The whole point with stable branch is that one is reluctant to make cosmetic changes to it. Or rather changes which were believed to be cosmetic so far, which is why I asked for evidence... Essentially the matter is not really an issue. It's just that the reason why the ticket was [attempted to be] resolved now is that we're scheduling 0.9.7f release and it's more about bad timing than real technical problem. I'll see what I can do prior 0.9.7f, but I can't make any promises... Cheers. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #986] Issue while installing openssl
[appro - Mon Dec 27 17:22:14 2004]: Fixed in latest 0.9.7 snapshots. Can you send me the URL to download the 0.9.7 snapshots. Also please let me know the steps to install it. thanks srinivas __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #986] Issue while installing openssl
Can you send me the URL to download the 0.9.7 snapshots. Also please let me know the steps to install it. Thanks Srinivas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov via RT Sent: Monday, December 27, 2004 11:22 AM To: Seeda, Srinivas Cc: openssl-dev@openssl.org Subject: [openssl.org #986] Issue while installing openssl Fixed in latest 0.9.7 snapshots. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #973] openssl dgst -rmd160 /tmp/very_large_file fail
i try to make a dgst of a 40Gb file, but when the openssl binary try to fopen the file, it's fail .. i think the problem was the fopen, maybe it's dont use the open (2) with the option O_LARGEFILE.. can you fix it ? Well, in certain sense it's by design. At the very least we try to adhere to ANSI as much as possible and ANSI stdio doesn't cover large file support on 32-bit platforms. There is transitional large file API, which can be engaged by defining certain macros at compile time. *But* it's unlikely to happen in 0.9.7 context or at least not in upcoming 0.9.7f context. It's not a question of triviality, it's just that we're not prepared to address possible cross-platform short-term problems that might emerge. As temporary workaround you can use 'openssl dgst -rmd160 /tmp/very_large_file'. Well, you still have to make sure your shell is capable of opening large files for redirection (most notably elder versions of tcsh fail to). To summarize. Issue will be addressed in 0.9.8, *possibly* in 0.9.7g if broader interest is shown. Till then stick to workaround. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #987] openssl-0.9.7e compiling problem on IRIX 5.3
Formally this puts us, OpenSSL developers, in rather tight situation. Indeed, as we can't possibly have access to *all* platforms OpenSSL can or *could* be compiled at, statements like this solves my problem in my out-of-date setup and I don't know how it affects others [who are most likely majority!] doesn't really make life easier, does it? So *please*, do some background research, provide pointers or information itself [like snippets from manual pages], etc. For example in this particular case request originator could have pointed at ld manual page at http://techpubs.sgi.com/library/ and ratiocinate that given that another major IRIX release is highly unlikely to appear and -none is still supported by 6.5, replacing -notall with -none resolves this backward compatibility issue and covers both up-to-date and legacy setups. One can argue what would be the point for him to do it, if an OpenSSL developer could do it [as we obviosuly see here]. Well, it's just that *I* *happened* to be familiar with IRIX, that's all. This is by no means guarantees that next time a similar matter will be left unattended or platform simply declared unsupported. A. if you had not been, by chance, familiar with that particular platform, you still could have replied with a brief mail asking me to figure it out. My intend was to merely point out the issue to you developers. Maybe I should have stated more explictly that of course if you needed further details you should not hesitate to say so. Georg -- Georg Schwarzhttp://home.pages.de/~schwarz/ [EMAIL PROTECTED] +49 177 8811442 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #949] openssl on cygwin bug and patch
I have encountered a problem when using openssl to encrypt binary files on cygwin. Here is how to reproduce the problem: 1) When you install cygwin, make sure that the format for text files is set to DOS 2) Encrypt a binary file (e.g. a .zip file, let's call it file.zip): openssl enc -bf -in file.zip -out file.zip.enc (give the password when prompted) 3) Decrypt the file: openssl enc -bf -d -in file.zip.enc -out file.dec.zip (give the password when prompted) 4) Compare the original and the decrypted files: cmp -l file.zip file.dec.zip You will notice that the files are different. It should be noted that in a sense this is an enironmental problem, i.e. local setup one. At least if it was universal problem, then 'make test' woudln't have passed, as the above are actually very kind of operations portion of 'make test' depends upon to succeed. I bet failure has everything to do with the fact that directory your file.zip resides in is mounted as textmode. But as we formally can't assume that everything is mounted as binmode, the report is still qualified as bug report and appropriate fix is commited to 0.9.7 and HEAD branches. Case is being dismissed. Case is being dismissed. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #752] [Patch] Win32 test programs
Essentail parts of the report in question were apparently addressed at earlier occasions. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #987] openssl-0.9.7e compiling problem on IRIX 5.3
if you had not been, by chance, familiar with that particular platform, you still could have replied with a brief mail asking me to figure it out. My intend was to merely point out the issue to you developers. Maybe I should have stated more explictly that of course if you needed further details you should not hesitate to say so. It's not about hesitation, it's about time constrains. Once again, the if works only one way: if any member of OpenSSL development team [by chance] in not familiar with any particular platform and report leaves more questions opened than answered, then report tends to remain unattended. Do not take chances and don't expect can you elaborate questions to be asked. Accompany report with solid argumentation and clear test-cases from the beginning. It's in your interest. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #944] Make fails at /crypto/lhash...
I'm sorry, but we can't possibly resolve all the crazy local OS configuration problems. I mean this looks very much like problem with your OS setup problem and you really be better talking to your system administator. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #943] make test failed
Your problem is most likely has everything to do with the fact that your working directory is mounted textmode. If it's mounted binmode, then it's still most likely your local cygwin setup/configuration problem, as I can't reproduce the problem. The latter means that you should rather bring it up with your system administrator, as we can't possibly help with all crazy OS setup problems. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #889] [PATCH] Support for VIA PadLock ACE (fwd)
The issue was resolved at openssl-dev, outside RT. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #875] Trying to compile OpenSSL.v0.9.7d on CygWin and Windows2000.
Your problem is most likely has everything to do with the fact that your working directory is mounted textmode. If it's mounted binmode, then it's still most likely your local cygwin setup/configuration problem, as I can't reproduce the problem. The latter means that you should rather bring it up with your system administrator, as we can't possibly help with all crazy OS setup problems. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #823] openssl 0.9.7c build fails
Dismissed as duplicate of #963. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #924] Patch for 0.9.7-stable (mingw)
Essential parts of report are addressed in latest snapshot. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
aes improvements (TSU NOTIFICATION)
On Thu, 23 Dec 2004, Andy Polyakov wrote: aes-586.pl module is committed to CVS now [see http://cvs.openssl.org/rlog?f=openssl/crypto/aes/asm/aes-586.pl]. Take Special note about instruction choice in commentary section for consideration even for AMD64. Merry Christmas to everybody:-) A. hmmm... i seem to have done better by switching back to scaling :) with the patch below i'm getting the following throughput improvements for aes-128-cbc 8192B buffer: patch delta p4-2+ 3.8% p4-3+11% p-m + 8.8% k8 +12% efficeon+ 4.3% the code is 229 bytes smaller in $small_footprint=1 ... i didn't look to see how much smaller it is for the fully unrolled variety (i would assume 1145 bytes or so). unfortunately this space improvement is hidden by the alignment pain caused by the placement of AES_Te and AES_Td :) i suggest moving both those tables to the top of the module so that their 64 byte alignment is taken care of once only. here's an updated comparison versus the gladman code -- this is in cycles/byte for 8192 byte buffer (smaller is better): openssl w/patch small large gladman p4-231.726.1 27.3 p4-332.332.9 18.7 p-m 23.823.3 16.9 k8 21.821.5 18.1 efficeon25.122.6 17.8 damn the p4 is a weird beast -- notice how the gladman code is better everywhere except p4-2 ... and p4-3 gladman is nearly twice as good as the openssl code. i'm a bit disappointed with efficeon but i know what the problems are (efficeon lacks native bswap, so your 1% estimation on the bswaps is more painful for efficeon, and the loop could be rotated differently). fixing that is a more significant effort -- so i figured i'd checkpoint by sending you a patch now. i made the following changes: o shifts by 24 don't need to be followed by and $0xff: shr $22,%esi-- shr $24,%esi and $0x3fc,%esi mov offs,(%ebp,%esi,4),esi mov offs(%ebp,%esi,1),esi o movzbl is 3 bytes shorter than and $imm: shr $14,%eax-- shr $16,%eax and $0x3fc,%eax movzbl %al,%eax mov offs(%ebp,%eax,1),%eax mov offs,(%ebp,%eax,4),%eax there's no perf degredation by making this change (in fact it improves on p4-2, p-m and efficeon). for consistency i made the same change to all the and $0x3fc,%edi ... unfortunately movzbl isn't an option there, but there was no negative perf impact anywhere with the change (and efficeon internally uses movzbl for this case so i'm slightly biased). o movzbl is 3 bytes shorter than and $imm (part 2): movl mem,%reg -- movzbl mem,%reg and $0xff,%reg this occurs several times loading from tables -- it's a space win and a perf win everywhere. o used a gladman trick on %edx in encode because it was easy enough -- during encode we finish with the low half of %edx before we need the high half, so after finishing with the low half i inserted a shr $16,%edx which lets us use movzbl %dl/%dh to get the top two bytes (similarly for %ecx during decode). i think i gave up a bit on p4-2 with this step, but i figured it was worth it because it helped everywhere else and p4-2 has been superceded by p4-3. plus this transform saves code space. it's not easy to transform the other 3 registers in this way without major surgery around loop edges ... which will have to wait for another rainy day. -dean SUBMISSION TYPE: TSU SUBMITTED BY: dean gaudet SUBMITTED FOR: dean gaudet POINT OF CONTACT: [EMAIL PROTECTED] PHONE and/or FAX: (408) 919-3086 MANUFACTURER: openssl PRODUCT NAME/MODEL #: 0.9.8-dev ECCN: 5D002 Index: crypto/aes/asm/aes-586.pl === RCS file: /home/dean/openssl/Repository/openssl/crypto/aes/asm/aes-586.pl,v retrieving revision 1.1 diff -u -r1.1 aes-586.pl --- crypto/aes/asm/aes-586.pl 23 Dec 2004 21:32:34 - 1.1 +++ crypto/aes/asm/aes-586.pl 28 Dec 2004 02:31:39 - @@ -4,6 +4,8 @@ # Written by Andy Polyakov [EMAIL PROTECTED] for the OpenSSL # project. Rights for redistribution and usage in source and binary # forms are granted according to the OpenSSL license. +# +# Additional contributions by dean gaudet [EMAIL PROTECTED]. # # # You might fail to appreciate this module performance from the first @@ -15,15 +17,6 @@ # more than *twice* as fast! Yes, all this buzz about PIC means that # [unlike other
Re: [openssl.org #944] Make fails at /crypto/lhash...
Hey, if you don't have a clue, just say so. I am the sys admin. Talking to myself isn't really helpful. I worked around this problem long ago...The original post to your (quite less than helpful) listserv was Sept 8th. Nice response time! JP On 12/27/04 4:33 PM, Andy Polyakov via RT [EMAIL PROTECTED] wrote: I'm sorry, but we can't possibly resolve all the crazy local OS configuration problems. I mean this looks very much like problem with your OS setup problem and you really be better talking to your system administator. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
