Re: OMC VOTE: selection and handling for SHA1 and RIMPEMD160

On Wed, Oct 12, 2022 at 03:35:19PM +0200, Richard Levitte wrote: > Topic: Provider selection and handling for SHA1 and RIPEMD160 should be > identical >given the current understanding of algorithm specific security issues. Shouldn't real-world usage be taken into account. SHA1 is

Re: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely

Is there an open pull request for this? > On Feb 23, 2021, at 8:21 AM, Tomas Mraz wrote: > > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. > > comment: The padding mode and the related functions (which are already > deprecated in the

Re: 1.1.1f

On Thu, Mar 26, 2020 at 11:33:40PM +, Matt Caswell wrote: > On 26/03/2020 23:15, Viktor Dukhovni wrote: > > On Thu, Mar 26, 2020 at 09:13:32PM +0100, Bernd Edlinger wrote: > > > >> we got into this situation because everything moves so quickly, > >> why d

Re: 1.1.1f

On Thu, Mar 26, 2020 at 09:13:32PM +0100, Bernd Edlinger wrote: > we got into this situation because everything moves so quickly, > why does everyone here think we should move even faster now? > > What is the reason for this? We've published a bug-fix release (1.1.1e) that's liable to cause

Re: Deprecations

> On Feb 22, 2020, at 4:53 AM, Richard Levitte wrote: > > Something that could be done is to take all those aged commands and > rewrite them as wrappers for genpkey, pkey and pkeyutl. Simply create > and populate a new argv and call genpkey_main(), pkey_main() or > pkeyutl_main(). Agreed, that

Re: Deprecations

On Sat, Feb 22, 2020 at 12:51:17AM +0100, Kurt Roeckx wrote: > > (I just realised that what the CHANGES entry says is that > > dhparam/dsaparam are deprecated in favour of pkeyparam - but actually I > > think the equivalent functionality is more split between genpkey and > > pkeyparam) > > Some

Re: Deprecations

On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote: > dhparam itself has been deprecated. For that reason we are not > attempting to rewrite it to use non-deprecated APIs. The informed > decision we have made about DH_check use in dhparam is to not build the > whole application in a

Re: crypt(3)

On Sun, Jan 19, 2020 at 12:26:06PM +0100, Kurt Roeckx wrote: > The only thing that we support currently that makes sense as a > default is -5 (sha256) and -6 (sha512). I suggest you go with -6. I concur, FWIW this is the default password hash for my FreeBSD 12 server, so it is not a Linux-only

Re: crypt(3)

On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote: > There are two functions (DES_crypt and DES_fcrypt) which implement the > old crypt(3) password algorithm. Once these are deprecated, they will > no longer be reachable via EVP. The confounding point is that they > aren’t quite DES

Re: Legacy provider

My abstain vote was a carefully considered neutral stance backed by many paragraphs of rationale. The gist of which is that given that the decision to load or not the provider is in the configuration file, the party ultimately making the decision is whoever packages the software, not the OpenSSL

Re: #10388

> On Nov 14, 2019, at 9:15 AM, Matt Caswell wrote: > > "No existing public interface can be removed until its replacement has > been in place in an LTS stable release. The original interface must also > have been documented as deprecated for at least 5 years. A public > interface is any

Re: #10388

On Thu, Nov 14, 2019 at 08:41:57AM +, Matt Caswell wrote: > I think that we should not add them to 1.1.1 without also adding them to 3.0. Yes. > OTOH if you have a 1.0.2 application that uses these things then not having > them would represent a barrier to moving off of 1.0.2. And it

Re: Deprecation of stuff

+1 (and more) to the below! > On Sep 4, 2019, at 10:15 AM, David Woodhouse wrote: > > I'd note that the question of *versioning* mechanisms is a very very > special case of "when to deprecate stuff". So much so as to almost make > it a completely separate question altogether. > > My own

Re: Deprecation of stuff

On Wed, Sep 04, 2019 at 02:43:34PM +0200, Tomas Mraz wrote: > > The dispute in PR https://github.com/openssl/openssl/pull/7853 has > > made it quote obvious that we have some very different ideas on when > > and why we should or shouldn't deprecate stuff. > > > > What does deprecation mean?

Re: Thread sanitiser problems

> On Jul 30, 2019, at 10:02 PM, Dr Paul Dale wrote: > > The #9454 description includes thread sanitisizer logs showing different lock > orderings — this has the potential to dead lock. Agreed with Rich that > giving up the lock would make sense, but I don’t see a way for this to be > easily

Re: Do we really want to have the legacy provider as opt-in only?

On Mon, Jul 15, 2019 at 02:27:44PM +, Salz, Rich wrote: > >>DSA > > > > What is the cryptographic weakness of DSA that you are avoiding? > > It's a good question. I don't recall the specific reason why that was > added to > the list. Perhaps others can comment.

Re: punycode licensing

On Thu, Jun 20, 2019 at 03:39:10PM +0100, Matt Caswell wrote: > PR 9199 incorporates the C punycode implementation from RFC3492: > > https://github.com/openssl/openssl/pull/9199 > > The RFC itself has this section in it: > > B. Disclaimer and license > >Regarding this entire document or

Re: Removing function names from errors (PR 9058)

On Fri, Jun 14, 2019 at 01:41:51PM +1000, Dr Paul Dale wrote: > I’m behind ditching the function identifier #defines but not their text names. Good to hear. > #define ERR_raise_error ERR_raise_error_internal(__FILE__, __LINE__, __FUNC__) Well, __FUNC__ is entirely non-standard, and __func__ is

Re: Removing function names from errors (PR 9058)

On Wed, Jun 12, 2019 at 10:02:25AM +0100, Matt Caswell wrote: > OTOH I do find them quite helpful from a debugging perspective, e.g. when > people > send in questions along the lines of "I got this error what does it mean/how > do > I fix it" - although what is actually useful is usually the

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> On Jun 7, 2019, at 7:24 PM, Kurt Roeckx wrote: > > That's all very nice, but nobody is going to run that. They also don't have to upgrade their kernel, or deploy new versions of OpenSSL. If platform release engineers don't deploy core services that ensure reliably CSPRNG seeding, then their

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

On Sat, Jun 08, 2019 at 12:54:36AM +0200, Kurt Roeckx wrote: > On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote: > > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote: > > > > > > For older kernels you install rng-tools that feeds the hwrng in > >

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote: > > For older kernels you install rng-tools that feeds the hwrng in > the kernel. Which works for me, and is pretty much the point I'm trying to make. Then, read /dev/random once early at boot, and do nothing special libcrypto (safely use

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> On Jun 7, 2019, at 2:41 PM, Kurt Roeckx wrote: > >> This is not the sort of thing to bolt into the kernel, but is not >> unreasonable for systemd and the like. > > The kernel actually already does this in recent versions, if > configured to do it. We're talking about what to do with for

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> On Jun 7, 2019, at 2:11 PM, Dr. Matthias St. Pierre > wrote: > >> The init system would >> need to create this kind of service, and then all software not using >> getentropy()/getrandom() would need to depend on that service. It > > FWIW: systemd already has a service for saving and

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

On Fri, Jun 07, 2019 at 11:09:45AM +0200, Matthias St. Pierre wrote: > See the discussion on openssl-users: > > https://mta.openssl.org/pipermail/openssl-users/2019-May/010585.html > https://mta.openssl.org/pipermail/openssl-users/2019-May/010593.html >

Re: No two reviewers from same company

On Thu, May 23, 2019 at 03:45:48PM +0100, Matt Caswell wrote: > IMO, no. I also don't see a need for this at present, and it is not clear that there are enough active part-time reviewers in place to keep up with commits from the fellows in a timely manner. -- Viktor.

Re: [openssl-project] inline functions

> On Jan 27, 2019, at 5:33 AM, Tim Hudson wrote: > > Tim - I think inline functions in public header files simply shouldn't be > present. I think they have their place, and we should try to make them more portable to less capable toolchains as needed. -- Viktor.

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

> 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

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

> On Jan 22, 2019, at 2:06 PM, Adam Langley wrote: > > (This is another installment of our experiences with deploying the > RFC-final TLS 1.3—previous messages: [1][2]. We share these with the > community to hopefully avoid other people hitting the same issues.) > > [...] > > However,

[openssl-project] Sanity check understanding of automatic module initialization?

With automatic library initialization in OpenSSL 1.1.0 and later, settings from the system-wide "openssl.cnf" file are automatically loaded and may in turn cause various "modules" to be initialized. For example, with: openssl.conf: openssl_conf= system-wide-modules #

Re: [openssl-project] Release scheduling

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] FYI: [postfix & TLS1.3 problems]

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]

