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, against: 0, abstained: 0, not voted: 4)
> 
> (Note: the OTC meeting will be held in place of the weekly OpenSSL
> 3.0 Planning
> meeting next Tuesday (2020-10-06) at 08:00 UTC. Pauli will send out a
> separate
> invitation to the OTC list.)
> 
> Matthias
> 
> 
> topic: OTC meeting will be called for next Tuesday (2020-10-06)
> Proposed by Matthias St. Pierre
> Public: yes
> opened: 2020-09-30
> closed: 2020-09-30
> accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)
> 
>   Matt   [+1]
>   Mark   [  ]
>   Pauli  [+1]
>   Viktor [  ]
>   Tim[+1]
>   Richard[+1]
>   Shane  [+1]
>   Tomas  [  ]
>   Kurt   [  ]
>   Matthias   [+1]
>   Nicola [+1]
> 
> 
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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:
> Hi,
>  
> Is OpenSSL 1.1.1g backward compatible with 1.0.2.f ? Can anyone help
> me with this ? Is there any impact on existing functionality after
> upgrading it to 1.1.1g ?
>  
> Thanks!
>  
> This email and any attachments thereto may contain private,
> confidential, and/or privileged material for the sole use of the
> intended recipient. Any review, copying, or distribution of this
> email (or any attachments thereto) by others is strictly prohibited.
> If you are not the intended recipient, please contact the sender
> immediately and permanently delete the original and any copies of
> this email and any attachments thereto.
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 this should
> go
> ahead or not

We should do something consistent - either rename the _ex functions
that just add libctx (and property query) or rename the existing
with_libctx functions to _ex functions.

The current state is a mess having some functions with _ex and some
with _with_libctx.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 characterized as new features, then it makes sense to have
> them included in the beta 1 milestone if we want them for 3.0.0.
> Otherwise, we will have to put them on the waiting list for after
> 3.0.0.

Yes, but that effectively makes them either "must have in beta1" if we
decide that we want them in 3.0.0 or "not at all in beta1" if we decide
otherwise. As we are so close to beta1 now we should not have any
"let's see if they can make it" features for 3.0.0 anymore.

> If they are not characterized as new features, that is a different
> matter, of course.  The conclusion is that we will have to take some
> time (I assume that'll be quick in most cases) thinking how we
> characterize certain PRs before beta 1 is released.

Yes!

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 would be really nice to get into beta 1, but they should
> not
> be considered blockers for it (i.e. if they didn't go in, it
> shouldn't
> stop us from releasing beta 1).
> 
> There are also some nice-to-have items:
> 
> https://github.com/openssl/openssl/pull/12777
> https://github.com/openssl/openssl/pull/12771
> https://github.com/openssl/openssl/pull/12726
> https://github.com/openssl/openssl/pull/12669
> https://github.com/openssl/openssl/pull/12072
> 
> Again - these are nice-to-have, and if they happen to get merged in
> time
> for beta 1 then great. Otherwise, they should wait for 3.1 (possibly
> things which are just cleanup/minor refactoring could still be done
> within the beta period). So, IMO, these should not be considered
> blockers either.
> 
> So - this leads me to the question - what is the milestone for? Does
> it
> means these things *must* go in before we can release beta 1? Or does
> it
> mean we would *like* to get these things in for beta 1?
> 
> I actually don't mind either way - but if its the latter, then I need
> a
> way of identifying the "must haves". These are the top priority
> items,
> and at the moment I can't easily track their progress.

I do not think the milestone should include nice-to-have items.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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
> > push
> > the new libctx when entering and pop the old one when leaving. With
> > that, I think the changes needed in the application code would be
> > fairly simple and minimal.
> 
> Let’s not overcomplicate things.
> We went through this discussion back when this was introduced.
> 
> 
> Push is:
> OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx);
> 
> Pop is:
> OPENSSL_CTX_set0_default(prevctx)
> 
> 
> I don’t see having an explicit stack of these is of any benefit to
> anything but unwarranted complexity.

There is one thing where it would be IMO helpful - let's say libcurl
has a callback into a calling application. With the current API in
libcurl API calls you would put the
calls OPENSSL_CTX_set0_default(libctx)/OPENSSL_CTX_set0_default(prevctx
) at the beginning and end. But you would have to save the prevctx
somewhere in the libcurl context structure because on callbacks you
would have to temoprarily reset the context to the prevctx value. If we
implemented real stack it would not be needed. But yeah, I am not sure
this convenience is that much worth it.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 suggestions, in wording or in code, on the table:
> 
> 1.  Pass it as first argument everywhere.  This is problematic, as
> "everywhere" is a *lot*, and if we do this, we might as well
> re-design the whole libcrypto API [*], and that's definitely not
> what OpenSSL 3.0 is about, quite the contrary.
> 
> This has been partially done, with all the _with_libctx
> functions.  As far as I've understood, these have been added on
> need basis, i.e. somewhere down the code path, a library context
> or a property query string is needed.  I can't say if this gives
> any sense of completeness or consistency, viewed as an cohesive
> API, or if we stand any chance of getting there without a
> complete
> API re-design.
> 
> Something to be noted is that it doesn't make sense to pass the
> library context everywhere, because it's already part of other
> structures that are passed.  For example, any method structure,
> such as EVP_CIPHER, EVP_MD, etc are tied to a provider, which is
> in turn tied to a library context.  Passing another library
> context to anything that includes one of those method structures
> would only be confusing.
> 
> 2.  Pass it when constructing different structures, mostly other
> context structures.  As an example, EVP_PKEY_CTX_new_from_pkey()
> that I displayed above.  There may be cases where we need to pass
> it directly to functions that aren't constructors, but I expect
> those cases to be relatively few.
> 
> This has been done for some other structures as well, on an as
> needed basis:
> 
> X509 *X509_new_with_libctx(OPENSSL_CTX *libctx, const char
> *propq);
> 
> X509_STORE_CTX *X509_STORE_CTX_new_with_libctx(OPENSSL_CTX
> *libctx,
>const char
> *propq);
> 
> (the following are internal only)
> 
> int x509_set0_libctx(X509 *x, OPENSSL_CTX *libctx, const char
> *propq);
> int x509_crl_set0_libctx(X509_CRL *x, OPENSSL_CTX *libctx,
> const char *propq);
> 
> 3.  Set a current library context, a pointer in a thread local
> variable.  We already have support for that, which this function:
> 
> OPENSSL_CTX *OPENSSL_CTX_set0_default(OPENSSL_CTX *libctx);
> 
> The usage model is this:
> 
> OPENSSL_CTX *prevctx = OPENSSL_CTX_set0_default(libctx);
> 
> /* do stuff with |libctx| as implicit current global state */
> 
> OPENSSL_CTX_set0_default(prevctx)
> 
> Looking at that list now, I realise that it goes from most intrusive
> to least intrusive, viewed as a public API.
> 
> The third choice in particular would let any application or library
> just set their library context for the duration of the code that
> should be execute with that as a "global state", and restore it when
> done, leaving the rest of the OpenSSL calls untouched.

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 push
the new libctx when entering and pop the old one when leaving. With
that, I think the changes needed in the application code would be
fairly simple and minimal.

