Re: VOTE: OTC meeting will be called for next Tuesday

2020-09-30 Thread Richard Levitte
; Mark [ ] > Pauli [+1] > Viktor [ ] > Tim[+1] > Richard[+1] > Shane [+1] > Tomas [ ] > Kurt [ ] > Matthias [+1] > Nicola [+1] > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Proposal for a libcrypto module style guide / policy

2020-09-28 Thread Richard Levitte
-- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ OpenSSL modules === A module in the sense described here is a part of OpenSSL functionality, in particular in libcrypto, not a dynamically loadable module. A module is recognised

Re: Status of the remaining beta1 PRs

2020-09-20 Thread Richard Levitte
Since this affects a public API we probably really do need to figure out > what to do with the EVP_PKEY_set_alias_type() There's a counter PR now: #12920 -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: 3.0 beta 1 milestone

2020-09-18 Thread Richard Levitte
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 mom

Re: 3.0 beta 1 milestone

2020-09-18 Thread Richard Levitte
0 milestone on everything that we consider a bug fix rather than a new feature. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: 3.0 beta 1 milestone

2020-09-18 Thread Richard Levitte
we characterize certain PRs before beta 1 is released. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: New GitHub label for release blockers

2020-09-15 Thread Richard Levitte
ecessary? Just use the milestones. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: New GitHub label for release blockers

2020-09-14 Thread Richard Levitte
Maybe there's a misunderstand of what "3.0 New Core" means. Please note the lack of comma. But if that doesn't help, how about the project description? I've seen a bit too much of wanting to pile *everything* into that project. That was never the intention. Cheers, Richard -- Ric

Re: Reordering new API's that have a libctx, propq

2020-09-14 Thread Richard Levitte
changed around so there are no compiler warnings if the > user hasn't picked up on reordering of parameters. That is indeed a problem, but I fail to see how removed arguments or the location of added arguments matter much for this. Unless we get into +1 -1 situation and that a 'void *' just

Re: Reordering new API's that have a libctx, propq

2020-09-09 Thread Richard Levitte
ve 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. A stack becomes potentially extra churn in memory allocation for every push, and wondering what to do with the stack

Re: Reordering new API's that have a libctx, propq

2020-09-09 Thread Richard Levitte
fault default", "ultimate default"?) library context already, it's possible that we should rename that to OPENSSL_CTX_set0_current(). Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Reordering new API's that have a libctx, propq

2020-09-09 Thread Richard Levitte
esign, but that's for the farther future and requires a lot of thought and time. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Reordering new API's that have a libctx, propq

2020-09-07 Thread Richard Levitte
On Sun, 06 Sep 2020 23:40:53 +0200, SHANE LONTIS wrote: > > If it is decided that the libctx is more important then the API > should really be something like this.. > OSSL_LIBCTX_MD_fetch(), (and I dont know if that is a good idea.).. I would rather not see that. -- Ric

Re: Reordering new API's that have a libctx, propq

2020-09-06 Thread Richard Levitte
combined, but that requires us to be clear on how it's used in different places. Cheers, Richard On Sat, 05 Sep 2020 23:18:21 +0200, Tim Hudson wrote: > > > On Sun, Sep 6, 2020 at 6:55 AM Richard Levitte wrote: > > I'd rank the algorithm name as the most important, it re

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread Richard Levitte
duces signatures matching > (IMHO) the conventional > usability patterns expected by consumers of the API, is it such a dramatic > conclusion that we want > to exclude it? > > 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 "importance" is the only remaining sorting > criteria, hence > (libctx, propq) are always the most important and should go to the beginning > of the args list > (with the exception of the `self/this` kind of argument that always goes > first)?  > > Nicola > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: OTC VOTE in progress: Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE

2020-08-20 Thread Richard Levitte
Votes have been cast, and the verdict is: accepted: yes (for: 5, against: 1, abstained: 4, not voted: 1) Cheers, Richard On Tue, 18 Aug 2020 13:15:46 +0200, Richard Levitte wrote: > > topic: Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE > >T

OTC VOTE in progress: Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE

2020-08-18 Thread Richard Levitte
. Associated issues and PRs: #12455, #12659 and #12660 Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ otc mailing list o...@openssl.org https://mta.openssl.org/mailman/listinfo

Re: API renaming

