RE: [openssl.org #3072] Strange behaviour when talking to microsoft exchange
> From: owner-openssl-...@openssl.org On Behalf Of Kurt Roeckx
> Sent: Tuesday, 18 June, 2013 18:50
> On Tue, Jun 18, 2013 at 05:25:06PM -0400, Dave Thompson wrote:
> > > My conclussions:
> > > - One of the 2 sides doesn't implement
> > > DES-CBC-SHA/DES-CBC3-SHA properly
> >
> > ... I think you're right and I suspect the other side because
> > openssl interoperates with lots of folks -- unless there's
> > something badly off in your build of openssl. Can you
> > connect with DES-CBC3-SHA to usual suspects like google?
>
> With google I get:
> Protocol : TLSv1.2
> Cipher: DES-CBC3-SHA
>
> (Or by default)
> Protocol : TLSv1.2
> Cipher: ECDHE-RSA-AES128-GCM-SHA256
>
> Both of course work as expected.
>
And is able to send and receive data? I forgot to ask that.
For an https server send "GET / HTTP/1.0\r\n\r\n" (I feed
from a file or echo| since it's hard to type that in) and
look for HTTP headers (followed by something HTMLish).
If so, your openssl is doing DES-CBC3 right; see below.
> > I think commandline nowadays picks up engines from openssl.cnf
> > even if you don't explicitly ask -- do you have any configured?
>
> There are no engines configured.
>
(That was just in case you got the cipher implementation
from someplace other than openssl itself.)
> > If you didn't build from source, can you try that?
>
> Enable engines? Which ones?
>
I didn't mean engines, I meant build from source, to be sure
you're running as-distributed code for the affected cipher.
But if you can communicate with e.g. google that's enough.
> PS: Are you unable to reproduce this? I can reproduce this with
> various sites including things like smtp.live.com.
>
I can't reproduce any starttls smtp; I suspecvt our provider
has done something to port 25 probably on the theory they're
fighting spam. I get banner which is clearly masked and
EHLO/250 response which is clearly altered, and STARTTLS
is rejected with various 5xx. If you have a server that
handles clear+STARTTLS on a different port I can try it.
I can do *https* 443 DES-CBC3 fine in 1.0.1e, and others.
One logical but unpleasant theory is that s_client starttls
code clobbers something that screws up DES-CBC3 but not RC4.
That would be quite a pain to debug. It's a little work, but
what I would try first is a simplified replacement for s_client,
without the bells and whistles especially nonblocking, like:
// add error checking to taste
ctx=SSL_CTX_new()
// set verify_locations, ciphers, etc, as desired
ssl=SSL_new(ctx)
ipaddr=gethostaddr("whatever")
s=socket()
connect(s,iapddr_and_port)
bio=push bufferBIO on socketBIO for s // easier to manage
BIO_gets for 220
BIO_puts "EHLO...\r\n"
BIO_gets until 250-no-hyphen looking for STARTTLS
BIO_puts "STARTTLS\r\n"
BIO_gets for 220
SSL_set_bio(ssl,bio,bio)
SSL_connect
SSL_write "AUTH...\r\n" // or whatever
SSL_read and look for valid lines
// continue until done
If that works, the problem is pretty definitely s_client.
If that fails, and on more than one or a few servers,
I don't know what to think.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
RE: Regarding SSL cert generation
>From: owner-openssl-...@openssl.org On Behalf Of Ajith Mamachan >Sent: Tuesday, 18 June, 2013 03:03 >When I generated the cert thru openssl, It not starting with BEGIN CERTIFICATE, >rather with >Certificate: >Data: >This creates problem in importing the cert to my server. >Anyone knows , whether the format is different or not?Anyone please explain If you used openssl (commandline) 'ca' it puts a human-readable display first as a "comment" and then the actual PEM certificate. 'x509' can be made to do this also. openssl when reading PEM files ignores such "comments" but other implementations don't. You can just edit the file to delete everything except the BEGIN line to the -END line (inclusive). That's the actual cert. If you want the program to do this for you, just run it through 'x509' without making any change: openssl x509 -in cert_with_comments -out cert_without_comments Or you can easily do it with sed or awk on Unix (or on Windows if you have Unix-like tools installed). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3075] [PATCH] Fix ASM support for FreeBSD 10
On 6/18/2013 4:47 AM, Andy Polyakov via RT wrote: >> For FreeBSD 10 we have changed /usr/lib/libc.so to be a text linker >> script and no longer a symlink. This breaks the config check on i386 for >> what binary format to use when building with ASM support. The current >> config check expects /usr/lib/libc.so to symlink to a /usr/lib/libc.so.X >> file to run file(1) against. For FreeBSD the real libc.so is in >> /lib/libc.so.X. >> >> Because the proper libc.so is not found, a.out format is chosen when >> using ASM and the build fails. >> >> With patch: >> Operating system: i386-pc-freebsd8.3 >> Configuring for BSD-x86-elf >> [...] >> Build passes. >> >> >> I have 2 proposed patches which solve the problem. Only 1 is needed. >> >> 1. Use file(1) against /bin/sh for all BSD platforms. I believe this >> will be more portable long-term. It will determine the binary type, >> regardless of where libc.so is or how it is setup. Note that -L is used >> to follow symlink incase someone symlinks /bin/sh to something else. >> >> http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-bin-sh.diff >> >> 2. Or just include /lib/libc.so.* in the search path to run file(1) >> against. I prefer #1 as it is possible that /usr/lib/libc.so is >> symlinked to a libc.ld script, which cause file(1) to return 'ASCII' and >> the config falls back on a.out. >> >> http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-lib-libc.diff > > We have to remember that those lines serve several BSD flavours and > preferred choice should be least invasive, Right. The entire script is running through /bin/sh, so it is guaranteed to be there. I really have no preference on which, if either, is taken. i.e. #2. But before we > proceed could you answer couple of questions? Is it possible to run > 32-bit x86 binaries on x86_64 FreeBSD system? Yes > Compile 32-bit program? Yes > How multi-lib is handled, i.e. where are 32- and 64-bit shared libraries > reside? Well, this is unlikely to affect the decision, I'm simply using > the opportunity to learn something that can affect future decisions. Thanks. > We have 32bit compat libraries in /usr/lib32 on 64bit hosts. -- Regards, Bryan Drewery signature.asc Description: PGP signature
Re: [openssl.org #3075] [PATCH] Fix ASM support for FreeBSD 10
On 6/18/2013 4:47 AM, Andy Polyakov via RT wrote: >> For FreeBSD 10 we have changed /usr/lib/libc.so to be a text linker >> script and no longer a symlink. This breaks the config check on i386 for >> what binary format to use when building with ASM support. The current >> config check expects /usr/lib/libc.so to symlink to a /usr/lib/libc.so.X >> file to run file(1) against. For FreeBSD the real libc.so is in >> /lib/libc.so.X. >> >> Because the proper libc.so is not found, a.out format is chosen when >> using ASM and the build fails. >> >> With patch: >> Operating system: i386-pc-freebsd8.3 >> Configuring for BSD-x86-elf >> [...] >> Build passes. >> >> >> I have 2 proposed patches which solve the problem. Only 1 is needed. >> >> 1. Use file(1) against /bin/sh for all BSD platforms. I believe this >> will be more portable long-term. It will determine the binary type, >> regardless of where libc.so is or how it is setup. Note that -L is used >> to follow symlink incase someone symlinks /bin/sh to something else. >> >> http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-bin-sh.diff >> >> 2. Or just include /lib/libc.so.* in the search path to run file(1) >> against. I prefer #1 as it is possible that /usr/lib/libc.so is >> symlinked to a libc.ld script, which cause file(1) to return 'ASCII' and >> the config falls back on a.out. >> >> http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-lib-libc.diff > > We have to remember that those lines serve several BSD flavours and > preferred choice should be least invasive, Right. The entire script is running through /bin/sh, so it is guaranteed to be there. I really have no preference on which, if either, is taken. i.e. #2. But before we > proceed could you answer couple of questions? Is it possible to run > 32-bit x86 binaries on x86_64 FreeBSD system? Yes > Compile 32-bit program? Yes > How multi-lib is handled, i.e. where are 32- and 64-bit shared libraries > reside? Well, this is unlikely to affect the decision, I'm simply using > the opportunity to learn something that can affect future decisions. Thanks. > We have 32bit compat libraries in /usr/lib32 on 64bit hosts. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: [openssl.org #3072] Strange behaviour when talking to microsoft exchange
On Tue, Jun 18, 2013 at 05:25:06PM -0400, Dave Thompson wrote: > > My conclussions: > > - One of the 2 sides doesn't implement > > DES-CBC-SHA/DES-CBC3-SHA properly > > ... I think you're right and I suspect the other side because > openssl interoperates with lots of folks -- unless there's > something badly off in your build of openssl. Can you > connect with DES-CBC3-SHA to usual suspects like google? With google I get: Protocol : TLSv1.2 Cipher: DES-CBC3-SHA (Or by default) Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Both of course work as expected. > I think commandline nowadays picks up engines from openssl.cnf > even if you don't explicitly ask -- do you have any configured? There are no engines configured. > If you didn't build from source, can you try that? Enable engines? Which ones? PS: Are you unable to reproduce this? I can reproduce this with various sites including things like smtp.live.com. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: parallel make broken
On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote: > While building openssl-1.0.1e I noticed that the parallel build > is broken. yes, it's pretty much always been broken > I found this patch on the net: > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl/fi > les/openssl-1.0.1-parallel-build.patch With it applied openssl builds fine > in parallel. heh, you've found me! the referenced ticket says it's been merged, but it doesn't seem that way (at least for the latest branch). the feedback loop w/the rt tracker has been kind of bad, so i lose incentive to fix keep posting patches. the other thing you should do is to run: make -j1 depend make -jN -mike signature.asc Description: This is a digitally signed message part.
RE: [openssl.org #3072] Strange behaviour when talking to microsoft exchange
> From: owner-openssl-...@openssl.org On Behalf Of Kurt Roeckx via RT > Sent: Tuesday, 18 June, 2013 12:30 > On Tue, Jun 18, 2013 at 12:30:58AM -0400, Dave Thompson wrote: > > > > Looking at your state_debug.log (which tries 1.2) I see: > > read/write preliminary SMTP as normal > > write ClientHello: offer 1.2 > > read ServerHello: agree 1.0 DES-CBC3-SHA > > rest of handshake normal > > > > Aside: I notice your build (here and in no-1.2) doesn't offer IDEA, > > so I'll guess it was built by longtime anti-patent person. > > This is tested on Debian where it was disabled many years ago and > never re-enabled. I see no reason to enable it anymore. > Okay. A little unusual, but okay. > > Then we have: > > > 250 OK > > > 214-This server supports the following commands: > > > 214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH > TURN ETRN BDAT > > VRFY > > These appear to be leftover (in mbuf) from the preliminary phase. > > No, this is most likely a logging problem. > What happens is that I get: > 250 OK > > I send: "HELP\r\n" > > I get as reply: > 214-This server supports the following commands: > 214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH > TURN ETRN BDAT VRFY > But this appeared before the -debug display of the outgoing (1+1) messages or any incoming messages? I agree that looks like a logging problem, which worries me because then I can't be entirely certain of the other stuff in the log. > And after that the connection breaks. > > > I suggest trying the default=1.2 with -cipher RC4-MD5; if > that works > > try RC4-SHA with default=1.2 and also -no_tls1_2 and/or exact -tls1. > > Conversely try -no_tls1_2 and/or -tls1 with -cipher DES-CBC-SHA . > Oops! I meant DES-CBC3-SHA; never use any single-DES mode. (Openssl probably should have named them 3DES-CBC or even 3DES-EDE-CBC like other folks did, it makes more sense to have the encryption primitive all in one place. Oh well, too late now.) > Using "-cipher RC4-MD5" or "-cipher RC4-SHA" I get that as cipher > and have connection that stays working. > > Using "-no_tls1_2 -cipher DES-CBC-SHA" I get the broken connection > after the HELP. > So if RC4 works regardless after any handshake and DES-CBC3 fails ditto ... > My conclussions: > - One of the 2 sides doesn't implement > DES-CBC-SHA/DES-CBC3-SHA properly ... I think you're right and I suspect the other side because openssl interoperates with lots of folks -- unless there's something badly off in your build of openssl. Can you connect with DES-CBC3-SHA to usual suspects like google? I think commandline nowadays picks up engines from openssl.cnf even if you don't explicitly ask -- do you have any configured? If you didn't build from source, can you try that? > - The server seems to act weird in changing between RC4-MD5 and > DES-CBC3-SHA. > That is kinda weird, though not in itself improper. It it (correctly!) implements both, and the client offers both (and openssl s_client by default offers nearly everything) it is allowed to choose between them. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
parallel make broken
Hi! While building openssl-1.0.1e I noticed that the parallel build is broken. If I try to build openssl with make -j N where N is > 1 the build fails due to unresolved symbols. E.g: make[2]: Entering directory `/home/rw/work/vpnbox/v2/maker/_build/openssl/openssl-1.0.1e/apps' make[2]: Warnung: Kein Jobserver verfügbar: -j1 wird gesetzt. »+« zur Ursprungsregel gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIO -O3 -fomit-frame-pointer -Wall -c -o rand_win.o rand_win.c req.o: In function `genpkey_cb': req.c:(.text+0x1e): undefined reference to `EVP_PKEY_CTX_get_app_data' req.c:(.text+0x30): undefined reference to `EVP_PKEY_CTX_get_keygen_info' req.c:(.text+0x51): undefined reference to `BIO_write' req.c:(.text+0x71): undefined reference to `BIO_ctrl' req.o: In function `do_X509_sign': req.c:(.text+0xd0): undefined reference to `EVP_MD_CTX_init' req.c:(.text+0xe4): undefined reference to `EVP_MD_CTX_init' req.c:(.text+0x110): undefined reference to `EVP_DigestSignInit' req.c:(.text+0x128): undefined reference to `sk_value' make -j 1 on the other hand build perfectly fine. I found this patch on the net: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl/files/openssl-1.0.1-parallel-build.patch With it applied openssl builds fine in parallel. Is this a known issue? I'm wondering why this patch is not mainline... Thanks, //richard P.s: Please CC me, I'm not subscribed. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14/06/13 14:16, Ben Laurie wrote: On 14 June 2013 14:08, Rob Stradling wrote: Apparently the ECDHE-ECDSA bug is in SecureTransport, which is an integral component of OSX. https://developer.apple.com/library/mac/#documentation/security/Reference/secureTransportRef/Reference/reference.html seems to suggest it is a library. Ben, what else needs to happen before this patch is either committed or rejected? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Regarding SSL cert generation
Hi When I generated the cert thru openssl, It not starting with BEGIN CERTIFICATE, rather with Certificate: Data: Version: 3 (0x2) Serial Number: 4 (0x4) Signature Algorithm: sha1WithRSAEncryption This creates problem in importing the cert to my server. Anyone knows , whether the format is different or not?Anyone please explain Thanks, Ajith
Re: [openssl.org #3072] Strange behaviour when talking to microsoft exchange
On Tue, Jun 18, 2013 at 12:30:58AM -0400, Dave Thompson wrote: > > Looking at your state_debug.log (which tries 1.2) I see: > read/write preliminary SMTP as normal > write ClientHello: offer 1.2 > read ServerHello: agree 1.0 DES-CBC3-SHA > rest of handshake normal > > Aside: I notice your build (here and in no-1.2) doesn't offer IDEA, > so I'll guess it was built by longtime anti-patent person. This is tested on Debian where it was disabled many years ago and never re-enabled. I see no reason to enable it anymore. > Then we have: > > 250 OK > > 214-This server supports the following commands: > > 214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH TURN ETRN BDAT > VRFY > These appear to be leftover (in mbuf) from the preliminary phase. No, this is most likely a logging problem. What happens is that I get: 250 OK I send: "HELP\r\n" I get as reply: 214-This server supports the following commands: 214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH TURN ETRN BDAT VRFY And after that the connection breaks. > I suggest trying the default=1.2 with -cipher RC4-MD5; if that works > try RC4-SHA with default=1.2 and also -no_tls1_2 and/or exact -tls1. > Conversely try -no_tls1_2 and/or -tls1 with -cipher DES-CBC-SHA . Using "-cipher RC4-MD5" or "-cipher RC4-SHA" I get that as cipher and have connection that stays working. Using "-no_tls1_2 -cipher DES-CBC-SHA" I get the broken connection after the HELP. My conclussions: - One of the 2 sides doesn't implement DES-CBC-SHA/DES-CBC3-SHA properly - The server seems to act weird in changing between RC4-MD5 and DES-CBC3-SHA. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3075] [PATCH] Fix ASM support for FreeBSD 10
> For FreeBSD 10 we have changed /usr/lib/libc.so to be a text linker > script and no longer a symlink. This breaks the config check on i386 for > what binary format to use when building with ASM support. The current > config check expects /usr/lib/libc.so to symlink to a /usr/lib/libc.so.X > file to run file(1) against. For FreeBSD the real libc.so is in > /lib/libc.so.X. > > Because the proper libc.so is not found, a.out format is chosen when > using ASM and the build fails. > > With patch: > Operating system: i386-pc-freebsd8.3 > Configuring for BSD-x86-elf > [...] > Build passes. > > > I have 2 proposed patches which solve the problem. Only 1 is needed. > > 1. Use file(1) against /bin/sh for all BSD platforms. I believe this > will be more portable long-term. It will determine the binary type, > regardless of where libc.so is or how it is setup. Note that -L is used > to follow symlink incase someone symlinks /bin/sh to something else. > > http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-bin-sh.diff > > 2. Or just include /lib/libc.so.* in the search path to run file(1) > against. I prefer #1 as it is possible that /usr/lib/libc.so is > symlinked to a libc.ld script, which cause file(1) to return 'ASCII' and > the config falls back on a.out. > > http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-lib-libc.diff We have to remember that those lines serve several BSD flavours and preferred choice should be least invasive, i.e. #2. But before we proceed could you answer couple of questions? Is it possible to run 32-bit x86 binaries on x86_64 FreeBSD system? Compile 32-bit program? How multi-lib is handled, i.e. where are 32- and 64-bit shared libraries reside? Well, this is unlikely to affect the decision, I'm simply using the opportunity to learn something that can affect future decisions. Thanks. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: MONTMUL performance: t4 engine vs inlined t4
Misaki, >> The measurement I sent yesterday for OpenSSL (with inlined T4 >> instruction support) was not quite accurate. >> Some of the T4 specific code you committed was not enabled when we >> tested, and I realized that __sparc__ was not defined on our system. >> Thus, I changed "#if defined(__sparc__)" to "#if defined(__sparc)". >> Now, we are seeing better number with OpenSSL. >> >> signverifysign/s verify/s >> rsa 1024 bits 0.000351s 0.24s 2852.9 42311.0 >> rsa 2048 bits 0.001258s 0.47s795.1 21128.6 >> rsa 4096 bits 0.006240s 0.000395s160.3 2533.3 > > Which is virtually identical to Linux results. So one mystery solved. > I'll commit the fix at some later point. > >> which is still slower than our t4 engine for 1k and 2k bit RSA sign: >> signverifysign/s verify/s >> rsa 1024 bits 0.000237s 0.28s 4221.9 36119.8 >> rsa 2048 bits 0.000876s 0.75s 1141.7 13285.6 >> rsa 4096 bits 0.006341s 0.002139s157.7467.5 > > As mentioned the problem seems to be "multi-layer" and we are moving in > right direction. http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4ddacd9921f48013b5cd011e4b93b294c14db1c2 improves RSA sign performance by 20-30%: rsa 1024 bits 0.000256s 0.16s 3904.4 61411.9 rsa 2048 bits 0.000946s 0.29s 1056.8 34292.7 rsa 4096 bits 0.005061s 0.000340s197.6 2940.5 This is still slower than your code, but conclusion we have to draw is that it's intentional. In sense that the discrepancy is accounted to the fact that OpenSSL implements counter-measures against cache-timing attack, and takes rather conservative approach. It remains to be seen if platform-specific and faster counter-measure will be suggested at later point. Meanwhile, please double-check on Solaris. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3076] openssl 1.0.1e outdated manuals
On 18 June 2013 09:42, Matt Caswell wrote: > With regards to other manual pages it is now possible to make updates > and fixes directly on the wiki (as long as you are comfortable with > POD syntax). Periodically I will be submitting as a patch to the > project containing any updates made on the wiki. Alternatively you can > use the "Talk" page associated with each man page to raise any > specific concerns. I should have mentioned that I wrote some guidelines on submitting man page updates through the wiki here: http://wiki.openssl.org/index.php/Guidelines_for_Manual_Page_Authors Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3074] On PA-RISC, OPENSSL_cleanse() causes crash when called from outside libcrypto, patch included
Hi, and thanks for report!
> I got a strange bug report claiming that "openssl md5" was dumping core on
> old parisc hardware. Sure enough, it was generating the correct result
> but then crashing:
>
> $ openssl md5 /dev/null
> MD5(/dev/null)= d41d8cd98f00b204e9800998ecf8427e
> Segmentation fault (core dumped)
It's perplexing that it went unnoticed for this long. Is it possible
that problem was compensated for in specific linker patch-level or
something? I mean linker can generate trampoline code that does the
right thing or simply replace the instruction under specific
circumstances...
> The debugger wasn't much help, but through trial and error I narrowed it
> down to the single call to OPENSSL_cleanse() in apps/dgst.c. I then spent
> a few frustrating hours learning the minutia of how parisc assembly works.
>
> It turns out the problem is rather subtle. The implementation of
> crypto/pariscid.pl returns to its caller with this instruction:
>
> bv ($rp)
>
> That would work if it were a function statically linked into bin/openssl.
> However, when returning to a function in a different segment you must use
> the "bve" instruction ("Branch Vectored _External_") or it will crash as
> as the branch completes. By the way, "bve($rp)" is known simply as "ret"
> when disassembling.
Replacing all bv's with bve's would break 32-bit builds, because bve is
2.0 instruction. Could you verify
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=02450ec69dda7815ba1e7bd74eb30f0ae1eb3042
that replaces bv only when build targets 64-bit mode? Once it's
verified, it goes down to 1.0.x.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3076] openssl 1.0.1e outdated manuals
On 18 June 2013 08:11, Doru Georgescu via RT wrote: > openssl 1.0.1e's man 3 ecdsa is two times outdated and horribly misleading. > Since it was written the API changed and then EC_KEY was buried into the > inner headers of the library such that key->group (it should have been > eckey->group, I guess) can no longer be accessed directly like in the manual > example. When I searched openssl ecdsa on google I found stackoverflow > answers only and it took me a long time to put together the snippets of > information and understand how to use openssl ecdsa correctly, in spite of > the manual example. Only after I did that I started to google for specific > functions in the API and I finally found wiki.openssl.org, which is pretty > good. Please substitute the man ecdsa (and other unhappy manuals) in openssl > 1.0.1e with a link to wiki.openssl.org to make many openssl beginners happy. > Hi Doru I recently wrote and had accepted some manual pages on the usage of EC_KEY (only in the git master at the moment). See: http://wiki.openssl.org/index.php/Manual:EC_KEY_new(3) With regards to other manual pages it is now possible to make updates and fixes directly on the wiki (as long as you are comfortable with POD syntax). Periodically I will be submitting as a patch to the project containing any updates made on the wiki. Alternatively you can use the "Talk" page associated with each man page to raise any specific concerns. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3076] openssl 1.0.1e outdated manuals
openssl 1.0.1e's man 3 ecdsa is two times outdated and horribly misleading. Since it was written the API changed and then EC_KEY was buried into the inner headers of the library such that key->group (it should have been eckey->group, I guess) can no longer be accessed directly like in the manual example. When I searched openssl ecdsa on google I found stackoverflow answers only and it took me a long time to put together the snippets of information and understand how to use openssl ecdsa correctly, in spite of the manual example. Only after I did that I started to google for specific functions in the API and I finally found wiki.openssl.org, which is pretty good. Please substitute the man ecdsa (and other unhappy manuals) in openssl 1.0.1e with a link to wiki.openssl.org to make many openssl beginners happy. Thank you. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
