Re: [openssl-dev] [openssl-master 0/1] AFALG: Support AES GCM

On Mon, Feb 05, 2018 at 12:08:38PM +0530, Atul Gupta wrote: > The objective of this patch is to add AEAD cipher aes-gcm > to afalg. Portion of code is borrowed from e_aes.c. The AEAD > auth size is set to program the TAG length. AAD (additional > authenc data) is sent in iov along with data[in].

Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface

On Thu, Jan 18, 2018 at 05:34:05PM +0100, Patrick Steuer wrote: > > Though aead is in some sense more than a cipher mode of operation. Providing > a dedicated api would have some advantages but i see that maybe i reopen a > discussion: > > "We are also evaluating the following new features. -New

Re: [openssl-dev] Is X509_free(NULL) ok?

On Fri, Dec 22, 2017 at 09:30:19AM -0500, Ken Goldman wrote: > On 12/22/2017 9:24 AM, Salz, Rich via openssl-users wrote: > > > if (ptr!= NULL) free(ptr); > > That shouldn’t be necessary for OpenSSL. If you find places where it is, > > please open an issue. > > OK. I'll mention a few, but

Re: [openssl-dev] Is X509_free(NULL) ok?

On Fri, Dec 22, 2017 at 01:06:20PM +, Salz, Rich via openssl-dev wrote: > Our intent is that all FREE functions can handle NULL. If you find things > missing or undocumented, please open an issue on GitHub. Thanks! I think we fixed all such cases in 1.1.0, all *_free() functions should

Re: [openssl-dev] Certificate Limitation Profile

On Mon, Nov 27, 2017 at 07:56:00PM +0300, Dmitry Belyavsky wrote: > Here is the link to the draft: > https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/ I'm wondering how you think that policy will be distributed and why it needs signed. I expect that there will

Re: [openssl-dev] Systemwide configurability of OpenSSL

On Wed, Oct 25, 2017 at 05:19:23PM +0200, Tomas Mraz wrote: > > The problem is that by default the applications do not read the file and > do not apply the defaults. Even the openssl s_client/s_server does not > seem to work, but I might be doing something wrong. > > What I would like to see is

Re: [openssl-dev] how to static compile ssl engine into openssl

On Tue, Sep 26, 2017 at 07:32:06AM +0200, Richard Levitte wrote: > > You mean to have nginx use the shared OpenSSL libraries, which also > enables dynamic engines? Yes, that's the usual way to go about these > things. Do we support dynamic engines with a static build? Kurt -- openssl-dev

Re: [openssl-dev] libcrypto.pc needs to list libpthread as a dependency

On Sun, Sep 17, 2017 at 08:04:10AM +0100, Matt Caswell wrote: > On Sat, 16 Sep 2017 22:26:10 +0100 > Howard Chu via openssl-dev wrote: > > > In OpenSSL 1.1 on Linux (at least) libcrypto now has a dependency on > > libpthread but this is not reflected in the pkgconfig

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On Tue, Aug 29, 2017 at 08:38:09PM +, Blumenthal, Uri - 0553 - MITLL wrote: > > If, based on its value, OpenSSL may decide that it now got “enough” entropy > > and doesn’t need to > > pull more from other sources before serving randomness to requestors – then > > it is harmful. > >

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On Tue, Aug 29, 2017 at 06:50:37PM +, Blumenthal, Uri - 0553 - MITLL wrote: > On 8/29/17, 12:45, "openssl-dev on behalf of Salz, Rich via openssl-dev" > wrote: > > ➢ An other problem with the current implemenation is

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On Tue, Aug 29, 2017 at 01:05:21PM +, Dr. Matthias St. Pierre wrote: > > Currently it's only possible to customize the callbacks but not the > deterministic algorithm. IMHO this is sufficient for the needs of a standard > OpenSSL user who only wants control over the entropy source. A true

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On Tue, Aug 29, 2017 at 11:31:03AM +, Dr. Matthias St. Pierre wrote: > > -Ursprüngliche Nachricht- > > Von: openssl-dev [mailto:openssl-dev-boun...@openssl.org] Im Auftrag von > > Matt Caswell > > Gesendet: Dienstag, 29. August 2017 12:17 > > An: openssl-dev@openssl.org > > Betreff:

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