> Something to be noted is that model 2 and 3 is possible to combine,
> which could give us a smoother transition between the current API and
> whatever we design going forward.

Although I have big sympathy with people that worked hard to add the
various _with_libctx() calls I would say that keeping the new
with_libctx variants would be too confusing. Especially for the reason
we would not have a complete set of them anyway. The exception might be
the low level EVP calls where we deal with the libctx directly and
where the algorithm fetched is actually associated with the context.

> 
> 
> Regarding the property query string, looking at it separate from the
> library context, the question remains where to put it, and a few
> proposals are on the table:
> 
> 1.  Put it last.
> 
> 2.  Put it next to the algorithm name or the object that an algorithm
> name is inferred from.
> 
> 3.  Set it "globally" with a thread local variable, a bit like what
> OPENSSL_CTX_set0_default() does for library contexts.
> 
> For this model, it's been argued if it should simply be stored in
> the current library context, thereby avoiding to add another
> thread local variable (which, for all intents and purposes, is
> another actually global thing to deal with, even though on
> per-thread level).
> 
> In my mind, model 2 would be more sensible than model 1, because of
> the implied tie between algorithm name and property 

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
>and is likely to occur in one place in an app, then it seems reasonable
>to change it to me.
>>
>>
>>> On 27 Jul 2020, at 11:08 am, Dr Paul Dale > wrote:
>>>
>>> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and
>sit badly with the move to provider based infrastructure.
>>> They are definitely being deprecated in master but without more, the
>extra layer of indirection and additional complexity generating random
>numbers will remain.
>>>
>>> The option I see are:
>>>
>>> 1. Remove, rather than deprecate, RAND_DRBG in 3.0.  This is a
>breaking change.
>>> 2. Bypass RAND_DRBG and live with a breaking change (refer:
>https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828
>)
>>> 3. Leave things as they currently are in master.
>>>
>>> The first two are breaking changes and will require an OMC vote.
>>>
>>>
>>> Some pertinent points:
>>>
>>> 1. RAND_bytes will continue to work as is — this API is perfect for
>almost everyone.
>>> 2. The RAND_METHOD functionality remains — this allows wholesale
>replacement of OpenSSL’s RNGs if desired.
>>> 3. The name EVP_RAND is the working name and might change — this is
>not relevant to this discussion.
>>> 4. The RAND_DRBG APIs are unlikely to be widely used — they were
>introduced in 1.1.1.  The two users I know of (Akamai and NCP) are both
>fine with them being removed.
>>>
>>>
>>> Thoughts anyone?
>>>
>>>
>>> Pauli
>>> --
>>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
>>> Phone +61 7 3031 7217
>>> Oracle Australia
>>>
>>



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. 2020 9:46, 9:46, SHANE LONTIS  napsal/a:
>As @levitte pointed out - it was not back ported (not sure why I
>thought it was)
>
>> On 24 Jul 2020, at 5:40 pm, Dr. Matthias St. Pierre
> wrote:
>>
>> > I think the KDF and MAC got back ported also...
>>
>> In this case it would be no question that we should keep the names
>EVP_KDF and EVP_MAC.
>>
>>
>>   Dr. Matthias St.
>Pierre
>>
>> Senior Software Engineer
>> matthias.st.pie...@ncp-e.com 
>> Phone: +49 911 9968-0
>> www.ncp-e.com
>
>>
>> Follow us on: Facebook
>
>| Twitter
>
>| Xing
>
>| YouTube
>
>| LinkedIn
>
>>
>> Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 •
>90449 • Nuremberg
>> North American HQ: NCP engineering Inc. • 601 Cleveland Str., Suite
>501-25 • Clearwater, FL 33755
>>
>> Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate
>Dietrich
>> Registry Court: Lower District Court of Nuremberg
>> Commercial register No.: HRB 7786 Nuremberg, VAT identification No.:
>DE 133557619
>>
>> This e-mail message including any attachments is for the sole use of
>the intended recipient(s) and may contain privileged or confidential
>information. Any unauthorized review, use, disclosure or distribution
>is prohibited. If you are not the intended recipient, please
>immediately contact the sender by reply e-mail and delete the original
>message and destroy all copies thereof.
>>
>>



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 1st. I will
read only the personal e-mail address e-mails (tm at t8m.info)
occassionally.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 changes?

In my opinion that would open a can of worms. Such branch would
inevitably mean there will be request for the 1.1.2 release and I do
not think it would be a good idea to have it. It would seriously
stretch the team resources IMHO.

It would be much better to have the rules not tightened for 1.1.1 right
now (i.e. still allow for example the performance improvements and
support for newer hardware) and tighten them only after the 3.0 release
is final.

Still, I do not think allowing any truly new features other than the
performance and HW support on 1.1.1 is worth it.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 may have hit on a key aspect of how we are disconnected, here.
> 
> I was under the impression that (as is the case for many OSS
> projects), the
> fact that 1.1.1 is an LTS release means that we enter a separate "LTS
> mode"
> at the "beginning of a long-term support period" (as Wikipedia puts
> it) but
> that there is some period prior to the start of the long-term support
> period for which the STS policies apply.
> 
> So, are you considering that 1.1.1 is now, and has always been, in
> LTS mode
> because it is marked as an "LTS release"?  Or is there a separate STS
> period before it transitions to "LTS mode"?

In my opinion the 1.1.1 should not enter such strongly restricted phase
earlier than after the 3.0 is released.

