It's an interesting idea. I'll chat with the Moz folks. Best we could do is
probably early patch to 1.0.2
__
OpenSSL Project http://www.openssl.org
Development Mailing List
This idea comes via https://bugzilla.mozilla.org/show_bug.cgi?id=1083767
(which I realize isn't on openssl's rt, but given the enormity of the
security problem I hope you'll forgive me). The proposal at that bug is
to create an environment variable for NSS to enforce disablement of
particular vers
>>> It's not clear to me that we ought to do anything; this is a problem
>>> only when building using compilers for MacOSX releases that have long
>>> since been EOLed.
>>
>> Well, if you can confirm following, then it would still be appropriate
>> to revert that change. Compile following snippet w
On 23 Oct 2014, at 13:38, Andy Polyakov wrote:
It's not clear to me that me ought to do anything; this is a problem
only when building using compilers for MacOSX releases that have long
since been EOLed.
Well, if you can confirm following, then it would still be appropriate
to revert that cha
On 23 Oct 2014, at 13:38, Andy Polyakov wrote:
It's not clear to me that we ought to do anything; this is a problem
only when building using compilers for MacOSX releases that have long
since been EOLed.
Well, if you can confirm following, then it would still be appropriate
to revert that c
On 23 Oct 2014, at 13:38, Andy Polyakov wrote:
It's not clear to me that we ought to do anything; this is a problem
only when building using compilers for MacOSX releases that have long
since been EOLed.
Well, if you can confirm following, then it would still be appropriate
to revert that
Hello Andy,
On Thu, Oct 23, 2014 at 5:34 PM, Andy Polyakov via RT
wrote:
> > I used the commands
> >
> > ./Configure shared debug
> I don't think this would be working build on
> a 64-bit platform such as one in question. Or rather even if it does
> work (make test pas
Hello Andy,
On Thu, Oct 23, 2014 at 5:34 PM, Andy Polyakov via RT
wrote:
> > I used the commands
> >
> > ./Configure shared debug
> I don't think this would be working build on
> a 64-bit platform such as one in question. Or rather even if it does
> work (make test pas
> I used the commands
>
> ./Configure shared debug
I don't think this would be working build on
a 64-bit platform such as one in question. Or rather even if it does
work (make test passes, etc.) it wouldn't be supported and questions
should be dismissed. "Official" way t
Hi,
> On the current branch openssl-SNAP-20141011
>
> perl ./Configure mingw -E -no-asm
>
> failure on :
>
> md4.h => ../../include/openssl/md4.h
>
> md4test.c => ../../test/md4test.c
> Can't open md4.c: No such file or directory at ../../util/mklink.pl line
> 62.
This should have been fixed
> This patch fixes clobbering of XMM6-XMM9 registers by the assembler
> implementation of aesni_ecb_encrypt().
This was fixed in RT#3552.
__
OpenSSL Project http://www.openssl.org
Development Maili
> Have attempted another build using Win 32 option
> perl Configure VC-WIN32 no-asm no-hw
>
> ms\do_ms completes without error or warnings.
>
> Running nmake -f ms\ntdll.mak compiles all C code but generates the
> following error on linking
> rc /fo"tmp32dll\libeay
> I am attempting to build Open SSL 1.0.1.i on Intel 64, Windows 7, using
> Visual Studio Professional 2012.
> I configured the build with
> perl Configure debug-VC-WIN64I no-asm no-hw
WIN64I denotes Itanium, while what you need on Windows 7 is WIN64A.
> ms\do_win64i compl
Hi,
Thanks for report. Good job.
> and that does not sit well with the documentation for MacOSX i386
> assembler:
> https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/Assembler/040-Assembler_Directives/asm_directives.html
>
> suggesting that the .comm directive takes
> The correct solution is to remove ',l' as was also suggested.
I mean like attached.
> This way compiler doesn't complain and macro is still compliant with
> style guidelines.
diff --git a/crypto/md32_common.h b/crypto/md32_common.h
index 16f363a..2146154 100644
--- a/crypto/md32_common.h
+++ b
> Is there any time that the value of HOST_cl2 is used? Could we just
> add the (void) cast to the macro definition?
It's not only about whether or not it's actually used, but even question
of style. Macros are *preferred* to be expressions so that they can be
used as part of other expression. Wh
16 matches
Mail list logo