I actually plan to work on most of not all the things you mention. This will probably result in the API changing before it's made public. I'm probably slow, so please be patient. Kurt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Thu, Aug 24, 2017 at 05:47:55PM +, Salz, Rich via openssl-dev wrote: > > >This is why I want to add things like that by default in the > >additional data. > > On reseed or generate? Mostly on generate, but I see little point in not doing it on reseed. Kurt -- openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Thu, Aug 24, 2017 at 05:32:15PM +, Salz, Rich via openssl-dev wrote: > > >An idea that I had was to default to reseed on fork if we know we > >have a working syscall. ... to get entropy > > Or /dev device too? The point is that you can't be sure that /dev is still going to be

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Thu, Aug 24, 2017 at 08:07:54AM +1000, Peter Waltenberg wrote: > The bad case I'm aware of is the fork() one as it's critical that the RNG > state diverge on fork(). Without that you can get some very nasty > behaviour in things like TLS servers. Some of which have a thread pool + > fork()

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Wed, Aug 23, 2017 at 05:12:56PM -0400, Paul Kehrer wrote: > On August 19, 2017 at 2:48:19 AM, Salz, Rich via openssl-dev ( > openssl-dev@openssl.org) wrote: > > > I think the safest thing is for us to not change the default. Programs that > know they are going to fork can do the right/safe

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Mon, Aug 21, 2017 at 06:12:16PM +0200, Kurt Roeckx wrote: > So I guess you want an interface that can both add things to the > "entropy" pool, and to the "additional data" pool? It shouldn't > be that hard, I'll try to come up with some proposal soon. I was thin

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Mon, Aug 21, 2017 at 03:56:29PM +, Blumenthal, Uri - 0553 - MITLL wrote: > >> P.S. I wonder if it's feasible to have a configuration parameter that > >> would allow me to tell the TLS code to invoke RAND_add_ex() before > >> generating session keys? > > > > Either you accept that

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Fri, Aug 18, 2017 at 09:22:48AM +0200, Tomas Mraz wrote: > On Thu, 2017-08-17 at 22:11 +0200, Kurt Roeckx wrote: > > On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote: > > > On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev > > > wrote: >

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote: > On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev wrote: > > I understand the concern.  The issue I am wrestling with is strict > > compatibility with the existing code.  Does anyone really *want* the > > RNG’s to not reseed

Re: [openssl-dev] Windows system cert store

On Sun, Jul 09, 2017 at 09:15:32AM +0200, Richard Levitte wrote: > In message >

Re: [openssl-dev] Compiler requirements

On Tue, Jul 04, 2017 at 05:42:42PM +0200, Richard Levitte wrote: > In message > <2f548b68de1c47dfaa6a3b0107080...@usma1ex-dag1mb1.msg.corp.akamai.com> on > Tue, 4 Jul 2017 15:05:06 +, "Salz, Rich via openssl-dev" > said: > > openssl-dev> > beldmit> What is the

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Wed, Jun 28, 2017 at 12:01:29PM -0500, Benjamin Kaduk via openssl-dev wrote: > > I'm not sure what you mean by "draining the kernel's entropy pools". > That is, if you are adhering to the belief that taking random bits out > of a generator removes entropy from it that must be replenished,

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Tue, Jun 27, 2017 at 11:56:04AM -0700, John Denker via openssl-dev wrote: > On 06/27/2017 02:28 AM, Matt Caswell wrote: > >> > >> I also agree that, by default, using the OS provided source makes a lot > >> of sense. > > Reality is more complicated than that; see below. > > On 06/27/2017

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Tue, Jun 27, 2017 at 02:42:52PM +0200, Matthias St. Pierre wrote: > > So I have two questions: > > - Do you intend to continue supporting RAND_set_rand_method() or will there > only be one 'perfect' random generator and no choice anymore? I think we should have a default one, but an option

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Mon, Jun 26, 2017 at 09:39:47PM -0700, John Denker via openssl-dev wrote: > > I'm not mentioning any names, but some people are *unduly* > worried about recovery following compromise of the PRNG > internal state, so they constantly re-seed the PRNG, to > the point where it becomes a

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Mon, Jun 26, 2017 at 01:18:58PM -0700, John Denker via openssl-dev wrote: > On 06/26/2017 12:41 PM, Salz, Rich wrote: > > > Suppose the chip supports RDRAND but the runtime doesn't have > > getrandom or /dev/random? > > That's an easy one! > > Check the feature-test bit and then call RDRAND

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Mon, Jun 26, 2017 at 11:29:19AM -0700, John Denker via openssl-dev wrote: > What's your threat model? I know that sounds like a cliché, > but it's actually important. > > In particular, in my world the #1 threat against any PRNG > is improper seeding. > -- If you trust the ambient OS to

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Mon, Jun 26, 2017 at 04:17:41PM +, Salz, Rich via openssl-dev wrote: > > > > Is it worth reposting my thoughts with your suggested wording changes? > > > > OK. Off-list or on. This stuff is important. > > Reposting. > > My thoughts. > > Randomness should be whitened. Anything feed

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Mon, Jun 26, 2017 at 08:58:21AM -0700, John Denker via openssl-dev wrote: > In the context of: > > >> If you mean for something to be hard for the attacker to guess, > >> the word "adamance" can be used. > > On 06/26/2017 08:32 AM, Salz, Rich wrote: > > > All my attempts to look up a

