From paul.dale at oracle.com  Thu Aug  1 04:27:19 2019
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Thu, 1 Aug 2019 14:27:19 +1000
Subject: Thread sanitiser problems
In-Reply-To: <F38A1886-4589-41E1-80ED-AF9A263B29CC@dukhovni.org>
References: <400D9C61-D01C-4FF5-A472-46D3AC189731@oracle.com>
 <20190730095938.GA7075@roeckx.be>
 <891d4fea-749c-d896-6af5-c5e363cb196c@ncp-e.com>
 <20190730104344.GA9041@roeckx.be>
 <69cb9f0b-b1b6-8c7f-49ff-1ced2c9d7139@ncp-e.com>
 <855d4517-e226-f6b5-9f4f-f13689f53941@ncp-e.com>
 <A16A4CE9-B1AA-4FF7-8772-F97EE5E114C8@oracle.com>
 <F38A1886-4589-41E1-80ED-AF9A263B29CC@dukhovni.org>
Message-ID: <D282EB53-5B25-4457-BA2C-3656FF40E8BC@oracle.com>

The locks aren?t being held for long.

I have noticed that the lock in the OPENSSL_CTX only seems to be locked for reading and only in one place.  crypto/context.c in openssl_ctx_get_data().  Writes seem to go via CRYPTO_alloc_ex_data() which uses a global write lock (on a different lock).  Would it be feasible to drop the OPENSSL_CTX lock completely?  This would address the issue.  Matt?  I think you know this code the best.

CRYPTO_alloc_ex_data() is calling the new_func pointer under the read lock and the new function can in turn cause a search of the providers for implementations which grabs the provider lock.  Conversely, searching the providers for implementations grabs the provider lock and can lead to openssl_ctx_get_data() grabbing the context lock.

We don?t appear to have recursion at the moment, but the setup seems a little fragile.  We do have two different ordering for grabbing locks which is also bad.


Pauli
-- 
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia



> On 31 Jul 2019, at 2:10 pm, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
>> On Jul 30, 2019, at 10:02 PM, Dr Paul Dale <paul.dale at oracle.com> 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 done.
> 
> My take is that we should never hold any lock long enough to even consider
> acquiring another lock.  No more than one lock should be held at any one
> time, and only long enough to bump a reference count to ensure that the
> object of interest is no deallocated before we (or our caller in a "get1"
> type interface) is done with it.
> 
> I don't know what "long-term" locks we're holding, but it would be great
> if it were possible to never (or never recursively) hold any such locks.
> 
> -- 
> 	Viktor.
> 


From beldmit at gmail.com  Sun Aug  4 14:08:39 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Sun, 4 Aug 2019 17:08:39 +0300
Subject: punycode licensing
In-Reply-To: <CAHEJ-S7dFrevrWPuV0d52m_i4KQAFHa_rwNgsfkC6r6JJttX=w@mail.gmail.com>
References: <0f19ead7-c5c8-f88a-4e23-0c2bc34eac00@openssl.org>
 <20190620162738.GP84864@straasha.imrryr.org>
 <20190621015945.GL52381@kduck.mit.edu>
 <06550780-9407-4F44-AFD9-E0B28C89B9F5@oracle.com>
 <CAHEJ-S4sxk0=tkKbpZ2urL9et31MDm=unobggsdAYnBMYkDSfQ@mail.gmail.com>
 <CAHEJ-S7Stabb5==KNhtGG_p+-z0acHCCtp5zjn6FK5J3b4e3hQ@mail.gmail.com>
 <17AC4003-CF6D-46AF-942B-438C61EB6FA9@akamai.com>
 <CAHEJ-S7yF5ofV8-qYoPHFkX8u5bVSoxPWD8zPcwhCHsS4dEjAg@mail.gmail.com>
 <CA1DC37B-F02D-4B4C-B7F9-5D572930CE73@akamai.com>
 <CAHEJ-S50AiWVAyWhH47Ei3REjffsFoHLq=w-5G9p7BsqE+Xw0A@mail.gmail.com>
 <CADqLbzLHto50Wfuz=sth0NCXB4qVzGhXVG3j5_E1MPV9x5bw+Q@mail.gmail.com>
 <CAHEJ-S7dFrevrWPuV0d52m_i4KQAFHa_rwNgsfkC6r6JJttX=w@mail.gmail.com>
