On Nov 9 01:19, Mike Frysinger wrote:
On Wed, Nov 09, 2005 at 12:00:19AM +0100, Dirk Mueller wrote:
the appended patch makes libcrypto.so compile without executable stack
requirements. it should be portable accross all versions of binutils (and
doesn't affect any non-linux platform
On Wednesday 09 November 2005 10:45, Corinna Vinschen wrote:
It's also used for Cygwin and the patch breaks the Cygwin build.
I don't have a cygwin toolchain around, but can you tell me the error message
so that I can work on fixing it?
does the attached patch work?
Thanks,
Dirk
---
On Nov 9 13:57, Dirk Mueller wrote:
On Wednesday 09 November 2005 10:45, Corinna Vinschen wrote:
It's also used for Cygwin and the patch breaks the Cygwin build.
I don't have a cygwin toolchain around, but can you tell me the error message
so that I can work on fixing it?
x86cpuid-cof.s:
On Wednesday 09 November 2005 14:30, Corinna Vinschen wrote:
Btw., the first asm message indicates that a \n is missing. You should
add this at the end of the section string to avoid the warning.
Ok, thanks for your help and the hint. I'd like to suggest the following patch
for inclusion
On Wed, Nov 09, 2005 at 02:39:47PM +0100, Dirk Mueller wrote:
Ok, thanks for your help and the hint. I'd like to suggest the following
patch
for inclusion into OpenSSL.
thanks, we've just been forcing -Wa,--noexecstack in Gentoo ... this is much
nicer :)
btw, does x86nasm.pl need to be
On Wednesday 09 November 2005 15:15, Mike Frysinger wrote:
btw, does x86nasm.pl need to be fixed too ? in theory, if it was used to
generate some source files which are included in the final lib, it'll force
back in exec stack markings ...
It doesn't seem to be used here. can you confirm
On Wed, Nov 09, 2005 at 03:21:20PM +0100, Dirk Mueller wrote:
On Wednesday 09 November 2005 15:15, Mike Frysinger wrote:
btw, does x86nasm.pl need to be fixed too ? in theory, if it was used to
generate some source files which are included in the final lib, it'll force
back in exec stack
the appended patch makes libcrypto.so compile without executable stack
requirements. it should be portable accross all versions of binutils
x86unix.pl is called to generate output suitable not only for GNU
assembler [applies to ELF, COFF and a.out targets], but even for vendor
assemblers, for
I'm trying to merge the work from Martin Witzel (openssl-e dated from
Nov. 2003) to reduce the OpensSSL footprint (for 386'er x86). With
OpenSSL 0.9.7 is was able to reduce the library size down to
1070834 bytes libcrypto.a
159774 bytes libssl.a
if only DES, MD5, RSA and SHA are used. Now
While seeing the Major changes between Openssl 0.9.7g and Openssl
0.9.8 I found that for Win64 support it says
: Added initial support for Win64
But I am not able to find out what initial support does this provide?
Could anyone elaborate on this?
Risking that the answer will be
On Wed, Nov 09, 2005 at 05:38:39PM +0100, Andy Polyakov wrote:
(and doesn't affect any non-linux platform anyway).
How come it turns from unsure should be portable to definitive
doesn't affect so easily:-)
it should be portable across all ELF targets ... after all, you're just adding
an
On Wednesday 09 November 2005 17:38, Andy Polyakov wrote:
(and doesn't affect any non-linux platform anyway).
How come it turns from unsure should be portable to definitive
doesn't affect so easily:-)
What I tried to say was that the extra section is ignored on platforms that do
not use a
First of all keep in mind and some platforms are pretty much community
supported, meaning that it's seldomly tested by occasional users and
platform support might end up being based on incomplete or inaccurate
information. This in turn means that you might have some irrational
impressions such
This was already reported and fixed. Case is being dismissed. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List
See http://marc.theaimsgroup.com/?l=openssl-devm=113155776813084w=2
for resolution. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Using either NetBSD 1.6.2 make, or NetBSD pkgsrc gmake to build 0.9.8a
seems to result in a continuous make loop.
Well, the make loop problem doesn't seem to be specific to NetBSD. If
you delete libcrypto.a and don't run 'make clean', all makes end up in
end-less loop.
After some
Thank you very much,
without filing a bug, just wanted to notice that after successful
installation OpenSSL-0.9.8a on linux 32, openssl version produces:
OpenSSL 0.9.6b [engine] 9 Jul 2001
while for linux 64
OpenSSL 0.9.7a Feb 19 2003
On other platforms version seems to be correct.
[EMAIL PROTECTED] via RT wrote:
In the rt now is a new patch for openssl HEAD (of 20051108)
that handles the subjectAltName generation.
This patch allows users to set all types of generalNames
from data provided in the DN of the request.
Bye
Goetz
--
DMCA: The greed of the few outweighs the
Hi,
are there any plans to add support for rfc3546 (Transport Layer Security (TLS)
Extensions),
especially Server Name Indication to openssl in the near future?
Regards
Rüdiger
__
OpenSSL Project
On Wed, Nov 09, 2005 at 12:00:19AM +0100, Dirk Mueller wrote:
Hi,
the appended patch makes libcrypto.so compile without executable stack
requirements. it should be portable accross all versions of binutils (and
doesn't affect any non-linux platform anyway).
The problem is that
I have two questions:
(1) When new version of openssl which implements the PSK ciphersuites
be released?
(2) I can use the patch supplied here in the until then, but then
there is the legal question: is the patch released under the same
license as openssl?
Thanks!
21 matches
Mail list logo