Re: [openssl-dev] discussion venue policy

On Mon, Jun 26, 2017 at 07:30:52AM -0700, John Denker via openssl-dev wrote: > On 06/26/2017 05:49 AM, Salz, Rich wrote: > > > Please take a look at GitHub pull request > > Is the RNG topic going to be discussed on github, or on openssl-dev? > What about other topics? > > Having some topics one

Re: [openssl-dev] [RFC 0/4] Kernel TLS socket API

On Thu, Jun 08, 2017 at 10:43:15AM +0200, Hannes Frederic Sowa wrote: > > we have discussed this in the past on net...@vger.kernel.org but I just > want to point out here again, that renewing the symmetric crypto keys is > not supported in the kernel part (for the time being). > > So in case the

Re: [openssl-dev] [RFC 0/4] Kernel TLS socket API

On Wed, Jun 07, 2017 at 03:35:45PM +0300, Boris Pismenny wrote: > Hello all, > > I would like to introduce you to the new kernel API for TLS transmit-side > data-path, and open a discussion regarding its support in OpenSSL. So my understanding is that there are really 2 parts in the kernel that

[openssl-dev] Google OSS-Fuzz reward

Google awarded us 1000 USD for the initial integration with OSS-Fuzz. See https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html I have asked Google to donate it to European Digital Rights (EDRi, https://edri.org/). Google doubles the amount if you donate it to a

Re: [openssl-dev] OpenSSL Project Bylaws

On Tue, Feb 14, 2017 at 09:30:31AM +, Matt Caswell wrote: > I am pleased to be able to announce the publication of our new Project > Bylaws. I have written a short blog post about what we are hoping to > achieve and some of the thinking that went into these here: > >

Re: [openssl-dev] ETA: TLS 1.3 release

On Wed, Apr 19, 2017 at 02:57:13PM +0200, Stefan Eissing wrote: > > > Am 19.04.2017 um 14:14 schrieb Salz, Rich via openssl-dev > > : > > > >> Out of curiosity, what's the ETA for TLS 1.3? > >> [1] mentions April 5 as the release date (which was two weeks ago). > >> >

Re: [openssl-dev] License change agreement

On Fri, Mar 24, 2017 at 12:22:14PM -0700, James Bottomley wrote: > > This is my understanding as well. From the GPL side, for both dynamic > and static linking of openssl to GPLv2 code, the section 3 system > exception applies. Not everybody agrees that it applies. Kurt -- openssl-dev

Re: [openssl-dev] License change agreement

On Fri, Mar 24, 2017 at 08:02:25PM +0100, Florian Weimer wrote: > * Quanah Gibson-Mount: > > > Zero people that I know of are saying to switch to the GPL. What is > > being pointed out is that the incompatibility with the current > > OpenSSL license with the GPLv2 has been a major problem. > >

Re: [openssl-dev] License change agreement

On Fri, Mar 24, 2017 at 11:43:17AM -0700, Quanah Gibson-Mount wrote: > --On Friday, March 24, 2017 7:47 PM +0100 Kurt Roeckx <k...@roeckx.be> > wrote: > > > On Fri, Mar 24, 2017 at 10:18:40AM -0700, Quanah Gibson-Mount wrote: > > > --On Friday, March 24, 2017

Re: [openssl-dev] License change agreement

On Fri, Mar 24, 2017 at 10:18:40AM -0700, Quanah Gibson-Mount wrote: > --On Friday, March 24, 2017 6:12 PM + "Salz, Rich" > wrote: > > > > Thanks Rich, that's a more useful starting point. Has dual licensing > > > been considered? Both in 2015 and now, the lack of GPLv2

Re: [openssl-dev] License change agreement

On Fri, Mar 24, 2017 at 08:36:02AM +0100, Otto Moerbeek wrote: > On Fri, Mar 24, 2017 at 08:21:49AM +0100, Marcus Meissner wrote: > > > On Fri, Mar 24, 2017 at 07:48:58AM +0100, Otto Moerbeek wrote: > > > On Fri, Mar 24, 2017 at 04:11:48AM +, Blumenthal, Uri - 0553 - MITLL > > > wrote: > > >

Re: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release

On Mon, Mar 20, 2017 at 10:41:12PM +, Jason Vas Dias wrote: > Hi - much thanks for many years of great OpenSSL releases, > but this 1.1.0 branch, IMHO, should not be put above the 1.0.2k > release on the website as the 'latest / best OpenSSL release' - this just > wastes everybody's time . No

Re: [openssl-dev] Travis [extended tests] tag

On Sun, Feb 26, 2017 at 11:23:42PM +0100, Andy Polyakov wrote: > In order to improve CI turn-around times Travis config in master branch > was tweaked to minimize the time it takes to process pull requests. This > is done by "short-circuiting" most expensive tests: sanitizers, > coverage,

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

On Sun, Feb 26, 2017 at 09:26:06AM +0300, Andrey Ponomarenko wrote: > 31.01.2017, 10:21, "Nikos Mavrogiannopoulos": > > On Fri, 2017-01-27 at 10:54 -0600, Benjamin Kaduk via openssl-dev > > wrote: > >>  [moving from github to -dev] > >> > >>  On 01/27/2017 07:36 AM, mattcaswell wrote: > >>  >

[openssl-dev] MD5 speed

I had some surprising results of the speed command when testing the md5 speed on the 1.1.0-stable branch (for both a shared and a static build): openssl speed md5 returns: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes md5 115869.46k

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

On Mon, Jan 02, 2017 at 08:50:24AM -0800, James Bottomley wrote: > On Mon, 2017-01-02 at 17:38 +0100, Kurt Roeckx wrote: > > On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote: > > > This patch adds RSA signing for TPM2 keys. There's a limitation to > > >

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote: > This patch adds RSA signing for TPM2 keys. There's a limitation to the > way TPM2 does signing: it must recognise the OID for the signature. > That fails for the MD5-SHA1 signatures of the TLS/SSL certificate > verification

Re: [openssl-dev] Backporting opaque struct getter/setter functions

On Thu, Nov 03, 2016 at 03:11:10PM -0500, Benjamin Kaduk wrote: > To revitalize an old thread (quoted below but summarized here), some > applications may desire source-code compatibility between the 1.0.2 API > and the 1.1.0 API. It seems like the sense of the team is that such > accessor

Re: [openssl-dev] openssl enc changed behaviour between 1.1.0 and earlear

On Fri, Nov 04, 2016 at 09:59:33PM +0100, Sebastian Andrzej Siewior wrote: > On 2016-11-03 22:12:44 [+0100], Richard Levitte wrote: > > > > That would be quite a job. The correctness of the key can't be > > discovered before the last encrypted block, where the decrypted > > padding will either

Re: [openssl-dev] After building 1.0.2h , ldd output shows current version as 1.0.0. How to CHange this , Why is this so ?

On Thu, Nov 03, 2016 at 01:53:56PM +0100, Richard Levitte wrote: > Hi, > > I'm curious. Why exactly do you want to change the shared library > version? I had to change the soname in Debian (because I dropped all SSLv2 and SSLv3 symbols) and changed it to 1.0.2. Kurt -- openssl-dev mailing

Re: [openssl-dev] OpenSSL F2F

On Tue, Oct 04, 2016 at 01:14:36PM +0100, David Woodhouse wrote: > > I would dearly have loved to make it, because I'd like to get some more > detailed consensus on adding PKCS#11 support. > > In the past we've provisionally agreed on "let's do it after 1.1"... so > now we should be looking at a

[openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse

Hi, Please read: http://www.metzdowd.com/pipermail/cryptography/2016-September/030151.html We use the same construct for our OPENSSL_cleanse, but I think we also have assmebler versions. Kurt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4684 Please log in as guest with

Re: [openssl-dev] [openssl.org #4256] CA.pl usage() does not mention -signcert

On Tue, Jan 19, 2016 at 07:25:04PM +, Kaduk, Ben via RT wrote: > Part of the patch submitted to RT #844 includes a patch to the usage > message of CA.pl. Although the functionality itself of CA.pl was > rewritten for 1.1 (so that #844 was closed), the usage message remains > incomplete, and

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

On Thu, Aug 18, 2016 at 04:24:56PM +0200, Andy Polyakov wrote: > >> I think you are assuming that ret is in the range [0, 2P), so that if > >> you subtract P, the result would be in the range [0, P). That is the > >> case in normal Montgomery multiplication, where the inputs are in the > >> range

Re: [openssl-dev] weird linker warnings on solaris 11

On Sat, Aug 13, 2016 at 08:27:30PM -0700, Erik Forsberg wrote: > > just updated to developer studio 12.5 on Solaris 11.3 > I see lot of warnings when linking OpenSSL 1.1 > looking like these > > link_app.solaris-shared > LD_LIBRARY_PATH=.: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG

Re: [openssl-dev] DRBG entropy

On Thu, Jul 28, 2016 at 09:08:32AM -0700, John Denker wrote: > > That means the chip design is broken in ways that the manufacturer > does not understand. The mfgr data indicates it "should" be much > better than that: > http://www.fdk.com/cyber-e/pdf/HM-RAE103.pdf Reading that, you don't

Re: [openssl-dev] DRBG entropy

On Thu, Jul 28, 2016 at 03:40:38PM -0700, Paul Dale wrote: > I probably should have mentioned this in my earlier message, but the > exponential example is valid for the NSIT SP800-90B non-IID tests too: > 5.74889 bits per byte of assessed entropy. Again about as good a result as > the tests

Re: [openssl-dev] DRBG entropy

On Wed, Jul 27, 2016 at 05:32:49PM -0700, Paul Dale wrote: > John's spot on the mark here. Testing gives a maximum entropy not a minimum. > While a maximum is certainly useful, it isn't what you really need to > guarantee your seeding. Fom what I've read, some of the non-IID tests actually

Re: [openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange messages in RSA key exchange

On Fri, Jul 22, 2016 at 10:16:16PM +, David Benjamin via RT wrote: > On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT wrote: > > > On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote: > > > On Fri Jul 22 14:56:11 2016, hka...@redhat.com wrote: > > > > the

Re: [openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange messages in RSA key exchange

On Fri, Jul 22, 2016 at 10:16:16PM +, David Benjamin via RT wrote: > On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT wrote: > > > On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote: > > > On Fri Jul 22 14:56:11 2016, hka...@redhat.com wrote: > > > > the

Re: [openssl-dev] [Pkg-openssl-devel] Bug#829272: Fwd: [openssl.org #4602] Missing accessors

On Mon, Jul 11, 2016 at 02:53:05PM +0200, Mischa Salle wrote: > Hi Richard, Mattias, others, > > I agree with you that it would be nice if OpenSSL could figure out > itself whether a cert needs to be treated as a proxy, but currently that > doesn't work reliably as far as I know. > The flag is

Re: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures

On Mon, Jul 11, 2016 at 05:48:06PM +, Salz, Rich via RT wrote: > Previously we've changed return-types from void to int. If there's still > time, that seems like the thing to do here. I've pushed a branched on github that at least does some of the things. See github #1330. Kurt --

Re: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures

On Mon, Jul 11, 2016 at 05:48:06PM +, Salz, Rich via RT wrote: > Previously we've changed return-types from void to int. If there's still > time, that seems like the thing to do here. I've pushed a branched on github that at least does some of the things. See github #1330. Kurt --

Re: [openssl-dev] [openssl.org #4591] asynctest: double free or corruption on hppa

On Tue, Jul 19, 2016 at 02:12:41PM +, Matt Caswell via RT wrote: > > Is this still an issue? And if so are you able to provide a backtrace? This might be a combination of kernel, glibc and gcc bugs, some of which might have been fixed. In any case, I don't think it's an openssl problem.

Re: [openssl-dev] [openssl.org #4591] asynctest: double free or corruption on hppa

On Tue, Jul 19, 2016 at 02:12:41PM +, Matt Caswell via RT wrote: > > Is this still an issue? And if so are you able to provide a backtrace? This might be a combination of kernel, glibc and gcc bugs, some of which might have been fixed. In any case, I don't think it's an openssl problem.

[openssl-dev] [openssl.org #4614] pthread_once and malloc failures

Hi, When trying to check what happens if we simulate malloc() returning NULL I'm running into a problem that I'm not sure how to deal with. We have CRYPTO_THREAD_run_once(), which takes an init() function that returns void, so it can't return failures. At least the pthread_once() function also

Re: [openssl-dev] MGF1-OAEP with SHA2

On Sat, Jul 09, 2016 at 08:42:39PM +0200, c.hol...@ades.at wrote: > Hi! > > I tried with Openssl 1.0.1t from current Debian testing. > But I get > undefined symbol: EVP_PKEY_CTX_set_rsa_oaep_md 1.0.1t is in stable, not testing. 1.0.1 doesn't have that function, 1.0.2 does. Kurt --

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

On Fri, Jul 08, 2016 at 05:43:21PM +0100, David Woodhouse wrote: > > This broke the OpenConnect VPN client, which now fails thus: > > DTLS handshake failed: 1 > 67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers > available:ssl/statem/statem_clnt.c:927: > > I tried the

Re: [openssl-dev] [openssl.org #4602] Missing accessors

On Thu, Jul 07, 2016 at 09:40:24PM +, Richard Levitte via RT wrote: > On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote: > > /* Add to include/openssl/x509v3.h */ > > > > void X509_set_extension_flags(X509 *x, uint32_t ex_flags); > > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);

Re: [openssl-dev] [openssl.org #4602] Missing accessors

On Thu, Jul 07, 2016 at 09:40:24PM +, Richard Levitte via RT wrote: > On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote: > > /* Add to include/openssl/x509v3.h */ > > > > void X509_set_extension_flags(X509 *x, uint32_t ex_flags); > > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);

[openssl-dev] [openssl.org #4605] OCSP accessors

In https://bugs.debian.org/828254, for the software "bro" I got a request for accessors to: - For OCSP_RESPID *rid: - rid->type - rid->value.byKey->length - rid->value.byKey->data - For OCSP_BASICRESP *basic: - basic->certs - basic->tbsResponseData->responderId Kurt -- Ticket

[openssl-dev] [openssl.org #4603] HMAC_Init_ex incompatible change (possibly doc bug)

Hi, I received the following bug: https://bugs.debian.org/829108 the HMAC manpage states: HMAC_Init_ex() initializes or reuses a HMAC_CTX structure to use the function evp_md and key key. Either can be NULL, in which case the existing one will be reused. However, the current code does

[openssl-dev] [openssl.org #4602] Missing accessors

Hi, I received the following bug in debian: https://bugs.debian.org/829272 I got a lot of bugs filed about packages FTBFS with openssl 1.1.0. I started to look at some of them, and many of them are due too structures having been made opaque. In many cases accessors already exists, but

Re: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible

On Mon, Jun 27, 2016 at 08:50:43PM +, Thomas Waldmann via RT wrote: > I didn't ask where to get the missing code from, I asked whether you > maybe want to make life simpler for people by adding this to 1.0.x > rather than having a thousand software developers copy and pasting it > into their

[openssl-dev] [openssl.org #4591] asynctest: double free or corruption on hppa

Hi, My last upload of openssl to experimental show this on hppa: *** Error in `./asynctest': double free or corruption (out): 0x007307d8 *** ../util/shlib_wrap.sh ./asynctest => 134 # Failed test 'running asynctest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 77. # Looks like you failed

Re: [openssl-dev] [openssl.org #4551] TCP re-transmissions are seen for every transfer with the Openssl version OpenSSL 1.0.2g

On Tue, May 31, 2016 at 04:21:13PM +, ajai.mat...@wipro.com via RT wrote: > Hi, > We are facing an issue from the OpenSSL 1.0.2g ,after upgraded from OpenSSL > 1.0.0s . [Linux version 2.6.24] > When a https file transfer started with a Windows 7 application, we notice > many TCP

Re: [openssl-dev] [openssl.org #4550] hppa assembler problem

On Mon, May 30, 2016 at 08:37:56PM +, Andy Polyakov via RT wrote: > > I'm getting assembler errors on hppa that look like: > > crypto/aes/aes-parisc.s: Assembler messages: > > crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa' > > crypto/aes/aes-parisc.s:7: Error: Unknown opcode:

Re: [openssl-dev] [openssl.org #4550] hppa assembler problem

On Mon, May 30, 2016 at 08:37:56PM +, Andy Polyakov via RT wrote: > > I'm getting assembler errors on hppa that look like: > > crypto/aes/aes-parisc.s: Assembler messages: > > crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa' > > crypto/aes/aes-parisc.s:7: Error: Unknown opcode:

[openssl-dev] [openssl.org #4550] hppa assembler problem

Hi, I'm getting assembler errors on hppa that look like: crypto/aes/aes-parisc.s: Assembler messages: crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa' crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt' crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC

[openssl-dev] [openssl.org #4549] powerpc test problem: missing symbols

Hi, I'm seeing this on powerpc: ../test/recipes/01-test_ordinals.t . ok # Failed test 'check that there are no missing symbols in libcrypto.so' # at ../test/recipes/01-test_symbol_presence.t line 112. # Looks like you failed 1 test of 4. ../test/recipes/01-test_symbol_presence.t ..

[openssl-dev] [openssl.org #4548] s390x build problem

Hi, I'm getting: crypto/chacha/chacha-s390x.S: Assembler messages: crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije' A full build log is available on: https://buildd.debian.org/status/fetch.php?pkg=openssl=s390x=1.1.0~pre5-1=1464594754 Kurt -- Ticket here:

Re: [openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

On Sat, Apr 30, 2016 at 08:59:46PM +, Matt Caswell via RT wrote: > > This is not a bug in OpenSSL. The problem here is that the server is behaving > incorrectly when receiving large ClientHello messages. The ClientHello is the > first message that is sent from the client to the server. If a

[openssl-dev] Getting raw ASN1 data from X509 certificate

Hi, I'm working on a tool that checks various things related to X509 certificates. I want to check that the encoding is actually correct DER. With things like ASN1_TIME is seems easy to get to the raw data, it just seems to contain it. But when I try it with an ASN1_INTEGER it doesn't seem to

Re: [openssl-dev] [openssl.org #4392] [PATCH] Resolve DTLS cookie and version before session resumption.

On Mon, Mar 07, 2016 at 10:03:20PM +, David Benjamin via RT wrote: > Session resumption involves a version check, so version negotiation must > happen first. Currently, the DTLS implementation cannot do session > resumption in DTLS 1.0 because the ssl_version check always checks against > 1.2.

Re: [openssl-dev] OS X 10.8, x86_64: 01-test_abort.t... sh: line 1: 71522 Abort trap: 6

On Sat, Mar 19, 2016 at 07:41:28PM -0400, Jeffrey Walton wrote: > On Sat, Mar 19, 2016 at 7:31 PM, Richard Levitte wrote: > > In message on Sat, 19 > > Mar 2016 23:08:17 +, "noloa...@gmail.com via RT"

Re: [openssl-dev] [openssl.org #4445] Configure does not honor enable-afalgeng

On Fri, Mar 18, 2016 at 01:18:04PM +, Matt Caswell wrote: > > > On 18/03/16 12:52, noloa...@gmail.com via RT wrote: > > I've configured with: > > > > ./config enable-afalgeng > > > > When I run the self tests, I see: > > > > ../test/recipes/30-test_afalg.t ... skipped:

Re: [openssl-dev] [openssl.org #4424] openssl 1.0.2.g and Indy-Procjet

On Sun, Mar 13, 2016 at 02:09:34PM +, Olaf Kirfel via RT wrote: > Hallo > I am using Embarcadero/Borland C++-Builder for my personal interest and > I have the problem, that after the update to openssl 1.0.2g the > indy-components are not working. > They are delivering an error message like

Re: [openssl-dev] [openssl.org #4422] OS X 32-bit PowerPC: blake2b.c:27: warning: integer constant is too large for 'unsigned long' type

On Sun, Mar 13, 2016 at 11:27:23AM +, noloa...@gmail.com via RT wrote: > >> static const uint64_t blake2b_IV[8] = > >> { > >> 0x6a09e667f3bcc908U, 0xbb67ae8584caa73bU, > >> 0x3c6ef372fe94f82bU, 0xa54ff53a5f1d36f1U, > >> 0x510e527fade682d1U, 0x9b05688c2b3e6c1fU, > >>

Re: [openssl-dev] [openssl.org #4422] OS X 32-bit PowerPC: blake2b.c:27: warning: integer constant is too large for 'unsigned long' type

On Sun, Mar 13, 2016 at 07:15:52AM -0400, Jeffrey Walton wrote: > On Sun, Mar 13, 2016 at 6:57 AM, Kurt Roeckx via RT <r...@openssl.org> wrote: > > On Sun, Mar 13, 2016 at 10:30:54AM +, noloa...@gmail.com via RT wrote: > >> crypto/blake2/blake2b.c:27: warning: integ

Re: [openssl-dev] [openssl.org #4422] OS X 32-bit PowerPC: blake2b.c:27: warning: integer constant is too large for 'unsigned long' type

On Sun, Mar 13, 2016 at 07:15:52AM -0400, Jeffrey Walton wrote: > On Sun, Mar 13, 2016 at 6:57 AM, Kurt Roeckx via RT <r...@openssl.org> wrote: > > On Sun, Mar 13, 2016 at 10:30:54AM +, noloa...@gmail.com via RT wrote: > >> crypto/blake2/blake2b.c:27: warning: integ

Re: [openssl-dev] [openssl.org #4422] OS X 32-bit PowerPC: blake2b.c:27: warning: integer constant is too large for 'unsigned long' type

On Sun, Mar 13, 2016 at 10:30:54AM +, noloa...@gmail.com via RT wrote: > crypto/blake2/blake2b.c:27: warning: integer constant is too large for > 'unsigned long' type That's a uint64_t. Why do you have an "unsigned long" as 64 bit uint64_t? Kurt -- Ticket here:

Re: [openssl-dev] [openssl.org #4411] VIA C7-D processor: Hang in 30-test_afalg.t

On Sun, Mar 13, 2016 at 06:29:14AM +, noloa...@gmail.com via RT wrote: > >> It looks like the hang is still present as of 603358d. > >> > >> When the following runs: > >> > >> ../test/recipes/30-test_afalg.t > >> > >> What is actually running? How can I get it under a debugger? > > > > > >

Re: [openssl-dev] [openssl.org #4355] OpenSSL 1.0.2 branch fails to build with MSVC

On Sun, Feb 28, 2016 at 02:33:34PM +, Simon Richter via RT wrote: > Hi, > > I just got this from our Jenkins instance that follows OpenSSL 1.0.2: That should have been fixed some time ago, but it seems your mail only got here today. Kurt -- Ticket here:

Re: [openssl-dev] [openssl.org #4369] OS X 10.5, 32-bit PPC, and "passing argument 2 of 'cmov' discards qualifiers from pointer target type"

On Wed, Mar 02, 2016 at 04:16:37PM +, noloa...@gmail.com via RT wrote: > curve25519.c: In function 'table_select': > curve25519.c:3323: warning: passing argument 2 of 'cmov' discards That should be fixed shortly. Kurt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4369

Re: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity

On Sun, Feb 28, 2016 at 12:17:41PM -0500, Jeffrey Walton wrote: > On Sun, Feb 28, 2016 at 12:18 AM, Viktor Dukhovni > wrote: > > > >> On Feb 27, 2016, at 7:42 PM, Jeffrey Walton wrote: > >> > >> Please ensure this is documented somewhere. I'm

Re: [openssl-dev] openssl-1.0.2-stable-SNAP-20160228

On Sun, Feb 28, 2016 at 06:20:42AM -0700, The Doctor wrote: > This cropped up this morning in That was fixed an hour ago. Kurt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4352] Failed test 'Duplicate ClientHello extension' when testing under Clang undefined behavior sanitizer

On Sat, Feb 27, 2016 at 01:58:26AM +, noloa...@gmail.com via RT wrote: > Platform is Linux, x86_64. The failure occurs under Clang with the > sanitizer. GCC is fine. > > I'm guessing the error output from the Undefined Behavior sanitizer is > causing the test to be interpreted as a fail. It

Re: [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

I can only find 1 place in the server that generates an SSL_R_BAD_SIGNATURE and that's in ssl3_get_cert_verify, in the case of signature algorithms are used, which is new in TLS 1.2. I don't see anything obviously wrong, and as far as I know the test suite also tests client authentication. Kurt

Re: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity

On Fri, Feb 26, 2016 at 05:34:14PM +, Viktor Dukhovni wrote: > On Fri, Feb 26, 2016 at 05:29:26PM +, Salz, Rich wrote: > > > As just about the only team member who trolls through RT and closes things > > with any quantity, I am not sure that I agree that fixing a bug requires > >

  1   2   3   4   5   6   >