Kurt raises an excellent point.
I want this in the release:
https://github.com/openssl/openssl/pull/5438
I want discussion about these two, hopefully concluding that they be in the
release:
https://github.com/openssl/openssl/pull/5326
>Release is complete and repo is now unfrozen.
>Thanks to Richard for all his help (as usual).
So Richard and Matt, please update the release instructions in the
release-tools part of the tools repo. (I know, for example, that making sure
an old/1.1.x release directory is
By a vote of 6-0-2 the OMC adopted the following travel reimbursement policy.
On a related matter, the OMC voted to hold a face-to-face meeting May 5-6 in
Ottawa, just before the ICMC conference. The travel policy will now be subject
to ruthless html’ization and posted to the website.
The
No love from Akamai for this: it seems to be done for completionist reasons and
it seems risky.
From: "paul.d...@oracle.com"
Date: Tuesday, April 9, 2019 at 8:07 PM
To: "fips-spons...@openssl.org"
Cc: "openssl-project@openssl.org"
Subject: SP 800-90C 10.1.2
Do any of the FIPS sponsors or
>Part of the idea was that this would be a means of communication
between application and provider, just like controls are with
libcrypto sub-systems.
I can probably find the email thread (or maybe it was a GitHub comment on my
proposal for params), where you said, quite
* Is this workable or should something more significantly different be used
before things freeze with the 3.0 release?
Well, since you asked: https://github.com/openssl/openssl/pull/8377
I think exposing the function internals is a mistake for a couple of reasons:
it encourages familiarity with, and dependence on, OpenSSL library internals,
and it goes against the spirit of layering, and there is no guarantee that the
function code does not change as internal code gets moved
* Unfortunately, the issue isn't the compatibility of the license - they do
indeed look relatively compatible to me - and the discussion on this thread has
so far been about that.
* However the contributor license agreement requires that the copyright
owner grants such permission - it
>> I'd be opposed to this last option without IANA/IETF being on board. By
doing so
>we are effectively no longer compliant with IETF TLS since we're using
certain
>codepoints and version numbers to mean things that IETF/IANA have no
visibility
>of, i.e. we would be
> 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
> In private email, and
https://github.com/openssl/openssl/pull/8886#issuecomment-494624313 the
implication is that this was a policy.
AFAIK this is not the case.
Is the comment wrong, either factually or because it is implementing something
that isn't an official policy?
>
> In that example the potential conflict of interest comes from the
> individual's
employment with the third party organisation, not because they are fellows.
Do you disagree with my contention that the OMC represents the project, and not
the fellows?
Regardless of where the conflict
Nicely worded. It doesn’t go as far as I’d like, but it’s a step.
* The current requirement for inclusion is “national
>I don't see it that way. As I understand it this is a completely different
protocol to standard TLS.
That's an interesting point, but ... they use the SSL "name."
> It is not intended to interoperate with it in any way.
Is that true? I didn't look closely at the protocol changes, but
> I'd be opposed to this last option without IANA/IETF being on board. By
> doing so
we are effectively no longer compliant with IETF TLS since we're using
certain
codepoints and version numbers to mean things that IETF/IANA have no
visibility
of, i.e. we would be doing
I will take the hint and stop commenting on this thread.
>DSA
What is the cryptographic weakness of DSA that you are avoiding?
>>DSA
>
> What is the cryptographic weakness of DSA that you are avoiding?
It's a good question. I don't recall the specific reason why that was added
to
the list. Perhaps others can comment.
The only weakness I know about is that if you re-use the nonce, the
Do you need to hold the lock across dependant items? For example, why can't the
DRBG code unlock before fetching the AES-CTR code?
> If DSA is almost never used, why enable it by default?
I am amused/bemused that, after years of saying we do not know what people are
doing with OpenSSL, it now is now becoming common practice to blithely assert
"this is not used" when it fits the personal viewpoint of some folks.
FWIW, I agree with Matt's points.
Thank you for the reply.
>The license under which the OpenSSL software is provided does not require
>"permission" to be sought for use of the software.
See
>I’m more concerned about adding these to 3.0. It means we’ll have to support
>the new API for a long time and it is one which we are currently trying to
>move away from.
Will you? Have you already decided that 3.0 is an LTS release? Otherwise, you
have the LTS burden and when the rest of
* It would be possible to implement a malloc failure feature in the test
suite that systematically runs a test many times, failing successive malloc
calls.
It’s there; look crypto/mem.c, shouldfail() and FAILTEST.
* It would be possible to implement a malloc failure feature in the test
suite that systematically runs a test many times, failing successive malloc
calls.
It’s there; look crypto/mem.c, shouldfail() and FAILTEST.
More detail, from off-list discusson:
i=0
while : ; do
Folks,
I did a Skype call with James. You might want to let him talk to you so that
it’s more than just my view :)
It was fun. He’s done a lot of number-crunching of OpenSSL through the years,
including things like complexity (depth of nesting) and such.
Maybe you can do a group-chat during
What about "proposed bug" "proposed feature" etc. And a single "accepted"
label?
if (!ossl_assert(ptr != NULL)) {
ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
return 0;
}
If the project decides to do this, I would like a configure option to ONLY turn
on ossl_assert so that previous behavior can be restored without debug
* In a production environment, it is almost never appropriate to simply
crash in an uncontrolled manner (i.e. dereferencing a NULL pointer).
Applications that want this can check parameters themselves before calling the
function.
Saying “C arguments don’t hold” is only because it goes
>Moreover, the deprecated commands print something to the effect of: "The
>command dsa is deprecated. Use ‘pkey’ instead." when executed.
I hope it only does that
If (isatty(0) && isatty(1) && isatty(2)) {
BIO_printf(bio_errerr, “%s: This command
For what it’s worth, during the Website redesign I asked if anyone could
provide a scalable logo so that our website worked on mobile, tablets, etc.
Tony Arceri sent me a pure-CSS solution that worked and looked similar.
A month ago Tim said[2] that PR 8797[1] requires on OMC decision on “whether or
not QUIC in this manner of approach should be added into OpenSSL at this time.”
To save you a click, this PR adds API’s to OpenSSL so that Google’s open source
QUIC implementation can be built on top of OpenSSL.
> Could we add a CI check for PRs that confirms that the target branch is
green in travis?
Looking at
https://docs.travis-ci.com/user/notifications/#conditional-notifications and
https://config.travis-ci.com/ref/notifications/email it seems like it should be
fairly easy configure
>Oh, actually, maybe I'm wrong. Is it just Appveyor that posts failures
and not Travis?
Yes. You need to config travis to mail failures, as I pointed out in my
earlier message.
* 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
>A small note about the 'no-deprecated' configuration option: this is an
> option to simulate the far future when the deprecated stuff has been removed
> from the public eye. Deprecated openssl commands should not build with such a
> configuration.
How can that work? If the deprecated
* I meant “what default makes the most sense for the passwd command line
application?”
* It was crypt which is deprecated. Should it be BSD’s MD5? One of the
SHA2 based algorithms? Or should it produce an error if no algorithm is
selected?
If you change the default, then the program
>distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
more fitting than FIPS_MODE?
Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use
OPENSSL_BUILDING_OPENSSL ...
There's no reason to use OSSL for internal macros.
Someone should turn off 1.0.2 :)
On 1/2/20, 11:48 PM, "scan-ad...@coverity.com" wrote:
Your request for analysis of OpenSSL-1.0.2 has been completed
successfully.
The results are available at
The list of committers is at https://www.openssl.org/community/committers.html
The list of OMC members is at https://www.openssl.org/community/omc.html
Will there be a list of OTC members also in the community tab soon? Or a mark
in the committers table?
I suspect that the primary motivation for this proposal is that PR’s against
master often become stale because nobody on the project looks at them. And then
submitters are told to rebase, fix conflicts, etc. It gets disheartening. If
that is the motivation, then perhaps the project should
* Disabling memory leak checking doesn’t sound like a great idea..
On that one platform, no?
This is great transparency info.
Failed CI's are a problem since it's often the fault of timeouts, or sometimes
master is broken. Any thoughts on how to handle that?
>So, ignoring deferred issues too you could summarise this as:
Stale PRs waiting for us to do something: 27 (last
>releases - we would simply do them every 3 weeks or so. I'd like to hear
opinions on that proposal too.
I am in favor of this, but you HAVE to keep the cadence regular: no slipping.
Perhaps the next Alpha release can do the error macro conversion?
Add script to convert XXXerr() to XXXerror,
https://github.com/openssl/openssl/pull/9441
In particular,
https://github.com/openssl/openssl/pull/9441#issuecomment-522171044
It might need updating if any new “error facility”
>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
will have to live with us at least until the 4.0 release and so it
Is it the project's understanding that Alpha and Beta releases are, in fact,
capital-R releases and therefore subject to OMC?
That seems weird to me.
On 06/10/2020 15:53, Salz, Rich wrote:
> Is it the project's understanding that Alpha and Beta releases are, in
fact, capital-R releases and therefore subject to OMC?
> That seems weird to me.
Yes - that is the case at the moment.
Looking at the release strategy [1] it
I am interested in helping out with the deprecation tasks. Should I assume that
Richard's PR to change how it's done will be going in?
On 14/10/2020 17:08, Salz, Rich wrote:
> I am interested in helping out with the deprecation tasks. Should I
assume that Richard's PR to change how it's done will be going in?
>
I'm not sure which of Richard's PRs you're referring to?
I thought he had a "rethin
> I thought he had a "rethinking how we deprecate" PR or issue, but I can't
find it now.
I think it was [#13074] (now merged).
Yes it was, thanks.
>Please can anyone with PRs that they wish to have included in OpenSSL
3.0 beta1 ensure that they are merged to master by 8th September.
And how are non-committers supposed to do that
As a sponsor of this release, we are concerned about further slippages in the
schedule.
I understand open source and “scratch your itch” and all that, but the project
made a commitment and several companies have contributed money and/or
engineering time. Some of those groups are making plans
If you do this, you should add a FAQ (in addition to NEWS) explaining it.
It would be really interesting to run this over the apps. Maybe reach out to
the author for help with that?
From: Dmitry Belyavsky
Date: Sunday, May 31, 2020 at 5:44 AM
To: "openssl-project@openssl.org"
Subject: Detecting Bad OpenSSL Usage
Hello,
Here is a nice article about a tool desired
* I suggest everyone takes a read through
What is the timetable for resolving
https://github.com/openssl/openssl/pull/12089 ?
The Beta is planned for a July 16 release. There is a massive RAND/DRBG PR
(https://github.com/openssl/openssl/pull/11682, the provider-friendly random)
that is in the pipeline, and 12089 and 11682 will
I assume nobody is surprised to see me say this: I do not see a requirement to
do this in 3.0. In particular, I hope that none of the contributors who already
have 3.0 work spend time on this.
If this is going to be considered for 3.0, I would like to know the rationale
for doing so. I don’t
https://github.com/xvzcf/tls-interop-runner :
The TLS Interop Test Runner aims to test interoperability
between implementations of TLS by running various tests involving clients and
servers drawn from differing implementations. It is fashioned after the QUIC
Interop Runner.
I think the current plan, to do QUIC over a series of releases, is a mistake it
seems seriously likely to make OpenSSL less relevant. Some reasons follow.
According to https://www.openssl.org/blog/blog/2019/11/07/3.0-update/, the
initial target for 3.0 was end of 2019, but the announced
101 - 161 of 161 matches
Mail list logo