Ideally, if we had releases based on some predictable cadence and not
rather feature based ones, we should have 3 active branches - master
for development of new features, one branch with bug fixes and even
non-invasive performance fixes, and one branch for LTS where only
security fixes with above than low severity and severe bug fixes would
be applied.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 added that don't follow the conventions they
> should be changed. 
> 
> It really is that simple - each developer may have a different set of
> personal preferences and if we simply allow any two people to pick
> their own API pattern effectively at whim we end up with a real mess
> over time.
> 
> This example is a clear cut case where we should fix the unnecessary
> variation in the pattern. It serves no benefit whatsoever to have
> such a mix of API patterns. 
> 
> We do have some variations that we should adjust - and for APIs that
> have been in official releases dropping in backwards compatibility
> macros is appropriate.
> 
> The argument that we aren't completely consistent is specious - it is
> saying because we have a few mistakes that have slipped through the
> cracks we have open season on API patterns. 
> 
> It also would not hurt to have an automated check of API deviations
> on commits to catch such things in future. 

The problem is that there is not really fully consistent convention
followed currently (even in 1.1.1, not counting the API additions in
3.0).

For example if we would like to follow the convention _fully_ we would
have to rename these new EVP_MAC functions:

int EVP_MAC_init(EVP_MAC_CTX *ctx);
  
int EVP_MAC_update(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen);
 
int EVP_MAC_final(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t 
outsize);

to something like:

int EVP_MacInit(EVP_MAC_CTX *ctx);
  
int EVP_MacUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen);
 
int EVP_MacFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t 
outsize);

or at least

int EVP_MACInit(EVP_MAC_CTX *ctx);
  
int EVP_MACUpdate(EVP_MAC_CTX *ctx, const unsigned char *data, size_t datalen);
 
int EVP_MACFinal(EVP_MAC_CTX *ctx, unsigned char *out, size_t *outl, size_t 
outsize);

Should we do that? I hope for the sheer ugliness of the supposedly
consistent names that we do not.

Fortunately or unfortunately depending on personal opinons we have
already diverged from that pattern with EVP_PKEY API.

And I actually hope we could add at least non-CamelCase aliases to the
existing (non-deprecated) CamelCase functions because they were always
the worst offender of the API consistency.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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:
https://docs.travis-ci.com/user/migrate/open-source-repository-migration/

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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, unless an OMC member explicitly puts in his veto and
> claims that higher level
> strategical interests of the OpenSSL project are affected.
> 
> But according to the current wording of the bylaws, I would say it is
> a 'feature requirement' and
> requires an OMC vote:

I do not understand this to be a 'feature requirement' - IMO if this
was a 'feature requirement' it would mean that OMC decides that
something must be implemented in such and such way that the OpenSSL 3.0
does this and that as a feature. But we do not do that for every
feature that is being added to master. So I do not even think this
requires any formal vote, unless someone from OTC or OMC calls for it
explicitly.

Of course it is kind-of API break but again I do not think every API
break in OpenSSL 3.0 was voted upon by OMC.

I mean I am definitely not against having a vote if someone feels it
should be done but if nobody requires it, I do not think it would be a
violation of anything if this is merged without a vote.

> > The OMC:
> > 
> > * makes all decisions regarding management and strategic direction
> > of the project; including:
> > - business requirements;
> > - feature requirements;
> > - platform requirements;
> > - roadmap requirements and priority;
> > - end-of-life decisions;
> > - release timing and requirement decisions;
> 
> Matthias
> 
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 not be
> available in the default security level of 1. You would have to set
> the
> security level to 0.
> 
> In my mind this feels like the right thing to do. The security bit
> calculations should reflect reality, and if that means that TLS < 1.2
> no
> longer meets the policy for security level 1, then that is just the
> security level doing its job. However this *is* a significant
> breaking
> change and worthy of discussion. Since OpenSSL 3.0 is a major release
> it
> seems that now is the right time to make such changes.
> 
> IMO it seems appropriate to have an OMC vote on this topic (or should
> it
> be OTC?). Possible wording:
> 
> "The TLS security bit values for MD5, MD5_SHA1 and SHA1 should be set
> to
> 39, 67 and 65 respectively in OpenSSL 3.0. Consequently TLS < 1.2
> will
> be disallowed in the default security level"
> 
> Thoughts?

+1

I do not even think this is too much controversial to do in a major
release. The only possibly controversial thing is the handling of the 
certificates signed with SHA1 and especially rejecting the client
certificates on the client side before they are sent to the server.

That is the:

https://github.com/openssl/openssl/issues/11702


-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 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 is an excellent summary of the current situation.
> > > 
> > > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno
> > > as a
> > > long term solution. It's a very confusing API for new
> > > applications to
> > > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error -
> > > except
> > > when its not. SSL_ERROR_SYSCALL should mean fatal error.
> > > 
> > > That said I also recognise that it is apparently commonplace to
> > > shut
> > > down a TLS connection without sending close_notify - despite what
> > > the
> > > standards may say about it (and TBH we can hardly claim the moral
> > > high
> > > ground here since s_server does exactly this - or at least it
> > > does in
> > > 1.1.1 and did until very recently in master).
> > > 
> > > But we do have to consider usages beyond HTTPS. I have no idea if
> > > this
> > > occurs in other settings or not.
> > > 
> > > Perhaps what we need is an option for "strict shutdown". With
> > > strict
> > > shutdown "off" we could treat EOF as if we had received a
> > > close_notify
> > > gracefully (and don't invalidate the session). Presumably
> > > existing
> > > code
> > > would be able to cope with that???
> > 
> > Yes, existing code would be able to cope with that with one
> > important
> > exception that I am going to talk about below.
> > 
> > > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in
> > > master).
> > > 
> > > I'm not sure though what the default should be.
> > 
> > In case we go with this solution, which would be acceptable I
> > think, we
> > MUST NOT EVER make it the default because existing applications
> > that
> > depend on the existing way how the unclean EOF condition is
> > returned
> > might actually depend on it to detect the truncation attack.
> 
> I agree that we should not return SSL_ERROR_ZERO_RETURN by default
> on an unexpected EOF.
> 
> If the default behaviour should be to make it a non-fatal error,
> like the old behaviour is, I would really prefer a different
> error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL.
> 
> So I think the suggestion is to have this:
> - By default, SSL_ERROR_SSL is returned with
>   SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be
>   marked invalid.
> - With an option, SSL_ERROR_ZERO_RETURN is returned, the session
>   will stay valid.

+1

And my suggestion for the SSL_OP name is SSL_OP_IGNORE_UNEXPECTED_EOF.

Dmitry, I think this solution should be working well for nginx and
similar http related applications. They just need to use the
SSL_OP_IGNORE_UNEXPECTED_EOF and the peers that do not properly
terminate the TLS session will just appear as if they properly
terminated it.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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
> > from
> > previous calls does not affect this.
> 
> On EOF, errno is normally not modified. It's value is not defined
> if no error is returned. It is not guaranteed to be 0 on success
> or EOF. It can be modified, because the implementation might have
> done other system calls that did return an error. But a simple test
> shows that it's not modified on my system.
> 

