In master and OpenSSL_1_1_0-stable we have:
commit df8c39d52256c2e5327a636928b6d1ed05f695a2
Author: Rich Salz
Date: Tue Sep 30 17:30:19 2014 -0400
RT3549: Remove obsolete files in crypto
Reviewed-by: Andy Polyakov
crypto/bn/asm/x86/add.pl | 76 --
crypto/bn/asm/x86/com
> On Feb 9, 2018, at 5:15 AM, Matt Caswell wrote:
>
> The new travis OS/X builds are failing with this:
>
> -MT apps/enc.o -c -o apps/enc.o apps/enc.c
> apps/enc.c:567:54: error: format specifies type 'uintmax_t' (aka
> 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned
> lon
> On Feb 9, 2018, at 11:23 AM, Richard Levitte wrote:
>
> From those errors, it looks to me like uintmax_t isn't 64-bit on that
> Mac OS/X machine, unless 'unsigned long' and 'unsigned long long' are
> the same.
No, the compiler is not telling you they're not actually the same, rather
it is te
> On Feb 9, 2018, at 11:36 AM, Viktor Dukhovni
> wrote:
>
> $ cat size.c
> #include
> #include
>
> int main(int argc, char **argv)
> {
>printf("char = %zu\n", sizeof(unsigned char));
>printf("short = %zu\n", sizeof(un
> On Feb 9, 2018, at 12:39 PM, Kurt Roeckx wrote:
>
> We document printf to be like the C standard, so it should be
> intmax_t, not int64_t, or we need to fix the documentation.
I don't think we get to coöpt "j" for another purpose, if we
we want a letter format for int64t, we'll need to use a
> On Feb 10, 2018, at 4:08 PM, Salz, Rich wrote:
>
> This is derived from bureau/libcrypto-proposal that Emilila made in November
> 2015.
>
> We should remove the assembler versions of the following
> Blowfish, cast, des, rc4, rc5, ripemd, whirlpool, md5
>
> The reason is t
> On Feb 10, 2018, at 4:58 PM, Viktor Dukhovni wrote:
>
>
> Is blowfish actually outdated? I thought it had some significant use,
> and don't recall any major weakness...
In particular, IIRC OpenSSH uses blowfish, and links to OpenSSL for
the underlying cipher...
On Sat, Feb 10, 2018 at 10:19:20PM +, Salz, Rich wrote:
> > Is blowfish actually outdated? I thought it had some significant use,
> > and don't recall any major weakness...
>
> In particular, IIRC OpenSSH uses blowfish, and links to OpenSSL for
> the underlying cipher...
> On Feb 11, 2018, at 2:20 AM, Richard Levitte wrote:
>
> Those same systems will probably not have the newest OpenSSL either,
> and OpenSSH on those machines will certainly not be linked with a
> newer OpenSSL...
It is not those systems, but other systems that need to communicate
with them (v
> On Feb 28, 2018, at 5:39 AM, Andy Polyakov wrote:
>
> I'd like to request more opinions on
> https://github.com/openssl/openssl/pull/5427. Key dispute question is
> whether or not following fragment should work
>
>unsigned char *inp = buf, *out = buf;
>
>for (i = 0; i < sizeof(buf);
> On Feb 28, 2018, at 11:25 AM, Viktor Dukhovni
> wrote:
>
>> I'd like to request more opinions on
>> https://github.com/openssl/openssl/pull/5427. Key dispute question is
>> whether or not following fragment should work
>>
>> unsigned char *i
> On Feb 28, 2018, at 11:32 AM, Viktor Dukhovni
> wrote:
>
>>> I'd like to request more opinions on
>>> https://github.com/openssl/openssl/pull/5427. Key dispute question is
>>> whether or not following fragment should work
>>>
>>>
> On Mar 6, 2018, at 11:40 PM, Benjamin Kaduk wrote:
>
>> One way to do this is to say that we will extend the BETA date by a week,
>> and in that week no new code from the team, only third-party existing pull
>> requests will be considered
>
> I'm open to extending the date, though am inter
> On Mar 15, 2018, at 8:12 AM, Salz, Rich wrote:
>
> https://github.com/openssl/openssl/pull/4848
I am also concerned about the performance implications of applying
the system settings at every SSL_CTX_new() (if that's the mechanism).
How does this interact with the creation of SSL contexts u
> On Mar 27, 2018, at 3:28 PM, Richard Levitte wrote:
>
> Now, I wonder how that will impact on Kurt, who sometimes produce
> these files, and on Google's oss-fuzz project, who do use this.
> My desire is to replace the current corpora with the corresponding
> cpio files, one for each test prog
> On Apr 4, 2018, at 4:32 AM, Richard Levitte wrote:
>
> The fix itself is easy (just add a line saying 'CPP=$(CC) -E'), and
> that's not what I'm here to talk about, but rather how we want to act
> in cases like this. Do we make a new release? Do we create an
> official patch? Do we make a
I'd like to thank Matt for going above and beyond the immediate issue raised
(documenting the EdDSA algorithm options) and thoroughly updating the
genpkey(1) manpage, reviewing the code and fixing bugs, etc.
This is the kind of thoroughness that it takes to pay down past technical debt
and pro
> 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. Note that I'm not say
> On Apr 14, 2018, at 4:18 PM, Richard Levitte wrote:
>
>> Will real applications run into any meaningful problems?
>
> This is an argument that I find *terribly* frustrating. Are you
> suggesting that we have no test that tries to do what can be expect
> from a "real" application?
I am sugg
> 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 is not a change in API
> 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 our public headers mak
> On Apr 14, 2018, at 5:13 PM, Salz, Rich wrote:
>
> 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 work *going
> forwards* ?
It is unclear what you mean by forwards and backwards, but some 1.1.0
te
> 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
> call "going forward", i
> On Apr 15, 2018, at 8:07 AM, Richard Levitte wrote:
>
> This touches an issue that's already mentioned in Matt's blog, and I
> gotta ask how the protocols so be presented for negotiation are chosen
> (yes, I know, I could dive into the code... and I will unless there's
> a quick answer). Do
> On Apr 15, 2018, at 2:24 AM, Bernd Edlinger wrote:
>
> One possible example of application failure that I am aware of is #5743:
> A certificate that is incompatible with TLS1.3 but works with TLS1.2.
> Admittedly that I did come up with that scenario only because I saw
> a possible issue per
> On Apr 15, 2018, at 12:55 PM, Salz, Rich wrote:
>
> Do our 1.1.0 tests work when linked against the 1.1.1 library?
Our tests don't, but Richard (valiantly I must say) went to the trouble
of doing just that. And found some tests that failed, ...
> Even then, there might be some failures bec
> On Apr 15, 2018, at 12:59 PM, Salz, Rich wrote:
>
> Let me turn the question around because we'll never know "everything" just
> works. Except for our tests, what programs work with 1.1.0 and *fail* to work
> with 1.1.1? Any? For various reasons that Viktor and I have detailed, *our
> tes
> On Apr 15, 2018, at 5:06 PM, Benjamin Kaduk wrote:
>
> IIUC a fixed DH certificate is incompatible with TLS 1.3 but can be
> TLS 1.2-compatible.
Yes, you're right, TLS 1.3 dropped fixed-dh support, but we've a while back
dropped support for all the (authenticated) corresponding TLS 1.2 ciph
> On Apr 16, 2018, at 6:00 AM, Matt Caswell wrote:
>
> That's not entirely true. This works:
>
> $ openssl s_server -cert dsacert.pem -key dsakey.pem -cipher ALL:@SECLEVEL=0
> $ openssl s_client -no_tls1_3 -cipher ALL@SECLEVEL=0
>
> This doesn't:
>
> $ openssl s_server -cert dsacert.pem -key
> On Apr 17, 2018, at 2:15 PM, Richard Levitte wrote:
>
> Depends on what "the best thing you know to do" is. In my mind,
> simply refusing to run as before because the new kid in town didn't
> like the environment (for example a cert that's perfectly valid for
> TLSv1.2 but invalid for TLSv1.
Just wanted to check. The TLS 1.3 draft lists SNI as mandatory to implement,
but is not mandatory to use. Clients should, but do not have to send SNI, and
servers may require SNI, but can just use some default chain instead.
Does OpenSSL's TLS 1.3 support mandate SNI in either the client or s
Applications that have hitherto used TLS <= 1.2 have often not needed to use
SNI. The extension, though useful for virtual-hosting on the Web, was optional.
TLS 1.3 has raised the status of SNI from optional to "mandatory to implement".
What this means that is that implementations must support
> On Apr 17, 2018, at 11:27 PM, Salz, Rich wrote:
>
> So far, if there's no SNI then we shouldn't do TLS 1.3 (as a client). That
> seems easy to code.
That might be a sensible work-around, with a bit of care to make sure that the
user has not also disabled TLS 1.2 (i.e. try TLS 1.3 without
> On Apr 18, 2018, at 10:12 AM, Andy Polyakov wrote:
>
> With this in mind, wouldn't it be more
> appropriate to simply not offer 1.3 capability if application didn't
> provide input for SNI?
That's what Rich suggested, and it makes sense, but what does not make any
sense to me is what Google
> On Apr 18, 2018, at 10:43 AM, Andy Polyakov wrote:
>
> It can either be a probe just to see if it's reasonable to demand it, or
> establish a precedent that they can refer to saying "it was always like
> that, *your* application is broken, not ours." Also note that formally
> speaking you can
> On Apr 18, 2018, at 1:14 PM, Kurt Roeckx wrote:
>
> I'm not sure you actually get downgraded? I get TLS 1.2 in all
> cases. I think they still speak a different draft version. If it's
> boringssl, I think they do 22 and 23 in the last release and 26
> (like we) in their current master version
> On Apr 18, 2018, at 6:23 PM, David Benjamin wrote:
>
> Rather than break existing clients, with TLS 1.3 we are trying a more
> incremental approach: if a client is new enough to support TLS 1.3 then
> either it should be sending SNI, or we'll give it a dummy certificate.
So it sure seems l
> On Apr 19, 2018, at 1:31 PM, David Benjamin wrote:
>
> Consequently, opportunistic SMTP clients (or those using mandatory TLS, but
> without
> DANE where the SNI value is still a guessing game we did not play) won't get
> TLS 1.3, until they start to make up some sort of SNI name.
>
> I'm
> On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni
> wrote:
>
> There is no "the name that is being verified". The Postfix SMTP client
> accepts multiple (configurable as a set) names for the peer endpoint. This
> may be the next-hop domain or the MX hostname,
> On Apr 19, 2018, at 1:31 PM, David Benjamin wrote:
>
> Consider a caller using a PKCS#1-only ENGINE-backed private key. PKCS#1 does
> not work in TLS 1.3, only PSS.
That's a local matter, and easy to resolve locally.
> Consider a caller which calls SSL_renegotiate.
Ditto. And sufficientl
> On Apr 19, 2018, at 3:15 PM, Kurt Roeckx wrote:
>
> I think there might be some disagreement on how to go forward with
> having proper TLS in SMTP. I think Google might want to go with
> how it works for https, and so have certificates issued by a CA
> for hostname you try to connect to. I th
> On Apr 19, 2018, at 2:54 PM, Salz, Rich wrote:
>
> I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or
> something like that.
You'll need to retract that.
--
Viktor.
___
openssl-project mailing list
openssl-pro
> On Apr 19, 2018, at 2:54 PM, Salz, Rich wrote:
>
> David has pointed out valid use-cases. I think most use-cases will "just
> work." We should document the known sharp edges.
I am pointing valid use-cases that David has not taken into account, and
conformance ratchets have cost/benefit t
> On Apr 19, 2018, at 4:24 PM, Salz, Rich wrote:
>
> Viktor found my comment offensive, which was not my intent. I was trying to
> be light-hearted in commenting on how Viktor dismissed all the issues David
> raised.
>
> If, in doing so, I went beyond our code of conduct and offended, I am
> On Apr 19, 2018, at 1:48 PM, Matt Caswell wrote:
>
>> I might suggest conditioning it on the compile-time version of OpenSSL
>> headers. This is a common transition strategy for systems working
>> through ABI constraints. (In some systems, this is implemented as some
>> target SDK version.)
>
> On Apr 21, 2018, at 2:42 PM, Kurt Roeckx wrote:
>
> Here is some attempt:
>
> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> 1.3 brings a lot of changes that might cause incompatibility. For
> an overview see https://wiki.openssl.org/index.php/TLS1.3
Should the Wiki me
> On Apr 21, 2018, at 3:45 PM, Kurt Roeckx wrote:
>
>>> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
>>> 1.3 brings a lot of changes that might cause incompatibility. For
>>> an overview see https://wiki.openssl.org/index.php/TLS1.3
>>
>> Should the Wiki mention the obser
> On Apr 22, 2018, at 12:16 PM, Richard Levitte wrote:
>
> openssl-users> > We are considering if we should enable TLS 1.3 by default or
> not,
> openssl-users> > or when it should be enabled. For that, we would like to
> know how
> openssl-users> > applications behave with the current versio
I tested a Postfix server and client built against OpenSSL 1.1.0,
using 1.1.1 run-time libraries. This exercised peer certificate
fingerprint matching and session resumption. No major issues.
The only interesting observations are:
* With TLS 1.3 a new session is generated even sessions are
> On Apr 23, 2018, at 3:35 AM, Matt Caswell wrote:
>
>> * With TLS 1.3 a new session is generated even sessions are
>>resumed, because the server responds with a new ticket
>>in the event of session resumption. With TLS 1.2 sessions
>>that had sufficient remaining lifetime did not
> On Apr 22, 2018, at 9:49 PM, Viktor Dukhovni
> wrote:
>
> - Client-side diagnostics -
On the server side I see that even when the ticket callback returns "0" to
accept and not re-issue the ticket, a new ticket is requested anyway. I'd like
to be ab
> On Apr 24, 2018, at 9:29 AM, Benjamin Kaduk wrote:
>
> To be clear, the current draft explicitly says "Servers SHOULD issue
> new tickets with every connection." This is not a MUST, but is
> perhaps strong enough guidance to merit overriding the existing
> ticket callback semantics.
Fine ad
> On Apr 28, 2018, at 2:41 PM, Kurt Roeckx wrote:
>
> So should I send that mail?
I made some editorial changes to the Wiki section on SNI.
No strong views on sending the mail...
--
Viktor.
___
openssl-project mailing list
openssl-project@
> On Apr 28, 2018, at 8:42 PM, Benjamin Kaduk wrote:
>
> [ ... nothing I don't agree with ... ]
We're on the same page here. OpenSSL the built-in defualt
callback can re-issue by default, so long as custom callbacks
can choose to not re-issue (their return code is honoured).
My other observa
> On May 21, 2018, at 8:15 AM, Salz, Rich wrote:
>
> The ghmerge script has a commented-out call to “opensslbuild” to build+test
> before submitting.
> I would like to enable that, and add either –build or –nobuild flags.
> Thoughts?
It probably does not know how/where I prefer to do builds
> On May 22, 2018, at 8:37 PM, Salz, Rich wrote:
>
> No, I'm sure it does not. I think the safer thing is to do a full build, to
> catch things like make update errors, and such. I also run the test suite
> before I submit.
I do the same, but I am reluctant having a script doing it for me
> On May 22, 2018, at 8:43 PM, Salz, Rich wrote:
>
> So do you guys use the ghmerge script or own procedures? I'm curious.
Good point, I've not yet had a chance to look at ghmerge and figure
out how/whether to use it. If that continues, ... my preferences for
its implementation don't carry m
https://travis-ci.org/openssl/openssl/jobs/382694134
https://api.travis-ci.org/v3/job/382694134/log.txt
Test Summary Report
---
../test/recipes/70-test_comp.t (Wstat: 26624 Tests: 0 Failed:
0)
Non-zero exit status: 104
Parse errors: No plan found in TAP outp
> On May 24, 2018, at 4:42 PM, Richard Levitte wrote:
>
> Those are non-standard and a matter of personal taste. I used those before I
> discovered --fixup and --squash. How many variants should we support?
>
> (I'm not totally against the idea, mind you...)
Let's stick with the standard ve
> On Jun 1, 2018, at 5:26 PM, Salz, Rich wrote:
>
> So maybe I should just create a PR to update INSTALL with the Mac recipe?
I just use:
./Configure --prefix=/some/where [options] shared darwin64-x86_64-cc
--
Viktor.
___
openssl
> On Jun 1, 2018, at 5:51 PM, Kurt Roeckx wrote:
>
> That would then just mean that the apps need to do the correct
> thing and convert it to UTF-8.
Module legacy files, with a passphrase in some other encoding.
For those the applications will have to provide the right
non-UTF8 octet string,
> On Jun 1, 2018, at 6:16 PM, Richard Levitte wrote:
>
> (I'm currently looking into alternatives where a UI_METHOD can present
> several variants of the same pass phrase, thus making it possible for
> the application to virtually say "hey, try one of these" instead of
> "hey, try this one"...
> On Jun 1, 2018, at 6:47 PM, Richard Levitte wrote:
>
> Ah, forgot one important detail: it is well understood that *all*
> file based objects will get the same requirements, right? That goes
> for anything protected through PKCS#5 as well (good ol' PEM
> encryption, PKCS#8 objects and what
> On Jun 2, 2018, at 2:36 AM, Richard Levitte wrote:
>
>> Canonicalize when importing for use with the store API.
>
> Yup.
>
>> Not sure whether wchar_t though, just octet string in UTF-8 seems saner.
>
> Dunno about that, really. The aim, to quote David W, is to make it
> *hard* for appli
> On Jun 3, 2018, at 4:45 AM, Richard Levitte wrote:
>
> Yeah, I just learned that myself. Somehow, I thought wchar_t would be
> Unicode characters. So ok, with this information, UTF-8 makes
> sense...
Nico has convinced me that the mapping from UTF-8 to BMPString should
be UTF-16, which is
https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-4
https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-5.2
> On Jun 6, 2018, at 11:23 AM, David Benjamin wrote:
>
> Is there a spec citation for this, or some documented experiments against
> On Jun 6, 2018, at 12:52 PM, David Benjamin wrote:
>
> Oh, I didn't realize that document existed. Although it doesn't say that it
> is overriding the BMPString restrictions. It says it "does not add any
> further restrictions to the input passwords of these methods, however it is
> RECOM
> On Jun 7, 2018, at 11:19 AM, Richard Levitte wrote:
>
> Regarding general use of other libraries, please think carefully before
> voting, 'cause this *is* tricky. If you have a look, you will see that we
> *currently* depend on certain standard libraries, such as, for example,
> libdl. An
On Thu, Jun 07, 2018 at 09:01:15PM +0200, Richard Levitte wrote:
> We don't have to answer the question "how high" now. I'm fully
> prepared to have the use of iconv limited to platforms where we know
> it's available (for example, we - or well, *I* - know that VMS has the
> iconv API in the C RT
> On Jun 7, 2018, at 3:59 PM, Salz, Rich wrote:
>
> If B<-pass8bit> is given, the password is taken to be encoded in the current
> locale, but is still used directly.
> A future release might automatically convert the password to valid UTF-8
> encoding if this flag is given.
I would propose t
> On Jun 11, 2018, at 11:46 AM, Salz, Rich wrote:
>
> And the docs for this *new flag* explain that the behavior could change in
> the future.
There must be no "change in the future". Whatever flags
we add now, must implement a stable interface. A flag
that changes behaviour is useless.
-
> On Jun 7, 2018, at 3:40 PM, Salz, Rich wrote:
>
> I think you forgot that this is not what I suggested. One flag indicates
> it's utf-8 encoded, don't touch it. The other flag indicates it might have
> high-bit chars, don't touch it.
The flags I'd like to see are:
-latin1: Passphras
> On Jun 12, 2018, at 3:39 PM, Richard Levitte wrote:
>
>> The flags I'd like to see are:
>>
>> -latin1: Passphrase is a stream of octets, each of which is a single
>> unicode
>> character in the range 0-255.
>
> I would prefer to call it -binary or something like that... it
> On Jun 12, 2018, at 6:56 PM, Richard Levitte wrote:
>
> Some implementations of the iconv library take the empty string as
> the locale-specific encoding, but that is in no way universal, and
> isn't specified in the standard:
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/ico
> On Aug 8, 2018, at 6:19 AM, Tim Hudson wrote:
>
> However in the context of removing such checks - that we should not be doing
> - the behaviour of the APIs in this area should not be changed
Should not be changed period. Even across major release boundaries.
This is not an ABI compatibil
Don't know whether everyone here also reads openssl-users, so to recap,
Robert Moskowitz reports considerable frustration
as a result of "default_md = sha256" being incompatible with Ed25519
(and Ed448). He's working around this with "-md null" sprinkled about
liberally, but it is not especially
> On Aug 9, 2018, at 9:49 AM, Salz, Rich wrote:
>
> This is another reason why I am opposed to NULL checks.
Whether one's for them, or against them, removing a check
from a function that would formerly return an error and
making it crash is a substantial API change. We must
avoid API changes
On Thu, Aug 09, 2018 at 05:53:11PM +0200, Richard Levitte wrote:
> I think we need to be a bit more nuanced in our views. Bug fixes are
> potentially behaviour changes (for example, I recently got through a
> PR that added a stricter check of EVP_PKEY_asn1_new() input; see #6880
> (*)).
We went
On Thu, Aug 09, 2018 at 06:40:14PM +0200, Richard Levitte wrote:
> In message <20180809162245.gd14...@straasha.imrryr.org> on Thu, 9 Aug 2018
> 12:22:45 -0400, Viktor Dukhovni said:
>
> openssl-users> It needs to be possible to recompile and run without auditing
> co
On Thu, Aug 09, 2018 at 07:12:18PM +0200, Richard Levitte wrote:
> viktor> X509 *x;
> viktor> STACK_OF(X509) *s;
> viktor>
> viktor> ...
> viktor> /* Allocate 's' and initialize with x as first element */
> viktor> if (sk_X509_push(s = sk_X509_new(NULL), x) < 0) {
>
On Thu, Aug 09, 2018 at 02:23:07PM -0700, Paul Dale wrote:
> > Real code often doesn't check return values. Even ours. :(
>
> Could we consider adding a lot more __owur tags to functions to encourage
> this?
>
> As an API change it would have to wait for a major release.
This is sometimes a g
On Sat, Aug 11, 2018 at 01:50:07PM +, Salz, Rich wrote:
> FYI. Quietly ignoring fractional seconds makes sense to me.
Ditto.
--
Viktor.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/
I just ran into: https://abi-laboratory.pro/index.php?view=timeline&l=openssl
Perhaps you've all seen this site already, but if not, enjoy!
FWIW, OpenSSL 1.1.1/master are looking fine. Just some SM2-related
symbol churn, which does not affect the stable ABI.
--
Viktor.
_
On Mon, Aug 13, 2018 at 03:07:02PM +0100, Matt Caswell wrote:
> - I think the ca app usability improvements for EdDSA (PR 6901) should
> go in (I have initial approval, awaiting a reconfirm from Viktor)
I already did that. Go ahead and merge.
--
Viktor.
When I configure a client with a legacy TLS 1.2 protocol exclusion,
e.g. by setting SSL_OP_NO_TLSv1_2 (rather than the new min/max
version interface), as a result of the new TLS 1.3 protocol
suport configurations that previously negotiated "up to" TLS 1.1,
now fail when communicating with a TLS 1.3
> On Aug 15, 2018, at 11:50 AM, Matt Caswell wrote:
>>
>> I think this counts as a regression, the client should notice that
>> it implicitly disabled TLS 1.3, and therefore not react to the
>> server's version sentinel by aborting the connection. Thoughts?
>>
>
> Hmm. Yes we should probabl
> On Sep 6, 2018, at 6:25 PM, Matt Caswell wrote:
>
> I'm not keen on that. What do others think?
No objections to issuing a release. We're unlikely to have to change the
API/ABI or feature set based on further beta feedback. Any late bugs can
be fixed in 1.1.1a, and unless they trigger CVE
I support Richard's numeric scheme as proposed, with one small change.
I think that setting the epoch to 8 to set the high bit is neither
necessary nor wise. Though the numeric version constant should be
manifestly unsigned (UL suffix not L), and having the top 3 nibbles
for the "effective" major
> On Sep 21, 2018, at 9:35 AM, Richard Levitte wrote:
>
> In that case, we should probably just thrown away
> OPENSSL_VERSION_NUMBER.
Sorry, that must not t happen and there's no need. My sense is that Tim
may end up "in the rough" on this issue, so unless there's more evidence
of support for
> On Sep 21, 2018, at 10:07 AM, Tim Hudson wrote:
>
> And the output you get:
>
> 0x10102000
The trouble is that existing software expects to potential ABI changes
resulting from changes in the 2nd and 3rd nibbles, and if the major
version is just in the first nibble, our minor version chan
> On Sep 21, 2018, at 11:00 AM, Tim Hudson wrote:
>
> If you repeat that in semantic versioning concepts just using the labels for
> mapping you get:
> - what is the major version number - the answer is clearly "1".
> - what is the minor version number - the answer is clearly "0"
> - what is
> On Sep 21, 2018, at 11:13 AM, Matthias St. Pierre
> wrote:
>
> I like Richard's approach (with the '8' or another number) and I don't think
> it is
> contradicting semantic versioning. Maybe a good compromise between your two
> opposing views would be to make the encoding irrelevant to o
> On Sep 21, 2018, at 11:16 AM, Viktor Dukhovni
> wrote:
>
> I'm afraid that's where you're simply wrong. Ever since 1.0.0, OpenSSL
> has promised (and I think delivered) ABI stability for the *minor* version
> and feature stability (bug fixes only) for the
> On Sep 21, 2018, at 11:27 AM, Tim Hudson wrote:
>
> No it isn't - as you note that isn't a valid mapping - 1.0 isn't a semantic
> version and there is no such thing as a fix number,
> You get three concepts and then on top of that the pre-release and the
> build-metadata.
>
> Semantic ver
> On Sep 21, 2018, at 11:40 AM, Tim Hudson wrote:
>
> That is something I wouldn't suggest makes sense as an approach - to change
> the tarfile name and leave all the internals the same achieves nothing.
And that's not the proposal. The proposal is that the new major number
is 2 (or 3 if so
> On Sep 21, 2018, at 11:56 AM, Tim Hudson wrote:
>
> What I was suggesting is that we don't need to break the current encoding at
> all.
Not changing the encoding has a downside.
* The bits that represent ABI stability would shift from the
2nd/3rd nibbles to just the first nibble.
* We
> On Sep 21, 2018, at 12:14 PM, Matt Caswell wrote:
>
> I support Richard's proposal with an epoch of 1.
> Grudgingly I would accept an epoch in the 3-8 range.
> I would oppose an epoch of 2.
I can live with that, though it might mean that a minority of
applications will interpret (based on o
> On Sep 21, 2018, at 12:50 PM, Tim Hudson wrote:
> If that is the case then our current practice of allowing ABI breakage with
> minor release changes (the middle number we document as the minor release
> number)
> has to change.
CORRECTION: As advertised when 1.0.0 first came out, and rep
> On Sep 21, 2018, at 4:01 PM, Richard Levitte wrote:
>
> For pre-processing, that might be different, I have no clue how people
> figure out the exact number to compare OPENSSL_VERSION_NUMBER... I
> assume, though, that they follow the path of least resistance and
> simply pick the current numb
> On Sep 21, 2018, at 4:55 PM, Richard Levitte wrote:
>
> I think we need to get rid of OPENSSL_VERSION_NUMBER.
Absolutely not. That's the one thing we must keep, and keep monotone
so that applications continue to compile and build.
Sure we need to communicate our ABI/API stability policies
1 - 100 of 142 matches
Mail list logo
