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
On 02/26/2017 02:10 AM, Richard Levitte wrote:
> In message <a2e37ebc-183e-023d-f059-7b89d6e3a...@akamai.com> on Fri, 27 Jan
> 2017 10:54:35 -0600, Benjamin Kaduk via openssl-dev <openssl-dev@openssl.org>
> said:
>
> openssl-dev> There was some discussion abou
On 02/26/2017 07:26 AM, Kurt Roeckx wrote:
> It's normal that you might see some symbols removed if you compare
> something like 1.0.1t against 1.0.2, but it shouldn't when compared
> to 1.0.2k.
I agree, and figured this out at some point after I sent the initial
query. Given the low interest
On 02/13/2017 10:13 AM, Matt Caswell wrote:
> I was targeting this change for 1.1.1. The issue is that this does
> change command line behaviour between minor versions of the 1.1.x series
> - which is supposed to preserve API and ABI compatibility. Of course
> this change affects neither API or
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
On 01/11/2017 08:43 AM, Richard Levitte wrote:
> A note: I have absolutely nothing against the addition of SIPhash in
> our collection of hash algos. My scepticism was only in regards to
> using it as a string hasher for our hash tables indexes.
>
Understood. Can you further clarify whether you
On 01/11/2017 11:27 AM, Richard Levitte wrote:
> The branch master has been updated
>via 66ed24b1624606593a23c9fe78d459718d26409c (commit)
>via 78b19e90b4aade1ffdf8d918277910b01dac1d76 (commit)
>via cc10f2275594eac2bcdaa218c1d6f672c2b891b7 (commit)
>via
On 01/10/2017 12:31 PM, Richard Levitte wrote:
>
> Benjamin Kaduk <bka...@akamai.com> skrev: (10 januari 2017 18:48:32 CET)
>> On 01/09/2017 10:05 PM, Salz, Rich wrote:
>>> Should we move to using SIPHash for the default string hashing
>>> function in OpenSS
On 01/09/2017 10:05 PM, Salz, Rich wrote:
>
> Should we move to using SIPHash for the default string hashing
> function in OpenSSL? It’s now in the kernel
> https://lkml.org/lkml/2017/1/9/619
>
ailto:fe...@indutny.com>> wrote:
>
> Hello Benjamin,
>
> On Fri, Dec 9, 2016 at 11:24 PM, Benjamin Kaduk <bka...@akamai.com
> <mailto:bka...@akamai.com>> wrote:
>
> On 12/09/2016 01:43 PM, Fedor Indutny wrote:
>> Hello,
>>
&g
On 12/09/2016 01:43 PM, Fedor Indutny wrote:
> Hello,
>
> During development of one feature for my TLS proxy bud, I have
> discovered that the cert_cb is invoked only for newly generated
> tickets/sessions. The reasoning behind this is clear, but I believe
> that it is most likely needs a
On 12/06/2016 10:42 PM, Richard Levitte wrote:
> The easiest was actually to rewrite PEM_read_bio_PrivateKey()
> entirely, so it solely uses the internal store_file functions I've
> provided.
> I wonder what kind of impact this would have on the community at
> large.
>
If you do that, please
On 12/06/2016 11:01 AM, James Bottomley wrote:
> The next problem is that this is slightly harder simply to insert into
> the PEM code. The BIO parsing is done in PEM_bytes_read_bio() not
> PEM_read_bio_PrivateKey(). The easy way to cope with this would be to
> move PEM parsing into the
On 12/05/2016 09:22 PM, Joel Winarske wrote:
> Hi folks,
>
> I'm having trouble building 1.1.0c for WIN32. Perl ends up in a hard
> loop. I see same symtom building 1.0.2j, but different error. Any
> suggestions to get past this?
>
What version of perl?
-Ben
--
openssl-dev mailing list
To
I'm failing to find a tag for 1.1.0c either on git.openssl.org or on github.
Am I missing something?
Thanks,
Ben
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
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 functions (or macros) should not be committed into the official
1.0.2 tree, but
Is it possible in the unified build system to apply certain compiler (or
linker) flags only to a specific file or set of files? This could make
some scenarios easier when one is willing to patch the tree (e.g., build
some things with -O3 and others with -O0 -ggdb3).
Given that the unified build
During some testing today, I ended up trying to do a build of 1.1.0b
configured for linux-elf --debug (with no-asm to work around some issue
that was not my primary concern at the time), which failed due to a
missing -lefence. The corresponding linux-x86_64 build on the same
machine succeeds.
It
On 08/25/2016 04:33 PM, Tom Ritter wrote:
> NCC Group has prepared (or begun preparing) a patch that integrates
> fuzzing of OpenSSL.
Exciting stuff, most of which I will ignore for now and ask a targeted
question.
> - Because ossltest cooks MD5 to output a constant value, OpenSSL's RNG
>
On 08/01/2016 02:02 PM, Dr. Stephen Henson wrote:
> The branch master has been updated
>via c2e888b54c3b25e89732f6ba66e489ef1ee5ef59 (commit)
>via b26ab17f3d3f56be57000e99b8ad94a4e90197a6 (commit)
>via 67302ade22b99eaa42031016d4861068b0681db3 (commit)
> from
On 08/01/2016 05:31 AM, Ben Laurie wrote:
> The branch master has been updated
>via 68e71e9d000b72d964eb8b4106a1d879a0da4908 (commit)
>via 3260adf1901ff3a842676ec7fa8c53dbfc66c4bd (commit)
>via 620c6ad3125d7631f08c37033d1cb4302aef819a (commit)
> from
On 07/10/2016 09:13 PM, Wang Hao Lee wrote:
>
> After I changed these files. Compiling using ./config fips; make
> depend; make was successful and the apps can link nicely. I
> even manage to test my cipher via the EVP interface: openssl speed
> -evp mynewcipher.
>
> However, when I build by
Hello,
On 05/04/2016 05:21 AM, Dirk Menstermann wrote:
> Hi,
>
> I've trouble with the newest OpenSSL as I'm operating a webserver application
> that answers with HTTP1.x and HTTP2.
>
> I registered the ALPN callback and in this the cipher list was adjusted
> "SSL_set_cipher_list (ssl,
On 04/25/2016 10:18 PM, Alex Hultman wrote:
> Hi Benjamin,
>
> Thanks for the answer. I actually found a working solution just a
> couple of minutes after I posted but I still wanted to hear what you
> recommended. I just did ssl->references++; and also the same on the
> attached BIO's before
On 04/23/2016 12:26 AM, Alex Hultman wrote:
> Hi,
>
> I'm having trouble "duping" an SSL connection. I have an SSL *pointer
> that is going to be SSL_free'd, so I need to clone it or up the ref
> count or somehow make it stay alive. I see that in OpenSSL 1.1.0 it
> seems you added the SSL_up_ref -
On 03/01/2016 03:18 PM, Brad House wrote:
> On 03/01/2016 02:15 PM, Viktor Dukhovni wrote:
>> On Tue, Mar 01, 2016 at 12:50:46PM -0500, Brad House wrote:
>>
>> The only plausible change from 1.0.2f to 1.0.2g that I see that might
>> be related to this is below. Does it work if you revert this
The ocsp utility is something of a jack-of-all-trades; in addition to
being able to function as an ocsp client or server (as the manual page
categorizes its behavior), it can do a few things that are not really
client or server behavior: generating a request but not sending it,
parsing a response
The ocsp utility is something of a jack-of-all-trades; in addition to
being able to function as an ocsp client or server (as the manual page
categorizes its behavior), it can do a few things that are not really
client or server behavior: generating a request but not sending it,
parsing a response
On 01/19/2016 05:37 PM, The Doctor wrote:
> Tried to compile an old bind and ran into
Why?
> What needs to be adjusted?
>
>
The bind code is what needs to be adjusted, given that openssl 1.1 is
intentionally introducing API changes and removing direct access to many
structures. It seems quite
On 12/15/2015 06:43 AM, Kurt Roeckx wrote:
> On Tue, Dec 15, 2015 at 01:24:12PM +0100, Florian Weimer wrote:
>> * Nico Williams:
>> Not on Windows.
>>
>>> What's the alternative anyways?
>> Using C++11.
> I think this is a relevant article:
>
On 11/18/2015 07:05 AM, Hubert Kario wrote:
> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to support
> both relatively modern TLS with user certificates, preferably the newest
> cryptosystems and hashes as well as the oldest ones that were
> standardised and used.
>
> That
On 11/17/2015 12:00 PM, Jeffrey Walton wrote:
>
>
> Also, if OpenSSL requires iOS 9 or above, then its setting policy for users.
In some sense, yes. But it has always done so -- OpenSSL only supports
certain platforms, and certain versions of certain platforms. There are
prerequisites to being
On 11/13/2015 09:31 AM, Jakob Bohm wrote:
> On 13/11/2015 14:40, Emilia Käsper wrote:
>> Hi all,
>>
>> We are considering removing from OpenSSL 1.1 known broken or outdated
>> cryptographic primitives. As you may know the forks have already done
>> this but I'd like to seek careful feedback for
On 11/13/2015 02:20 PM, Daniel Kahn Gillmor wrote:
> On Fri 2015-11-13 14:48:41 -0500, Viktor Dukhovni wrote:
>> The simplest approach is to remove ciphersuites from the SSL/TLS
>> code (effectively making them unavailable even via ALL:COMPLEMENTOFALL),
>> but leave the underlying crypto in the
EAY is Eric A. Young, the original author of SSLeay, which became OpenSSL.
https://en.wikipedia.org/wiki/SSLeay
-Ben
On 10/23/2015 09:44 PM, Fan Zhang wrote:
> Thanks that seems to be the right place to look into.
>
> btw, what does eay stand for?
>
>> On Oct 23, 2015, at
On 10/23/2015 08:22 AM, Alessandro Ghedini wrote:
> Hello everyone,
>
> (sorry for the wall of text...)
>
> one of the things that both BoringSSL and LibreSSL have in common is the
> replacement of OpenSSL's default RNG RAND_SSLeay() with a simpler and saner
> alternative. Given RAND_SSLeay()
On 10/23/2015 04:27 PM, Fan Zhang wrote:
> Hi, all,
>
> Happy to meet your guys by this email. I’m trying to dig into the code base
> and find an implementation of RSA signature. Naturally, I looked into the
> function `int RSA_sign` in file `crypto/rsa/rsa_sign.c`, which further calls
> the
Hi all,
I happened to stumble across crypto/store while poking around at some
other stuff, and it's unclear that the generic object (key, certificate,
CRL, etc.) store is getting used. I don't see any consumers in the
tree, and at present there only seems to be a memory-backed backend
("highly
On 09/30/2015 12:53 PM, Salz, Rich wrote:
> No, it's this
> #ifdef OPENSSL_NO_STDIO
> #define BIO_new_file(f,m) NULL
> #endif
>
That looks like the library is conditionally exporting different symbols
depending on the build configuration, which I considered doing for my
work on
On 09/30/2015 12:59 PM, Salz, Rich wrote:
>> That looks like the library is conditionally exporting different symbols
>> depending on the build configuration
> No more than any other compile-time control.
>
Okay, I guess you have convinced me, in that the ship has already sailed.
-Ben
On 09/11/2015 12:46 PM, Salz, Rich wrote:
>> When I configure with --strict-warnings and, say, no-seed, my build fails due
>> to an empty compilation unit e_seed.c.
> Does just putting an extern declaration in the file work? Or do we need
> something like "#if PEDANTIC" in apps/dsa.c, for
On 09/14/2015 10:43 AM, Benjamin Kaduk wrote:
> Duplicating the declaration of SEED_encrypt() (with or without an extern
> keyword) at the end of the file, outside the #ifndef, lets the build
> succeed.
Sorry, I was mistakenly testing with seed enabled; the quoted statement
is fal
Hi all,
When I configure with --strict-warnings and, say, no-seed, my build
fails due to an empty compilation unit e_seed.c. Is it just expected
that if I'm going to use strict-warnings I will have most/all features
enabled, or is this something that we would want to fix?
Thanks,
Ben
On 09/03/2015 03:26 PM, Rich Salz wrote:
> The branch master has been updated
>via 64b25758edca688a30f02c260262150f7ad0bc7d (commit)
> from fb4844bbc62fb014c115cd8fd2fc4304cba6eb89 (commit)
>
>
> - Log -
> commit
74 matches
Mail list logo