Yeah, that's what I actually meant, sorry for not being clear. I did
not mean that the errno is explicitly set to 0 on EOF by the read call
but that the errno is 0 because it is not modified and was 0 before
coincidentally. 

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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
> > behavior for this condition than the existing one as of 1.1.1f
> > would be
> > clearly wrong. Switching on a SSL_OP if that newly provided OP is a
> > trivial change to an application that needs to accommodate various
> > versions of OpenSSL (and I am not talking about forks), however
> > switching on a SSL_OP and also add another special error case is
> > much
> > more complicated change and has potential for bringing regressions
> > in
> > the applications that need to do it.
> 
> Of course, just adding a call to get the old behaviour back is a
> very easy change. But I currently don't see how a different error
> is that much more complicated.
> 
> > Is there really another situation where SSL_ERROR_SYSCALL with
> > errno 0
> > could be returned apart from the unclean EOF condition?
> > 
> > I can't really think of any.
> 
> It's not because we can't think of any other case that there aren't
> any.
> 
> I also have a problem with checking errno being 0. We don't set
> errno. There is no reason to assume that errno is set to any
> value. errno can be modified on a succesful call. That errno is 0
> is just a coincidence. If we're going to document that, we should
> actually make sure that that is the case.

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 from
previous calls does not affect this.

> I think the other property of the old behaviour is that we don't
> add anything to the error stack.
> 
> > So I would be just for properly documenting the condition and
> > keeping
> > it as is if the SSL_OP to ignore unclean EOF is in effect.
> 
> And also don't add an option for applications that do want to get
> a fatal error?

Why another option? That would be the default behavior.

But anyway I like the Matt's proposal even more.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 is an excellent summary of the current situation.
> 
> I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno as a
> long term solution. It's a very confusing API for new applications to
> use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - except
> when its not. SSL_ERROR_SYSCALL should mean fatal error.
> 
> That said I also recognise that it is apparently commonplace to shut
> down a TLS connection without sending close_notify - despite what the
> standards may say about it (and TBH we can hardly claim the moral
> high
> ground here since s_server does exactly this - or at least it does in
> 1.1.1 and did until very recently in master).
> 
> But we do have to consider usages beyond HTTPS. I have no idea if
> this
> occurs in other settings or not.
> 
> Perhaps what we need is an option for "strict shutdown". With strict
> shutdown "off" we could treat EOF as if we had received a
> close_notify
> gracefully (and don't invalidate the session). Presumably existing
> code
> would be able to cope with that???

Yes, existing code would be able to cope with that with one important
exception that I am going to talk about below.

> With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in
> master).
> 
> I'm not sure though what the default should be.

In case we go with this solution, which would be acceptable I think, we
MUST NOT EVER make it the default because existing applications that
depend on the existing way how the unclean EOF condition is returned
might actually depend on it to detect the truncation attack.

The existing legacy way does not really prevent applications from
detecting the truncation attack because the condition is reported to
the application albeit in this legacy undocumented way. So changing the
default to mean - never report the unclean EOF condition at all, simply
return as if the shutdown was clean, would actually mean a security
issue for these existing applications that care about the unclean EOF.

So yes, perhaps it would be better for the SSL_OP to actually fully
ignore the unclean EOF instead of returning this undocumented error
condition, but it must not be a default (not even in SSL_OP_ALL).

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 behaviour.
> 
> The change itself is small, it just calls SSLfatal() with a new
> error code. This has at least 2 effects:
> - The error code was changed from SSL_ERROR_SYSCALL with errno 0
>   to SSL_ERROR_SSL with reason code
>   SSL_R_UNEXPECTED_EOF_WHILE_READING
> - The session is marked as in error, and so can't be used to
>   resume.
> 
> There is code written that now checks for the SSL_ERROR_SYSCALL
> with errno 0 case, while we never documented that behaviour. The
> 1.1.1 manpage of SSL_get_error() currently reports this as a bug
> and that it will change to SSL_ERROR_SSL /
> SSL_R_UNEXPECTED_EOF_WHILE_READING.
> 
> Code that checks the SSL_ERROR_SYSCALL with errno 0 seem to fall
> in at least 2 categories:
> - Ignore the error
> - Check for the error, for instance in a test suite
> 
> Not sending the close notify alert is a violation of the TLS
> specifications, but there is software out there doesn't send it,
> so there is a need to be able to deal with peers that don't send
> it.
> 
> When the close notify alert wasn't received, but we did get an
> EOF, there are 2 cases:
> - It's a fatal error, the protocol needs the close notify alert to
>   prevent a truncation attack
> - The protocol running on top of SSL can detect a truncation
>   attack itself, and does so. It doesn't need the close notify
>   alert. It's not a fatal error. They just want to check that that
>   is what happened.
> 
> The problem is that we can't make a distiction between the 2
> cases, so the only thing we can do currently is to look at
> it as a fatal error. So the documentation was changed to say
> that if you're in the 2nd cases, and need to talk to a peer
> that doesn't send the close notify alert, you should not wait
> for the close notify alert, so that you don't get an error.
> 
> The alternative is that we add an option that does tell us if we
> should look at it as a fatal error or not.
> 
> There is at least a request that we keep returning the old error code
> (SSL_ERROR_SYSCALL with errno 0). I think that from an API point
> of view this is very confusing. We'd then have SSL_ERROR_SYSCALL
> as documented that it's fatal, except when errno is 0. If errno is
> 0, it can either be fatal or not, and we're not telling you which
> one it is. I think we also can't guarantee that SSL_ERROR_SYSCALL
> with errno 0 is always the unexpected EOF, we returned that
> combination because of a bug in OpenSSL.
> 
> 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?

>From application developer side of view for protocols that do not
depend on SSL detecting the truncation I think inventing a different
behavior for this condition than the existing one as of 1.1.1f would be
clearly wrong. Switching on a SSL_OP if that newly provided OP is a
trivial change to an application that needs to accommodate various
versions of OpenSSL (and I am not talking about forks), however
switching on a SSL_OP and also add another special error case is much
more complicated change and has potential for bringing regressions in
the applications that need to do it.

It is also an API break, however we would do it anyway unless we make
the legacy behavior the default one, so that is not really relevant
here.

Is there really another situation where SSL_ERROR_SYSCALL with errno 0
could be returned apart from the unclean EOF condition?

I can't really think of any.