2020-07-24 Thread Richard Levitte
hat bothers me about OPENSSL_CTX in particular is the fact that it is a > > mixture of > > a non-abbreviated and an abbreviated word. IMHO it should be either > > OSSL_CTX or > > OPENSSL_CONTEXT, and the former is obviously preferrable for its length. > > > > Matthias

Re: API renaming

2020-07-24 Thread Richard Levitte
e: > > > They also correspond directly to EVP_MAC and EVP_KDF types. Would the types > change as well? > -- > -Todd Short > // tsh...@akamai.com > // “One if by land, two if by sea, three if by the Internet." > > On Jul 23, 2020, at 11:56 AM, Matt Caswell wro

Re: API renaming

2020-07-24 Thread Richard Levitte
ANE LONTIS wrote: > > For (1) the use of either ‘OPENSSL_' OR ‘OSSL_’ is not a particularly great > rule either. > We should decide which one to use and stick to it. > > > On 24 Jul 2020, at 3:20 pm, Richard Levitte wrote: > > > > A couple of points: > > &g

Re: API renaming

2020-07-23 Thread Richard Levitte
; > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > On 24 Jul 2020, at 3:20 pm, Richard Levitte wrote: > > A couple of points: > > 1. Quite a while ago, we (the

Re: API renaming

2020-07-23 Thread Richard Levitte
ew. 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, wrote: >

Re: API renaming

2020-07-23 Thread Richard Levitte
doesn't carry the same sort of history, which makes it much easier for me to think "just do it and get it over with"... Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Naming conventions

2020-07-06 Thread Richard Levitte
ithout a long term strategy. We are too close to 3.0 beta1 to > embark on this journey now. I'm also not convinced that strategically > this is the right pattern to use. What I hear from this is that 3.0 is the wrong time to introduce a new (and hopefully better) public API, that we should post

Re: Naming conventions

2020-06-29 Thread Richard Levitte
, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Naming conventions

2020-06-19 Thread Richard Levitte
osoft... and well, there are quite a few Microsoft ideas that have infiltrated OpenSSL... need I mention '_ex'?) Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Naming conventions

