Re: How to help OpenSSL
I see. Thank you. 2014-04-28 0:48 GMT+08:00 Dr. Stephen Henson st...@openssl.org: On Sun, Apr 27, 2014, Weibin Yao wrote: Is it accessable for read (rt.openssl.org) ? I can't access it and don't know where to register. Read access is possible through the guest account: https://www.openssl.org/support/rt.html Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Weibin Yao Developer @ Server Platform Team of Taobao __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Which of HOW TO CONTRIBUTE TO OpenSSL in README is still relevant?
On Fri, Apr 25, 2014, Jeff Trawick wrote: Note: Glance at http://wiki.openssl.org/index.php/Main_Page#Feedback_and_Contributions for some context. Anyway, about that section in README: openssl-bugs is dead, right? (instead: https://www.openssl.org/support/rt.html) It still works but just sends to rt. Patches seem to be better covered at http://wiki.openssl.org/index.php/Use_of_Git#Making_patches Yes. I guess the debug-steve64, debug-geoff comments could be covered at http://wiki.openssl.org/index.php/Contributions??? (shrug) There is also a configuration option --strict-warnings which can be used here. Patches and contributions must compile without warnings. I hope to deity; that nobody needs to notify the US government about patches anymore. Unknown. Can someone comment on this? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Which of HOW TO CONTRIBUTE TO OpenSSL in README is still relevant?
On 04/28/2014 07:31 AM, Dr. Stephen Henson wrote: ... Unknown. Can someone comment on this? With respect to U.S. export controls (EAR), open source cryptographic code contributions appearing on the publicly visible OpenSSL web site appear to fall under the TSU exception to ECCN 5D002. The necessary notification for that code to the Commerce Department was by OSF done years ago and is renewed from time to time (even though such renewal is not explicitly required). U.S. contributors do need to be *very* careful about crypto code that is exported anywhere. Note that in EAR/ITAR parlance export essentially means potentially seen by non-U.S. persons. So for instance posting such code to github would be an export, as would E-mailing to anyone overseas. When in doubt consult your own attorney, as U.S. export controls are more than a little nonsensical. TBH it's such a mess that I quit working directly on crypto code myself after unwittingly attaining the dubious and expensive distinction of becoming a registered international arms dealer (mandatory registration with the State Department DDTC per ITAR). In short, while your odds of actually being prosecuted are probably low, it's damn hard to be a U.S. citizen and lawfully work on open source cryptography. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3328] [PATCH] Support for GOST R 34.10-2012 digital signature algorithm
Дмитрий, а есть ли у вас планы по внедрению TLS, основанного на новых ГОСТах, в OpenSSL ? Сам собирался занятся этим в начале лета, после отпуска. С вашей помощью, теперь, это совсем тривиально должно получиться. Можно скооперироваться как-нибудь. Если вы, конечно, всё сами не сделаете до этого. :-)
RE: [openssl.org #3331] [PATCH] respect LDFLAGS during build
While rpaths are not needed in some contexts, they are important in others, please do not remove rpath support. Yes, such as cross-compiling or embedded systems. I think it's reasonable to make it a config option tho. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3133] AutoReply: minor make install improvement for Windows/Visual Studio in ms\nt.mak
Hi,
It unfortunately took a long time that I was able to check the problem below
again. The proposed fix is incorrect. Because the .mak file is generated by
util/mk1mf.pl, the change should be done on top of that file. Both for
openssl1.0.1e as well as for openssl1.0.1g the following diff can be applied
and adds a line to copy the pdb file to the lib directory.
Diff on openSSLDir/opensslversion/util/mk1mf.pl between original file and
changed file:
580c580,581
\$(CP) \\$(BIN_D)$o\$(E_EXE)$exep \$(INSTALLTOP)${o}bin\
---
\$(CP) \\$(BIN_D)${o}\$(E_EXE)$exep \$(INSTALLTOP)${o}bin\
\$(CP) \\$(OBJ_D)${o}lib.pdb\ \\$(INSTALLTOP)${o}lib\
I also replaced one occurrence of $o by ${o}, which means the same, but
semantically more adheres to what is already used.
The change is of minor importance, but just simplifies adoption by a Visual
Studio/Windows build (and solves warnings).
I assume that the name 'lib.pdb' is fixed, since I did not see a macro that
defines this name.
Regards,
Kees
-Original Message-
From: The default queue via RT [mailto:r...@openssl.org]
Sent: Thursday, September 26, 2013 19:08
To: Kees Dekker
Subject: [openssl.org #3133] AutoReply: minor make install improvement for
Windows/Visual Studio in ms\nt.mak
Greetings,
This message has been automatically generated in response to the
creation of a trouble ticket regarding:
minor make install improvement for Windows/Visual Studio in
ms\nt.mak,
a summary of which appears below.
There is no need to reply to this message right now. Your ticket has been
assigned an ID of [openssl.org #3133].
Please include the string:
[openssl.org #3133]
in the subject line of all future correspondence about this issue. To do so,
you may reply to this message.
Thank you,
r...@openssl.org
-
Hi,
It may be useful to add the .pdb file to the lib directory in the install
target. Windows build that adopt OpenSSL may benefit from it. When using
ssleay32.lib and/or libeay32.lib then Visual Studio may complain about missing
symbol information. That information is in the pdb file. If a pdb file is not
provided, then Visual Studio will raise the following warning:
libeay32.lib(cryptlib.obj) : warning LNK4099: PDB 'lib.pdb' was not found with
'libeay32.lib(cryptlib.obj)' or at 'xyz\lib.pdb'; linking object as if no debug
info.
Suggestion: change ms\nt.mak a little and add a line, similar to the following
diff:
474c474
---
$(CP) $(OBJ_D)\lib.pdb $(INSTALLTOP)\lib
Regards,
Kees Dekker
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Which of HOW TO CONTRIBUTE TO OpenSSL in README is still relevant?
On Mon, Apr 28, 2014 at 8:33 AM, Steve Marquess marqu...@opensslfoundation.com wrote: On 04/28/2014 07:31 AM, Dr. Stephen Henson wrote: ... Unknown. Can someone comment on this? With respect to U.S. export controls (EAR), open source cryptographic code contributions appearing on the publicly visible OpenSSL web site appear to fall under the TSU exception to ECCN 5D002. The necessary notification for that code to the Commerce Department was by OSF done years ago and is renewed from time to time (even though such renewal is not explicitly required). U.S. contributors do need to be *very* careful about crypto code that is exported anywhere. Note that in EAR/ITAR parlance export essentially means potentially seen by non-U.S. persons. So for instance posting such code to github would be an export, as would E-mailing to anyone overseas. When in doubt consult your own attorney, as U.S. export controls are more than a little nonsensical. TBH it's such a mess that I quit working directly on crypto code myself after unwittingly attaining the dubious and expensive distinction of becoming a registered international arms dealer (mandatory registration with the State Department DDTC per ITAR). In short, while your odds of actually being prosecuted are probably low, it's damn hard to be a U.S. citizen and lawfully work on open source cryptography. -Steve M. Steve M., what do you think about this vague text, probably destined for the first section of http://wiki.openssl.org/index.php/Contributions? 1. Legal considerations regarding development, import, and export of crypto Various jurisdictions around the world regulate implementations of cryptography. For example, U.S. contributors posting implementations to public fora such as GitHub or OpenSSL mailing lists could conceivably be treated as exporters of cryptography. The OpenSSL developers and staff cannot define the legal requirements of contributors to the OpenSSL crypto implementation, or even define which areas of contribution would be considered as cryptography by regulatory agencies. Individual contributors are responsible for researching potential limitations on or requirements of their contributions based on the type of contribution and the laws and regulations which are applicable to them. --/-- This is an alternative to the fairly strong statements in the README which imply that some legal evaluation is performed by committers to determine if a contribution can be accepted. (apparently no evaluation; it is on the contributor to evaluate for themselves) -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: [openssl.org #3320] Invalid large memory access in openssl due
to a bug on the client side Reply-To: In-Reply-To: 2a0efb9c05d0164e98f19bb0af3708c7120c61f...@usmbx1.msg.corp.akamai.com On Sat, Apr 26, 2014 at 01:16:08PM -0400, Salz, Rich wrote: If the API requires the same buffer and count, then perhaps the SSL structure should hold those values, and require the user to send NULL/0 in subsequent calls? Or assert(). It's a programming error that requires source changes to fix. To me this all sounds like an we end up in an inconsistent state. I'm expecting write(2) like behaviour of SSL_write(). I think it should either have returned 0 and have done nothing with the buffer or 0, but maybe != num, and that the rest of the buffer needs to be send again the next call at which point it might return the 0. But maybe that doesn't work correctly for the blocking case? The documentation mentions that you might need to call SSL_read() because of renegiotation, and I would love that the library could just handle that internally without the application having to call the correct function and then later call SSL_write() again with the same parameters. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3320] Invalid large memory access in openssl due
to a bug on the client side Reply-To: In-Reply-To: 2a0efb9c05d0164e98f19bb0af3708c7120c61f...@usmbx1.msg.corp.akamai.com On Sat, Apr 26, 2014 at 01:16:08PM -0400, Salz, Rich wrote: If the API requires the same buffer and count, then perhaps the SSL structure should hold those values, and require the user to send NULL/0 in subsequent calls? Or assert(). It's a programming error that requires source changes to fix. To me this all sounds like an we end up in an inconsistent state. I'm expecting write(2) like behaviour of SSL_write(). I think it should either have returned 0 and have done nothing with the buffer or 0, but maybe != num, and that the rest of the buffer needs to be send again the next call at which point it might return the 0. But maybe that doesn't work correctly for the blocking case? The documentation mentions that you might need to call SSL_read() because of renegiotation, and I would love that the library could just handle that internally without the application having to call the correct function and then later call SSL_write() again with the same parameters. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3320] Invalid large memory access in openssl due
On 28 Apr 2014, at 4:20 PM, Kurt Roeckx wrote: To me this all sounds like an we end up in an inconsistent state. I'm expecting write(2) like behaviour of SSL_write(). You can request write(2)-like behavior from SSL_write() by setting SSL_MODE_ENABLE_PARTIAL_WRITE with SSL_CTX_set_mode(). However, this bug is one that occurs when the write(2)-like behavior is not set. I do think it would be reasonable to sanity-check 's-s3-wnum' against 'len' in ssl3_write()/ssl2_write(), perhaps duplicating ssl3_write_pending()'s error checks so that they happen before the underflow occurs. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
