Re: LTS+

2020-10-19 Thread Tomas Mraz
I wonder if something like adding a new entropy source on an existing platform especially on some that currently don't have adequate ones would be covered by this. ⁣Tomáš​ 19. 10. 2020 18:29, 18:29, Matt Caswell napsal/a: > > >On 19/10/2020 15:14, Matt Caswell wrote: >> LTS+ releases may

Re: VOTE: Weekly OTC meetings until 3.0 beta1 is released

2020-10-09 Thread Tomas Mraz
+1 On Fri, 2020-10-09 at 15:00 +0300, Nicola Tuveri wrote: > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 >and until 3.0 beta1 is released, in lieu of the weekly > "developer >meetings". > Proposed by Nicola Tuveri > Public: yes > opened: 2020-10-09 >

OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch

2020-10-09 Thread Tomas Mraz
topic: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch As the change is borderline on bug fix/behaviour change OTC needs to decide whether it is acceptable for 1.1.1 branch. Proposed by Tomas Mraz Public: yes opened: 2020-10

Re: Vote proposal: Technical items still to be done

2020-10-09 Thread Tomas Mraz
On Thu, 2020-10-08 at 12:00 +, Salz, Rich wrote: > >Of course the 3.0 release is kind of special because we are > > defining a > completely new API - the providers API - with the intention to > have it > stable for many years to come. Any bugs in the API design for > providers >

Re: VOTE: Technical Items still to be done

2020-10-08 Thread Tomas Mraz
+1 On Thu, 2020-10-08 at 15:47 +0100, Matt Caswell wrote: > topic: The following items are required prerequisites for the first > beta > release: > 1) EVP is the recommended API, it must be feature-complete compared > with > the functionality available using lower-level APIs. >- Anything

Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

2020-10-08 Thread Tomas Mraz
+1 On Thu, 2020-10-08 at 15:27 +0100, Matt Caswell wrote: > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality > as > shown in PR #13018 into the 3.0 release > Proposed by Matt Caswell > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X,

Re: Vote proposal: Technical items still to be done

2020-10-08 Thread Tomas Mraz
On Thu, 2020-10-08 at 09:47 +0100, Matt Caswell wrote: > > On 07/10/2020 19:07, Kurt Roeckx wrote: > > On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote: > > > The following items are required prerequisites for the first beta > > > release: > > [...] > > > * Address 3.0beta1

Re: Vote proposal: Technical items still to be done

2020-10-08 Thread Tomas Mraz
+1 to that. There is a reason why almost all the major projects switched over to doing time based releases instead of feature completeness based ones. Of course the 3.0 release is kind of special because we are defining a completely new API - the providers API - with the intention to have it

Re: Vote proposal: Technical items still to be done

2020-10-07 Thread Tomas Mraz
On Wed, 2020-10-07 at 12:35 +0100, Matt Caswell wrote: > I had an action from the OTC meeting today to raise a vote on the OTC > list of technical items still to be done. Here is my proposed vote > text. > There will be a subsequent vote on the "beta readiness checklist" > which > is a separate

Re: Tracking important issues

2020-10-05 Thread Tomas Mraz
On Mon, 2020-10-05 at 10:00 +0100, Matt Caswell wrote: > > On 04/10/2020 15:22, Kurt Roeckx wrote: > > On Wed, Sep 23, 2020 at 08:51:28PM +0200, Kurt Roeckx wrote: > > > Hi, > > > > > > I would like to have a system so that we can tag issues as > > > important. But I think they fall in a few

Re: VOTE: OTC meeting will be called for next Tuesday

