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

On 28 June 2017 at 03:41, Theodore Ts'o wrote: > On Wed, Jun 28, 2017 at 11:41:11AM +1000, Peter Waltenberg wrote: > > And FYI. On systems not backed with hardware RNG's /dev/random is > > extremely slow. 1-2 bytes/second is a DOS attack on it's own without any > > other effort

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

On 26 June 2017 at 18:10, Salz, Rich via openssl-dev < openssl-dev@openssl.org> wrote: > > Pseudorandomness of the output has been a design goal/requirement only > > in SHA-3 family. Any prior hash function’s exhibition of this property is > > coincidental. > > > > Therefore I suggest using SHA3

Re: [openssl-dev] Google OSS-Fuzz reward

I should also point out that up to $10k is available for "ideal" integration. On 14 May 2017 at 10:57, Ben Laurie <b...@links.org> wrote: > Cool. > > On 14 May 2017 at 10:49, Kurt Roeckx <k...@roeckx.be> wrote: >> Google awarded us 1000 USD for the init

Re: [openssl-dev] Google OSS-Fuzz reward

Cool. On 14 May 2017 at 10:49, Kurt Roeckx wrote: > 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,

[openssl-dev] Out-of-tree build?

If I try to do one, I get: WARNING: there are indications that another build was made in the source directory. This build may have picked up artifacts from that build, the safest course of action is to clean the source directory and redo this configuration. even though I have just done make