So I would be just for properly documenting the condition and keeping
it as is if the SSL_OP to ignore unclean EOF is in effect.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 seem too serious.
> It's
> possible, I suppose, that existing applications that use this will
> fail
> to spot the error return since this function can now fail. The
> function
> itself was only recently added (in 1.1.1), and I suspect real-world
> usage is very small (or possibly nil).
> 
> Is this considered ok?

I would say this is an acceptable thing if it is documented (which it
is in the PR). Especially because the error return can happen only when
the application sets up the SSL to use kernel TLS.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 openssl-project or another list perhaps?). We could then quickly fix
it if cherry-pick introduced a regression.

I also see only a single case where a cherry pick introduced regression
on the 1.1.1 branch during the April. So I do not think we have a
serious issue requiring the mandatory process change immediately.
On the other hand I have no hard problems with the Matthias' proposal
either.

Also perhaps we should just make a recommendation on which kind of
commits (although cherry-picking cleanly) should have a separate PR.
For example commits touching crypto implementations and the EVP layer
should have separate 1.1.1 PRs even though they cherry-pick cleanly. 

And of course there is no requirement to not do the cherry-pick PR even
if the cherry-pick is clean. It is up to the committer discretion to
decide whether it is needed or not.

Tomas

On Wed, 2020-04-29 at 13:28 +, Dr. Matthias St. Pierre wrote:
> I completely agree with Nicolas reasoning. But we should try to keep
> things simple and not
> add too many regulations. What do you think of the following
> formulation?
>  
> > 
> For change requests which target both the master and the
> OpenSSL_1_1_1-stable branch,
> the following procedure should be followed:
>  
> - First, a pull request needs to be opened against the master branch
> for discussion.
>   Only after that pull request has received the necessary amount of
> approvals,
>   a separate pull request can be opened  against the OpenSSL_1_1_1-
> stable branch.
>  
> - A separate pull request against the OpenSSL_1_1_1-stable branch is
> required.
>   This holds - contrary to common practice - even if the change can
> be cherry-picked
>   without conflicts from the master branch. The only exception from
> this rule are
>   changes which are considered 'CLA: trivial', like e.g.
> typographical fixes.
> > 
>  
> Matthias
>  
>  
> From: openssl-project  On Behalf
> Of Nicola Tuveri
> Sent: Wednesday, April 29, 2020 3:05 PM
> To: openssl-project@openssl.org
> Subject: Re: Cherry-pick proposal
>  
> I can agree it is a good idea to always require backport as a
> separate PR, with the following conditions:
> - unless it's a 1.1.1 only issue, we MUST always wait to open the
> backport-to-111 PR until after the master PR has been approved and
> merged (to avoid splitting the discussions among different PRs, which
> make review and revisiting our history very hard)
> - trivial documentation changes, such as fixing typos, can be
> exempted
> 
> It must be clear that although things have changed a lot in the inner
> plumbings, we have so far managed to keep crypto implementations very
> much in sync between 1.1.1 and master, by applying the policy of
> "first merge to master, then possibly backport".
> 
> What I am afraid of in Bernd's proposal, and recent discussions, is
> that committers might be tempted to open PRs changing implementations
> against 1.1.1 first (to avoid frequent rebases due to unrelated
> changes) and let the `master` PR stagnate indefinitely because it
> feels like too much hassle to keep up with the development pace of
> master if your PR collaterally changes certain files.
> 
> An example of what can go wrong if we open a 1.1.1 PR concurrently
> with a PR for master can be seen here:
> - `master` PR: https://github.com/openssl/openssl/pull/10828
> - `1.1.1` PR: https://github.com/openssl/openssl/pull/11411
> 
> I highlight the following problems related to the above example:
> - as you can see the `1.1.1` has been merged, even though the
> `master` one has stalled while discussing which implementation we
> should pick. (this was my fault, I should have applied the `hold`
> label after stating that my approval for 1.1.1 was conditional to
> approving the `master` counterpart)
> - discussion that is integral part of the decision process was split
> among the 2 PRs, with over 40 comments each
> - there is no clear link between the `master` PR and the `1.1.1` PR
> for the same feature (this makes it very difficult to review what is
> the state of the "main" PR, and if we or someone else in some months
> or years needs to go check why we did things the way we did, will
> have a hard time connecting the dots)
> 
> I also think that the proposal as written is a bit misleading: I
> would very like to keep seeing in 1.1.1 a majority of commits cherry-
> picked from commits merged to master, with explicit tags in the 1.1.1
> commit messages (this helps keeping the git history self-contained
> without a too strong dependency on GitHub).
> I would rephrase the proposal as follows:
> 
> Merge to 1.1.1 should only happen after 

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 bit of stuff, I propose
> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
> 
> Thoughts?

I think my opinion is clear from the discussions in GitHub. But for the
record: Yes, I agree with it, unless we know of anything major just
ahead.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 compatibility with 3.0 however that is definitely not
> > the
> > case so the only reasonable thing is to either try to emulate the
> > behavior as much as possible or remove completely so the users of
> > the
> > API would know immediately that they have to be changed.
> > 
> 
> I don't have a strong view, but I think I tend to agree that removal
> is
> the better option. 3.0 *is* a major release and we've never
> guaranteed
> that there will be *no* breaking changes at all. We've only aimed for
> most applications that work in 1.1.1 not having to change. Since
> these
> functions exist in 1.1.1, but always fail, it seems reasonable to
> think
> that very few 1.1.1 application actually call them.

But they do not fail always - the FIPS_mode_set just works fine if you
do not use it to actually enable the FIPS mode and FIPS_mode always
returns 0 (without error). And that is fine because there is no FIPS
module in 1.1.1. But of course this behavior would not be fine with
3.0, it would be completely confusing.

>  If there are any
> that do so, then they probably need to re-examine their code anyway
> to
> confirm what the behaviour should be with 3.0.

Exactly.

> If we remove them then we should have some good documentation
> somewhere
> that explains what people should do instead.

+1

