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 required.
>
> Plea
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 i
I should also point out that up to $10k is available for "ideal" integration.
On 14 May 2017 at 10:57, Ben Laurie wrote:
> Cool.
>
> On 14 May 2017 at 10:49, Kurt Roeckx wrote:
>> Google awarded us 1000 USD for the initial integration with
>> OSS-Fuzz. See
>&
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,
> https://edri.or
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 clea
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 wrote:
> On 14 March 2016 at 20:31, Salz, Rich wrote:
>>> In particular, how do you know there is
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 compiling.
>
> --
> o
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 combinations, like VIA's
>>
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 hw.optional.x86_64 is t
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 the way
> to go, it
On 6 March 2016 at 22:40, Viktor Dukhovni wrote:
>
>> On Mar 6, 2016, at 12:00 PM, Ben Laurie wrote:
>>
>> Hmm. So why do I see this on my macbook?
>>
>> $ arch
>> i386
>
> Try "uname -m"
x86_64
But AIUI, uname -m tells me what hard
eless 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 be better
> to d
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
On Sat, 21 Nov 2015 at 22:39 Kurt Roeckx wrote:
> On Sat, Nov 21, 2015 at 10:09:51PM +0000, Ben Laurie wrote:
> > 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 Satur
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 compatible
> with
> >
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, 2015 at 04:50:59PM +00
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, 2015 at 04:50:59PM +00
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 a correctly functi
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 a correctly functi
On Mon, 24 Aug 2015 at 19:35 Matt Caswell wrote:
> On 24/08/2015 10:08, Ben Laurie wrote:
> >
> >
> > On Mon, 24 Aug 2015 at 03:56 Salz, Rich > <mailto:rs...@akamai.com>> wrote:
> >
> >
> > >On Sat, 22 Aug 2015 at 01:56 Salz, Rich >
On Mon, 24 Aug 2015 at 09:53 Alessandro Ghedini
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 that you are no
On Mon, 24 Aug 2015 at 03:56 Salz, Rich wrote:
>
> >On Sat, 22 Aug 2015 at 01:56 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.
>
> >Are these linked from the website somewhere?
>
>
On Sat, 22 Aug 2015 at 01:56 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.
>
Are these linked from the website somewhere?
___
openssl-dev m
On Thu, 6 Aug 2015 at 14:14 David Woodhouse via RT 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 firmware, those f
On Thu, 6 Aug 2015 at 14:14 David Woodhouse via RT 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 firmware, those f
On Sat, 1 Aug 2015 at 14:22 mancha 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) == 4 is
On 8 June 2015 at 13:27, John Foley 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 seeing:
>
> [j
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: right-hand
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 in
On 17 August 2014 06:44, Rich Salz via RT 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
>
> ___
On 16 August 2014 19:50, Dominyk Tiller 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:
>
> "/usr/local/cellar/openssl/*/bin/openss
On 11 July 2014 11:56, Andy Polyakov 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 seem
On 11 July 2014 08:30, Andy Polyakov via RT wrote:
>>> openssl enc command with -aes-xxx-xts doesnt work if an IV is specified
>>
>> When you say it "doesn't work", what do you mean? Do you get an error? If so
>> what is it?
>
> If only it was the actual problem. The thing is that *if* one wants t
On 11 July 2014 09:53, Kyle Hamilton wrote:
> EC_POINT_is_on_curve is documented to return -1 on error, 0 if it's not
> on the curve, and 1 if it is on the curve.
>
> However, this breaks the standard idiom if(!EC_POINT_is_on_curve()) {
> return BAD_KEY; }, because it requires an additional test f
On 9 July 2014 14:38, Paul Morriss 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
depressingly high (or was last
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 Ma
On 5 July 2014 12:37, Kurt Roeckx 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 what it really
On 5 July 2014 18:46, Zoltan Arpadffy 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 in the main l
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)?
On 4 July 2014 15:20, Toralf Förster 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, Be
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
Au
It'd be nice, btw, if someone would report the bug to cppcheck.
On 4 July 2014 10:15, Ben Laurie wrote:
> On 3 July 2014 22:35, Kurt Roeckx wrote:
>> On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
>>> On 3 July 2014 20:06, Kurt Roeckx via RT wrote:
>>&
On 3 July 2014 22:35, Kurt Roeckx wrote:
> On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
>> On 3 July 2014 20:06, Kurt Roeckx via RT wrote:
>> > On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
>> >> I think cppcheck is right
On 3 July 2014 23:04, Salz, Rich wrote:
> Why not just have bn_expand_internal call memset?
Exactly, this makes more sense.
>
> ; git diff bn_lib.c
> diff --git a/crypto/bn/bn_lib.c b/crypto/bn/bn_lib.c
> index b1e224b..86d1d37 100644
> --- a/crypto/bn/bn_lib.c
> +++ b/crypto/bn/bn_lib.c
> @@ -3
On 3 July 2014 20:06, Kurt Roeckx via RT 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);<--- Uninitialized
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
On 3 July 2014 15:28, Salz, Rich 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 it doesn
On 3 July 2014 14:13, Theodore Ts'o 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 increasing t
ambridge, MA
> IM: 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
>&
On 3 July 2014 12:04, Salz, Rich 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 - not
sure
On 2 July 2014 23:17, Rich Salz via RT 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 merge...
_
On 1 July 2014 19:15, Salz, Rich 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
>> in the
On 1 July 2014 18:34, Tim Rice 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?
OPENSSL_NO_STORE -- dsa.c
>>>
>>> Produces the same output except *without* ../include/openssl/dh.h. (I
>>> presume you meant dh.h, not dh.o earlier.)
>>>
>>> Of course, with your GitConfigure/GitMake scripts, you're using the
>>> compiler
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 http://www.openssl.org
On 1 July 2014 06:52, Zoltan Arpadffy 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 are willing
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 f
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
De
On 21 June 2014 19:51, Otto Moerbeek wrote:
> On Sat, Jun 21, 2014 at 06:15:28PM +0100, Ben Laurie wrote:
>
>> On 12 June 2014 23:15, Matt Caswell wrote:
>> >
>> >
>> > On 12/06/14 22:43, Otto Moerbeek wrote:
>> >> On Thu, Jun 12,
On 12 June 2014 23:15, Matt Caswell 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
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) wrote:
> Update : Crashes are seen only on MAC OS
On 6 June 2014 22:21, Zoltan Arpadffy 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
>
>
> -
>
> SYSTEM@ia64$
You didn't update the test...
On 1 June 2014 21:26, Viktor Dukhovni 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 not
>> be co-prime t
the first byte we are sure that it will spawn a
> (strong) prime, just like 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 an
On 28 May 2014 01:47, mancha 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 improve on
On 28 May 2014 00:03, Viktor Dukhovni 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
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 wrote:
> Hi SSL Team,
>
> I was looking for ways to make calculating RSA public/private keys f
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 gene
On 27 May 2014 09:16, Joseph Birr-Pixton wrote:
> On 27 May 2014 08:45, Peter Waltenberg 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 example RSA blinding data can sa
On 26 May 2014 19:52, Viktor Dukhovni wrote:
> On Mon, May 26, 2014 at 07:24:54PM +0100, Ben Laurie wrote:
>
>> Finally, all of them have a bias: they're much more likely to pick a
>> prime with a long run of non-primes before it than one that hasn't (in
>> the
I was looking at the internal functions in bn_prime.c:
probable_prime(), probable_prime_dh() and probably_prime_dh_safe().
Possibly I'm missing something, but... don't all of these functions
actually generate (probable) safe primes? This is particularly
bemusing for the DH ones.
Also, probable_pr
-- Forwarded message --
From: Martin Haufschild
Date: 23 May 2014 07:34
Subject: Using Frankencerts for Automated Adversarial,Testing of
Certificate Validation,in SSL/TLS Implementations
Hello,
FYI
https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf
There seem to be two discrepan
On 20 May 2014 15:17, Ken Goldman wrote:
> On 5/20/2014 7:24 AM, Ben Laurie wrote:
>>
>>
>> There is already a strndup replacement: BUF_strndup(). Switching to
>> use that would be better.
>
>
> However
>
> - if that function points to strndup, don
On 20 May 2014 06:40, The Doctor,3328-138 Ave Edmonton AB T5Y
1M4,669-2000,473-4587 wrote:
> Found that strndup would not work.
>
> I had to add
>
> #if !HAVE_STRNDUP
>
> #include
> #include
> #include
> #include
>
> /* Find the length of STRING, but scan at most MAXLEN characters.
>If no
On 26 April 2014 12:16, Kurt Roeckx 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 w
On 24 April 2014 19:54, Kurt Roeckx 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.
>
On 25 April 2014 00:08, Matt Caswell 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?
__
OpenSSL Pro
On 24 April 2014 18:44, Mike Bland wrote:
> On Thu, Apr 24, 2014 at 1:31 PM, Ben Laurie wrote:
>>
>> 6. Write new tests
>>
>> Our test suite sucks. More tests is better.
>
>
> Shall I send a pull request for this:
>
>
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
On 24 April 2014 10:06, 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://rt.openssl.org/).
>
> RT has been neglected for a l
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 ca
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 ca
On 1 January 2014 21:39, Daniel Kahn Gillmor 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
On 1 January 2014 21:39, Daniel Kahn Gillmor 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
On 20 December 2013 18:51, Stephen Henson via RT 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 now, th
On 11 December 2013 08:55, Tomas Mraz 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
On 22 October 2013 06:47, Nico Williams 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 reply!
>
>
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 wrote:
> Th
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...
On 12 September 2013 17:14, Arthur Mesh via RT 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 {
>
> 647
I find these easier to deal with as pull requests...
On 12 September 2013 17:14, Kyle McMartin via RT 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 _armv7_tick(
On 8 September 2013 13:35, Dr. Stephen Henson 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:
http://www.iana.org/assignments/tls-extensiontype-values/
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 wrote:
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref chan
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 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 -D_REENTRANT
On 15 August 2013 09:21, Tomas Mraz 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
> 2^32 differe
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 -
Since people are always complaining about OpenSSL docs, I thought this
might be of interest.
-- Forwarded message --
From: adam
Date: 1 August 2013 08:23
Subject: [Foundations] 2013 Doc Camp CFP
To: Foundations List
hi
If any projects on the list are lacking good documentatio
On 24 June 2013 22:00, Jeff Mendoza (MS OPEN TECH)
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 in the p
On 22 June 2013 23:06, Mike Frysinger wrote:
> On Saturday 22 June 2013 15:07:49 Ben Laurie wrote:
>> On 22 June 2013 19:04, Mike Frysinger wrote:
>> > On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote:
>> >> On 18 June 2013 22:35, Mike Frysinger wrote:
>>
On 22 June 2013 19:04, Mike Frysinger wrote:
> On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote:
>> On 18 June 2013 22:35, Mike Frysinger wrote:
>> > On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote:
>> >> While building openssl-1.0.1e I noticed th
1 - 100 of 835 matches
Mail list logo