Message-ID: <CADqLbzLhE1aVx981bkwcD94QVavo4ohGDPsTPHgA9TBAhucqJw@mail.gmail.com>

Dear Tim,

Sorry for the delay with the response.

On Thu, Jul 11, 2019 at 2:44 AM Tim Hudson <tjh at cryptsoft.com> wrote:

> On Thu, Jul 11, 2019 at 12:37 AM Dmitry Belyavsky <beldmit at gmail.com>
> wrote:
>
>> Dear Tim,
>>
>> Formally I am a contributor with a signed CLA.
>> I took a code definitely permitting any usage without any feedback,
>> slightly modified it (at least by openssl-format-source and splitting
>> between header and source), and submitted it as my feedback to OpenSSL.
>>
>> I still think that it will be a good idea if Adam signs the CLA, but if
>> he declines, we still have a correct interpretation.
>>
>
> In your ICLA it contains the instructions you have to follow (reproduced
> here to save you time):
>
> 7. Should You wish to submit work that is not Your original creation, You
> may submit it to the Foundation separately from any Contribution,
> identifying the complete details of its source and of any license or other
> restriction (including, but not limited to, related patents, trademarks,
> and license agreements) of which you are personally aware, and
> conspicuously marking the work as "Submitted on behalf of a third-party:
> [named here]".
>
>
> Your current PR at https://github.com/openssl/openssl/pull/9199  does not
> actually do this - basically you have to have punycode.c, punycode.h in a
> separate submission not intermixed with anything else.
>
> The reason for not intermixing the code should be pretty clear - as we
> need to know which parts belong to someone else and aren't covered by your
> ICLA and which parts are - with no possibility of confusion.
>
> You would also need to include the *license* that those files are under
> which you have not done so - which according to the RFC is:
>
>     Regarding this entire document or any portion of it (including
>     the pseudocode and C code), the author makes no guarantees and
>     is not responsible for any damage resulting from its use.  The
>     author grants irrevocable permission to anyone to use, modify,
>     and distribute it in any way that does not diminish the rights
>     of anyone else to use, modify, and distribute it, provided that
>     redistributed derivative works do not contain misleading author or
>     version information.  Derivative works need not be licensed under
>     similar terms.
>
> Separately, Rich Salz indicated he had email from the author with respect to being willing to license under the Apache License 2.0 which you would need to get directly from the author (or Rich would need to be the submitter). Only the author (actually copyright owner) can change the license terms of code they create. This isn't about the license.
>
> You really should reach out to the author to ask if he is willing to sign an ICLA - that is the normal steps involved.
> There is nothing particularly onerous in the ICLAs - they are basically there to provide certainty and a legal background for the project to be able to provide the code that it does.
>
> You should also note that the license noted in the RFC misses many of the provisions within the ICLA and within the Apache License 2.0 itself and is incompatible with the Apache License 2.0 because it contains restrictions and conditions beyond those stated in this license.
>
> After all the work that the project did to be able to move to its current license (and a lot of that work was Rich Salz's efforts) it is important that we maintain the foundation of the clear license terms for the entire code base.
>
> Unfortunately, the author of the code did not respond to my letter in
which I asked him whether he agrees to sign the ICLA and close the
discussion.

Do I correctly understand that for now, the best solution is just
reimplementing the punycode encoding/decoding myself to avoid all the
conflicts?
It's a solution I do not like, but if OMC insists, I will do it.

Thank you!

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190804/668e0038/attachment-0001.html>

From mark at awe.com  Tue Aug  6 08:10:00 2019
From: mark at awe.com (Mark J Cox)
Date: Tue, 6 Aug 2019 09:10:00 +0100
Subject: Planning a face to face committers meeting
Message-ID: <CABU6YObfpPnrrBnDuaT0dJngrMU5Sy9B_T6Agr+RQh1VLtYZXQ@mail.gmail.com>

We're planning a face to face two day committers meeting in October 2019.
If you're an OpenSSL committer you should have received an email from me
with the dates and locations we are considering.... to get your likely
availability to help us choose the best location.  If you didn't get the
email let me know off list.

Regards, Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190806/f7f564db/attachment.html>

From matt at openssl.org  Wed Aug  7 14:38:51 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 7 Aug 2019 15:38:51 +0100
Subject: Monthly Status Report (July)
Message-ID: <6fd23ad9-11e7-425d-4733-f5527092e13c@openssl.org>

As well as normal reviews, responding to user queries, wiki user
requests, OMC business, handling security reports, etc., key activities
this month:

- Continued work leading to an eventual merge of the PR to bring PKCS#3 DH
handling into the default provider
- Further work leading to an eventual merge of the PR enabling BIGNUM rand
functions to be usable from the FIPS provider
- Implemented PR to stop RUN_ONCE from being used inside the FIPS provider (to
avoid its accidental use)
- Fixed some BIGNUM issues that were failing in the FIPS provider
- Implemented PR to make the EC code available from inside the FIPS provider
- Fixed the return value for SSL_get0_chain_certs()
- Fixed no-dh
- Corrected an Extended Master Secret bug on EBCDIC systems
- Significant review work on the CMP PR
- Cleaned up the core <-> provider interface by removing some unnecessary
utility functions
- Created PR to fix a problem with SSL_check_chain() so that it works correctly
with TLSv1.3 (not merged yet)
- Add documentation for the provider DIGEST operation
- Created PR to clarify the INSTALL document
- Add documentation for the provider CIPHER operation
- Created PR to load the config file by default


Matt

From levitte at openssl.org  Wed Aug 14 14:16:09 2019
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 14 Aug 2019 16:16:09 +0200
Subject: Late Monthly Status Report (April 2019)
Message-ID: <87sgq3g7di.wl-levitte@openssl.org>

Apart from normal business, such as normal reviews, OMC business,
normal system administration tasks, etc., key activities this month:

* Development

  - Restore the "heartbeats" configuration option in Configure among
    the deprecated
    (PR openssl/openssl#8632)
  - Made it possible to check module availability and to disable
    module building
    (PRs openssl/openssl#8623, openssl/openssl#8665)
  - Added a provider configuration module
    (PR openssl/openssl#8549)
  - Renamed the PROVIDER_CONF and ENGINE_CONF trace classes to CONF
    (PR openssl/openssl#8680)
  - Added EVP_set_default_properties() to set global properties and a
    corresponding configuration command
    (PR openssl/openssl#8681)
  - Changed the params API to require sizes for {utf8,octet}_ptr
    (PR openssl/openssl#8703)
  - Fixed the generic EVP algorithm fetch to actually cache them
    (PR openssl/openssl#8781)
  - Reworked the processing of %user and %useradd in Configure so they
    are merged into %config earlier, and make disabling stuff easier
    and safer
    (PR openssl/openssl#8812)
  - Added the possibility to display and use MODULESDIR
    (PR openssl/openssl#8709)
  - Added a new function OPENSSL_info() as a way for application to
    get built-in OpenSSL data, as well as a corresponding command
    'openssl info' for scripting purposes
    (PR openssl/openssl#8709)
  - Made Configure recognise clang -fsanitize options and translate
    them to our disabling options
    (PR openssl/openssl#8778)
  - Configure: process shared-info.pl later
    (PR openssl/openssl#8846)
  - Made the oneshot proider cipher function like the others
    (PR openssl/openssl#8849)
  - Gave the possibility for the provider to create a context
    (PR openssl/openssl#8848)
  - Submitted and kept working on previous work to switch apps to use
    OSSL_STORE to find certs, keys and CRLs
    (PR openssl/openssl#7390)
  - [unpublished] Continued work on flexible installation commands for
    Makefiles
  - [1.1.1 only] Reworked DSO API conditions and configuration option
    (PR openssl/openssl#8622)

* System administration

  - Worked on our bind configuration for better templating of repeated
    data.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Wed Aug 14 14:17:57 2019
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 14 Aug 2019 16:17:57 +0200
Subject: Late Monthly Status Report (May 2019)
Message-ID: <87r25ng7ai.wl-levitte@openssl.org>

Apart from normal business, such as normal reviews, OMC business,
normal system administration tasks, etc., key activities this month:

* Development

  - [not yet merged] Created a FIPS module checksum script and
    modified the Makefile rules to use it
    (PR openssl/openssl#8871)
  - [not yet merged] Started work to move all MAC implementations to
    the providers
    (PR openssl/openssl#8877)
  - Created internal dynamic id number<->name mapping API, to replace
    the legacy NID<->name database, and made the generic EVP fetching
    mechanism use it
    (PR openssl/openssl#8878)
  - [not yet merged] Added a .pragma directive for configuration files
    and added a pragma that allows '$' to be considered a symbol
    character unless followed by a brace.
    (PR openssl/openssl#8882)
  - [not yet merged] Modify the VMS entropy gathering unit to use the
    upcoming system servive SYS$GET_ENTROPY
    (PR openssl/openssl#8926)
  - [not yet merged] Added new X509_LOOKUP method that works with
    OSSL_STORE and a new command line options -CAstore that takes an
    OSSL_STORE URI
    (PR openssl/openssl#8442)
  - [not yet merged] Modified the internal dynamic id number<->name
    map to handle multiple names for the same id number
    (PR openssl/openssl#8967)
  - [not yet merged] Provided a couple of alternatives for populating
    the internal dynamic id number<->name map with aliases
    (PR openssl/openssl#8984 pre-populates the map with hard-coded
    aliases within the EVP sub-system)
    (PR openssl/openssl#8985 makes it possible for providers to
    provide aliases)
  - Attended the OMC f2f in Vancouver
  - Attended the ICMC conference in Vancouver
  - Clarified the requirements for X509_LOOKUP methods as to what side
    effects are expected when looking up diverse objects
    (PR openssl/openssl#8755)
  - Join the x509 and x509v3 directories
    (PR openssl/openssl#8925)
  - Constify OSSL_PROVIDER getter input parameters
    (PR openssl/openssl#9054)
  - Released OpenSSL 1.1.1c, 1.1.0k and 1.0.2s
  - Backport making make C++ build tests optional and configurable to
    1.1.1
    (PRs openssl/openssl#8370 and openssl/openssl#9016)

* Internal

  - Recorded a number of committers that accepted their invitations
    while in Vancouver

* System administration

  - Worked on our Apache configs to remove some kinks

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Wed Aug 14 14:18:32 2019
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 14 Aug 2019 16:18:32 +0200
Subject: Late Monthly Status Report (June 2019)
Message-ID: <87pnl7g79j.wl-levitte@openssl.org>

Apart from normal business, such as normal reviews, OMC business,
normal system administration tasks, etc., key activities this month:

* Development

  - [not yet merged] Moved BLAKE2 and MD5_SHA1 digests completely to
    default provider
    (PRs openssl/openssl#9075 and openssl/openssl#9076)
  - [not yet merged] Continued work to move all MAC implementations to
    the providers
    (PR openssl/openssl#8877)
  - For EVP fetching, made operation_id part of the method identity
    (PR openssl/openssl#9109)
  - Added support for variables in build.info files and used them
    where it's worth the while
    (PR openssl/openssl#9144)
  - Added a core upcall to get the provider object's library context,
    adapted all our providers to use it
    (PR openssl/openssl#9160)
  - Allowed build.info conditions and variable values to have variable
    references, and using that, moved all the asm and aux source specs
    to the build.info files
    (PR openssl/openssl#9166)
  - Added tracing capability in test utilities
    (PR openssl/openssl#9191)
  - Enhanced and update the docs of the internal ossl_provider API
    (PR openssl/openssl#9200)
  - [merged] Added support for multiple names per algorithm
    (PR openssl/openssl#8967)
  - [1.1.1 only] Backported the modification to only output DER with
    SPKAC input and when -out is chosen
    (PR openssl/openssl#8368)

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Wed Aug 14 14:19:09 2019
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 14 Aug 2019 16:19:09 +0200
Subject: Monthly Status Report (July 2019)
Message-ID: <87o90rg78i.wl-levitte@openssl.org>

Apart from normal business, such as normal reviews, OMC business,
normal system administration tasks, etc., key activities this month:

* Development

  - Re-implemente error reporting for providers and adapted the FIPS
    module.
    (PR openssl/openssl#9174)
  - Adapted provider cipher implementations to give back diverse
    parameters in form of OSSL_PARAM instead of specialized functions.
    (PR openssl/openssl#9328)
  - Corrected some OSSL_PARAM documentation
    (PR openssl/openssl#9408)
  - Enable the use of Dl_info and dladdr() on Cygwin
    (PR openssl/openssl#9402)
  - Added basic EVP_KEYMGMT API and libcrypto <-> provider interface,
    and an export/import mechanism in the EVP sub-system to allow keys
    to be passed between providers, insofar that the providers allow it.
    (PR openssl/openssl#9312)
  - Added documentation to describe providers and the libcrypto <->
    provider interface, provider(7), and provider-base(7) that
    describing the base functions
    (PR openssl/openssl#9409)
  - Added documentation of the KEYMGMT interface, provider-keymgmt(7)
    (PR openssl/openssl#9429)
  - Re-implemented the cipher and digest listings for 'openssl list'
    to be able to display implementations by providers alongside the
    legacy built in one.  This included reworking the functionality to
    walk through all available implemented algorithms, and diverse
    added EVP information functionality.
    (PR openssl/openssl#9356)
  - Documented OSSL_PARAM as a parameter descriptor, and replaced all
    uses of OSSL_ITEM with OSSL_PARAM as parameter descriptor,
    everywhere
    (PR openssl/openssl#9346)
  - [draft] Started work on adapting OSSL_STORE for providers
    (PR openssl/openssl#9389)
  - [not yet merged] Started the same work I did for ciphers (PR
    9328), but for hash implementations
    (PR openssl/openssl#9391)
  - Adapted DH to use with KEYMGMT
    (PR openssl/openssl#9394)
  - Added functions to see if a provider is available for use, and
    modify test/evp_test.c to check if the legacy provider is
    available for the algorithms that are implemented there.
    (PR openssl/openssl#9398)
  - [1.1.1 and 1.1.0] CVE-2019-1552 Fixed mingw installation paths
    (PRs openssl/openssl#9400 and openssl/openssl#9460)
  - [1.0.2 only] CVE-2019-1552 Document issues with default
    installation path
    (PR openssl/openssl#9456)
  - Implemented ERR_raise() and ERR_raise_data() for more flexible
    error reporting, and refactored all the XXXerr() macros to use
    them.  Also refactored the provider error reporting support and
    adapted the FIPS provider to use the new functionality.
    (PR openssl/openssl#9452)
  - [not yet merged] Continued work to move all MAC implementations to
    the providers
    (PR openssl/openssl#8877)

* Web

  - CVE-2019-1552 Added security advisory
    (PR openssl/web#134)

* System administration

  - Added CAA records for our main domains
  - Moved our VMs to larger space by creating a LLVM volume for them
    on an unused partition, moving them there, then added the old
    partition to that volume.

* Internal

  - Better logging of gitolite triggers

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From tshort at akamai.com  Fri Aug 16 14:08:10 2019
From: tshort at akamai.com (Short, Todd)
Date: Fri, 16 Aug 2019 14:08:10 +0000
Subject: Upcoming releases?
Message-ID: <4EDCD11F-2A02-4E75-8EA7-5554E896F4AB@akamai.com>

Hi openssl-project:

Given the typical release cadence and the imminent demise of 1.1.0, will there be another set bug fix releases (i.e. a final 1.1.0 release with friends)?

Thanks,

--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, threeif by the Internet."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190816/b97fc190/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2991 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190816/b97fc190/attachment-0001.bin>

From jayashankara5.drs at gmail.com  Mon Aug 19 11:37:04 2019
From: jayashankara5.drs at gmail.com (Jayashankara DM)
Date: Mon, 19 Aug 2019 17:07:04 +0530
Subject: Planing to contribute to Openssl community
Message-ID: <CABVxiVxo0wOfS9C5cXaCYjWH7GPzS8hTEp3YpDC=yED7g+bPYw@mail.gmail.com>

Hi All,

This is Jayashankara D M , Newly joined to this community :)
I would like to contribute some thing to openssl community which i came
across while working on one of my project .

I am planing to build wrapper on top of openssl library to verify the X509
certificate.So that someone wants to verify there client/server certificate
can easy verify without knowing much internal details of openssl library.

Basically it's is library which can be used by any application which uses
SSL to verify the certificates.

As we now many application will have different security/certificate
requirements like life span of x509 certificate, domain-name, signature
algorithms being used and which revocation method used to check revocation
status of x509 certificate and many more.

I would like here you from your end if this looks fine or not.

Note: Let me know if there any case where i can contribute.


Thanks & Regards,
Jayashankara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190819/3bb0bfbc/attachment.html>

From kaduk at mit.edu  Tue Aug 27 16:41:45 2019
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Tue, 27 Aug 2019 11:41:45 -0500
Subject: will there be a final "wrap-up" 1.1.0l release?
Message-ID: <20190827164144.GZ84368@kduck.mit.edu>

Hi all,

I note that 1.1.0 goes EOL on 2019-09-11, and the current 1.1.0k release is
from the end of May.  On the normal 3-ish-month cycle for letter releases
(to "roll up" accumulated changes in the absence of a security release), we
would be having one soon.  Are there any plans to do a final letter release
to package up all the changes before 1.1.0 goes EOL?  (If we do, will there
also be "roll up" letter releases on the other branches?)

Thanks,

Ben

From matt at openssl.org  Tue Aug 27 16:53:58 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 27 Aug 2019 17:53:58 +0100
Subject: will there be a final "wrap-up" 1.1.0l release?
In-Reply-To: <20190827164144.GZ84368@kduck.mit.edu>
References: <20190827164144.GZ84368@kduck.mit.edu>
Message-ID: <354e373d-c3ed-3f56-ae6e-3e73afb86da3@openssl.org>



On 27/08/2019 17:41, Benjamin Kaduk wrote:
> Hi all,
> 
> I note that 1.1.0 goes EOL on 2019-09-11, and the current 1.1.0k release is
> from the end of May.  On the normal 3-ish-month cycle for letter releases
> (to "roll up" accumulated changes in the absence of a security release), we
> would be having one soon.  Are there any plans to do a final letter release
> to package up all the changes before 1.1.0 goes EOL?  (If we do, will there
> also be "roll up" letter releases on the other branches?)

Yes, we are due a release soon. Whether we will have a wrap up for 1.1.0 or not
is currently under discussion. My expectation is - yes.

Matt