The problem appears to be 325da823, x509_vfy.c line 1132.
best_score starts at 0 (from get_crl_delta's crl_score, initialised to
0), and (for whatever reason) crl_score also turns out to be 0. So
if (ASN1_TIME_diff(, , X509_CRL_get_lastUpdate(best_crl),
We've been recently hitting this compilation failure (on Windows). For
example,
set ASM=ml64 /c /Cp /Cx /Zi
perl crypto\x86_64cpuid.pl tmp32dll\x86_64cpuid.asm
ml64 /c /Cp /Cx /Zi /Fotmp32dll\x86_64cpuid.obj tmp32dll\x86_64cpuid.asm
Assembling: tmp32dll\x86_64cpuid.asm
Andy Polyakov ap...@openssl.org writes:
[...]
As FIPS module is compiled without BN_DEBUG it can and certainly will
confuse code compiled with BN_DEBUG that will call it. This surely is
the explanation for the phenomena and the answer to specific question is
no, you shouldn't define it.
Bruce Stephens bruce.steph...@isode.com writes:
When I build with ./Configure debug-linux-x86_64 then the tests all
pass. When I build with ./Configure debug-linux-x86_64 fips
--with-fipsdir=... then all tests pass up to ecdsatest:
prime239v2: ok
prime239v3: ok
prime256v1
When I build with ./Configure debug-linux-x86_64 then the tests all
pass. When I build with ./Configure debug-linux-x86_64 fips
--with-fipsdir=... then all tests pass up to ecdsatest:
prime239v2: ok
prime239v3: ok
prime256v1: ok
sect163k1: ok
sect163r1:
Nikos Mavrogiannopoulos via RT r...@openssl.org writes:
[...]
Indeed interesting. I downloaded 1.0.0h from source I saw the behavior
you describe. The issue is triggered on the version 1.0.0h as
distributed by debian.
I don't see anything obviously related in the list of Debian-specific
William A. Rowe Jr. wr...@rowe-clan.net writes:
On 3/14/2012 12:27 PM, Bruce Stephens wrote:
open...@master.openssl.org (OpenSSL) writes:
[...]
o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
I note that #2741 appears not to be resolved, so if you build on Windows
open...@master.openssl.org (OpenSSL) writes:
[...]
o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
I note that #2741 appears not to be resolved, so if you build on Windows
and use --with-fipsdir=... then that probably won't work.
[...]
ms/nt.mak and ms/ntdll.mak end up with
FIPSDIR=C:\\
BASEADDR=...
and the trailing \ quotes the line ending. Or something, anyway it
doesn't work.
I didn't notice that earlier because I send an incorrect suggestion for
PR: 2708; mine changed just the first / which isn't what was
Dr. Stephen Henson st...@openssl.org writes:
[...]
Please try the latest CVS, there have been some workarounds for these issues
such as:
http://cvs.openssl.org/chngview?cn=22031
Thanks, that fixes the issue.
(My apologies for trying to confuse you by giving the wrong version. I
messed up
If EXHEADER is set to empty, make install will fail on some
platforms. This is fixed in most subdirectories and this just copies the
fix to srp.
--- a/crypto/srp/Makefile
+++ b/crypto/srp/Makefile
@@ -43,7 +43,8 @@ links:
@$(PERL) $(TOP)/util/mklink.pl ../../apps $(APPS)
install:
-
This is when built with fips enabled. The issue seems to be some
difference in gcc behaviour:
make[3]: Entering directory `/releng/nightly/trunk/build/openssl/crypto/bn'
../../util/domd ../.. -MD gcc -- -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
At line 62:
$fipsdir =~ tr/\//${o}/;
But that's before the platform file has been loaded, so $o hasn't been
set. And tr doesn't do variable expansion, so this won't work anyway.
Using s rather than tr and moving it down the file (after the platform
file has been loaded, so line 236 or
Stephen Henson via RT r...@openssl.org writes:
[...]
As I indicated there were problems with the PKITS data itself, not
OpenSSL. The test data has now been updated (see message from David
Cooper in PKITS mailing list). Try downloading it again from NIST site.
OK, thanks. I thought that might
Stephen Henson via RT r...@openssl.org writes:
According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
I see a related change, to permit use of the old PKITS (with now expired
trust anchor).
However, the three
Stephen Henson via RT r...@openssl.org writes:
According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
I see a related change, to permit use of the old PKITS (with now expired
trust anchor).
However, the three
Stephen Henson via RT r...@openssl.org writes:
According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
I see a related change, to permit use of the old PKITS (with now expired
trust anchor).
However, the three
Stephen Henson via RT r...@openssl.org writes:
[...]
As I indicated there were problems with the PKITS data itself, not
OpenSSL. The test data has now been updated (see message from David
Cooper in PKITS mailing list). Try downloading it again from NIST site.
OK, thanks. I thought that might
4.3.10 Valid Rollover from PrintableString to UTF8String Test10 : Failed!
Filename:
pkits/smime/SignedValidRolloverfromPrintableStringtoUTF8StringTest10.eml
Return code:52, expected 0
Command output:
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
Verification failure
Dr. Stephen Henson st...@openssl.org writes:
[...]
+#ifdef ECDSA_POINT_MUL_NO_CONSTTIME
+ /* We do not want timing information to leak the length of k,
+* so we compute G*k using an equivalent scalar of fixed
+* bit-length. */
+
+ if
This check seems not to work as intended on one of our Windows 64
machines (a VM we use for building releases, as luck would have it):
{ my ($stddev,$stdino,@junk)=stat(STDOUT);
my ($outdev,$outino,@junk)=stat($output);
open STDOUT,$output || die can't open $output: $!
if
Does this now require nasm?
I tried
perl Configure VC-WIN64A
ms\do_win64a.bat
nmake -f ms\ntdll.mak
but that gives an error when compiling tmp32dll\x86_64cpuid.asm:
tmp32dll\x86_64cpuid.asm(144) : error A2008: syntax error : DB
(Previously we also ran ms\do_masm.bat
Bruce Stephens bruce.steph...@isode.com writes:
[...]
(Previously we also ran ms\do_masm.bat but that seems to have gone.)
My mistake, we call that for Windows 32 builds, not 64-bit builds.
When do_win64a.bat is being run it gives errors about nasm not being
found
Mario Brandt jbl...@gmail.com writes:
For 64 bit there is no ASM source available.
Really? But what about crypto/aes/asm/aes-x86_64.pl? That looks like
it'll create ASM for WIN64, and appears to (in tmp32dll I have an
aes-x86_64.asm).
For me it builds fine.
Hmm, that's odd. Perhaps a
Andy Polyakov ap...@fy.chalmers.se writes:
[...]
The line looks like one generated for ml64. Even though ml64 is not
unsupported, it's not periodically tested. Meaning that eventual
problems are fixed upon user feedback. Like this one. Thanks for report.
OK, I understand.
[...]
Verify
Mario Brandt jbl...@gmail.com writes:
[...]
I wonder! Since in INSTALL.W64 there is written that there isn't ASM
code for x64.
I think that file just hasn't been updated.
[...]
Perhaps a difference in VS version or something
I use VC 2008 and nasm is in my %PATH%
Well, that's why it
I think the included patch is appropriate (to match other similar
sections). (The change matters if you do 'make EXHEADER= install' on
some platforms, to avoid installing headers.)
--- a/crypto/ts/Makefile
+++ b/crypto/ts/Makefile
@@ -60,7 +60,7 @@ links:
@$(PERL) $(TOP)/util/mklink.pl
Bruce Stephens bruce.steph...@isode.com writes:
[...]
Wouldn't it make sense for the truncation to be done in ECDSA_do_sign(),
as it is in dsa_do_sign()?
Presuming that this is sensible, would this change be about right?
--- a/crypto/ecdsa/ecs_ossl.c
+++ b/crypto/ecdsa/ecs_ossl.c
@@ -251,26
Dr. Stephen Henson st...@openssl.org writes:
[...]
I'd suggest you try OpenSSL 1.0.0 and the EVP interface instead.
Wouldn't it make sense for the truncation to be done in ECDSA_do_sign(),
as it is in dsa_do_sign()?
For the OP's question surely using the EVP interface isn't possible, is
it?
We've just been hit by this (not on AIX---the bug is quite general, I
think). The problem looks real (the ZLIB_INCLUDE flag is set but
never used), and the patch looks plausible.
Is there some reason the bug is still open?
__
In 0.9.8g (the Debian package of it, anyway), this works:
openssl pkcs12 -export -name name -inkey 1215091299.pem -in certs.pem
-out p12.p12
(where those files have appropriate types, and certs.pem contains a
user certificate and a CA certificate.)
In 0.9.8h which I just built, it
Patrick Patterson [EMAIL PROTECTED] writes:
On May 15, 2008 10:58:07 am John Parker wrote:
In the wake of the issues with Debian, is it possible to modify the
source so that it is possible to use valgrind with openssl without
reducing the key space?
It is already possible to use openssl and
Andreas Hasenack [EMAIL PROTECTED] writes:
[...]
Any hints?
gcc-4.2? If so, try gcc-4.1 if you can, otherwise try disabling all
the asm stuff.
__
OpenSSL Project http://www.openssl.org
Darryl Miles [EMAIL PROTECTED] writes:
[...]
So the -DPURIFY kills the only known source of uninitialized data
warnings in the OpenSSL project that has been reported todate.
There's another little one in RAND_load_file. If the function is
given a non-NULL file that doesn't exist, it still
If RAND_load_file is called with a non-NULL file which does not exist,
then it still does:
i=stat(file,sb);
/* If the state fails, put some crap in anyway */
RAND_add(sb,sizeof(sb),0.0);
if (i 0) return(0);
And sb may well be uninitialized.
Obviously that's of
I build OpenSSL 0.9.8d on x86 GNU/Linux with gcc-4.1, and on SPARC
Solaris with Sun Studio 11 cc.
I get the following. On GNU/Linux:
brs% ./openssl aes-128-cbc -in pca-cert.srl -k secret -a
U2FsdGVkX1/4wyyZncUl/+DrVpt/HzuHZcO+reAKB/w=
On Solaris:
edmund% ./openssl aes-128-cbc -in
Bruce Stephens [EMAIL PROTECTED] writes:
[...]
Ah, I see a problem.
The SPARC one fails the AES-128-ECB(encrypt) test:
OK, on another box (with more up to date compiler and OS patches) it
passes, so it's probably a toolchain problem
The following trivial C file fails to compile in 0.9.8a:
#include openssl/sha.h
void
foo(void)
{
}
In file included from test.c:1:
/usr/include/openssl/sha.h:109: error: syntax error before 'size_t'
/usr/include/openssl/sha.h:111: error: syntax error before 'size_t'
OpenSSL Project [EMAIL PROTECTED] writes:
OpenSSL STATUS Last modified at
__ $Date: 2002/08/08 22:55:28 $
DEVELOPMENT STATE
o OpenSSL 0.9.8: Under development...
o OpenSSL 0.9.7-beta3: Released on July 30th,
they get used, that's going to cause some prblems
on some filesystems.
However, I'd guess the current design is probably fine for, say, 1
certificates. Specific applications might find the scalability a
problem, but for most purposes it's fine.
--
Bruce Stephens [EMAIL
40 matches
Mail list logo
