Re: [openssl-project] build/test before merging

2018-05-22 Thread Viktor Dukhovni
> 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

Re: [openssl-project] build/test before merging

2018-05-22 Thread Viktor Dukhovni
> 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

Re: [openssl-project] build/test before merging

2018-05-22 Thread Viktor Dukhovni
> 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

Re: [openssl-project] build/test before merging

2018-05-24 Thread Viktor Dukhovni
> 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

[openssl-project] Some failing builds in travis?

2018-05-23 Thread Viktor Dukhovni
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

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-12 Thread Viktor Dukhovni
> 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:

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Viktor Dukhovni
> 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.

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Viktor Dukhovni
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

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Viktor Dukhovni
> 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

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-12 Thread Viktor Dukhovni
> 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: > >

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-12 Thread Viktor Dukhovni
> 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...

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-12 Thread Viktor Dukhovni
> 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.

Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-01 Thread Viktor Dukhovni
> 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,

Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-01 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Is Mac a supported platform?

2018-06-01 Thread Viktor Dukhovni
> 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. ___

Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-01 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-02 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-05 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-06 Thread Viktor Dukhovni
> 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 >

Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-06 Thread Viktor Dukhovni
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

Re: [openssl-project] When to enable TLS 1.3

2018-04-28 Thread Viktor Dukhovni
> 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

Re: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test

2018-04-28 Thread Viktor Dukhovni
> 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).

[openssl-project] crypto/bn/asm/x86/ gone, but still used by crypto/bn/asm/x86.pl?

2018-02-06 Thread Viktor Dukhovni
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

Re: [openssl-project] OS/X builds failing

2018-02-09 Thread Viktor Dukhovni
> 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'

Re: [openssl-project] OS/X builds failing

2018-02-09 Thread Viktor Dukhovni
> 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,

Re: [openssl-project] OS/X builds failing

2018-02-09 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Removing assembler for outdated algorithms

2018-02-10 Thread Viktor Dukhovni
> On Feb 10, 2018, at 4:58 PM, Viktor Dukhovni <vik...@dukhovni.org> 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

Re: [openssl-project] Removing assembler for outdated algorithms

2018-02-10 Thread Viktor Dukhovni
> 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 >

Re: [openssl-project] Removing assembler for outdated algorithms

2018-02-10 Thread Viktor Dukhovni
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...

Re: [openssl-project] Removing assembler for outdated algorithms

2018-02-11 Thread Viktor Dukhovni
> 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

[openssl-project] EdDSA and "default_md"?

2018-08-08 Thread Viktor Dukhovni
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

Re: [openssl-project] Removal of NULL checks

2018-08-09 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Removal of NULL checks

2018-08-08 Thread Viktor Dukhovni
> 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

[openssl-project] Inappropriate fallback triggered when "holes" in client protocol list indirectly exclude TLSv1.3

2018-08-15 Thread Viktor Dukhovni
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

Re: [openssl-project] Inappropriate fallback triggered when "holes" in client protocol list indirectly exclude TLSv1.3

2018-08-15 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Releases tomorrow

2018-08-13 Thread Viktor Dukhovni
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.

Re: [openssl-project] FW: Certificate fractional time processing in upcoming openssl releases

2018-08-11 Thread Viktor Dukhovni
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

[openssl-project] ABI change tracking

2018-08-11 Thread Viktor Dukhovni
I just ran into: https://abi-laboratory.pro/index.php?view=timeline=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.

Re: [openssl-project] Removal of NULL checks

2018-08-09 Thread Viktor Dukhovni
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 &g

Re: [openssl-project] Removal of NULL checks

2018-08-09 Thread Viktor Dukhovni
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) { >

Re: [openssl-project] Removal of NULL checks

2018-08-09 Thread Viktor Dukhovni
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

Re: [openssl-project] Removal of NULL checks

2018-08-09 Thread Viktor Dukhovni
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

Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Applying system defaults to TLS config

2018-03-15 Thread Viktor Dukhovni
> 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

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-14 Thread Viktor Dukhovni
> 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

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-14 Thread Viktor Dukhovni
> 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

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-14 Thread Viktor Dukhovni
> 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

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-14 Thread Viktor Dukhovni
> 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.

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-14 Thread Viktor Dukhovni
> 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"

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-18 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-18 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-18 Thread Viktor Dukhovni
> 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

Re: [openssl-project] When to enable TLS 1.3

2018-04-21 Thread Viktor Dukhovni
> 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

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-14 Thread Viktor Dukhovni
> 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 >

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-16 Thread Viktor Dukhovni
> 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

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-15 Thread Viktor Dukhovni
> 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

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-15 Thread Viktor Dukhovni
> 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

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-15 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Proto over ciphers or ciphers over proto? (was: The problem of (implicit) relinking and changed behaviour)

2018-04-15 Thread Viktor Dukhovni
> 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)

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-19 Thread Viktor Dukhovni
> On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni <openssl-us...@dukhovni.org> > 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

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-19 Thread Viktor Dukhovni
> 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.

Re: [openssl-project] When to enable TLS 1.3

2018-04-23 Thread Viktor Dukhovni
> 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

[openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test

2018-04-23 Thread Viktor Dukhovni
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

Re: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test

2018-04-23 Thread Viktor Dukhovni
> On Apr 22, 2018, at 9:49 PM, Viktor Dukhovni <openssl-us...@dukhovni.org> > 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 a

Re: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test

2018-04-24 Thread Viktor Dukhovni
> 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

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-17 Thread Viktor Dukhovni
> 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

[openssl-project] TLS 1.3 and SNI

2018-04-17 Thread Viktor Dukhovni
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

[openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-17 Thread Viktor Dukhovni
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

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-19 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-19 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-19 Thread Viktor Dukhovni
> 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

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-18 Thread Viktor Dukhovni
> 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

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-17 Thread Viktor Dukhovni
> 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.

[openssl-project] When to enable TLS 1.3 (was: Google's SNI hurdle)

2018-04-19 Thread Viktor Dukhovni
> 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 >>

Re: [openssl-project] Speeding up the fuzz test...

2018-03-27 Thread Viktor Dukhovni
> 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,

Re: [openssl-project] Fw: [openssl/openssl] 1.1.0h build issue on SPARC/Solaris and maybe HPUX (#5867)

2018-04-04 Thread Viktor Dukhovni
> 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

Re: [openssl-project] to fully overlap or not to

2018-02-28 Thread Viktor Dukhovni
> On Feb 28, 2018, at 11:32 AM, Viktor Dukhovni <openssl-us...@dukhovni.org> > 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 wor

[openssl-project] FYI: [postfix & TLS1.3 problems]

2018-10-11 Thread Viktor Dukhovni
Apparently, some SMTP clients set fallback_scsv when doing TLS 1.2 with Postfix servers using OpenSSL 1.1.1. Not yet clear whether they tried TLS 1.3 first and failed, or just sent the SCSV out of the blue... See attached. If this is a common problem, it might be useful to have a control that

Re: [openssl-project] FYI: [postfix & TLS1.3 problems]

2018-10-12 Thread Viktor Dukhovni
On Thu, Oct 11, 2018 at 07:03:21PM -0500, Benjamin Kaduk wrote: > I would guess that the misbehaving clients are early openssl betas > that receive the real TLS 1.3 version and then try to interpret > as whatever draft versino they actually implemnet. Early, partial reports of the cause seem to

Re: [openssl-project] FYI: [postfix & TLS1.3 problems]

2018-10-15 Thread Viktor Dukhovni
On Mon, Oct 15, 2018 at 06:56:06PM +0100, Matt Caswell wrote: > > What do you make of the > > idea of making it possible for servers to accept downgrades (to some > > floor protocol version or all supported versions)? > > I'm really not keen on that idea at all. I understand the healthy

Re: [openssl-project] FYI: [postfix & TLS1.3 problems]

2018-10-15 Thread Viktor Dukhovni
> On Oct 15, 2018, at 9:19 AM, Matt Caswell wrote: > >> Early, partial reports of the cause seem to indicate that the sending >> side was using OpenSSL with: >> >> SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV); >> >> seemingly despite no prior handshake failure, > > Are you sure

Re: [openssl-project] Release scheduling

2018-11-14 Thread Viktor Dukhovni
On Wed, Nov 14, 2018 at 01:27:17PM +, Matt Caswell wrote: > There are now no open PRs/issues with the 1.1.1a milestone so I think we > should > go ahead and do a release. The question is when? I propose next Tuesday > (20th), > with releases of 1.1.0 and 1.0.2 on the same day. It's been a

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> 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 patch l

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> 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

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> 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

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> 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

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
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"

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> 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

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> 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

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> 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

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> 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

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> On Sep 21, 2018, at 9:28 PM, Tim Hudson wrote: > > That parsing of history I think is at best a stretch and not supportable and > also not what our users think. This isn't a mathematical theorem or even a legal debate. We should do what makes the most sense going forward. Richar proposes,

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> On Sep 22, 2018, at 12:59 AM, Richard Levitte wrote: > > So in summary, do we agree on this, and that it's a good path forward? > > - semantic versioning scheme good, we should adopt it. > - we need to agree on how to translate that in code. > - we need to stop fighting about history.

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> On Sep 22, 2018, at 12:50 AM, Tim Hudson wrote: > > The impact of the breaking change on anyone actually following our documented > encoding cannot. > i.e. openssh as one example Richard pointed out. The only use of OPENSSL_VERSION_NUMBER bits in OpenSSH (which is not yet ported to 1.1.x

Re: [openssl-project] Release strategy updates & other policies

2018-09-26 Thread Viktor Dukhovni
> On Sep 25, 2018, at 9:51 AM, Matt Caswell wrote: > > 5.0.0 > 5.0.1 (bug fix) > 5.1.0 (add accessor) > 6.0.0 (new feature) > 6.0.1 (bug fix) > 5.1.1 (bug fix)6.0.2 (bug fix) > 5.2.1 (add accessor) > 6.1.0 (add

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> 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

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> 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

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> 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

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Viktor Dukhovni
> 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

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

2019-01-23 Thread Viktor Dukhovni
> On Jan 23, 2019, at 12:42 PM, David Benjamin wrote: > > (a) Debugging hooks for tracing, often copied from the openssl binary. > (b) As a callback to know when the handshake (in the RFC8446 sense described > above, not the OpenSSL sense) is done, sensitive to SSL_CB_HANDSHAKE_DONE. > (c) As a

  1   2   >