> 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] FYI: [postfix & TLS1.3 problems]

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

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

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] Release strategy updates & other policies

> 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)

> 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] A proposal for an updated OpenSSL version scheme (v2)

> 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)

> 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)

> 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)

> 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] A proposal for an updated OpenSSL version scheme (v2)

> 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)

> 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)

> 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)

> 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)

> 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)

> 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)

> 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)

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] Release Criteria Update

> 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] Inappropriate fallback triggered when "holes" in client protocol list indirectly exclude TLSv1.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

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

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] Releases tomorrow

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.

[openssl-project] ABI change tracking

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] FW: Certificate fractional time processing in upcoming openssl releases

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

Re: [openssl-project] Removal of NULL checks

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] Removal of NULL checks

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

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

> 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

[openssl-project] EdDSA and "default_md"?

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

> 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

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

> 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

> 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

> 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

> 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] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

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] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

> 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)

> 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)

> 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)

> 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] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

> 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] Is Mac a supported platform?

> 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-project] Some failing builds in travis?

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] build/test before merging

> 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] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test

> 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

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

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

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

> 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] Potentially bad news on TLS 1.3 compatibility (sans SNI)

> 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)

> 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)

> 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)

> 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] Potentially bad news on TLS 1.3 compatibility (sans SNI)

> 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)

> 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)

> 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] The problem of (implicit) relinking and changed behaviour

> 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] Potentially bad news on TLS 1.3 compatibility (sans SNI)

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

[openssl-project] TLS 1.3 and SNI

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

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

> 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

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

> 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

> 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

> 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] The problem of (implicit) relinking and changed behaviour

> 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

> 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

> 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

> 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

> 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] Speeding up the fuzz test...

> 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] Applying system defaults to TLS config

> 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] Removing assembler for outdated algorithms

> 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

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

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...

  1   2   >