Re: [openssl-dev] [openssl.org #4169] openssl-1.0.2e build still recommends deprecated (unnecessary?) `make depend`, returns numerous warnings abt not finding stddef.h

BTW, there's something very suspicious about make clean; make _not_ working, when (presumably) make clean; make depend; make does work. On 14 March 2016 at 21:03, Ben Laurie <b...@links.org> wrote: > On 14 March 2016 at 20:31, Salz, Rich <rs...@akamai.com> wrote: >>> I

Re: [openssl-dev] [openssl.org #4169] openssl-1.0.2e build still recommends deprecated (unnecessary?) `make depend`, returns numerous warnings abt not finding stddef.h

On 14 March 2016 at 20:31, Salz, Rich wrote: >> In particular, how do you know there is not one important warning hiding >> among the thousands of others? > > We're talking "make depend" Is there some good reason to not fix make depend? It should also be warning free. > Not

Re: [openssl-dev] Please consider delaying the Beta-1 freeze for a week or two

On 11 March 2016 at 09:24, Jeffrey Walton wrote: >> noloader> Testing master on real hardware is showing some minor issues on a >> few >> noloader> platforms, including ARM32, ARM64, PowerPC and i686. In addition, >> noloader> there seems to be one-off issues on other

Re: [openssl-dev] MacOS defaults?

On 7 March 2016 at 09:59, Andy Polyakov wrote: > Hmm. So why do I see this on my macbook? > > $ arch > i386 Try "uname -m" >>> >>> This is not reliable. Because it must have changed recently, it used to >>> be i386 even on 64-bit systems. sysctl -n

Re: [openssl-dev] MacOS defaults?

On 6 March 2016 at 23:05, Andy Polyakov wrote: >>> Hmm. So why do I see this on my macbook? >>> >>> $ arch >>> i386 >> >> Try "uname -m" > > This is not reliable. Because it must have changed recently, it used to > be i386 even on 64-bit systems. sysctl -n hw.optional.x86_64 is

Re: [openssl-dev] MacOS defaults?

On 6 March 2016 at 22:40, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote: > >> On Mar 6, 2016, at 12:00 PM, Ben Laurie <b...@links.org> wrote: >> >> Hmm. So why do I see this on my macbook? >> >> $ arch >> i386 > > Try "uname -

Re: [openssl-dev] MacOS defaults?

the Verizon Wireless 4G LTE network. > *From: *Ben Laurie > *Sent: *Sunday, March 6, 2016 06:21 > *To: *OpenSSL development > *Reply To: *openssl-dev@openssl.org > *Subject: *[openssl-dev] MacOS defaults? > > Currently OpenSSL defaults to 32 bit in MacOS. I'm told it might b

[openssl-dev] MacOS defaults?

Currently OpenSSL defaults to 32 bit in MacOS. I'm told it might be better to default to 64 bit these days. Does anyone have any views? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] We're working on license changes

On Sat, 21 Nov 2015 at 22:39 Kurt Roeckx <k...@roeckx.be> wrote: > On Sat, Nov 21, 2015 at 10:09:51PM +0000, Ben Laurie wrote: > > On Sat, 21 Nov 2015 at 21:14 Kurt Roeckx <k...@roeckx.be> wrote: > > > > > On Sat, Nov 21, 2015 at 12:02:22PM -0800, Quanah Gibso

Re: [openssl-dev] We're working on license changes

On Sat, 21 Nov 2015 at 21:14 Kurt Roeckx wrote: > On Sat, Nov 21, 2015 at 12:02:22PM -0800, Quanah Gibson-Mount wrote: > > --On Saturday, November 21, 2015 8:24 PM +0100 Kurt Roeckx < > k...@roeckx.be> > > wrote: > > >>So the MPLv2 is compatible with the APLv2. The MPLv2 is

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

On Sat, 17 Oct 2015 at 06:35 Kurt Roeckx via RT wrote: > On Fri, Oct 16, 2015 at 09:44:22PM +, Kaduk, Ben via RT wrote: > > On 10/16/2015 04:35 PM, Kurt Roeckx via RT wrote: > > > On Fri, Oct 16, 2015 at 06:50:36PM +, Kurt Roeckx via RT wrote: > > >> On Fri, Oct 16,

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

On Sat, 17 Oct 2015 at 06:35 Kurt Roeckx via RT wrote: > On Fri, Oct 16, 2015 at 09:44:22PM +, Kaduk, Ben via RT wrote: > > On 10/16/2015 04:35 PM, Kurt Roeckx via RT wrote: > > > On Fri, Oct 16, 2015 at 06:50:36PM +, Kurt Roeckx via RT wrote: > > >> On Fri, Oct 16,

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

On Fri, 16 Oct 2015 at 01:32 Matt Caswell via RT wrote: > > > On 15/10/15 20:53, Alexander Cherepanov via RT wrote: > > On 2015-10-15 15:41, Matt Caswell via RT wrote: > >> The purpose of the sanity check is not then for security, but to guard > >> against programmer error. For

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

On Fri, 16 Oct 2015 at 01:32 Matt Caswell via RT wrote: > > > On 15/10/15 20:53, Alexander Cherepanov via RT wrote: > > On 2015-10-15 15:41, Matt Caswell via RT wrote: > >> The purpose of the sanity check is not then for security, but to guard > >> against programmer error. For

Re: [openssl-dev] Continuous Integration for OpenSSL

On Mon, 24 Aug 2015 at 19:35 Matt Caswell m...@openssl.org wrote: On 24/08/2015 10:08, Ben Laurie wrote: On Mon, 24 Aug 2015 at 03:56 Salz, Rich rs...@akamai.com mailto:rs...@akamai.com wrote: On Sat, 22 Aug 2015 at 01:56 Salz, Rich rs...@akamai.com mailto:rs

Re: [openssl-dev] Continuous Integration for OpenSSL

On Mon, 24 Aug 2015 at 03:56 Salz, Rich rs...@akamai.com wrote: On Sat, 22 Aug 2015 at 01:56 Salz, Rich rs...@akamai.com wrote: Thanks! We have several cross-compile builds running on Cisco's build farm. The more the merrier. I am sure ARM would be appreciated. Are these linked from the

Re: [openssl-dev] Continuous Integration for OpenSSL

On Mon, 24 Aug 2015 at 09:53 Alessandro Ghedini alessan...@ghedini.me wrote: On Sat, Aug 22, 2015 at 12:55:43am +, Salz, Rich wrote: Thanks! We have several cross-compile builds running on Cisco's build farm. The more the merrier. I am sure ARM would be appreciated. Does this mean

Re: [openssl-dev] Continuous Integration for OpenSSL

On Sat, 22 Aug 2015 at 01:56 Salz, Rich rs...@akamai.com wrote: Thanks! We have several cross-compile builds running on Cisco's build farm. The more the merrier. I am sure ARM would be appreciated. Are these linked from the website somewhere? ___

Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled

On Thu, 6 Aug 2015 at 14:14 David Woodhouse via RT r...@openssl.org wrote: This code does open-coded division on 64-bit quantities and thus when building with GCC on 32-bit platforms will require functions such as __umoddi3 and __udivdi3 from libgcc. In constrained environments such as

Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled

On Thu, 6 Aug 2015 at 14:14 David Woodhouse via RT r...@openssl.org wrote: This code does open-coded division on 64-bit quantities and thus when building with GCC on 32-bit platforms will require functions such as __umoddi3 and __udivdi3 from libgcc. In constrained environments such as

Re: [openssl-dev] common factors in (p-1) and (q-1)

On Sat, 1 Aug 2015 at 14:22 mancha manc...@zoho.com wrote: On Fri, Jul 31, 2015 at 06:46:22PM +, Viktor Dukhovni wrote: On Fri, Jul 31, 2015 at 11:19:39AM -0700, Bill Cox wrote: Cool observation. From running a bit of Python code, it looks like the probability that GCD(p-1, p-q)

Re: [openssl-dev] FreeBSD build broken?

On 8 June 2015 at 13:27, John Foley fol...@cisco.com wrote: Is anyone having problems building 1.0.2-stable on FreeBSD? It appears the following commit may have broken the build: https://github.com/openssl/openssl/commit/f877da9cedb95df94105d7292f8e0963175e58dc Here's the error we're

HOST_c2l warnings...

Building 1.0.2 with gcc 4.9 and no-asm, I get a lot of: ADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIOS -O3 -Wall -c sha256.c In file included from sha256.c:115:0: sha256.c: In function 'sha256_block_data_order': ../md32_common.h:248:41: warning:

1.0.2 head doesn't build...

Workaround (I wasn't sure if the functions were intended to be used somewhere, so not deleted yet): diff --git a/crypto/constant_time_test.c b/crypto/constant_time_test.c index 1b4b18d..78e7fca 100644 --- a/crypto/constant_time_test.c +++ b/crypto/constant_time_test.c @@ -195,7 +195,7 @@ static

Re: [openssl.org #2917] [PATCH] dsa: fix return code when -noout is used

On 17 August 2014 06:44, Rich Salz via RT r...@openssl.org wrote: This will be fixed in the post-1.0.2 release. Why not fix in 1.0.2? Thanks. (rsalz-monolith branch on github, akamai/openssl) -- Rich Salz, OpenSSL dev team; rs...@openssl.org

Re: Default Security Level

On 16 August 2014 19:50, Dominyk Tiller dominyktil...@gmail.com wrote: Ah! That's where my confusion lies, I'm getting myself tied up between development stable. Thanks for the clarity on that. Homebrew is currently on 1.0.1i stable. These are the ssl2 ciphers active:

Re: [openssl.org #3442] [patch] AES XTS: supporting custom iv from openssl enc command

On 11 July 2014 11:56, Andy Polyakov ap...@openssl.org wrote: Bottom line [still] is that enc is not the place to perform XTS, *unless* it's treated specially. In other words question should not be about setting IV, but about *if* XTS should be supported by enc, and if so, how exactly. It

Re: Unit Testing/statically analysing OpenSSL

On 9 July 2014 14:38, Paul Morriss paul.morr...@tokenbay.co.uk wrote: I am keen to get more involved in the development of OpenSSL, I am curious, has the code been run through a static analysis tool (such as Coverity)? Coverity do run OpenSSL through their tool. The false positive rate is

JPAKE?

Does anyone use it? We're considering removing or refactoring it... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List

*_ctrl() functions

I've been experimenting with more type correctness and less casting. Some of the big casting culprits are the various _ctrl() functions, e.g. SSL_ctrl(). Does anyone have any clue why these exist? Is there any reason to not replace them with direct function calls (other than API stability)?

Re: [openssl.org #3436] Platform strategy

On 5 July 2014 18:46, Zoltan Arpadffy z...@polarhome.com wrote: Hi, I absolutely agree, that other less popular platforms need support. Unfortunately, reading the conversation in the last few days, I got a feeling that the OpenSSL core development is not willing to support those platforms

Re: BIO_get_accept_socket weirdness

On 5 July 2014 12:37, Kurt Roeckx k...@roeckx.be wrote: But then I found some MSDN documentation that says that Windows allows others to hijack your socket when you've set SO_REUSEADDR and the results are non-deterministic. They also created an SO_EXCLUSIVEADDRUSE and I'm getting confused

Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d

On 3 July 2014 22:35, Kurt Roeckx k...@roeckx.be wrote: On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote: On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org wrote: On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote: I think cppcheck is right here in void

Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d

It'd be nice, btw, if someone would report the bug to cppcheck. On 4 July 2014 10:15, Ben Laurie b...@links.org wrote: On 3 July 2014 22:35, Kurt Roeckx k...@roeckx.be wrote: On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote: On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org

Preventing the next Heartbleed

Interesting paper by David Wheeler: http://www.dwheeler.com/essays/heartbleed.html. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org

Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d

On 4 July 2014 15:20, Toralf Förster toralf.foers...@gmx.de wrote: On 07/04/2014 11:17 AM, Ben Laurie wrote: It'd be nice, btw, if someone would report the bug to cppcheck. http://5.150.254.56:443/trac-cppcheck/ticket/5970#ticket Thanks. Thx On 4 July 2014 10:15, Ben Laurie b...@links.org

Re: [openssl.org #3277] OpenSSL s_client doc missing option

On 2 July 2014 23:17, Rich Salz via RT r...@openssl.org wrote: Fixed, added -servername to the pod file. Looks to me like you've only fixed this (and many others) in master - surely should also go to 1.0.2 at least (and probably older branches, too)? Also, we generally rebase rather than

Re: [openssl.org #3277] OpenSSL s_client doc missing option

On 3 July 2014 12:04, Salz, Rich rs...@akamai.com wrote: Looks to me like you've only fixed this (and many others) in master - surely should also go to 1.0.2 at least (and probably older branches, too)? Okay, tell me which branches. Since this is a bug, all active branches (that it applies to

Re: [openssl.org #3277] OpenSSL s_client doc missing option

: rs...@jabber.me; Twitter: RichSalz -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl- d...@openssl.org] On Behalf Of Ben Laurie Sent: Thursday, July 03, 2014 7:15 AM To: OpenSSL development Cc: Jeffrey Walton Subject: Re: [openssl.org #3277] OpenSSL

Re: OpenSSL roadmap

On 3 July 2014 14:13, Theodore Ts'o ty...@mit.edu wrote: However, in the kernel we are much more lax about who gets access to the Coverity project. Part of this is the sure and certain knowledge that the bad guys are quite willing to pay for a Coverity license, and so for us the balance of

Re: OpenSSL roadmap

On 3 July 2014 15:28, Salz, Rich rs...@akamai.com wrote: release processes at various distributions. (Given that Microsoft has weekly patch Tuesdays, if even slow moving *Microsoft* can turn around a security update in a week, what's your excuse? :-) They have a regular release train, but

Google Patch rewards updated to include refactoring

https://www.google.com/about/appsecurity/patch-rewards/ Refactorings that make it easier to reason about the security properties of the code. __ OpenSSL Project http://www.openssl.org Development

Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d

On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org wrote: On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote: I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85 and 96, or ?: The line before that: dp=d; l2c(v0,dp);---

Makedepend bug?

I've been trying to figure out why my make depend differs from other developers, and why it appears to be wrong. For example, apps/dsa.o depends, according to makedepend, on dh.o, but with the standard developer flags ($gcc_devteam_warn) it should not. AFAICS, makedepend gets passed the right

Re: Very old release, unsupported platform

On 1 July 2014 06:52, Zoltan Arpadffy z...@polarhome.com wrote: Hi, I see that Rich is doing a fantastic job by cleaning up the backlog... I absolutely agree that very old releases cannot be supported, but what about the platforms? I thought until now, that as long there are developers who

Reward for proactive security improvements

In case people haven't noticed, Google has announced a reward program for this (last year, in fact): https://www.google.com/about/appsecurity/patch-rewards/ __ OpenSSL Project

Re: Makedepend bug?

AM, Ben Laurie b...@links.org wrote: I've been trying to figure out why my make depend differs from other developers, and why it appears to be wrong. For example, apps/dsa.o depends, according to makedepend, on dh.o, but with the standard developer flags ($gcc_devteam_warn) it should

Re: Makedepend bug?

On 1 July 2014 18:34, Tim Rice t...@multitalents.net wrote: On Tue, 1 Jul 2014, Ben Laurie wrote: Aha! Well done. I suspect there's not really any reason to support makedepend anymore - should perhaps just switch to always using gcc/clang for dependencies? So now gcc/clang is required

Re: Makedepend bug?

On 1 July 2014 19:15, Salz, Rich rs...@akamai.com wrote: I was wondering why 'make depend' output was saved in the Makefiles. Because way back when (think like early X and xmkmf) that's the way things were done. So I guess adding the .d files to the repository and using include statements

[openssl.org #3241] Patch: Constify openssl tables.

As you know, constification is my vice. The stuff that works easily has been committed to master at 8892ce7. Other branches/attribution not dealt with. __ OpenSSL Project http://www.openssl.org

Re: [openssl.org #3375] Patch: Off-by-one errors in ssl_cipher_get_evp()

On 12 June 2014 23:15, Matt Caswell m...@openssl.org wrote: On 12/06/14 22:43, Otto Moerbeek wrote: On Thu, Jun 12, 2014 at 10:26:56PM +0200, Matt Caswell via RT wrote: Patch applied: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=abfb989fe0b749ad61f1aa4cdb0ea4f952fc13e0 Many

Re: Crash in openSSL 1.0.1g

You should be using 1.0.1h. Also, not familiar with MacOS X heap checking, but it looks like heap corruption, which may or may not be OpenSSL's fault. Probably hard to diagnose without a test case! On 10 June 2014 07:25, Navneet Kumar (navneeku) navne...@cisco.com wrote: Update : Crashes are

Re: [PATCH] 1.0.1h does not build nor test HEARBEAT bug on OpenVMS

On 6 June 2014 22:21, Zoltan Arpadffy z...@polarhome.com wrote: Hi, after some testing the new release I realized that 1.0.1h does not build nor run HEARBEAT bug unit test on OpenVMS. The following patch corrects the problem. Best as a pull request on github. Thanks, Z -

Re: New unbiased prime generator function fixes

You didn't update the test... On 1 June 2014 21:26, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Sun, Jun 01, 2014 at 08:14:00PM +, Viktor Dukhovni wrote: The new prime generator does not ensure that generated primes are safe modulo 2, 3, 5, 7 or 11. In particular (p-1)/2 might

Re: open ssl rsa key generation improvement idea

On 28 May 2014 00:03, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, May 27, 2014 at 09:04:20PM +0100, Ben Laurie wrote: It inspired my son, Felix, and I to think about a related idea: generate random numbers which are inherently coprime to small primes. Felix went on to implement

Re: Prime generation

On 28 May 2014 01:47, mancha manc...@zoho.com wrote: Fouque and Tibouchi [3] offer the differing view that it's preferable to minimize bias and generate primes that are almost uniform even if it is not immediately clear how such biases can help an adversary. They suggest a few algorithms that

Re: Re : Re: open ssl rsa key generation improvement idea Prime generation

incremental search This is just an idea as I didn't implement anything yet however with full optimization this could be quicker than incremental search And sorry if I'm mistaking anyhow Nico - Mail d'origine - De: Ben Laurie b...@links.org À: OpenSSL development openssl-dev@openssl.org

Re: Prime generation

On 27 May 2014 09:16, Joseph Birr-Pixton jpix...@gmail.com wrote: On 27 May 2014 08:45, Peter Waltenberg pwal...@au1.ibm.com wrote: ... I did change the RNG sources for some of the OpenSSL code in our hacked version to help with the performance problems using the wrong source causes, for

Re: open ssl rsa key generation improvement idea

Nice idea. It inspired my son, Felix, and I to think about a related idea: generate random numbers which are inherently coprime to small primes. Felix went on to implement the idea, and include benchmarks and tests. Not finished - while implementing, we noticed that the existing prime number

Re: open ssl rsa key generation improvement idea

Also, I should note that this approach is not portable. You need to operate in the same base as BIGNUM does, or account for endianness is the byte-level operations. On 26 May 2014 02:31, Russell Harkins russ...@russellharkins.info wrote: Hi SSL Team, I was looking for ways to make calculating

Fwd: Using Frankencerts for Automated Adversarial,Testing of Certificate Validation,in SSL/TLS Implementations

-- Forwarded message -- From: Martin Haufschild martin.haufsch...@uni-rostock.de Date: 23 May 2014 07:34 Subject: Using Frankencerts for Automated Adversarial,Testing of Certificate Validation,in SSL/TLS Implementations Hello, FYI

Re: test/heartbleed_test.c

On 20 May 2014 06:40, The Doctor,3328-138 Ave Edmonton AB T5Y 1M4,669-2000,473-4587 doc...@doctor.nl2k.ab.ca wrote: Found that strndup would not work. I had to add #if !HAVE_STRNDUP #include stdio.h #include string.h #include sys/types.h #include malloc.h /* Find the length of STRING,

Re: How to help OpenSSL

your.patch On 24 April 2014 10:06, Ben Laurie b...@links.org wrote: Note that this is just how to help me, not a consensus view from the whole team, though I have no doubt much of it will be helpful to the team, too. 1. Triage RT (https://rt.openssl.org/). RT has been neglected for a long

Attribution of pull requests in git

I just noticed that if I merge a pull request, then both author and committer are set to whoever made the pull request. From the POV of figuring out what went wrong, when things go wrong, that seems bad. Is there an easy way to fix that? That is, I would expect it to show me as the committer and

Re: How to help OpenSSL

On 24 April 2014 18:44, Mike Bland mbl...@acm.org wrote: On Thu, Apr 24, 2014 at 1:31 PM, Ben Laurie b...@links.org wrote: 6. Write new tests Our test suite sucks. More tests is better. Shall I send a pull request for this: https://github.com/mbland/openssl/commit

Re: How to help OpenSSL

On 25 April 2014 00:08, Matt Caswell fr...@baggins.org wrote: Ben - Is it possible for some of us to get RT users created? The above assumes we can configure RT statuses - is this possible? I think you now have RT access, right?

Re: How to help OpenSSL

On 24 April 2014 19:54, Kurt Roeckx k...@roeckx.be wrote: On Thu, Apr 24, 2014 at 06:31:34PM +0100, Ben Laurie wrote: Note that this is just how to help me, not a consensus view from the whole team, though I have no doubt much of it will be helpful to the team, too. 1. Triage RT (https

Re: Attribution of pull requests in git

On 26 April 2014 12:16, Kurt Roeckx k...@roeckx.be wrote: On Sat, Apr 26, 2014 at 11:29:39AM +0100, Ben Laurie wrote: Is there an easy way to fix that? That is, I would expect it to show me as the committer and the original author as the author. That is how it should always work, and I'm

How to help OpenSSL

Note that this is just how to help me, not a consensus view from the whole team, though I have no doubt much of it will be helpful to the team, too. 1. Triage RT (https://rt.openssl.org/). RT has been neglected for a long time. People could usefully go through it and identify: a) Tickets that

Re: [openssl.org #3203] Normalize PFS key exchange labels

On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 01/01/2014 12:48 PM, Ben Laurie wrote: Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). OK, i've rebased the series against

Re: [openssl.org #3203] Normalize PFS key exchange labels

On 20 December 2013 18:51, Stephen Henson via RT r...@openssl.org wrote: On Fri Dec 20 19:04:32 2013, d...@fifthhorseman.net wrote: I can do whatever you think is most useful, but i need a bit more guidance to be sure i'm giving you what will be most useful for you. I've pulled the update

Re: [openssl.org #3203] Normalize PFS key exchange labels

On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 01/01/2014 12:48 PM, Ben Laurie wrote: Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). OK, i've rebased the series against

Re: Avoid multiple locks in FIPS mode commit to OpenSSL_1_0_1-stable

On 11 December 2013 08:55, Tomas Mraz tm...@redhat.com wrote: On Út, 2013-12-10 at 14:45 +0100, Dr. Stephen Henson wrote: On Mon, Dec 09, 2013, geoff_l...@mcafee.com wrote: Shouldn't the code read: if (!FIPS_mode()) CRYPTO_w_[un]lock(CRYPTO_LOCK_RAND); Note the '!'

Re: Self-initialization of locking/threadid callbacks and auto-detection of features

On 22 October 2013 06:47, Nico Williams n...@cryptonector.com wrote: On Monday, October 21, 2013, Salz, Rich wrote: I like your proposal, but I'd prefer to see an already initialized error code returned. Or a flag to the (new?) init api that says ignore if already set Thanks for your

Re: bsdmake mystery

I finally got around to taking another look at this. The next weird thing is MacOS thinks it _is_ a .S file, even though there's only mention of .s in the makefile. MacOS is, of course, case-insensitive, which probably doesn't help. On 19 August 2013 15:39, Ben Laurie b...@links.org wrote

Mixing time into the pool

I just pushed 3cd8547a2018ada88a4303067a2aa15eadc17f39 to master, which adds time to the random pool. Before I cherry-pick back to earlier branches, it'd be nice if people let me know about any platform dependencies...

Re: [openssl.org #3125] [PATCH 1.0.1e] openssl/crypto/armcap.c: fix a typo in OPENSSL_rdtsc

I find these easier to deal with as pull requests... On 12 September 2013 17:14, Kyle McMartin via RT r...@openssl.org wrote: a | 1 is always true, regardless of OPENSSL_armcap_P, and mrc cp15 will fail on = v6. --- a/crypto/armcap.c +++ b/crypto/armcap.c @@ -23,7 +23,7 @@ unsigned int

Re: [openssl.org #3124] potential bug in ssl/s3_cbc.c

On 12 September 2013 17:14, Arthur Mesh via RT r...@openssl.org wrote: I am not 100% sure this is a real bug, hence first tried mailing openssl-users instead of rt@. But since there was no reply, I am sending this to rt@ 641 if (is_sslv3) 642 { snip

Re: [openssl] OpenSSL source code branch master updated. 5e3ff62c345c976cd1ffbcc5e6042f55264977f5

On 8 September 2013 13:35, Dr. Stephen Henson st...@openssl.org wrote: To enable it set the appropriate extension number (0x10 for the test server) using e.g. -DTLSEXT_TYPE_encrypt_then_mac=0x10 That's unfortunate, 16 is already allocated:

Re: [openssl] OpenSSL source code branch supplemental-data-api-2 updated. 85b2ca671513df2b21df404d3dfa76cf681e553d

FWIW, I pushed this to the openssl repo instead of my own by mistake, but I guess since it is in a branch its not that big a deal. On 5 September 2013 14:45, Ben Laurie b...@openssl.org wrote: This is an automated email from the git hooks/post-receive script. It was generated because a ref

Re: AES GCM considerations in regards to SP800-38D

On 15 August 2013 09:21, Tomas Mraz tm...@redhat.com wrote: Hello OpenSSL developers, in a review of the AES GCM code it was found that there might be some requirements that are placed by SP800-38D document missing. Especially there is no checking that the key is not used with more than

Re: bsdmake mystery

Thanks for this ... haven't had the chance to test it yet (travel) but will do shortly. On 12 August 2013 05:49, Andy Polyakov ap...@openssl.org wrote: I'm trying to figure out why bsdmake on MacOS does this using the standard Makefiles: cc -c -I. -I.. -I../include -DOPENSSL_THREADS

bsdmake mystery

I'm trying to figure out why bsdmake on MacOS does this using the standard Makefiles: cc -c -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wall -pedantic -DPEDANTIC -Wno-long-long -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Werror -DCRYPTO_MDEBUG_ALL

Fwd: [Foundations] 2013 Doc Camp CFP

Since people are always complaining about OpenSSL docs, I thought this might be of interest. -- Forwarded message -- From: adam a...@flossmanuals.net Date: 1 August 2013 08:23 Subject: [Foundations] 2013 Doc Camp CFP To: Foundations List foundati...@lists.freedesktop.org hi If

Re: [Patch] ALPN Implementation for OpenSSL

On 24 June 2013 22:00, Jeff Mendoza (MS OPEN TECH) jemen...@microsoft.com wrote: We simply cannot drop support for NPN (i.e. SPDY) just to add support for ALPN. The idea is to have the choice as a ./config option. The default will stay as NPN, as to not disrupt anyone. I don't have this

Re: parallel make broken

On 22 June 2013 23:06, Mike Frysinger vap...@gentoo.org wrote: On Saturday 22 June 2013 15:07:49 Ben Laurie wrote: On 22 June 2013 19:04, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote: On 18 June 2013 22:35, Mike Frysinger vap...@gentoo.org wrote

Re: [Patch] ALPN Implementation for OpenSSL

On 21 June 2013 02:29, Thor Lancelot Simon t...@panix.com wrote: On Thu, Jun 20, 2013 at 09:30:32PM +, Jeff Mendoza (MS OPEN TECH) wrote: Yeah, my point was that in the perfect world, you'd support both at runtime (at least on the server-side) and either ALPN or NPN could be used. I

Re: parallel make broken

On 22 June 2013 19:04, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote: On 18 June 2013 22:35, Mike Frysinger vap...@gentoo.org wrote: On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote: While building openssl-1.0.1e I noticed

Re: [Patch] ALPN Implementation for OpenSSL

On 20 June 2013 21:46, Jeff Mendoza (MS OPEN TECH) jemen...@microsoft.com wrote: -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Piotr Sikora Sent: Thursday, June 20, 2013 10:41 AM To: openssl-dev@openssl.org Subject: Re:

Apple are, apparently, dicks...

...and don't intend to fix their broken ECDSA support in Safari. It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d What do people think? __ OpenSSL

Re: Apple are, apparently, dicks...

On 14 June 2013 09:39, Rob Stradling rob.stradl...@comodo.com wrote: On 13/06/13 17:39, Ben Laurie wrote: ...and don't intend to fix their broken ECDSA support in Safari. Ben, you've got your wires a bit crossed there. The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8

Re: Apple are, apparently, dicks...

On 14 June 2013 12:25, Rob Stradling rob.stradl...@comodo.com wrote: On 14/06/13 10:20, Ben Laurie wrote: On 14 June 2013 09:39, Rob Stradling rob.stradl...@comodo.com wrote: On 13/06/13 17:39, Ben Laurie wrote: ...and don't intend to fix their broken ECDSA support in Safari. Ben

Re: Apple are, apparently, dicks...

On 14 June 2013 13:57, Rob Stradling rob.stradl...@comodo.com wrote: On 14/06/13 12:31, Ben Laurie wrote: On 14 June 2013 12:25, Rob Stradling rob.stradl...@comodo.com wrote: snip Ah, so you're criticizing Apple for not being willing to force all OSX 10.8.x users to update to 10.8.4

Re: Apple are, apparently, dicks...

On 14 June 2013 13:54, The Doctor doc...@doctor.nl2k.ab.ca wrote: On Thu, Jun 13, 2013 at 05:39:36PM +0100, Ben Laurie wrote: ...and don't intend to fix their broken ECDSA support in Safari. It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit

Re: Apple are, apparently, dicks...

On 14 June 2013 14:08, Rob Stradling rob.stradl...@comodo.com wrote: On 14/06/13 13:58, Ben Laurie wrote: On 14 June 2013 13:57, Rob Stradling rob.stradl...@comodo.com wrote: snip Safari's User-Agent string reveals the OSX version that it is running on. A few weeks ago I analyzed some

  1   2   3   4   5   6   7   >