> I also think this will probably need an OMC vote.
> 
> Matt
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 support FIPS mode. */   
>   
>  return 0;  
>  }
> 
>  int FIPS_mode_set(int on)  
>  {
>  if (r == 0)  
> return 1;
> 
>  CRYPTOerr(0, CRYPTO_R_FIPS_MODE_NOT_SUPPORTED); 
>  return 0;  
> }
> 
> The original plan for these API’s is listed in the design document
> for 3.0
> i.e- the set would - set the global property and then do a fetch of a
> particular algorithm (this is problematic in itself since the
> algorithm may not exist for a 3rd party fips provider which could
> just implement a single algorithm).
> And FIPS_mode() would just return true if the global property for
> fips was set.
> 
> This got some pushback and after discussion with a few other otc
> members - it was decided that the functions should be deprecated
> since it would be confusing to a user because there are multiple
> library contexts allowed each with their own fips property that can
> be changed at
> any time.
> 
> This is done in https://github.com/openssl/openssl/pull/11075 and
> there is a related discussion in the comments.
> 
> This PR has also been rejected the deprecation and discusses
> - FIPS_mode_set() function could be completely removed.
> - FIPS_mode() - query using the default library context OR completely
> remove.
> 
> I have no issue with both functions being deleted as they no longer
> really mean the same thing as they did before.
> Each library context has its own default properties - so querying
> FIPS_mode() could only return what the default library context’s fips
> properties are - it doesnt mean every library context is in fips
> mode, or even that the fips module is loaded. 
> If the functions are removed then it may require a OMC vote since
> this could be viewed as a breaking change..

I believe that making these function return an error unconditionally is
a breaking change as well and for that reason I prefer removing them
completely or actually removing the FIPS_mode_set() and making the
FIPS_mode() to query the fips properties of the default context.

As for the use-cases the FIPS_mode() call has in the applications I
know of this implementation would be completely OK. If the call is
removed these applications would call the
EVP_default_properties_is_fips_enabled on the default context anyway.
The applications do not call FIPS_mode() to query for the FIPS
compliance but they use it to change their behavior i.e. prefer or
select different algorithms to be used.

The current implementation in the PR - unconditionally returning error
- is completely useless. It would make some (not much) sense if we
aimed for ABI compatibility with 3.0 however that is definitely not the
case so the only reasonable thing is to either try to emulate the
behavior as much as possible or remove completely so the users of the
API would know immediately that they have to be changed.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 appearance reminds
> me of the nineties and has slightly gone out of style. Just take a
> look
> how the Google logo changed over time [1], for example.
> 
> I think it's time for a more modern layout. Let's have a competition.

I like the logo as sent by Paul. There is no "3D appearance" in it.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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.
> 
> https://github.com/openssl/web/blob/master/inc/screen.css#L131-L158
> 
> While I'm not opposed to brush up the OpenSSL logo, I think this
> can't
> be done simply be replacing it on the fly. I think this requires a
> general
> discussion among the team members and finally an OMC decision,
> and shouldn't be rushed. Because after all, the shape of the logo is
> an
> essential part of the OpenSSL 'trade mark'.
> 
> If we we want to brush up the Logo, we should give everybody time to
> come up
> with proposals and then have an open contest, ideally among all
> committers,
> not only OMC or OTC.  (And you can be sure, I will come up with a
> proposal ;-) )
> 
> Finally, the OMC can run a vote, for example whether to pick the
> winner of the
> contest or to leave the logo as it is.

The logo (attached) that Paul Yang created is matching the logo on the
old OpenSSL website. You can see it here for example:

https://j3pd.files.wordpress.com/2011/08/openssl.jpg

I do not know how the current logo on the web was created or if there
was any formal decision process applied but I would expect it was
created just as an approximation of the original logo without using a
picture.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



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’ image file at hand an I think someone needs to figure
> how to extract the image then include it in the markdown file...
> 
> Regards,
> 
> Paul Yang
> 
> > On Feb 27, 2020, at 5:12 AM, Dmitry Belyavsky 
> > wrote:
> > 
> > Looks great! Many thanks for your efforts!
> > 
> > On Wed, Feb 26, 2020 at 11:13 PM Dr. Matthias St. Pierre <
> > matthias.st.pie...@ncp-e.com> wrote:
> > > The OpenSSL Project GitHub has a new landing page:
> > > 
> > > https://github.com/openssl/openssl
> > > 
> > > Scroll down. Enjoy.
> > > 
> > > 
> > > Matthias
> > > 
> > > 
> > 
> > 
> > -- 
> > SY, Dmitry Belyavsky
> 
> 
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 to work for FIPS modules,
> it’s hubris to think OpenSSL will get it completely right for other
> uses.
>  
> All other deprecations point to existing API’s or, if they are brand
> new, are not a lot of code/work to implement them.  The provider
> interface is both brand new and significant work.  Deprecating and
> saying “use providers” without at least one release cycle of 
> providers, seems premature.

This is an argument for not removing engines in 4.0 (or earlier than
one major release after the provider interface fully stabilizes and
proves viable). However I do not think that it is argument for not
deprecating it. Deprecation is declaration of intent and not a way to
force people stop using the API immediately.

How is the provider API going to improve/stabilize, if the 3rd party
engine suppliers will not get the the message that the engine API is
eventually going away in future and start writing providers as
replacement.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 provider that could load engines and make them
> appear to be a provider.  After a fair amount of investigation, this
> was deemed to be too difficult in the 3.0 time frame.
> 
> Do we still want to deprecate engines in 3.0?
> Should we defer until 4.0 instead?
> 
> 
> The main benefits seem to boil down to continuing to support existing
> engines vs removing the legacy code paths and switching to the
> provider model.


I do not understand the pushback too much - Perhaps it could be
resolved by proper explanation that deprecation does not mean a
removal?

Also even if some stuff deprecated in 3.0 is removed in 4.0, it does
not necessarily mean that engines must be removed in the same release.
They can continue to be supported (just deprecated) until 5.0 for
example.

I think that doing the deprecation as early as possible is better - it
properly gives the signal that the engine interface is legacy and it
will disappear at some point. It provides more time for 3rd party
engines to transform into providers.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 that the misunderstanding lies in when FIPS_MODE is
> > defined.
> 
> Reading this sentence it occurred to me that the misunderstanding
> comes from
> the fact that the define is indeed misnamed. The term "FIPS mode" is
> a relict
> from FIPS 2.0, where the OpenSSL 1.0.x library had an API to enable
> FIPS mode
> *at runtime*.
> 
> (Note that the *compile time* option to include the FOM was called
> OPENSSL_FIPS,
> not FIPS_MODE. So the misleading name must have crept in only
> recently.)
> 
> > It's defined when the FIPS provider module is being built, never
> > otherwise.
> 
> Exactly, in OpenSSL 3.0 the DEFAULT and the FIPS provider are
> partially built from
> the same source files, which is the reason why we need a build time
> constant to
> distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would
> be
> more fitting than FIPS_MODE?
> 
> 
>  #ifdef OSSL_FIPS_PROVIDER
>  ...
>  #endif
> 
> 
> Matthias
> 
> 
> P.S: Even though it is an internal define, it should have an OSSL_
> prefix IMHO.
> P.P.S: Optionally, one could also #define an OSSL_DEFAULT_PROVIDER,
> OSSL_LEGACY_PROVIDER, ...
> 
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 and hope they go away
> > painlessly at
> > some point.
> 
> 2 is really just and extension of 3 - either way we deprecate them.
> In 2
> we additionally provide a replacement.
> 
> I definitely think they *should* be deprecated.
> 
> Any replacement would necessarily go in the "legacy" provider I
> think.
> If a replacement is not difficult I would favour that. But I could
> live
> with (2).

