[openssl-project] As per vote, the project list is created
Mark J Cox
mark at awe.com
Wed Jan 3 13:04:51 UTC 2018
Would be nice to add the group photo, did we get one that worked out ok Richard?
Mark
On Tue, Jan 2, 2018 at 8:42 PM, Salz, Rich <rsalz at akamai.com> wrote:
> I wrote a draft blog post. If anyone on the OMC wants to edit and put their name on it, or suggest edits and I post it, that’s fine with me.
>
> On 1/1/18, 7:30 PM, "Paul Dale" <paul.dale at oracle.com> wrote:
>
> A concurrent update for the mailing list page: https://www.openssl.org/community/mailinglists.html too?
>
> Pauli
> --
> Oracle
> Dr Paul Dale | Cryptographer | Network Security & Encryption
> Phone +61 7 3031 7217
> Oracle Australia
>
> -----Original Message-----
> From: Richard Levitte [mailto:levitte at openssl.org]
> Sent: Saturday, 23 December 2017 12:48 AM
> To: openssl-project at openssl.org
> Subject: Re: [openssl-project] As per vote, the project list is created
>
> In message <20171222105738.GA17869 at roeckx.be> on Fri, 22 Dec 2017 11:57:38 +0100, Kurt Roeckx <kurt at roeckx.be> said:
>
> kurt> You should probably announce this new list more widely
>
> Agreed. Wasn't someone going to make a blog post about it? Or was that just a general "we should" where noone actually said "I will"?
> For if no one feels they've taken that on, I will ;-)
>
> --
> Richard Levitte levitte at openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
>
>
>
> ---------- Forwarded message ----------
> From: Rich Salz <rsalz at openssl.org>
> To: <openssl-omc at openssl.org>
> Cc:
> Bcc:
> Date: Tue, 2 Jan 2018 20:41:12 +0000
> Subject: [openssl-omc] [blog] master update
> The branch master has been updated
> via 90a4eb9e289be237bc80dc5393d32e79b2d7b001 (commit)
> from 0c536ced1e9bb1684ddf60af42e236dd69d3dd52 (commit)
>
>
> - Log -----------------------------------------------------------------
> commit 90a4eb9e289be237bc80dc5393d32e79b2d7b001
> Author: Rich Salz <rsalz at akamai.com>
> Date: Tue Jan 2 15:39:37 2018 -0500
>
> Draft of F2F blog post
>
> -----------------------------------------------------------------------
>
> Summary of changes:
> source/_posts/2018-01-04-f2f-email-etc.markdown | 130 ++++++++++++++++++++++++
> 1 file changed, 130 insertions(+)
> create mode 100644 source/_posts/2018-01-04-f2f-email-etc.markdown
>
> diff --git a/source/_posts/2018-01-04-f2f-email-etc.markdown b/source/_posts/2018-01-04-f2f-email-etc.markdown
> new file mode 100644
> index 0000000..c62a133
> --- /dev/null
> +++ b/source/_posts/2018-01-04-f2f-email-etc.markdown
> @@ -0,0 +1,130 @@
> +---
> +layout: post
> +title: "Another Face to Face: Email changes and crypto policy"
> +date: 2018-01-04 1:00
> +comments: true
> +author: "???"
> +published: false
> +---
> +
> +The OpenSSL OMC met last month for a two-day face-to-face meeting, and
> +like previous F2F meetings, most of the team was present and we got a
> +great deal of issues addressed. This blog posts talks about some of them,
> +and most of the others will get their own blog posts, or notices, later.
> +
> +One of the overall threads of the meeting was about increasing the
> +transparency of the project. By default, everything should be done in
> +public. We decided to try some major changes to email and such.
> +
> +<!-- more -->
> +
> +## Security Releases
> +
> +First, a short item. We are changing our release schedule so that unless
> +there are extenuating circumstances, security releases will go out on
> +Tuesday, with the pre-notification being the previous Tuesday. We don't see
> +a need to have people ready to sacrifice their weekend every time a new CVE
> +comes out (see our
> +<a href="https://www.openssl.org/policies/secpolicy.html">security policy</a>
> +for details).
> +
> +On the other hand, a Heartbleed-style vulnerability that has known exploits
> +would a good example of an extenuating circumstance.
> +
> +## Online communication
> +
> +We created a new mailing list,
> +<a href="https://mta.openssl.org/mailman/listinfo/openssl-project">openssl-project</a>,
> +that is for discussions about the governance and policies of OpenSSL.
> +Anyone can join this list. Initially, only members of the OMC and committers
> +will be able to post; everyone else will be moderated.
> +At first glance, this seems to go against our goal of more transparency.
> +We want this to be a useful list for the project members to communicate in
> +public -- like many Parliaments, for example, where debate is public but the
> +public doesn't speak.
> +
> +Still, not everyone is completely comfortable with this, and some have said
> +that they will basically approve any posting held for moderation.
> +It's an experiment, and if we can open the list for public posting, without
> +getting drowned out, we'll do so. Note that all OMC vote results will be
> +posted here, as will initial discussions about vote topics. One important item
> +that will be discussed on this list is planning for upcoming releases.
> +Also, our paid fellows will be posting monthly status reports there.
> +
> +We decided to increase our use of GitHub. In addition to asking that all
> +bug reports and enhancement requests be reported as issues, we now want all
> +major code proposals to be discussed as issues before a large pull request
> +shows up. This will let the community discuss the feature, offer input on
> +design and such, before having code to look at. We hope this will let us
> +all first look at the bigger picture, before getting bogged down in the
> +weeds of line-by-line code reviews.
> +
> +We are going to close the openssl-dev mailing list. The distinction between
> +openssl-dev and openssl-users was often unclear, and the changes described
> +above will make that situation worse. GitHub issues are the way
> +most projects work these days, and with the creation of openssl-project it
> +should be much more clear how and when to use the openssl-users mailing
> +list.
> +
> +If our expectations are wrong, of course, we'll fix or revert these
> +changes.
> +
> +## Cryptography Policies
> +
> +Part of our discussions were about our mission.
> +
> +- What security properties are we trying to provide our users?
> +- Do we see ourselves as responsbile for keeping the ecosystem secure?
> +- Are we a TLS toolkit or a "it's all there" crypto toolkit?
> +- And so on...
> +
> +While discussing these questions, we came up with a few policy decisions.
> +These apply to all new cryptography, and in a future release we will address
> +the existing source.
> +
> +- Insecure configuration options will not be enabled by default but must
> +be enabled by a compile-time switch. We had already started to do this by
> +disabling SSLv2 and small keys. A recent change is that "multi-prime RSA"
> +will enforce a maximum number of prime factors by default. In the future,
> +it's possible we'll increase the minimum key sizes for a variety of algorithms.
> +
> +- It must be possible to disable all new algorithms at compile-time.
> +When we extend that existing code, we'll probably skip cases that are known
> +to not work. Building OpenSSL without SHA will break libssl, so it's not worth
> +spending time on that.
> +
> +- The EVP interface is the primary interface for calling crypto operations.
> +All new algorithms should only provide this API.
> +In a future release, existing API's like ``AES_encrypt`` will be provided
> +with a compatibility layer, perhaps separately, that wraps the EVP API.
> +
> +- All algorithms and protocols should be recognized by a national or
> +international standards body. That is somewhat vague, but the important
> +point is that we are implementors, not cryptographers, and will defer
> +judgement to experts.
> +
> +- The DEFAULT value for the cipher string is not the same as ALL.
> +That is, while many ciphers will be available to the libraries, they will
> +not be enabled at the TLS layer unless specified at run-time.
> +This brought up the point that the syntax of the cipher string cannot
> +support the things people need it to do, including "cipher classes,"
> +custom keywords, and site-wide configurations.
> +
> +## Roadmap
> +
> +We remain committed to having TLS 1.3 be the main feature for our next
> +release. Of course we must wait for the IETF to finish it. We'll again
> +point out that this is version 1.1.1, and you should get your applications
> +ready by porting to 1.1.0 now.
> +
> +We reviewed the status of our license-change work. We'll post an update in
> +a couple of weeks, but our goal is to change the license with this next
> +release.
> +
> +We also decided that the primary focus of the next feature release will be
> +FIPS. We know that FIPS is very important to some, not all, members of our
> +community and we are committed to addressing this. We don't have much more
> +information to share, and we know there has been some confusion and
> +misleading communication out there. But we do want to make this strong,
> +definitive statement: OpenSSL will implement a FIPS solution, and we expect
> +it will be much faster than previous timetables.
>
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
More information about the openssl-project
mailing list