2020-06-18 Thread Richard Levitte
On Thu, 18 Jun 2020 16:36:30 +0200, Matt Caswell wrote: > On 18/06/2020 13:03, Richard Levitte wrote: > > As for not doing something piecemeal, I actually disagree, I see > > benefit in more than just one person getting their hands dirty (plus > > changing everything in one g

Re: Naming conventions

2020-06-18 Thread Richard Levitte
0: ABI concerns aren't a factor, so the old functions can be renamed, and we can preserve the old names as macros. No need for double entries in libcrypto.num. - Cons for 4.0: By that's far away, which means that we solidify the old pattern even more before remaking it. Side note: if we get

Monthly Status Report (May 2020)

2020-06-16 Thread Richard Levitte
openssl/openssl#11980) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Late Monthly Status Report (April 2020)

2020-06-16 Thread Richard Levitte
ncluded 2020-03-04 - Move a set of directories to omc-tools, as per vote concluded 2020-03-04 - Move release-tools/do-release.pl to omc-tools - Give OTC push access to tools - mediawiki: add the NumberHeadings extension -- Richard Levitte levi...@openssl.org OpenSSL Project

Late Monthly Status Report (March 2020)

2020-06-16 Thread Richard Levitte
: Refactor ec_curve_name2nid() to accept NIST curve names (PR openssl/openssl#11391) - PROV: Fix EC_KEY exporters to allow domain parameter keys (PR openssl/openssl#11394) * Web - Fix 'make relupd' -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Late Monthly Status Report (February 2020)

2020-06-16 Thread Richard Levitte
(PR openssl/openssl#11159) - Deprecate ASN1_sign(), ASN1_verify() and ASN1_digest() (PR openssl/openssl#11161) - Fix util/mktar.sh to use the new VERSION information (PR openssl/openssl#11190) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.opens

Late Monthly Status Report (January 2020)

2020-06-16 Thread Richard Levitte
review to be for OTC rather than OMC -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: The hold on PR 12089

2020-06-10 Thread Richard Levitte
n within the OMC. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: addrev warning

2020-06-08 Thread Richard Levitte
native filtering tool such as 'git filter-repo' >(https://github.com/newren/git-filter-repo/) instead. See the >filter-branch manual page for more details; to squelch this warning, >set FILTER_BRANCH_SQUELCH_WARNING=1. > Proceeding with filter-branch... > > >

Re: Travis jobs not getting started

2020-06-06 Thread Richard Levitte
t: > 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

Re: OMC VOTE: Drop the 'openssl' interactive mode as per GH #12023

2020-06-05 Thread Richard Levitte
4 voted for, none against, no abstencions, 3 have not yet voted. This PR will be merged. Cheers, Richard On Wed, 03 Jun 2020 12:46:41 +0200, Richard Levitte wrote: > > topic: Drop the 'openssl' interactive mode as per GH #12023 > comment: It is undocumented, pretty much unused,

OMC VOTE: Drop the 'openssl' interactive mode as per GH #12023

2020-06-03 Thread Richard Levitte
topic: Drop the 'openssl' interactive mode as per GH #12023 comment: It is undocumented, pretty much unused, and hard to keep stable. Proposed by Richard Levitte Public: yes -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: error conversion macro's

2020-05-15 Thread Richard Levitte
ht need updating if any new “error facility” values have been added, > but I didn’t notice any > of them. > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Alpha2

2020-05-14 Thread Richard Levitte
sday 14th May). Unless I hear objections otherwise, I > > plan to go with that. > > I'm currently thinking that we're not quite ready for alpha2 and I would > like to push it by a day. Any objections? Not from me... among others, I want to see #11758 in there... Cheers, Ri

Re: Alpha2

2020-05-08 Thread Richard Levitte
e Alpha 2 release > next week (on Thursday 14th May). Unless I hear objections otherwise, I > plan to go with that. > > Matt > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Technically an API break

2020-05-07 Thread Richard Levitte
> is in the PR). Especially because the error return can happen only when > the application sets up the SSL to use kernel TLS. I agree with this assessment. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Cherry-pick proposal

2020-04-29 Thread Richard Levitte
posal and a request that we vote on it: > > I would like to request that we do not allow cherry-picks between master > and 1.1.1-stable because these two versions are now very different, if a > cherry-pick succeeds, there is no guarantee that the result will work. >

Re: Revisiting tradition: branches and tags

2020-04-14 Thread Richard Levitte
have to be in absolute sync, even though that would be desirable. In other words, we can figure out the details of 2 even after we've started 1. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Revisiting tradition: branches and tags

2020-04-13 Thread Richard Levitte
github. Ref git help symbolic-ref Cheers, Richard ( still thinks it's worth making the change with 3.0 ) > > Matt > > > > > > Matthias > > > > > > > >> -Original Message- > >> From: openssl-project On Behalf Of >

Revisiting tradition: branches and tags

2020-04-10 Thread Richard Levitte
, Richard (*) Well, not quite, there was RCS, there was SCCS, and a few other versioning systems that would make your skin crawl by today's standards, even more so than CVS. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

RE: Release done

2020-03-17 Thread Richard Levitte
The problem was running "make relupd" in the web worktree. It assumes CHANGES and NEWS in all branches. We could have discovered this earlier...  "Dr. Matthias St. Pierre" skrev: (17 mars 2020 19:53:12 CET) >> Problems were due to: >> ... >> - Rename of CHANGES/NEWS to CHANGES.md/NEWS.md >

Re: An OpenSSL cookbook, where and how?

2020-03-07 Thread Richard Levitte
On Sat, 07 Mar 2020 10:01:59 +0100, Richard Levitte wrote: > > As part of a documentation effort, more specifically in some > discussions in https://github.com/openssl/openssl/pull/11220 (exact > references below), I've floated the idea that bigger coding examples > s

An OpenSSL cookbook, where and how?

2020-03-07 Thread Richard Levitte
this, where do we want that cookbook? Who keeps it up to date, and how? https://wiki.openssl.org/ could be one answer, but is it the answer we want? Thoughts welcome! Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Deprecations

2020-02-22 Thread Richard Levitte
l those aged commands and rewrite them as wrappers for genpkey, pkey and pkeyutl. Simply create and populate a new argv and call genpkey_main(), pkey_main() or pkeyutl_main(). std::mantra: PR welcome! Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Deprecations

2020-02-22 Thread Richard Levitte
't a great solution. (as a matter of fact, I would turn everything to go through the EVP interface, whether the '-evp' option has been given or not) Cheers, Richard ( std::mantra: PR welcome! ) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Deprecations

2020-02-21 Thread Richard Levitte
"Salz, Rich" skrev: (21 februari 2020 17:17:54 CET) >>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

Re: Deprecations

2020-02-21 Thread Richard Levitte
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. Cheers Richard Kurt Roeckx skrev: (21

Re: Deprecation

2020-02-14 Thread Richard Levitte
On Fri, 14 Feb 2020 12:17:30 +0100, Dmitry Belyavsky wrote: > > > Dear Richard, > > On Fri, Feb 14, 2020 at 1:37 PM Richard Levitte wrote: > > It should be pointed out that the engine stuff isn't as stable as you > might think, because it shares internal s

Re: Deprecation

2020-02-14 Thread Richard Levitte
and it will > be great if somebody else could look at PR 10904 to avoid it when > possible). Apart from a few details, that PR looks rather innocuous. I frankly haven't had time to look at it too deeply (I just discovered that I was prompted), as I haven't dived in the CMS code yet..

Re: fips mode and key management

2020-01-21 Thread Richard Levitte
se external keys? > > > Regards > Roumen Petrov > > P.S. If is not allowed this regression to previous FIPS > releases(validations). > Neither OpenSSL nor Red Hat nor Solaris FIPS validation forbid use of > "external" keys. > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: crypt(3)

2020-01-17 Thread Richard Levitte
Right. Such a KDF could be implemented elsewhere, as a separate project. Cheers Richard Kurt Roeckx skrev: (17 januari 2020 21:35:00 CET) >On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote: >> I’ve got several choices: >> Leave them public and unchanged — that is, don’t deprecate

Re: crypt(3)

2020-01-17 Thread Richard Levitte
necessary. > > Thoughts? Other alternatives? > > I don't know enough about embedded systems to speak about what if > anything we need to do for those with respect to crypt(). > > -- >Viktor. > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Legacy provider

2020-01-15 Thread Richard Levitte
t; clarity on the circumstances would be helpful, if possible. This was a vote that I found extremely difficult. This topic has been disputed on and off for quite a while, both on github and within the OMC, and I could never decide between the two sides. Both have pros and cons that outweigh each

monthly Status Report (December 2019)

2019-12-28 Thread Richard Levitte
- Block pushes to branches on the main repo that are now EOL (1.1.0 and 1.0.2) - Added xymon entry for internal github instance - Set up infrastructure for premium customers -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Late Monthly Status Report (November 2019)

2019-12-28 Thread Richard Levitte
(PR openssl/openssl#7390) - [unpublished] Support serializers in 'openssl provider' and 'openssl list' -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Late Monthly Status Report (September 2019)

2019-12-28 Thread Richard Levitte
) * System administration - Installed and set up internal github EE instance - Fixed letsencrypt issues with our gitlab instance - Modernized our apache config template usage -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Late Monthly Status Report (September 2019)

2019-12-28 Thread Richard Levitte
) * System administration - Installed and set up internal github EE instance - Fixed letsencrypt issues with our gitlab instance - Modernized our apache config template usage -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Late Monthly Status Report (October 2019)

2019-12-28 Thread Richard Levitte
/openssl#10187) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Late Monthly Status Report (August 2019)

2019-12-28 Thread Richard Levitte
internal github EE instance - Fixed letsencrypt issues with our gitlab instance - Modernized our apache config template usage -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Flaw in our process for dealing with trivial changes

2019-12-13 Thread Richard Levitte
https://github.com/openssl/tools/pull/49 Quite an exercise, I think my python-fu has increased significantly. I have *no* idea how to debug CGI stuff in a sensible way, suggestions welcome! Cheers, Richard On Fri, 13 Dec 2019 12:08:42 +0100, Richard Levitte wrote: > > clacheck modifi

Re: Flaw in our process for dealing with trivial changes

2019-12-13 Thread Richard Levitte
vial” :( > I’ve not reverted it at this point but will if necessary. > > Let’s get the label in. > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > On 13 Dec 2019, at 11:02 am

Re: AW: Flaw in our process for dealing with trivial changes

2019-12-13 Thread Richard Levitte
t; > closes and re-opens a PR... or whatever other action that triggers > > the "pull_request" event (and there's a lot that does that... our > > script is being kept busy!). > > > > Cheers, > > Richard > > > This seems to be implied already by my last p

Re: Flaw in our process for dealing with trivial changes

2019-12-12 Thread Richard Levitte
el will rapidly be annoying as soon as someone closes and re-opens a PR... or whatever other action that triggers the "pull_request" event (and there's a lot that does that... our script is being kept busy!). Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project

Re: AW: Flaw in our process for dealing with trivial changes

2019-12-12 Thread Richard Levitte
l, the problem we have hit is that "CLA: trivial" can go undetected, so let's make sure it doesn't, without adding a lot of other redundant mechanisms that only make our lives harder, yeah? Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Flaw in our process for dealing with trivial changes

2019-12-12 Thread Richard Levitte
- IF there's a 'CLA: Trivial' line: # - at least one of the reviewers MUST have a CLA and MUST be member of the # 'omc' group. # - at least two of the reviewers MUST have a CLA and MUST be member of the # 'commit' group. (gitolite works by having a denial on any output VREF/UNREVIEWED/ line) Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: AW: Check NULL pointers or not...

2019-11-28 Thread Richard Levitte
orgotten that one, so reminder appreciated. Looking at the diff shows me that there's a precedent for what I proposed (using ossl_assert). Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Check NULL pointers or not...

2019-11-27 Thread Richard Levitte
. Thoughts? Cheers, Richard [1] https://github.com/openssl/openssl/pull/7630 -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Re-requesting reviews on GitHub

2019-10-30 Thread Richard Levitte
This is a good idea, and also a detectable event for a bot to listen to. Cheers Richard "Dr. Matthias St. Pierre" skrev: (30 oktober 2019 09:30:11 CET) >> Independently of the new 'approval: *' state labelling I was >wondering whether it wouldn't >> be a good idea to adopt the habit of

Re: Build failures on master

2019-09-29 Thread Richard Levitte
> > https://travis-ci.org/openssl/openssl/jobs/590874670 > > Test Summary Report > --- > 30-test_evp.t(Wstat: 256 Tests: 19 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > 30-test_evp_fetch_prov.t (Wstat: 5376 Tests: 34 Failed: 21) > Failed tests: 1, 9-18, 25-34 > Non-zero exit status: 21 > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: AW: Being socially aware

2019-09-17 Thread Richard Levitte
t; > Second, looking at the profile of the contributor, one can assert that he > might > be relatively new to our project, but he is certainly experienced in Open > Source > development. So I wouldn't worry too much about his feelings  > > Regards, > Matthias >

Being socially aware

2019-09-16 Thread Richard Levitte
s how we welcome new contributors, they might more often than not choose to step away from it all. So maybe let's be a little more careful with contributions for "good first issue" and potential newcomers, yeah? Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project

Deprecation of stuff

2019-09-02 Thread Richard Levitte
started with the following four questions, for as many of us to answer as possible: 1. Why should we deprecate stuff 2. Why should we not deprecate stuff 3. When should we deprecate stuff 4. When should we not deprecate stuff Cheers, Richard -- Richard Levitte levi...@openssl.org

Re: GitHub issue template for general questions

2019-09-01 Thread Richard Levitte
> interaction on the mailing lists is fading and more and more user questions > are being asked on > GitHub. What do you think about the suggestion? > > Matthias > > > > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Monthly Status Report (July 2019)

2019-08-14 Thread Richard Levitte
by creating a LLVM volume for them on an unused partition, moving them there, then added the old partition to that volume. * Internal - Better logging of gitolite triggers -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Late Monthly Status Report (June 2019)

2019-08-14 Thread Richard Levitte
names per algorithm (PR openssl/openssl#8967) - [1.1.1 only] Backported the modification to only output DER with SPKAC input and when -out is chosen (PR openssl/openssl#8368) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Late Monthly Status Report (May 2019)

2019-08-14 Thread Richard Levitte
C++ build tests optional and configurable to 1.1.1 (PRs openssl/openssl#8370 and openssl/openssl#9016) * Internal - Recorded a number of committers that accepted their invitations while in Vancouver * System administration - Worked on our Apache configs to remove some kinks -- Rich

Late Monthly Status Report (April 2019)

2019-08-14 Thread Richard Levitte
sl/openssl#8622) * System administration - Worked on our bind configuration for better templating of repeated data. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Machine downtime tomorrow morning

2019-07-26 Thread Richard Levitte
Now done. It all went smoothly. Cheers, Richard ( your friendly sysadmin of the day ) On Thu, 25 Jul 2019 22:10:08 +0200, Richard Levitte wrote: > > I'm in the process of moving our VMs to a new volume with more space, > which as running short in the current VM partition. > &g

Planning for future downtime

2019-07-25 Thread Richard Levitte
Our main server, which hosts all our VMs, will need some maintenance some time soon. I plan to do this in the second half of August. Flag day will be announced after my time off. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org

Machine downtime tomorrow morning

2019-07-25 Thread Richard Levitte
, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Time off the next two weeks

2019-07-25 Thread Richard Levitte
I will take partial time off from Monday July 29th to the weekend after and full time off from Sunday August 4th to Thursday August 9th. Partial time off means that I might still spend a couple of hours daily on OpenSSL, as time allows. Cheers, Richard -- Richard Levitte levi

Taking some rest

2019-07-18 Thread Richard Levitte
tomorrow, I plan on being fairly minimally present until Monday (just in case you find my responses slow). Cheers, Richard ( feels like a balloon that lost all its air ) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Do we really want to have the legacy provider as opt-in only?

2019-07-15 Thread Richard Levitte
", so I don't quite understand "oversimplified". Regardless of where this discussion gets us, it has always been the aim that this will be configurable with the config file. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Vote FYI: Remove function codes from error reporting functions as per PR#9058

2019-07-10 Thread Richard Levitte
The vote closed today, with the following result: +1: 4 0: 3 (where one is a -0) -1: 0 The vote passes. Cheers, Richard On Thu, 04 Jul 2019 18:01:59 +0200, Richard Levitte wrote: > > topic: Remove function codes from error reporting functions as per PR#9058. > comment:

Re: Cleaning up include file inconsistencies

2019-07-06 Thread Richard Levitte
gt; crypto/include/crypto, and thereby did > > this: > > > > #include "crypto/evp.h" > > > > That, to me, is much clearer than the "_int" suffix. > > This sounds like an excellent idea to me. "Someone" should create a PR... Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: AW: Cleaning up include file inconsistencies

2019-07-06 Thread Richard Levitte
ere are two header files. I must have forgotten about one of them when creating the other... They should be merged into one. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: AW: Cleaning up include file inconsistencies

2019-07-06 Thread Richard Levitte
rer if we renamed crypto/include/internal -> crypto/include/crypto, and thereby did this: #include "crypto/evp.h" That, to me, is much clearer than the "_int" suffix. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Vote FYI: Remove function codes from error reporting functions as per PR#9058

2019-07-04 Thread Richard Levitte
topic: Remove function codes from error reporting functions as per PR#9058. comment: Discussed in https://mta.openssl.org/pipermail/openssl-project/2019-June/001426.html Proposed by Richard Levitte opened: 2019-07-04 closed: -mm-dd I will follow up with the tally when the vote

Re: OSSL_PARAM thought

2019-07-02 Thread Richard Levitte
> one line many times seems like a win. > > Pauli > -- > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Removing function names from errors (PR 9058)

2019-06-14 Thread Richard Levitte
onf.h.in isn't the best place for this kind of macro, not even for OPENSSL_FILE and OPENSSL_LINE. I'd rather move all that to e_os2.h. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Richard Levitte
On Thu, 13 Jun 2019 22:04:17 +0200, Roumen Petrov wrote: > > Richard Levitte wrote: > > On Thu, 13 Jun 2019 20:23:05 +0200, > > Roumen Petrov wrote: > >> Hello, > >> > >> First I did not understand what is wrong to use function or > >> r

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Richard Levitte
d those useful. Function codes, on the other hand, are unstable and thereby quite useless, at least for figuring out errors. > To parse openssl error code in an application code is bad practice. Is it? Would you say it's bad practice to look at errno codes too? Error *text* is a different matt

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Richard Levitte
at which point it might choose to try and mitigate. The question is what's easier for the application, getting the wanted information as a top error or having to walk to the bottom of the error stack to figure things out. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Richard Levitte
function call that includes the flexibility of BIO_printf() probably would encourage producing better information. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/

  1   2   3   >