Branch: refs/heads/master
Home: https://github.com/openssl/general-policies
Commit: 8ff792500fea00294cf54f2adc203bc8c0cea3b1
https://github.com/openssl/general-policies/commit/8ff792500fea00294cf54f2adc203bc8c0cea3b1
Author: Tim Hudson
Date: 2022-09-14 (Wed, 14 Sep 2022
nctionality it would be
> useful to have it as a separate shared library so loading libcrypto is
> less expensive. Still I think this is a 4.0 project.
>
> Tomas
>
> On Fri, 2022-07-08 at 09:00 +0200, David von Oheimb wrote:
> > On 07.07.22 23:02, Tim Hudson wrote:
> >
I do not think this makes sense at this stage at all. One of the key
elements people are looking for when contributing code is the distribution
vector of getting including in default OS distributions and standard builds.
This is something we could look at tackling in a future major release - but
e
+1
Tim.
On Mon, Nov 1, 2021 at 8:23 PM Tomas Mraz wrote:
> topic: Accept openssl/technical-policies PR#1 - the policy change
> process proposal as of commit 3bccdf6. This will become an official OTC
> policy.
>
> comment: This will implement the formal policy change process so we can
> introdu
On the basis of further discussion I'm changing my vote to 0 which enables
this to pass now.
Tim.
On Wed, Oct 20, 2021 at 5:18 PM Matt Caswell wrote:
>
>
> On 19/10/2021 19:31, Nicola Tuveri wrote:
> > I believe Matt will find the time at some point to post the minutes
> > from today's meeting
PR you can argue it's not the
> comments but the code, but what happens in case the PR is changed
> before I can vote? We have also voted on issue, were several
> things were mentioned in the issue, some things I agree we should
> do, others I don't.
>
>
> Kurt
>
8:07 AM Kurt Roeckx wrote:
> On Wed, Aug 04, 2021 at 07:21:57AM +1000, Tim Hudson wrote:
> >
> > This isn't about the OTC meeting itself - this is about the details of
> the
> > topic actually being captured within the PR.
> > You need to actually look at the
On Wed, Aug 4, 2021 at 5:26 AM Dr. Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> wrote:
> > I'm starting to vote -1 on anything has a vote text that looks like
> that, so -1.
>
> I perfectly understand Kurt's dislike of this kind of votes. The text is
> not very informative for OTC members w
+1 as this is consistent with previous OTC post-beta decisions to accept
such changes (subject to OTC vote).
Tim.
On Thu, Jul 22, 2021 at 10:51 PM Matt Caswell wrote:
> topic: Accept PR 16128 in 3.0 subject to our normal review process
> Proposed by Matt Caswell
> Public: yes
> opened: 2021-07
On the call the votes were very clear to accept the PR (not reject it).
So I'm again rejecting the request to reject the PR - it would be better
to express such votes in positive terms.
-1
Tim.
On Wed, Apr 21, 2021 at 9:06 AM Dr Paul Dale wrote:
> -0
>
> Pauli
>
> On 20/4/21 8:23 pm, Nicola
Nicola, you are (in my view) conflating multiple items.
For the provider and property design approach it is rather simple.
- Algorithm implementations can vary.
- Selection between algorithm implementations when multiple providers are
available is performed by properties
Algorithm implementations
0
Tim.
On Tue, Feb 23, 2021 at 8:21 PM Tomas Mraz wrote:
> topic: The RSA_SSLV23_PADDING and related functions should be
> completely removed from OpenSSL 3.0 code.
>
> comment: The padding mode and the related functions (which are already
> deprecated in the current master branch) is useless o
On Tue, Dec 15, 2020 at 10:24 PM Kurt Roeckx wrote:
> If an applications wants to switch from one to the other
> algorithm, it should be as easy as possible. But the application
> might need to change, and might need to be aware which parameters
> are needed.
A provider may not need any of thos
On Tue, Dec 15, 2020 at 5:46 PM Richard Levitte wrote:
> Of course, checking the gettable and settable tables beforehand works
> as well. They were originally never meant to be mandatory, but I
> guess we're moving that way...
>
The only one who knows whether or not a given parameter is critica
+1
Note I support also changing all key types to be able to operate without
the public component (where that is possible) which goes beyond what this
vote covers (as previously noted).
Having a documented conceptual model that is at odds with the code isn't a
good thing and in particular this choi
+1
On Mon, 30 Nov 2020, 10:03 pm Nicola Tuveri, wrote:
> Vote background
> ---
>
> This follows up on a [previous proposal] that was abandoned in favor of
> an OMC vote on the behavior change introduced in [PR#13359].
> Within today's OTC meeting this was further discussed with the a
-1
As I said in the OTC meeting, I agree we should change the conceptual model
to not require a private key to be a super-set of a public key; however I
do not think we should introduce key-type specific behaviour in this area -
i.e. if it makes sense to change the model then it should apply equal
In a 3.0 context, EVP_PKEY_ASN1_METHOD and all the associated functions
should be marked deprecated in my view.
Tim.
-1
I don't see this as a bug fix.
Tim
On Fri, Oct 9, 2020 at 10:02 PM Tomas Mraz wrote:
> topic: The PR #11359 (Allow to continue with further checks on
> UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch
> As the change is borderline on bug fix/behaviour change OTC needs
> to
+1
Tim
On Fri, 9 Oct 2020, 10:01 pm Nicola Tuveri, wrote:
> topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13
>and until 3.0 beta1 is released, in lieu of the weekly "developer
>meetings".
> Proposed by Nicola Tuveri
> Public: yes
> opened: 2020-10-09
> close
+1
Tim.
On Fri, Oct 9, 2020 at 12:47 AM Matt Caswell wrote:
> topic: The following items are required prerequisites for the first beta
> release:
> 1) EVP is the recommended API, it must be feature-complete compared with
> the functionality available using lower-level APIs.
>- Anythin
+1
Tim
On Fri, Oct 9, 2020 at 12:27 AM Matt Caswell wrote:
> topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as
> shown in PR #13018 into the 3.0 release
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-10-08
> closed: 2020-mm-dd
> accepted: yes/no (for: X, again
Thanks Matt - cut-n-paste fumble on my part from the previous vote summary.
The tally should always equal the number of OMC members.
For: 6, against: 0, abstained 0, not voted: 1
Tim.
On Wed, Sep 16, 2020 at 8:11 AM Matt Caswell wrote:
>
>
> On 15/09/2020 23:10, Tim Hudson wrote:
&g
The OMC voted to:
*Release stable branch on the second last Tuesday of the last month in each
quarter as a regular cadence.*
The vote passed.
For: 6, against: 9, abstained 0, not voted: 1
Thanks,
Tim.
On Mon, Sep 14, 2020 at 9:52 PM Matt Caswell wrote:
> > And that is the point - this is not how the existing CTX functions work
> > (ignoring the OPENSSL_CTX stuff).
>
> Do you have some concrete examples of existing functions that don't work
> this way?
>
SSL_new()
BIO_new_ssl()
BIO_new_ssl_con
On Mon, Sep 14, 2020 at 9:19 PM Matt Caswell wrote:
> I must be misunderstanding your point because I don't follow your logic
> at all.
>
> So this is the correct form according to my proposed policy:
>
> TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx)
>
And that is the point - this is not ho
Any proposal needs to deal with the constructors consistently - whether
they come from an OPENSSL_CTX or they come from an existing TYPE_CTX.
That is absent in your PR.
Basically this leads to the ability to provide inconsistent argument order
in functions.
TYPE *TYPE_make_from_ctx(TYPE_CTX *ctx,
On Sun, Sep 6, 2020 at 6:55 AM Richard Levitte wrote:
> I'd rank the algorithm name as the most important, it really can't do
> anything of value without it.
>
It also cannot do anything without knowing which libctx to use. Look at the
implementation.
Without the libctx there is no "from-where"
On Sat, Sep 5, 2020 at 8:45 PM Nicola Tuveri wrote:
> Or is your point that we are writing in C, all the arguments are
> positional, none is ever really optional, there is no difference between
> passing a `(void*) NULL` or a valid `(TYPE*) ptr` as the value of a `TYPE
> *` argument, so "importan
On Sat, Sep 5, 2020 at 6:38 PM Nicola Tuveri wrote:
> In most (if not all) cases in our functions, both libctx and propquery are
> optional arguments, as we have global defaults for them based on the loaded
> config file.
> As such, explicitly passing non-NULL libctx and propquery, is likely to b
I place the OTC hold because I don't believe we should be making parameter
reordering decisions without actually having documented what approach we
want to take so there is clear guidance.
This was the position I expressed in the last face to face OTC meeting -
that we need to write such things dow
Placing everything under EVP is reasonable in my view. It is just a prefix
and it really has no meaning these days as it became nothing more than a
common prefix to use.
I don't see any significant benefit in renaming at this point - even for
RAND.
Tim.
On Fri, 24 Jul 2020, 1:56 am Matt Caswell,
topic: Change some words by accepting PR#12089
4 against, 3 for, no absensions
The vote failed, the PR will now be closed.
Thanks,
Tim.
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.
What you (Ben and Matt) are both describing is not LTS but STS ... these
are different concepts.
For LTS the focus is *stability *and *reduced risk of disrupt
On Sat, 20 Jun 2020, 8:14 am Benjamin Kaduk, wrote:
> On Sat, Jun 20, 2020 at 08:11:16AM +1000, Tim Hudson wrote:
> > The general concept is to only fix serious bugs in stable releases.
> > Increasing performance is not fixing a bug - it is a feature.
>
> Is remediating a si
The general concept is to only fix serious bugs in stable releases.
Increasing performance is not fixing a bug - it is a feature.
Swapping out one implementation of algorithm for another is a significant
change and isn't something that should go into an LTS in my view.
It would be less of an issu
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
Given that this change impacts interoperability in a major way it should be
a policy vote of the OMC IMHO.
Tim.
On Thu, 18 Jun 2020, 5:57 am Kurt Roeckx, wrote:
> On Wed, May 27, 2020 at 12:14:13PM +0100, Matt Caswell wrote:
> > PR 10787 proposed to reduce the number of security bits for MD5 a
Any change to the review gate check we have in place now that lowers it
will certainly not get my support.
If anything, that check before code gets approved should be raised, not
lowered.
Tim.
On Thu, 30 Apr 2020, 1:24 am Salz, Rich, wrote:
> I suspect that the primary motivation for this prop
We don't guarantee constant time.
Tim.
On Fri, 27 Mar 2020, 5:41 am Bernd Edlinger,
wrote:
> So I disagree, it is a bug when it is not constant time.
>
>
> On 3/26/20 8:26 PM, Tim Hudson wrote:
> > +1 for a release - and soon - and without bundling any more changes
+1 for a release - and soon - and without bundling any more changes. The
circumstances justify getting this fix out. But I also think we need to
keep improvements that aren't bug fixes out of stable branches.
Tim.
On Fri, 27 Mar 2020, 3:12 am Matt Caswell, wrote:
> On 26/03/2020 15:14, Short, T
On Fri, Nov 29, 2019 at 7:08 PM Tomas Mraz wrote:
> The "always check for NULL pointers" approach does not avoid
> catastrophical errors in applications.
I didn't say it avoided all errors (nor did anyone else on the thread that
I've read) - but it does avoid a whole class of errors.
And for t
The way I view the issue is to look at what happens when things go wrong -
what is the impact - and evaluate the difference in behaviour between the
approaches.
You have to start from the premise that (in general) software is not tested
for all possible usage models - i.e. test coverage isn't at 10
FYI - I have reviewed and added my approval. No need to back out anything.
Tim.
On Fri, Oct 4, 2019 at 5:50 PM Dr Paul Dale wrote:
> I believed that it required two OMC approvals but was pointed to an
> earlier instance where only one was present and I flew with it without
> checking further.
>
Merge early is pretty much my default position ... and that applies to this
context in my view.
Tim.
On Sat, 28 Sep. 2019, 7:44 am Dr. Matthias St. Pierre, <
matthias.st.pie...@ncp-e.com> wrote:
> Hi,
>
> some of you might have loosely followed pull request #9333 (see [1]),
> where I am reorgani
My view point (which has been stated elsewhere) is that OpenSSL-3.0 is
about internal restructuring to allow for the various things noted in the
design documents.
It is not about changing the feature set (in a feature reduction sense).
In future releases we will make the mixture of providers avail
On Thu, Jul 11, 2019 at 12:37 AM Dmitry Belyavsky wrote:
> Dear Tim,
>
> Formally I am a contributor with a signed CLA.
> I took a code definitely permitting any usage without any feedback,
> slightly modified it (at least by openssl-format-source and splitting
> between header and source), and s
Previous assertions that if the license was compatible that we don't need a
CLA in order to accept a contribution were incorrect.
You are now questioning the entire purpose of contributor agreements and
effectively arguing they are superfluous and that our policy should be
different.
You are (of c
On Wed, Jul 10, 2019 at 1:58 AM Salz, Rich wrote:
> Thank you for the update. This brings to mind a few additional questions:
>
> 1. Does other code which is copyright/licensed under the Apache 2 license
also require CLAs?
See points 1-3 of previous email. CLAs are required for anything
non-trivia
on the license terms of a contribution
Thanks,
Tim.
On Fri, Jun 21, 2019 at 4:24 PM Tim Hudson wrote:
> 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 abou
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 is the fundamenta
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 possi
On Fri, May 24, 2019 at 7:34 PM Matt Caswell wrote:
> On 24/05/2019 10:28, SHANE LONTIS wrote:
> > It doesn’t stop us both reviewing a PR. That doesn’t mean we both need
> to approve.
>
> Right...but in Matthias's version if you raise a PR, and then Pauli
> approves it,
> then you only then need
As part of various discussions, I've drafted a proposed (not yet put to a
formal vote) change to the committers policy to address the perception of a
potential conflict-of-interest situation. I don't believe that we have
actually encountered a conflict of interest in our current policy, but
avoidin
We have discussed this at numerous OMC meetings in terms of how to managed
potential *perceived *conflicts of interest that might arise if people
outside of the fellows come from the same company and hence can effectively
turn the OMC review control mechanism into a single control rather than a
dua
"handle" is the wrong name for this - if you want to have private const
data then do that rather than something which might be abused for instance
specific information. It could just be an int even or a short. It doesn't
have to be a pointer.
That would reduce the likely of it being used to hold n
Looking at PR#8287 I think we need to get some naming schemes written down
and documented and followed consistently. The naming used in this PR seems
to be somewhat inconsistent.
For me, I think the naming convention most often used is
return_type SOMETHING_whatever(SOMETHING *,...)
as a general
Add a -r to your diff command so you recursively compare ... then you will
see the actual code changes.
Without the -r you are only comparing files in the top-level directory of
each tree.
diff *-r* -dup openssl-1.0.2q openssl-1.0.2r
Tim.
-- Forwarded message --
From: Hong Cho
T
On Mon, Feb 18, 2019 at 8:36 PM Matt Caswell wrote:
>
>
> On 18/02/2019 10:28, Tim Hudson wrote:
> > It should remain completely opaque.
> > As a general rule, I've never seen a context where someone regretted
> making a
> > structure opaque over time, but th
It should remain completely opaque.
As a general rule, I've never seen a context where someone regretted making
a structure opaque over time, but the converse is not true.
This is opaque and should remain opaque.
We need the flexibility to adjust the implementation at will over time.
For anything
>From https://github.com/openssl/openssl/pull/7721
Tim - I think inline functions in public header files simply shouldn't be
present.
Matt - I agree
Richard - I'm ambivalent... in the case of stack and lhash, the generated
functions we made static inline expressly to get better C type safety, and
On Thu, Jan 24, 2019 at 9:45 PM Matt Caswell wrote:
> > This notion of "handshake" is not supported by RFC 8446 uses the terms
> "the
> > handshake", "a handshake", and "post-handshake". "Post-handshake", in
> > particular, implies KeyUpdate are after the handshake, not part of it.
>
> I just don
The function has been there for a long time (since then beginning) and it
is all about version related information - so both names aren't exactly
clearly descriptive.
OpenSSL_version_information() would be a better name.
It would also argue that the "version" program should be renamed "info" as
t
I don't see a *substantial benefit* from going to C99 and I've worked on
numerous embedded platforms where it is highly unlikely that C99 support
will ever be available.
Kurt - do you have a specific list of features you think would be
beneficial - or is it just a general sense to move forward?
W
On Fri, Sep 28, 2018 at 4:55 PM Matt Caswell wrote:
> Either we go with semver and totally commit to it - or we stick with what
> we've already got. No
> half-way, "well we're kind of doing semver, but not really".
>
+1
I see no point in changing what we are doing *without* getting the benefit
On Tue, Sep 25, 2018 at 11:02 PM Matt Caswell wrote:
> You're right on this one. I misread the diff.
>
Not a problem - you are doing the look-at-what-we-did and how it would be
impacted - and that is certainly what we should be doing - working through
what impact this would have had.
Semantic ve
On Tue, Sep 25, 2018 at 10:37 PM Matt Caswell wrote:
> - Added some new macros:
> https://github.com/openssl/openssl/pull/6037
No we didn't change our public API for this one - we changed *internals*.
The change to include/openssl/crypto.h was entirely changing *comments* to
document that the i
On Tue, Sep 25, 2018 at 9:22 PM Matt Caswell wrote:
> Lets imagine we release version 5.0.0. We create a branch for it and
> declare a support period. Its an LTS release. This is a *stable*
> release, so we shouldn't de-stabilise it by adding new features.
>
> Later we do some work on some new fe
On Tue, Sep 25, 2018 at 8:07 PM Matt Caswell wrote:
> On 25/09/18 10:58, Tim Hudson wrote:
> > On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte > <mailto:levi...@openssl.org>> wrote:
> >
> > So what you suggest (and what I'm leaning toward) means
On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte wrote:
> So what you suggest (and what I'm leaning toward) means that we will
> change our habits.
>
Adoption of semantic versioning will indeed require us to change our habits
in a number of areas - that is the point of having a single clear
defin
A fairly common approach that is used is that you can only remove something
that has been marked for deprecation at a MAJOR release version boundary.
That is entirely independent of the semantic versioning view of things -
which also happens to say the same thing (that adding a deprecation
indicat
On Sat, Sep 22, 2018 at 3:12 PM Viktor Dukhovni
wrote:
> The proposal to move the minor version into nibbles 2 and 3 breaks this
> OpenSSH function.
>
No it doesn't - because I'm not talking about moving *anything* in the
current encoding for major and minor - see earlier post.
The positions don
If you accept that we have a MAJOR.MINOR.FIX.PATCH encoding currently
documented and in place and that the encoding in OPENSSL_VERSION_NUMBER is
documented then the semantic versioning is an easy change.
We do not need to change our encoding of MAJOR.MINOR - that is documented
and fixed. We just ne
On Sat, Sep 22, 2018 at 11:55 AM Viktor Dukhovni
wrote:
> this is an ad-hoc encoding with monitonicity as the
> the only constraint.
>
If you start from the position that the encoding of OPENSSL_VERSION_NUMBER
is free to change so long as the resulting value is larger than what we
have been usin
On Sat, 22 Sep. 2018, 3:24 am Viktor Dukhovni,
wrote:
> > On Sep 21, 2018, at 12:50 PM, Tim Hudson wrote:
> > If that is the case then our current practice of allowing ABI breakage
> with
> > minor release changes (the middle number we document as the minor
> release n
On Sat, 22 Sep. 2018, 2:29 am Viktor Dukhovni,
wrote:
>
>
> > On Sep 21, 2018, at 12:14 PM, Matt Caswell wrote:
> >
> > I support Richard's proposal with an epoch of 1.
> > Grudgingly I would accept an epoch in the 3-8 range.
> > I would oppose an epoch of 2.
>
> I can live with that, though it
On Sat, Sep 22, 2018 at 1:39 AM Viktor Dukhovni
wrote:
> The only change needed is a minor one in applications that actually
> parse the nibbles
What I was suggesting is that we don't need to break the current encoding
at all.
We have a major.minor.fix version encoded and documented in the heade
On Sat, Sep 22, 2018 at 1:34 AM Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> wrote:
>
> On 21.09.2018 17:27, Tim Hudson wrote:
> >
> > We cannot remove the current major version number - as that concept
> exists and we have used it all along.
> > We don
On Sat, Sep 22, 2018 at 1:16 AM Viktor Dukhovni
wrote:
>
>
> > On Sep 21, 2018, at 11:00 AM, Tim Hudson wrote:
> >
> > If you repeat that in semantic versioning concepts just using the labels
> for mapping you get:
> > - what is the major version number - the
On Sat, Sep 22, 2018 at 12:32 AM Viktor Dukhovni
wrote:
> > On Sep 21, 2018, at 10:07 AM, Tim Hudson wrote:
> >
> > And the output you get:
> >
> > 0x10102000
>
> The trouble is that existing software expects to potential ABI changes
> resulting from cha
_VERSION_MINOR,OPENSSL_VERSION_PATCH);
printf("%s\n",OPENSSL_VERSION_TEXT);
}
And the output you get:
0x10102000
1.1.2
1.1.2-beta1+21Sep2018.optbuild.arm
Tim.
On Fri, Sep 21, 2018 at 11:36 PM Richard Levitte
wrote:
> In message w2o_njr8bfoor...@mail.gmail.com> on Fri, 21
Now I get the conceptual issue that Richard and Matt are differing on - and
it is about actually replacing OpenSSL's versioning concept with semantic
versioning compared to adopting semantic versioning principles without
actually being precisely a semantic version approach.
The whole concept of se
Semantic versioning is about a consistent concept of version handling.
And that concept of consistency should be in a forms of the version - be it
text string or numberic.
That you see them as two somewhat independent concepts isn't something I
support or thing makes sense at all.
Our users code
So as a concrete example - taking master and the current
OPENSSL_VERSION_TEXT value.
"OpenSSL 1.1.2-dev xx XXX "
would become
"1.1.2-dev+xx.XXX."
That is what I understand is the point of semantic versioning. You know how
to pull apart the version string.
-dev indicates a pre-release v
On Fri, Sep 21, 2018 at 9:02 PM Matt Caswell wrote:
> I think this is an incorrect interpretation of Richard's proposal. The
> OPENSSL_VERSION_NUMBER value is an *integer* value. It does not and
> cannot ever conform to semantic versioning because, because version
> numbers in that scheme are *st
On Fri, Sep 21, 2018 at 7:58 PM Richard Levitte wrote:
> Our FAQ says that such changes *may* be part of a major
> release (we don't guarantee that breaking changes won't happen), while
> semantic versioning says that major releases *do* incur backward
> incompatible API changes.
>
I think you a
On Mon, Sep 10, 2018 at 8:44 AM, Matt Caswell wrote:
> As far as the release criteria go we only count the ones shown in the
> Coverity tool. That's not to say we shouldn't fix issues in the tests as
> well (and actually I'd suggest we stop filtering out problems in the
> tests if anyone knows ho
Done.
Tim.
On Sun, Sep 9, 2018 at 8:34 PM, Matt Caswell wrote:
> Please can someone freeze the repo:
>
> ssh openssl-...@git.openssl.org freeze openssl matt
>
>
> Thanks
>
> Matt
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> ht
All PRs except #7145 now reviewed and marked ready.
Tim
On Fri, Sep 7, 2018 at 8:41 AM, Matt Caswell wrote:
> 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 issu
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 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 note
Welcome to Paul Dale (OMC) , Paul Yang and Nicola Tuveri (Commiters).
See the blog post at https://www.openssl.org/blog/blog/2018/08/22/updates/
Thanks,
Tim.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/l
We don't have a formal policy of no NULL checks - we just have a few
members that think we should have such a policy but it has never been voted
on as we had sufficiently varying views for a consensus approach to not be
possible.
Personally I'm in favour of high-level APIs having NULL checks as it
No that vote does not pass. All votes require participation by a majority
of active members. Failure to have a majority participation causes a vote
to fail.
With only three out of eight members voting this vote simply did not pass.
Tim.
On Thu, 24 May 2018, 12:59 am Salz, Rich, wrote:
> Anoth
Where we are stating that ABI compatibility is in place we should be
testing it.
i.e. the older release binaries should be run against the current release
libraries - and that should be put into CI in my view.
Going the other direction isn't something I have thought we have ever
guaranteed (i.e. d
> In message w...@mail.gmail.com> on Tue, 03 Apr 2018 15:36:15 +, Tim Hudson <
> t...@cryptsoft.com> said:
>
> tjh> And it should have a test - which has nothing to do with ASM and
> everything to do with improving
> tjh> test coverage.
> tjh>
> tjh&
And it should have a test - which has nothing to do with ASM and everything
to do with improving test coverage.
Bugs are bugs - and any form of meaningful test would have caught this.
For the majority of the ASM code - the algorithm implementations we have
tests that cover things in a decent mann
Improved testing to me is something that is a good thing - and a value
judgement.
It doesn't change libcrypto or libssl - and that to me is the way I think
of it.
Fixing tests and apps and Makefiles to me are different from adding
features to libcrypto or libssl.
On this one - the fuzz testing has
Seeing "This was the original information, might still be valid for < 1.0.2
openssl versions :" at
https://wiki.openssl.org/index.php/Hostname_validation raises the question
as to whether or not the wiki should contain information for versions of
OpenSSL that are no longer supported.
Thoughts?
Ti
https://github.com/openssl/openssl/pull/2181
and
https://github.com/openssl/openssl/pull/1603#issuecomment-248649700
One thing that should be noted is that if you are building with -Wall
-Werror (which many projects do) and you are using OpenSSL and things
change from a const perspective builds br
1 - 100 of 111 matches
Mail list logo