2020-09-30 Thread Tomas Mraz
+1 On Wed, 2020-09-30 at 13:57 +, Dr. Matthias St. Pierre wrote: > The following vote has been proposed and voted on at the vF2F today: > > topic: OTC meeting will be called for next Tuesday > > It has been closed immediately by Tim, the verdict is > > accepted: yes (for: 7,

Re: Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ?

2020-09-30 Thread Tomas Mraz
Hello, unfortunately no, 1.1.1g is neither API nor ABI compatible with 1.0.2f. You cannot directly replace 1.0.2f with 1.1.1g. The applications have to support 1.1.1 release and be recompiled against it to work with it. Regards, Tomas Mraz On Tue, 2020-09-22 at 14:08 +, Kapil Awate wrote

Re: Status of the remaining beta1 PRs

2020-09-18 Thread Tomas Mraz
On Fri, 2020-09-18 at 16:24 +0100, Matt Caswell wrote: > > 1 PR which is in a state of "its unclear what we do with this": > [WIP] Rename some XXX_ex() related methods to XXX_with_libctx() > https://github.com/openssl/openssl/pull/12701 > With no agreement on a naming convention its unclear if

Re: 3.0 beta 1 milestone

2020-09-18 Thread Tomas Mraz
On Fri, 2020-09-18 at 09:26 +0200, Richard Levitte wrote: > On Thu, 17 Sep 2020 15:57:52 +0200, > Tomas Mraz wrote: > > I do not think the milestone should include nice-to-have items. > > Another view is that beta 1 is feature freeze. If those nice to have > items are

Re: 3.0 beta 1 milestone

2020-09-17 Thread Tomas Mraz
On Thu, 2020-09-17 at 13:48 +0100, Matt Caswell wrote: > There's been quite a number of PRs added to the 3.0 beta 1 milestone. > > Within the PRs there are a couple of bug fixes: > > https://github.com/openssl/openssl/pull/12884 > https://github.com/openssl/openssl/pull/12874 > > IMO these

Re: Reordering new API's that have a libctx, propq

2020-09-09 Thread Tomas Mraz
On Wed, 2020-09-09 at 22:29 +1000, Dr Paul Dale wrote: > > On 9 Sep 2020, at 9:38 pm, Tomas Mraz wrote: > > > > We could even provide a convenience thread local stack of lib > > contexts > > so the caller would not have to keep the old value but would just &g

Re: Reordering new API's that have a libctx, propq

2020-09-09 Thread Tomas Mraz
On Wed, 2020-09-09 at 11:41 +0200, Richard Levitte wrote: > > Regarding the library context, when viewed as a global state, it > makes > sense to have it as a first argument where it's being passed, if at > all. The question is, where should we actually pass it? We have a > few different

Re: RAND_DRBG

2020-07-27 Thread Tomas Mraz
+1 for the removal ⁣Tomáš​ 27. 7. 2020 4:58, 4:58, SHANE LONTIS napsal/a: > >i.e. Choose option (1) > >> On 27 Jul 2020, at 11:14 am, SHANE LONTIS >wrote: >> >> If this is not going to break 99% of users + it improves the >interface + the replacement to achieve the same is a few lines of code

Re: API renaming

2020-07-27 Thread Tomas Mraz
It was backported to Fedora and RHEL openssl packages. But of course that's our problem and is not a blocker for the rename. On the other hand KDFs and MACs being a class of algorithms similarly to ciphers and digests gives some argument why to keep the EVP prefix. ⁣Tomáš​ ⁣Tomáš​ 24. 7.

Re: My vacation

2020-07-23 Thread Tomas Mraz
On Thu, 2020-07-23 at 10:35 +0300, Dmitry Belyavsky wrote: > Hello, > > I go on my vacation from July 24 to August 5. On vacation, my > internet access is very limited. > If you have smth urgent, please let me know via direct email. > Same here. I will be on vacation from July 24th to August

Re: Backports to 1.1.1 and what is allowed

2020-06-25 Thread Tomas Mraz
On Thu, 2020-06-25 at 14:49 +, Dr. Matthias St. Pierre wrote: > Since already a few backporting requests to 1.1.1 have accumulated > which are controversial > or not allowed for an LTS release, would it make sense to consider > creating a new 1.1.2 STS > branch which could then receive such

Re: Backports to 1.1.1 and what is allowed

2020-06-22 Thread Tomas Mraz
On Sun, 2020-06-21 at 14:34 -0700, Benjamin Kaduk wrote: > Hi Tim, > > On Sat, Jun 20, 2020 at 10:11:04AM +1000, Tim Hudson wrote: > > I suggest everyone takes a read through > > https://en.wikipedia.org/wiki/Long-term_support as to what LTS is > > actually > > meant to be focused on. > > You

Re: Naming conventions

2020-06-19 Thread Tomas Mraz
On Fri, 2020-06-19 at 01:48 +1000, Tim Hudson wrote: > We have a convention that we mostly follow. Adding new stuff with > variations in the convention offers no benefit without also adjusting > the rest of the API. Inconsistencies really do not assist any > developer. > > Where APIs have been

Travis jobs not getting started

2020-06-05 Thread Tomas Mraz
Apparently the travis jobs are not getting started anymore for some reason. It happened to me on the GitHub linux-pam project and the solution (or workaround) was to migrate the project to the travis-ci.com. I just did it by following the instructions in this document:

Re: Reducing the security bits for MD5 and SHA1 in TLS - OTC or OMC vote?

2020-05-27 Thread Tomas Mraz
On Wed, 2020-05-27 at 14:16 +, Dr. Matthias St. Pierre wrote: > > IMO it seems appropriate to have an OMC vote on this topic (or > > should it > > be OTC?). Possible wording: > > Personally, I would prefer if technical questions would by default be > discussed (and voted on) > by the OTC,

Re: Reducing the security bits for MD5 and SHA1 in TLS

2020-05-27 Thread Tomas Mraz
On Wed, 2020-05-27 at 12:14 +0100, Matt Caswell wrote: > PR 10787 proposed to reduce the number of security bits for MD5 and > SHA1 > in TLS (master branch only, i.e. OpenSSL 3.0): > > https://github.com/openssl/openssl/pull/10787 > > This would have the impact of meaning that TLS < 1.2 would

Re: Unexpected EOF handling

2020-05-11 Thread Tomas Mraz
On Fri, 2020-05-08 at 12:09 +0200, Kurt Roeckx wrote: > On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote: > > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > > > So I think we need at least to

Re: Unexpected EOF handling

2020-05-07 Thread Tomas Mraz
On Thu, 2020-05-07 at 15:45 +0200, Kurt Roeckx wrote: > On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote: > > Actually the coincidence is that the errno is set to 0 on EOF. So > > yes, > > we should explicitly clear the errno on EOF so any leftover value > > f

Re: Unexpected EOF handling

2020-05-07 Thread Tomas Mraz
On Thu, 2020-05-07 at 14:53 +0200, Kurt Roeckx wrote: > On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote: > > From application developer side of view for protocols that do not > > depend on SSL detecting the truncation I think inventing a > > different > >

Re: Unexpected EOF handling

2020-05-07 Thread Tomas Mraz
On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > So I think we need at least to agree on: > > - Do we want an option that makes the unexpected EOF either a fatal > > error or a non-fatal error? > > - Which error should we return? > > This

Re: Unexpected EOF handling

2020-05-07 Thread Tomas Mraz
On Thu, 2020-05-07 at 13:22 +0200, Kurt Roeckx wrote: > Hi, > > We introduced a change in the 1.1.1e release that changed how we > handled an unexpected EOF. This broke various software which > resulted in the release of 1.1.1f that reverted that change. > In master we still have the 1.1.1e

Re: Technically an API break

2020-05-07 Thread Tomas Mraz
On Thu, 2020-05-07 at 09:24 +0100, Matt Caswell wrote: > PR11589 makes a change to the public API function > `SSL_set_record_padding_callback` to change its return type from void > to > int: > > https://github.com/openssl/openssl/pull/11589 > > This is technically an API break - but it doesn't

Re: Cherry-pick proposal

2020-04-29 Thread Tomas Mraz
That we do not run CI explicitly before such cherry picks does not mean that there is no CI run at all. The CI is triggered when the cherry- picked commit is merged. If we were checking the status of the 1.1.1 branch CI runs periodically (with a bot sending e-mails about failures to

Re: 1.1.1f

2020-03-26 Thread Tomas Mraz
On Thu, 2020-03-26 at 14:14 +, Matt Caswell wrote: > The EOF issue (https://github.com/openssl/openssl/issues/11378) has > resulted in us reverting the original EOF change in the 1.1.1 branch > (https://github.com/openssl/openssl/pull/11400). > > Given that this seems to have broken quite a

Re: Should FIPS_mode() and FIPS_mode_set() be updated, deprecated, or completely removed..

2020-03-04 Thread Tomas Mraz
On Wed, 2020-03-04 at 10:18 +, Matt Caswell wrote: > > On 04/03/2020 08:15, Tomas Mraz wrote: > > The current implementation in the PR - unconditionally returning > > error > > - is completely useless. It would make some (not much) sense if we > > aimed for ABI

Re: Should FIPS_mode() and FIPS_mode_set() be updated, deprecated, or completely removed..

2020-03-04 Thread Tomas Mraz
On Wed, 2020-03-04 at 13:47 +1000, SHANE LONTIS wrote: > FIPS_mode() and FIPS_mode_set() are functions that were used by the > old FOM. > > In OpenSSL_111 they were stripped down to do almost nothing > i.e:- > > int FIPS_mode(void) > { > /* This version of the library does not

Re: OpenSSL Logo

2020-02-27 Thread Tomas Mraz
On Thu, 2020-02-27 at 11:28 +0100, Matthias St. Pierre wrote: > Thank you for the clarification, Mark. > > So this means we have some artistic freedom in choosing the logo? > > Personally, I'm not sure whether we really should aim at restoring > the historic logo. IMHO this ornate font with 3D

Re: OpenSSL Logo (was: New GitHub Project Landing Page)

2020-02-27 Thread Tomas Mraz
On Thu, 2020-02-27 at 10:31 +0100, Matthias St. Pierre wrote: > > The openssl.svg was chosen to match the current logo at > > https://www.openssl.org/ > > as close as possible. According to the style sheet, the font of the > logo > is HelveticaNeue-Light. > >

Re: New GitHub Project Landing Page

2020-02-26 Thread Tomas Mraz
Could you, please, send me the .ai file? I'll try converting it. Is the font freely available? Tomas On Thu, 2020-02-27 at 14:17 +0800, Paul Yang wrote: > The logo could be changed to the 'correct-font' version -as the one > printed on the stickers I brought to Nuremberg > > I have an '.ai’

Re: Deprecation

2020-02-14 Thread Tomas Mraz
On Fri, 2020-02-14 at 16:17 +, Salz, Rich wrote: > I think we should delay the deprecation of engine stuff to 4.0. > Personally I don't have sense of stability of provider API. > > I share this concern. This is the first release of the provider > infrastructure, and while it will be known

Re: Deprecation

2020-02-13 Thread Tomas Mraz
On Fri, 2020-02-14 at 12:30 +1000, Dr Paul Dale wrote: > There is some pushback against the deprecations going on in various > PRs. > > The plan has always been to deprecate engines in 3.0 and removing > support for them 5+ years later. Originally, the path was to have > included an engine

Re: fips mode and key management

2020-01-21 Thread Tomas Mraz
I can only add +1 to what Matthias suggests. Although I know the meaning of the FIPS_MODE define, for a newcomer it is obviously not clear what the define really means. Tomas On Tue, 2020-01-21 at 13:31 +0100, Matthias St. Pierre wrote: > On 21.01.20 10:36, Richard Levitte wrote: > > I think

Re: crypt(3)

2020-01-17 Thread Tomas Mraz
On Fri, 2020-01-17 at 10:34 +, Matt Caswell wrote: > > On 17/01/2020 06:31, Dr Paul Dale wrote: > > 1. Leave them public and unchanged — that is, don’t deprecate > > these two > > functions yet. > > 2. Deprecate them and add KDFs to replace them. > > 3. Deprecate them, leave them alone

Re: crypt(3)

2020-01-17 Thread Tomas Mraz
On Fri, 2020-01-17 at 16:31 +1000, Dr Paul Dale wrote: > In the deprecation efforts for 3.0, I’ve hit something in the DES > code that I’d appreciate input on. > > There are two functions (DES_crypt and DES_fcrypt) which implement > the old crypt(3) password algorithm. Once these are deprecated,

Re: Check NULL pointers or not...

2019-11-29 Thread Tomas Mraz
The "always check for NULL pointers" approach does not avoid catastrophical errors in applications. For example let's say an application code encrypts some plaintext in-place and sends it out as encrypted. Let's say we check for the NULL EVP_CIPHER_CTX in EVP_CipherUpdate() but the app does not

Re: Check NULL pointers or not...

2019-11-28 Thread Tomas Mraz
On Thu, 2019-11-28 at 11:19 -0800, Benjamin Kaduk wrote: > On Wed, Nov 27, 2019 at 10:38:41AM +0100, Richard Levitte wrote: > > Depending on who you're asking, you get different responses. > > > > The topic is: should we check pointers coming from applications > > before > > using them or not? >

Re: Deprecation of stuff

2019-09-04 Thread Tomas Mraz
On Mon, 2019-09-02 at 08:38 +0200, Richard Levitte 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? Essentially,

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

2019-07-15 Thread Tomas Mraz
On Mon, 2019-07-15 at 16:25 +0200, Richard Levitte wrote: > On Mon, 15 Jul 2019 16:15:01 +0200, > Tomas Mraz wrote: > > So saying this is "just recompliation and configuration change" is > > at least somewhat oversimplified. > > > > But I am OK with t

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

2019-07-15 Thread Tomas Mraz
On Mon, 2019-07-15 at 14:48 +0100, Matt Caswell wrote: > > On 15/07/2019 14:43, Tomas Mraz wrote: > > On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote: > > > On 15/07/2019 13:58, Tomas Mraz wrote: > > > > > > > IMO this is a major

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

2019-07-15 Thread Tomas Mraz
On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote: > > On 15/07/2019 13:58, Tomas Mraz wrote: > > Hi everyone, > > > > if the Subject was already fully discussed and thought through then > > please disregard this but otherwise I'd like this e-mail to be a >

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

2019-07-15 Thread Tomas Mraz
Hi everyone, if the Subject was already fully discussed and thought through then please disregard this but otherwise I'd like this e-mail to be a starting point for discussion. I suppose the current intention is to make the legacy provider as opt- in only by either application explicitly loading

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Tomas Mraz
On Thu, 2019-06-13 at 19:34 +1000, Tim Hudson wrote: > On Thu, Jun 13, 2019 at 6:40 PM Salz, Rich wrote: > > The proper way to handle this, in my experience, is *DO NOT REUSE > > ERROR CODES.* > > No. This is a path to a rather unacceptable outcome. > Taking your example and running forward

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Tomas Mraz
On Fri, 2019-06-07 at 10:18 +0200, Tomas Mraz wrote: > On Fri, 2019-06-07 at 18:03 +1000, Dr Paul Dale wrote: > > > > Viktor replied: > > > > > I just want to make sure we don't lock ourselves in to a single > > > potentially clumsy solution in the

Re: No two reviewers from same company

2019-05-23 Thread Tomas Mraz
On Thu, 2019-05-23 at 17:17 +0200, Richard Levitte wrote: > On Thu, 23 May 2019 16:25:07 +0200, > Salz, Rich wrote: > > I understand that OpenSSL is changing things so that, by mechanism > > (and maybe by policy although > > it’s not published yet), two members of the same company cannot > >