On 01/23/2018 07:19 PM, Salz, Rich via openssl-dev wrote:
>
> * OpenSSL APIs, which makes the following OpenSSL documentation
> statement invalid
> (https://www.openssl.org/docs/man1.0.2/crypto/threads.html
>
>
On 01/17/2018 12:04 PM, Patrick Steuer wrote:
> libcrypto's interface for ciphers and digests implements a flexible
> init-update(s)-final calling sequence that supports streaming of
> arbitrary sized message chunks.
>
> Said flexibility comes at a price in the "non-streaming" case: The
>
On 01/09/2018 01:47 PM, Misaki Miyashita wrote:
>
>>> Sorry, I meant to say it is for the 1.0.2 branch.
>>>
>> Except in exceptional circumstances, code only ends up in the 1.0.2
>> branch after having first gotten into the master branch and then the
>> 1.1.0 branch. The current release policy
On 01/09/2018 08:32 AM, Randall S. Becker wrote:
> On January 9, 2018 8:41 AM, Rich Salz
>> ➢ We are currently modifying the source from Apache to OpenSSL open
>> source
>> licensing for the Speck/OpenSSL integration. Related repositories such
>> as the cipher itself will remain under the
On 01/09/2018 12:53 AM, Misaki Miyashita wrote:
>
>
> On 01/ 8/18 04:46 PM, Misaki Miyashita wrote:
>> (switching the alias to openssl-dev@openssl.org)
>>
>> I would like to suggest the following fix so that a valid certificate
>> at .x can be recognized during the cert validation even when
>> .0
On 01/08/2018 03:10 PM, William Bathurst wrote:
> Hi Hanno/all,
>
> I can understand your view that "more is not always good" in crypto.
> The reasoning behind the offering can be found in the following
> whitepaper:
>
>
On 10/04/2017 04:30 AM, Matt Caswell wrote:
>
> Looks like we should have an exception for this case (with a suitable
> comment explaining why). Will you create a PR?
>
Yes, I was planning to. I was just taking some time to ponder whether
it's worth burning an option bit on, to allow an opt-out
Hi all,
Doing some testing with a snapshot of master (s_client with -tls1_2 and
optionally a cipherspec that prefers ECDHE ciphers), we're running into
a sizeable number of servers that are sending extension 0xa (formerly
"elliptic_curves", now "supported_groups") in the ServerHello. This is
not
On 09/18/2017 09:32 AM, Blumenthal, Uri - 0553 - MITLL wrote:
>
> RSA-OAEP supports different hash functions and MGF. SHA-1 is the default.
>
>
>
> OpenSSL implementation of OAEP wrongly refuses to set the hash
> algorithm, preventing one from using SHA-2 family:
>
>
You'll probably need to
On 09/18/2017 01:07 AM, Mahesh Bhoothapuri wrote:
>
> Hi,
>
> I am sending a Tls 1.3 client hello, and am seeing an issue with
>
> ossl_statem_client_write_transition in statem_clnt.c.
>
>
> /*
> * Note that immediately before/after a ClientHello we don't know what
> * version we are
On 09/06/2017 05:24 PM, Matt Caswell wrote:
> Issue 4283 (https://github.com/openssl/openssl/issues/4283) has caused
> me to take a close look at QUIC. This seems to have been getting a *lot*
> of attention just recently. See the IDs below for details:
Yes, it's generated a lot of excitement and
On 08/29/2017 01:50 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> IMHO this interface is a way for the user to improve the quality of the
> randomness it would get from the given RNG, *not* to replace (or diminish)
> its other sources. My proposal is to abolish this parameter, especially since
>
On 08/09/2017 08:03 AM, Loganaden Velvindron wrote:
> Dear OpenSSL folks,
>
> I was wondering if there is a branch for draft-21 ?
>
draft-21 support is on master at the moment; there's no need for a
separate branch until there is a draft-22 document to support.
-Ben
--
openssl-dev mailing list
On 07/28/2017 01:22 AM, Matthew Stickney wrote:
> With a make distclean, ./config, make depend (didn't appear to do
> anything), and a make, I'm getting the essentially the same thing:
>
> Error: _num does not have a number assigned
> /usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres
>
On 07/25/2017 07:49 PM, Matthew Stickney wrote:
> Possibly. The original errors and hanging perl process have been
> replaced with an enormous number of "undefined reference" errors. For
> example:
> libssl.a(tls_srp.o):tls_srp.c:(.text+0xc4c): undefined reference to `BN_ucmp'
>
On 07/26/2017 08:15 AM, Emeric Brun wrote:
> Hi All,
>
> This bug also affects the 1.1.0
>
Are you able to submit the patch as a github pull request? That would
be the preferred form, as it enables some automation that we have for
CLA checks and CI.
-Ben
--
openssl-dev mailing list
To
On 07/25/2017 01:52 PM, Matthew Stickney wrote:
> I've been trying to build OpenSSL to work on a new feature, but I've
> had problems with the build hanging. I'm building on Windows 10 with
> mingw-w64 under msys2; perl is v5.24, and I installed the
> Text::Template module from CPAN.
>
You did
On 06/26/2017 11:28 PM, Paul Dale wrote:
> Given the variety of RNGs available, would an EVP RNG interface make sense?
> With a safe default in place (and no weak generators provided), the decision
> can be left to the user.
> A side benefit is that the unit tests could implement a simple fully
On 06/27/2017 07:24 PM, Paul Dale wrote:
>
> The hierarchy of RNGs will overcome some of the performance concerns.
> Only the root needs to call getrandom().
>
> I do agree that having a DRBG at the root level is a good idea though.
>
>
>
Just to check my understanding, the claim is that
On 06/27/2017 04:51 PM, Kurt Roeckx wrote:
> On Tue, Jun 27, 2017 at 11:56:04AM -0700, John Denker via openssl-dev wrote:
>>
>> On 06/27/2017 11:50 AM, Benjamin Kaduk via openssl-dev wrote:
>>
>>> Do you mean having openssl just pass through to
>>> ge
Hi Ted,
On 06/27/2017 03:40 PM, Theodore Ts'o wrote:
>
> My recommendation for Linux is to use getrandom(2) the flags field set
> to zero. This will cause it to use a CRNG that will be reseeded every
> five minutes from environmental noise gathered primarily from
> interrupt timing data. For
On 06/27/2017 02:28 AM, Matt Caswell wrote:
>
> On 26/06/17 21:18, Kurt Roeckx wrote:
>
>> I think it should by default be provided by the OS, and I don't
>> think any OS is documenting how much randomness it can provide.
>>
> I also agree that, by default, using the OS provided source makes a lot
On 06/07/2017 10:19 AM, Salz, Rich via openssl-dev wrote:
> A couple of comments.
>
> First, until this shows up in the kernel adopted by major distributions, it
> is a bit premature to include in OpenSSL. Including netinet/tcp.h is
> seriously wrong
I don't know that we would need to wait
On 05/15/2017 12:15 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>
> On a semi-related note, I want able to locate mann.h file either.
`man mmap` will list any headers needed for the mmap() declaration and
flag values.
On the random OS X machine I have handy, it claims is
needed, and a
On 05/12/2017 03:05 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>
> I’m not sure. It may well be that it “simply” takes all the memory
> over, so there is no way for anything else to start and do the clean-up…
>
Hmm, I wonder if a top(1) started before the tests would keep running,
in the case that
On 05/12/2017 02:15 PM, Benjamin Kaduk via openssl-dev wrote:
> From just looking at the code, the only question that comes to mind is
> whether you have a 32- or 64-bit size_t in the build environment in
> question, which is unlikely to cause a eureka moment :(
(The test runs happ
On 05/12/2017 02:05 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> On 5/12/17, 2:49 PM, "openssl-dev on behalf of Benjamin Kaduk via
> openssl-dev" <openssl-dev-boun...@openssl.org on behalf of
> openssl-dev@openssl.org> wrote:
>
> ➢ I’m sorry to report that in
On 05/12/2017 01:34 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>
> I’m sorry to report that in the current OpenSSL 1.1 master running
> “make test” freezes up the machine. Mac OS X 10.11.6, Xcode-8.2,
> current Github master. Here’s the configuration:
>
A commit hash would be more useful than
It seems like a more elegant option would be if there was some attribute
of the engine that could be queried and override the check against zero.
-Ben
On 04/11/2017 06:20 PM, Michael Reilly wrote:
> Unfortunately the check breaks code which doesn't know nor need to know the
> keysize. The
Hi all,
We noticed that the depth limit check seems to behave differently
between 1.0.2 and 1.1.0.
In particular, with a (1.1.0)
openssl/test$ ../util/shlib_wrap.sh ../apps/openssl s_server -port 8080
-cert certs/ee-cert.pem -certform PEM -key certs/ee-key.pem -keyform PEM
-no-CApath -CAfile
I guess the dashboard is only picking up incremental differences, then,
so the four missing symbols is just for 1.0.1u to 1.0.2 (no letter); any
symbols that were added to both 1.0.1 and 1.0.2 letter releases (e.g.,
for CVE fixes) would show up as "removed" since they weren't in the
initial 1.0.2
[moving from github to -dev]
On 01/27/2017 07:36 AM, mattcaswell wrote:
>
> 1.0.2 is the software version.
> The numbers on the end of lbssl.so.1.0.0 refer to the ABI version -
> which is different. Software version 1.0.2 is a drop in replacement
> for 1.0.1, which is a drop in replacement for
32 matches
Mail list logo
