> On Apr 15, 2018, at 1:38 AM, Richard Levitte wrote:
>
> Errr, are we? Please inform me, because I cannot remember having seen
> tests that specifically targets the case of programs built with 1.1.0
> that get implicitly relinked with 1.1.1 libraries (that's what you
>
In message on Sat, 14 Apr
2018 21:13:47 +, "Salz, Rich" said:
rsalz> We have *no* data points, except our tests, that anything fails to work.
rsalz> In fact, we are increasingly collecting data that shows everything is
> On Apr 14, 2018, at 5:09 PM, Richard Levitte wrote:
>
>> I just tested posttls-finger compiled for 1.1.0 running with a 1.1.1
>> library against a TLS 1.2 server and it worked fine.
>
> Does this answer the whole question, or do they just do the most basic
> stuff that
We have *no* data points, except our tests, that anything fails to work.
In fact, we are increasingly collecting data that shows everything is just fine.
I believe we were led into the current situation, because our tests don't
completely work *going backwards.* Do the 1.1.0 tests basically
> On Apr 14, 2018, at 4:40 PM, Richard Levitte wrote:
>
> Would you say that it's an application bug if it stumbles on a change
> in API behavior that isn't due to a bug fix? (and even better, if it
> worked according to documentation?)
Negotiating a new version of TLS
In message <44fe0745-31df-41c3-b697-97025643c...@dukhovni.org> on Sat, 14 Apr
2018 16:24:56 -0400, Viktor Dukhovni said:
openssl-users>
openssl-users>
openssl-users> > On Apr 14, 2018, at 4:18 PM, Richard Levitte
wrote:
openssl-users> >
In message <352ebaa2-b2d4-4a2e-adc4-1033a1735...@dukhovni.org> on Sat, 14 Apr
2018 16:01:42 -0400, Viktor Dukhovni said:
openssl-users> > 2. Make TLSv1.2 the absolutely maximum TLS version available
for
openssl-users> > programs linked with libssl 1.1.0. This is
I have not heard that any application program -- NOT COUNTING OUR TESTS -- that
break. The one counterpoint we have is that s_client/s_server work.
___
openssl-project mailing list
openssl-project@openssl.org
> On Apr 14, 2018, at 3:32 PM, Richard Levitte wrote:
>
> So regarding assumptions, there's only one assumption that I'm ready
> to make: a program that worked correctly with libssl 1.1.0 and uses
> its functionality as advertised should work the same with libssl
> 1.1.1.
On Sat, Apr 14, 2018 at 09:54:41PM +0200, Richard Levitte wrote:
> Yes, I agree that the TLSProxy tests aren't the most important in this
> regard. Also note that this part was a side note.
Can you then find examples of what a normal user of the library
might be expected to do that fails?
I
In message <20180414194244.ga27...@roeckx.be> on Sat, 14 Apr 2018 21:42:45
+0200, Kurt Roeckx said:
kurt> On Sat, Apr 14, 2018 at 09:32:31PM +0200, Richard Levitte wrote:
kurt> >
kurt> > a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests
kurt> >that are
On Sat, Apr 14, 2018 at 09:32:31PM +0200, Richard Levitte wrote:
>
> a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests
>that are meant to fail (i.e. if the individual tests fail, the
>recipe is successful). When run against 1.1.1 libraries, the
>recipe fails, i.e.
Hi,
First, a note: I don't want this discussion to be just about technical
details, but also about philosophy, and guidance for policy making in
the long run. My feeling is that we've been... well, a bit lax with
regards to library upgrade and program relinking (explicit or
implicit, that
13 matches
Mail list logo