Did you mean (3) here actually?

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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, they
> will no longer be reachable via EVP.  The confounding point is that
> they aren’t quite DES — close but not identical.  I would be
> surprised if they aren’t still in use for /etc/passwd files on old
> and/or embedded systems.
> 
> I’ve got several choices:
> Leave them public and unchanged — that is, don’t deprecate these two
> functions yet.
> Deprecate them and add KDFs to replace them.
> Deprecate them, leave them alone and hope they go away painlessly at
> some point.

As deprecation is NOT a removal and the removal is at least 5 years in
future I think the third option is clearly OK. We could argue about any
other functionality that we deprecate the same way and we would not be
able to deprecate anything.

When we get in time to the point of removal of the functionality
deprecated in 3.0 we might even decide to selectively postpone the
removal of this particular thing although I do not think that would be
necessary. Use of these calls should be really abandoned anyway as the
old crypt() algorithm is totally weak anyway.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 bother checking for the error
return as it did not bother for the same on EVP_CIPHER_CTX_new(). The
application will then happily (and silently) send out a plaintext
instead of ciphertext.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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?
> > 
> > There are two positions on this:
> > 
> > 1. Yes we should so we don't crash processes unnecessarily, and we
> >should return an error if pointers are NULL (unless that's valid
> >input, such as for the freeing functions).  There is a generic
> >error reason code for it, ERR_R_PASSED_NULL_PARAMETER.
> > 
> > 2. No we should not, as we don't cater for user programming errors.
> >Also, it allows us to catch our own errors early.
> > 
> > For a while, our pendulum was going with option 2, but lately, we
> > seem
> > to go back to option 1.
> > 
> > Both options have their pros and cons:
> > 
> > 1. cons: there's the very real possibility that users don't check
> > for
> >  errors as they should, and things go wrong further on,
> >  sometimes in ways where the actual cause is very hard to
> >  figure out.
> >pros: programs will not spuriously crash because we didn't catch
> > an
> >  internal corner case in our tests.
> > 
> > 2. cons: programs may crash, sometimes due to our own mistakes,
> >  sometimes due to user errors.
> >pros: some very subtle bugs are found, either quicker or at all.
> >  An actual case is PR 7630 [1], which was uncovered because
> >  there was a crash due to a NULL being used (this was
> >  ultimately due to users not checking errors).
> > 
> > As a middle ground, and perhaps a way to satify both camps, we
> > could
> > use ossl_assert() in our checks for input NULL, as follows:
> > 
> > if (!ossl_assert(ptr != NULL)) {
> > ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
> > return 0;
> > }
> > 
> > This means that in a debug build, there may be crashes due to
> > pointers
> > being NULL, while in a release build, the caller gets an error.
> > 
> > Thoughts?
> 
> My recollection was that we had some reasonable support for this
> "middle
> ground" approach.  I don't personally have strong enough feelings to
> advocate a specific position, and will try to adhere to the group
> consensus
> going forward.

I'd the option 2 or the middle-ground option. However if we choose the
middle-ground will we try to apply it to old code or will we just add
it to the new API calls or when the code of an existing API call is
being significantly reworked anyway?

Also there might be exceptional cases where taking the option 1 is
actually a better choice, but I do not think this should be the norm.

Also in some cases where the API call is called very frequently in
performance sensitive code it might be good idea to choose option 2
even in case we would decide to use the middle-ground otherwise.
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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, it's a warning that at some
> point in the future, the deprecated functionality will be removed.  I
> believe that part of the issue surrounding this is uncertainty about
> when that removal will happen, so let me just remind you what's
> written in our release strategy document:
> 
>   * 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 function, structure or macro declared
> in
> a public header file.
> 
> Ref: https://www.openssl.org/policies/releasestrat.html
> 
> I'd like to get this thread started with the following four
> questions,
> for as many of us to answer as possible:
> 
> 1. Why should we deprecate stuff

Because keeping every legacy API/feature/option/... increases the
maintenance burden, attack surface, confuses users/developers, and in
general hinders the development.

> 2. Why should we not deprecate stuff

If something does not really have an adequate replacement, it does not
really increase the maintenance burden, does not significantly increase
the attack surface, and is still used widely in applications, it should
not be deprecated.

> 3. When should we deprecate stuff

As soon as possible when there is a better replacement for the stuff. I
believe it is better to give the warning about future removal as soon
as possible rather than to plan deprecating and later removing
something anyway but delay the deprecation "to not scare someone
early".

> 4. When should we not deprecate stuff


-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 that. I'm just saying it should be better
> > advertised
> > and that internally openssl should not use the "load legacy
> > provider by
> > having it in default config file" to actively encourage the "load
> > legacy provider only if you *really* need it" behavior.
> 
> I'm a little confused.  "configuration changes" is about "having it
> in
> the config file", so I don't quite understand "oversimplified".

Basically no application that would like to work with algo from legacy
provider and that always needs it to work properly - let's say for
example something that needs to connect legacy Windows shares which use
MD4 to compute some password hash - that application cannot depend on
having the legacy enabled in the openssl config file. It should
explicitly load the legacy provider.

> Regardless of where this discussion gets us, it has always been the
> aim that this will be configurable with the config file.

Sure. What I'm just saying is that having it configurable does not
always mean it can be depended on.

I can see for example an application that works with various hashes and
by default uses secure ones and you as user need the app to check some
old file with old MD4 or RIPEMD160 hash as an exception - this can be
done by the user enabling the legacy provider in the openssl config
file.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 release and therefore we should be taking the
> > > opportunity to
> > > encourage applications to move away from these legacy algorithms.
> > > That's kind of
> > > the point of having a legacy provider in the first place. Most
> > > applications
> > > should not need to use these legacy algos so in my mind it is a
> > > sensible default
> > > to not have them available. Only if you *really* need them should
> > > you
> > > load the
> > > legacy provider.
> > 
> > OK, but then for the applications that *really* need the legacy
> > algorithms the move to 3.0.0 will definitiely not be just a
> > recompilation.
> 
> It can still be a simple recompilation even in this case - combined
> with a
> configuration change.

