)
Changed paths:
M votes/vote-2022-sensitive-info.txt
M votes/vote-2022-travel-policy.txt
Log Message:
---
Update votes
2022)
Changed paths:
M votes/vote-20221107-test-labels.txt
Log Message:
---
[VOTE][late update] test labelling policy
The vote is as shown below.
OMC members should cast their vote here:
https://github.com/openssl/general-policies/pull/21
Mark
Topic: Accept the security policy as of
314ef25aa50e6f0c6a5b026251a06a1c4941e5a2
Proposed by: Mark Cox
Issue link: https://github.com/openssl/general-policies/pull/21
Topic: Update security prenotification policy to include MODERATE issues
Proposed by: Mark Cox
Issue link: https://github.com/openssl/general-policies/pull/20
Public: yes
Opened: 2022-05-11
Closed: -MM-DD
Accepted: yes/no (for: X, against: Y, abstained: Z, not voted: W)
Kurt
The OTC vote for this policy proposal has now started.
OTC members please cast your votes here:
https://github.com/openssl/technical-policies/pull/17
Matt
FYI, OTC met today to discuss the 3.0 final release. Due to the security
release taking place later today they decided that 3.0 final will not be
released this week.
Matt
I forgot one word:
On 24.05.19 17:45, Matthias St. Pierre wrote:
(Otherwise, the missing approvers need to be from the Reviewed-by list
and additional approvals would be needed).
need to be _removed_ from the Reviewed-by list
On 24.05.19 16:54, Richard Levitte wrote:
On Fri, 24 May 2019 16:39:51 +0200,
Matt Caswell wrote:
On 24/05/2019 15:30, Richard Levitte wrote:
Not in practice. We *do* ask on the PR in question if it should be
cherry-picked to 1.1.1 and seek approval for that action, but then it
hasn't at
On Fri, 24 May 2019 16:39:51 +0200,
Matt Caswell wrote:
>
>
>
> On 24/05/2019 15:30, Richard Levitte wrote:
> >
> > Not in practice. We *do* ask on the PR in question if it should be
> > cherry-picked to 1.1.1 and seek approval for that action, but then it
> > hasn't at all been clear what
On Fri, 24 May 2019 16:20:59 +0200,
Matt Caswell wrote:
> On 24/05/2019 15:10, Richard Levitte wrote:
> > If we go with the idea that an approval also involves approving what
> > branches it goes to, then what happens if someone realises after some
> > time that a set of commits (a PR) that was
Matt and Richard, I think you are mixing up cherry-picking and nit-picking
here. (Sorry for the pun ;-)
Matthias
> To be picky, may I assume that you meant a reviewed-by tag for you
> > should be *added*? The commit itself (its contents) having been
> > reviewed by those already there, I
>> 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
> On May 22, 2019, at 10:16, Salz, Rich wrote:
>
>>> 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
> On May 21, 2019, at 22:13, Salz, Rich wrote:
>
>
>> 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
> 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
> On May 20, 2019, at 07:49, Matt Caswell wrote:
>
>
> On 20/05/2019 15:23, Salz, Rich wrote:
>>> 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."
>
> Which isn't
>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
On Mon, 20 May 2019 16:05:49 +0200,
Salz, Rich wrote:
>
> * The current requirement for inclusion is “national standard” or better.
> Thus, this change
> should be accepted.
>
> The problem is that they squatted on codepoints that the IETF controls. So
> while it is a national
>
* The current requirement for inclusion is “national
Rich made a good point: HYPERLINK
On Wed, Feb 13, 2019 at 03:28:30PM -0500, Michael Richardson wrote:
>
> Matt Caswell wrote:
> > Please see my blog post for an OpenSSL 3.0 and FIPS Update:
>
> > https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/
>
> Thank you, it is very useful to hav
Matt Caswell wrote:
> Please see my blog post for an OpenSSL 3.0 and FIPS Update:
> https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/
Thank you, it is very useful to have these plans made up front.
I think your posts should probably explain what happened
Please see my blog post for an OpenSSL 3.0 and FIPS Update:
https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/
Matt
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
a way that does not break binary
> compatibility. ...
In fact, the only official mentions of the new versioning scheme are the blog
post [2]
from November 28 and (indirectly) the License page [3] because it has been
updated for the Apache relicensing.
So maybe `releasestrat.html` needs an update?
On Thu, Nov 29, 2018 at 03:34:29PM +, Mark J Cox wrote:
> Changes to policies require an OMC vote which I've called to approve an
> update to the security policy. This was as discussed at the face to face
> and the details and diff are at https://github.com/openssl/we
Changes to policies require an OMC vote which I've called to approve an
update to the security policy. This was as discussed at the face to face
and the details and diff are at https://github.com/openssl/web/pull/96
topic: Update security policy as per https://github.com/openssl
On 07/09/18 10:09, Richard Levitte wrote:
> In message on Fri, 7 Sep
> 2018 09:56:01 +0100, Matt Caswell said:
>
>>
>>
>> On 07/09/18 01:51, Richard Levitte wrote:
>>> I think this one should be part of the lot as well:
>>>
>>> #7144
>>> ASN.1 DER: Make INT32 / INT64 types read badly
On 07/09/18 01:51, Richard Levitte wrote:
> I think this one should be part of the lot as well:
>
> #7144
> ASN.1 DER: Make INT32 / INT64 types read badly encoded LONG zeroes
>
> For example, *all* two-prime RSA keys from pre-1.1.1 become unreadable
> in 1.1.1, because pre-1.1.1 encodes the
In message <20180907.025152.1131079938025695690.levi...@openssl.org> on Fri, 07
Sep 2018 02:51:52 +0200 (CEST), Richard Levitte said:
> For example, *all* two-prime RSA keys from pre-1.1.1 become unreadable
That was a bit of an over-statement... but it seems that there are
things in the wild
nssl-project] Release Criteria Update
All PRs except #7145 now reviewed and marked ready.
Tim
On Fri, Sep 7, 2018 at 8:41 AM, Matt Caswell mailto:m...@openssl.org"m...@openssl.org> wrote:
We currently have 8 1.1.1 PRs that are open. 3 of which are in the
"ready" st
We currently have 8 1.1.1 PRs that are open. 3 of which are in the
"ready" state. There are 2 which are alternative implementations of the
same thing - so there are really on 4 issues currently being addressed:
#7145 SipHash: add separate setter for the hash size
Owner: Richard
Awaiting review
> On Sep 6, 2018, at 6:25 PM, Matt Caswell wrote:
>
> I'm not keen on that. What do others think?
No objections to issuing a release. We're unlikely to have to change the
API/ABI or feature set based on further beta feedback. Any late bugs can
be fixed in 1.1.1a, and unless they trigger
We need to get this release out and available - there are a lot of people
waiting on the "production"release - and who won't go forward on a beta
(simple fact of life there).
I don't see the outstanding items as release blockers - and they will be
wrapped up in time.
Having the release date as a
On 06/09/18 17:32, Kurt Roeckx wrote:
> On Tue, Sep 04, 2018 at 05:11:41PM +0100, Matt Caswell wrote:
>> Current status of the 1.1.1 PRs/issues:
>
> Since we did make a lot of changes, including things that
> applications can run into, would it make sense to have an other
> beta release?
I'm
On Tue, Sep 04, 2018 at 05:11:41PM +0100, Matt Caswell wrote:
> Current status of the 1.1.1 PRs/issues:
Since we did make a lot of changes, including things that
applications can run into, would it make sense to have an other
beta release?
Kurt
___
On Thu, Sep 6, 2018 at 8:59 AM, Matt Caswell wrote:
> #7113 An alternative to address the SM2 ID issues
> (an alternative to the older PR, #6757)
>
> Updates made following earlier review. Awaiting another round of reviews.
> Owner: Paul Yang
All the previous comments have been addressed. I
On Wed, Sep 05, 2018 at 11:59:34PM +0100, Matt Caswell wrote:
> Today's update is that we still have 6 open PRs for 1.1.1. 5 of these
> are the same as yesterday. The 1 that was marked as "ready" yesterday
> has now been merged, and a new PR addressing issue #7
Today's update is that we still have 6 open PRs for 1.1.1. 5 of these
are the same as yesterday. The 1 that was marked as "ready" yesterday
has now been merged, and a new PR addressing issue #7014 has been opened.
There are still 2 open issues for 1.1.1 but both of these are now being
On Tue, Sep 04, 2018 at 05:11:41PM +0100, Matt Caswell wrote:
> There are 2 open issues for 1.1.1. One of these is being addressed by
> PR#7073 above. The other one is:
>
> #7014 TLSv1.2 SNI hostname works in 1.1.0h, not in 1.1.1 master (as of
> 18-Aug)
>
> This one seems stuck!! No clear way
Current status of the 1.1.1 PRs/issues:
There are currently 6 open PRs for 1.1.1. However in 2 cases there are 2
alternative implementations for the same thing - so really there are
only 4 issues being addressed. One of these is in the "ready" state.
The remaining 3 are:
#7114 Process KeyUpdate
A quick update on the status of the 1.1.1 release criteria:
- All open github issues/PRs older than 2 weeks at the time of release
to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
milestone to be closed
Status:
We have 5 open issues (4 of which were opened within the last 2
Apache trunk now supports OpenSSL’s TLS 1.3 Woo hoo!
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
uot;t...@openssl.org" <t...@openssl.org>
Reply-To: "openssl-project@openssl.org" <openssl-project@openssl.org>
Date: Wednesday, March 14, 2018 at 5:33 AM
To: "openssl-project@openssl.org" <openssl-project@openssl.org>
Subject: [openssl-project] OpenSSL FIPS
https://wiki.openssl.org/index.php/FIPS_module_3.0
I've edited that to be closer to the list of items we are discussing and to
remove things which looked like commitments that are out of scope of our
current plans.
As always, feedback is welcome - but we have had a few people referencing
that
On Mon, Feb 05, 2018 at 08:43:04PM +0100, Dr. Matthias St. Pierre wrote:
>
>
> Am 05.02.2018 um 19:13 schrieb Salz, Rich:
> >
> >
> > Do not put a size after sizeof; do use parens.
> >
>
> nit: Do not put a /space /after sizeof.
>
> >
> >
> > Treat a single-statement with comment as if it
* nit: Do not put a space after sizeof.
fixed.
* Wasn't there also the suggestion by someone that if one part of an
if-else statements needs braces that the other part should get some, too?
It already says that.
___
openssl-project mailing
On 05/02/18 19:43, Dr. Matthias St. Pierre wrote:
>
> Wasn't there also the suggestion by someone that if one part of an
> if-else statements needs braces that the other part should get some, too?
That's already in the style guide:
Do not unnecessarily use braces around a single statement:
Am 05.02.2018 um 19:13 schrieb Salz, Rich:
>
>
> Do not put a size after sizeof; do use parens.
>
nit: Do not put a /space /after sizeof.
>
>
> Treat a single-statement with comment as if it were multi-line and use
> curly braces
>
>
>
> if (test()) {
>
>
➢ In general we should prefer ossl_assert over assert. Never use
OPENSSL_assert() in libcrypto or libssl.
Maybe that’s all to put into the guide, then.
___
openssl-project mailing list
openssl-project@openssl.org
A summary of the discussion thread so far. Not surprisingly, it’s all about
the whitespace. :)
The descriptions here were written to be understandable stand-alone. Once we
come to a conclusion, we’ll wordsmith them into the coding style.
Do not put a size after sizeof; do use parens.
When
50 matches
Mail list logo