This might be fine for a special build of openssl included within an
application. But what would you recommend for a distribution wide
openssl?

If the legacy provider is not supposed to be loaded for normal
applications then the system-wide configuration file must not load the
provider. And then you have the special legacy apps that need it and so
they need to explicitly load the legacy provider. So saying this is
"just recompliation and configuration change" is at least somewhat
oversimplified.

But I am OK with that. I'm just saying it should be better advertised
and that internally openssl should not use the "load legacy provider by
having it in default config file" to actively encourage the "load
legacy provider only if you *really* need it" behavior.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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
> > starting point for discussion.
> > 
> > I suppose the current intention is to make the legacy provider as
> > opt-
> > in only by either application explicitly loading it or by having it
> > added to the default configuration file.
> 
> The current plan is that if no provider is loaded by the time the
> first "fetch"
> is done, then then "default" provider gets loaded automatically. In
> other words
> the "legacy" provider won't get loaded automatically *unless* it is
> loaded by
> the default configuration file.
> 
> I don't recall any discussion about what will be in the default
> configuration
> file. My assumption has always been that the legacy provider would
> not be
> automatically loaded.
> 
> > Is there anywhere any document which categorizes the current set of
> > algorithms with which are considered legacy and which not?
> 
> The algorithms planned to be moved to the legacy provider are:
> 
> Blowfish
> CAST
> DES (but not 3DES)
> DSA
> IDEA
> MD2
> MD4
> MDC2
> RC2
> RC4
> RC5
> RIPEMD160
> SEED
> Whirlpool
> 
> This is documented in the "Legacy Provider Module" section of the
> Design Document:
> 
> https://www.openssl.org/docs/OpenSSL300Design.html
> 
> Note the following caveat that document has about the above list:
> 
> "this is not meant to be an exhaustive list, even though fairly
> complete for the
> moment"
> 
> > I understand that for the current digest algos implemented in the
> > legacy provider the problem might not be as pressing as these
> > algorithms are not widely used however which other algorithms are
> > going
> > to be moved into the legacy provider?
> 
> My guess is that the ones likely to give us the most problems would
> be DES, DSA
> and RC4
> 
> > Wouldn't it be better to make the legacy provider opt-out? I.E.
> > require
> > explicit configuration or explicit API call to not load the legacy
> > provider.
> > 
> 
> IMO this is a major release and therefore we should be taking the
> opportunity to
> encourage applications to move away from these legacy algorithms.
> That's kind of
> the point of having a legacy provider in the first place. Most
> applications
> should not need to use these legacy algos so in my mind it is a
> sensible default
> to not have them available. Only if you *really* need them should you
> load the
> legacy provider.

OK, but then for the applications that *really* need the legacy
algorithms the move to 3.0.0 will definitiely not be just a
recompilation.

But then I agree with the notion that the default config file should
not load the legacy provider. Otherwise we will see very mixed reports
of what legacy applications fail or not based on whether the legacy
application loads the default configuration file or not, whether the
default configuration file was updated with the new version that loads
the legacy provider, etc. etc.

So to encourage the right implementation of legacy apps perhaps the
openssl application (here by adding a -legacy option for example?) and
the test apps should explicitly load legacy provider if asked to work
with legacy algorithm.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 it or by having it
added to the default configuration file.

Is there anywhere any document which categorizes the current set of
algorithms with which are considered legacy and which not?

I understand that for the current digest algos implemented in the
legacy provider the problem might not be as pressing as these
algorithms are not widely used however which other algorithms are going
to be moved into the legacy provider?

Wouldn't it be better to make the legacy provider opt-out? I.E. require
explicit configuration or explicit API call to not load the legacy
provider.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 with it, having an out-of-
> memory separate error code for every possible context would like to
> 589 error codes for just handling out-of-memory in master at a single
> level.
> And then on top of that you would need to cascade those errors up the
> call chain potentially.
> 
> Each error condition that might require different treatment should
> have a common code.
> The concept of out-of-memory (as a simple example) is not context
> specific (in terms of handling).
> The concept of unable-to-open-file is also not context specific.

Exactly, as application writer I do not really care about whether the
out of memory condition happened when creating some particular part of
RSA key or when allocating memory to store the RSA key der
representation or whatever.

In case of opening a file, it would be much more useful (by the use of
additional error data) to know which file name failed to open.

Also the debugging information for the library writers should be
attached automatically but of course must be separated from the
information useful to the end user.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 library.  Various strategies
> > > may be appropriate depending on the platform, and ultimately the
> > > cooperation of the system administrator to enable the required
> > > mechanisms.
> > > 
> > > Potential additional sources for initial entropy on systems
> > > without getrandom(2) might include:
> > > 
> > >   RDSEED/RDRAND
> > >   TPM (or Virtualized TPM which is sometimes better!)
> > >   RNG state saved across reboots.
> > >   ...
> > > 
> > > This requires knowledge of various platforms, and potential
> > > help from the platform vendors.  It might, for example, make
> > > sense to delegate initial seeding to systemd on platforms
> > > that use systemd, and work with the systemd maintainers to
> > > provide a set of sensible entropy sources for initial boot.
> > > 
> > > Exposing a decent RNG to virtual guests and containers is
> > > would be another area of focus.
> 
> From the point of view of distribution maintainer of OpenSSL I would
> say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT
> had
> no real problems for us.

And to clarify myself - we have no problem with the DEVRANDOM_WAIT
introduction either as the -DDEVRANDOM=/dev/urandom works nicely for
us.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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
> > approve the same PR.  That’s
> > great.  (I never approved Akamai requests unless it was trivial
> > back when I was on the OMC.)
> 
> We mostly seem to agree that it's morally dubious to approve stuff
> from people of the same company, and as far as I've heard so far,
> it's
> to ensure that the project's interests are over-ridden by company
> interests (including involuntary bias, which no one is really free
> from).

Does this also apply to non-committers submitting a PR being the same
company as one of the two required reviewers? I would have a problem if
there was only a single review required for non-committers but given
there are two reviews required one of them being from OMC member I
would not see much conflict of interest.

> > Should this policy be extended to OpenSSL’s fellows?
> 
> I believe it's assumed that fellows have the project's interests in
> mind before any other work, so no conflicting bias there, i.e. not
> quite the same.  If this is a possible point of dispute, we should
> discuss it, of course.

+1 - I also don't see the reasons for conflict of interest applying to
fellows.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]