Branch: refs/heads/master
Home: https://github.com/openssl/general-policies
Commit: 2de222ffce6c32685988c7dac091c55415c96dea
https://github.com/openssl/general-policies/commit/2de222ffce6c32685988c7dac091c55415c96dea
Author: Richard Levitte
Date: 2024-05-17 (Fri, 17 May 2024
Branch: refs/heads/master
Home: https://github.com/openssl/general-policies
Commit: 2dd1d86c5c0e5c9996938449503f7f195b17d859
https://github.com/openssl/general-policies/commit/2dd1d86c5c0e5c9996938449503f7f195b17d859
Author: Richard Levitte
Date: 2022-10-12 (Wed, 12 Oct 2022
Branch: refs/heads/master
Home: https://github.com/openssl/general-policies
Commit: 1d2377fbe6bdd673430923eeab56d3f8d59056ce
https://github.com/openssl/general-policies/commit/1d2377fbe6bdd673430923eeab56d3f8d59056ce
Author: Richard Levitte
Date: 2022-10-12 (Wed, 12 Oct 2022
Topic: Accept PR#19375 to add RIPEMD160 to the default provider for 3.0 subject
to the normal review process
Proposed by: Tim
Public: yes
Opened: 2022-10-12
Closed: 2022-10-12
Accepted: yes/no (for: 3, against: 0, abstained: 2, not voted: 1)
Matt [+1]
Mark [+1]
Pauli
Topic: Provider selection and handling for SHA1 and RIPEMD160 should be
identical
given the current understanding of algorithm specific security issues.
Proposed by: Tim
Public: yes
Issue link: https://github.com/openssl/general-policies/issues/35
Opened: 2022-10-12
Closed: 2022-10-12
Accep
Branch: refs/heads/master
Home: https://github.com/openssl/general-policies
Commit: 2e5697419515a0a25eb0820998123a9f325ea153
https://github.com/openssl/general-policies/commit/2e5697419515a0a25eb0820998123a9f325ea153
Author: Richard Levitte
Date: 2022-10-12 (Wed, 12 Oct 2022
Branch: refs/heads/master
Home: https://github.com/openssl/general-policies
Commit: b8b85215e2596a47b98ed37ba161ef9e566ef24c
https://github.com/openssl/general-policies/commit/b8b85215e2596a47b98ed37ba161ef9e566ef24c
Author: Richard Levitte
Date: 2022-10-12 (Wed, 12 Oct 2022
Branch: refs/heads/master
Home: https://github.com/openssl/general-policies
Commit: 918c86138a5d2495dc83e50781fc583cd4bd1992
https://github.com/openssl/general-policies/commit/918c86138a5d2495dc83e50781fc583cd4bd1992
Author: Richard Levitte
Date: 2022-10-12 (Wed, 12 Oct 2022
Branch: refs/heads/master
Home: https://github.com/openssl/general-policies
Commit: 59dbd96730d772be7341b17db609735908becb6a
https://github.com/openssl/general-policies/commit/59dbd96730d772be7341b17db609735908becb6a
Author: Richard Levitte
Date: 2022-10-12 (Wed, 12 Oct 2022
Branch: refs/heads/master
Home: https://github.com/openssl/general-policies
Commit: 2b23a45c28c1357b2859325f08d98ffca004488f
https://github.com/openssl/general-policies/commit/2b23a45c28c1357b2859325f08d98ffca004488f
Author: Richard Levitte
Date: 2022-10-12 (Wed, 12 Oct 2022
p
error, with Github support assistance
- Fixed Zenhub downtime, with Zenhub support assistance
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
Google Workspace setup for OpenSSL
- Add an admin HOWTO for adding management network VPN clients
* Other:
- Strawman manager policy
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
- log: add management network to openssl-auth (auth.openssl.org)
** System configuration:
- iptables: Allow guests on the management network to reach each other
- apache: Reconfigure www.openssl.org/docs as alias to /var/www/docs
- apache: enable SSI on .html files in /var/www/docs
- bin
a specific group
in OMC tools OpenSSL::Query, QueryApp
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
a specific group
in OMC tools OpenSSL::Query, QueryApp
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
eople and CLA databases being moved
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
ckets for work.openssl.org
** Other
- Added HOWTOs on cloning pr creating a new guest
- Updated hardware and network information
- Updated our internal admin handbook
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
a specific group
in OMC tools OpenSSL::Query, QueryApp
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
pages
** System configuration
- apache: modify the /blog alias for www.openssl.org
- Restored our mailman installation to Ubuntu packaging, and
upgraded it.
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
openssl/web#269)
- bin/mk-latest: Treat post 1.x.x releases right
(PR openssl/web#271)
- Unify source archives
(PR openssl/web#272)
- Drop source/snapshot/README
(PR openssl/web#275)
* Internal:
- do-release.pl: don't copy tarballs to /var/www/openssl/source any more
--
Ri
openssl/web#269)
- bin/mk-latest: Treat post 1.x.x releases right
(PR openssl/web#271)
- Unify source archives
(PR openssl/web#272)
- Drop source/snapshot/README
(PR openssl/web#275)
* Internal:
- do-release.pl: don't copy tarballs to /var/www/openssl/source any more
--
Ri
generated from template
(PR openssl/web#258)
* Internal:
* Sysadm:
- Drop all traces of Request-Tracker
- Drop run.openssl.org
- Install a Mac Mini Intel and a buildbot worker on it
- Install Zenhub instance
--
Richard Levitte levi...@openssl.org
OpenSSL Project http
renewal scripts
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
ildbot master
* Sysadmin:
- Decomissioned the Stockholm server
- Wrote an Administrator Handbook for our staff
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
re than just HTML files
(PR openssl/web#241)
* Internal:
- Worked on more details of the FIPS buildbot master
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
FIPS buildbot master
* Sysadm:
- Updated some configurations for newer Ubuntu installations (18.04
and 20.04)
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
t; Matt [ ]
> Pauli [ ]
> Tim [ ]
> Richard [ ]
> Shane [ ]
> Tomas [+1]
> Kurt [ ]
> Matthias [ ]
> Nicola [ ]
>
>
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-10
> closed: 2021-mm-dd
> accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T)
>
> Dmitry [ 0]
> Matt [+1]
> Pauli [ ]
> Tim[+1]
> Richard[ ]
> Shane [+1]
> Tomas [+1]
> Kurt [ ]
>
/no (for: X, against: Y, abstained: Z, not voted: T)
>
> Dmitry [+1]
> Matt [+1]
> Pauli [ ]
> Tim[-1]
> Richard[ ]
> Shane [-1]
> Tomas [+1]
> Kurt [ ]
> Matthias [ ]
> Nicola [-1]
>
--
=2 l= 3 prim: INTEGER :010001
That's a badly formatted RSAPrivateKey (it looks like a RSAPublicKey).
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
voted: T)
>
> Matt [+1]
> Pauli [ ]
> Tim[ ]
> Richard[ ]
> Shane [ ]
> Tomas [ ]
> Kurt [ ]
> Matthias [ ]
> Nicola [ ]
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
ease yet
(PR openssl/web#233)
- Reorder the old source directory list in source/old/
(PR openssl/web#236)
* Internal:
- release-tools: Separate do-release.pl docs from mkrelease.pl docs
(dir internal/tools) [9d9c86fe443afcb8a13a8ae40b91674a6afefcd3]
* Sysadm:
- Add new instruction on how
buildbot master development / configuration / setup
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
purious & in the description
(PR openssl/web#214)
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
penssl/web#216)
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
enssl/openssl#13700)
- GitHub CI: Add 'check-update' and 'check-docs'
(PR openssl/openssl#13701)
- TEST: Fix test/endecode_test.c for 'no-legacy'
(PR openssl/openssl#13705)
- Fix 'no-deprecated'
(PR openssl/openssl#13706)
--
Richard Levitte
rect digestinfo_ripemd160_der[]
(PR openssl/openssl#13562)
* Web:
- REVIEWED: Update newsflash for alpha 8 release
(PR openssl/web#206 by mattcaswell)
- REVIEWED: Update newsflash for new release
(PR openssl/web#208 by mattcaswell)
--
Richard Levitte levi...@openssl.org
Ope
d: 2021-mm-dd
> accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T)
> Matt [ ]
> Mark [ ]
> Pauli [ ]
> Viktor [ ]
> Tim [ ]
> Richard [ ]
> Shane [ ]
> Tomas [ ]
> Kurt [ ]
> Ma
branch) is useless outside of SSLv2
> support. We do not support SSLv2 and we do not expect anybody using
> OpenSSL 3.0 to try to support SSLv2 by calling those functions.
>
> Proposed by Tomas Mraz.
>
> public: yes
> opened: 2021-02-23
>
>
>
--
Richard Lev
vote passes.
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
rameters, but then they probably
> shouldn't be using that provider to begin with.
>
> > After that the provided EVP object should be either in a consistent
> state
> > or not, assuming the upcoming operation.
>
> The object should always be in a consistent state. I would prefer
> that in case of failure the object is not created (or modified).
> Which brings us to some other open points about the API we have. We
> should not introduce new APIs where you can modify the state of the
> object, so it can not be in a non-consistent state. It's much more
> simple to get things correct in that case. But as long as we have
> to support old APIs where it can be modified, the prefered
> consistent state is to not mofify the object on error. Some APIs make
> this very hard, so the other acceptable state is that you can free
> the object. With an API that doesn't allow modification, either
> you get a complete object, or you get no object.
>
> Kurt
>
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
overrules the
> * all implementations apart from EC require the public component to
> be present;
>part of the vote closed on 2020-11-17.
>
> Proposed by Tomas Mraz
> Public: yes
> opened: 2020-12-04
>
> Tomas Mraz
>
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
ior triggering
>early exits (compared to previous versions of the apps), as bug
>fixes, they do not qualify as behavior changes that require an
>explicit OMC approval.
> Proposed by Nicola Tuveri
> Public: yes
> opened: 2020-11-30
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
VP_PKEY` object on load
> (and with some caching mechanism to validate keys created manually via
> `EC_KEY` objects): this would once again reveal that the use pattern
> in #12612 was invalid to begin with, as the validity checks were
> enforcing the "keypair assumption" in
ST CURVE: P-256
> ; dd if=/dev/zero of=/tmp/foo.hash bs=1 count=32
> ; openssl pkeyutl -sign -inkey /tmp/p256_invalid.pem -in /tmp/foo.hash
> -out /tmp/sig.der
> # here is the infinite loop
> ~~~
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
penssl/evp.h
int EVP_PKEY_private_check(EVP_PKEY_CTX *ctx);
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
exact same d2i_{TYPE}PrivateKey()
internally, which do the actual work.
The only actual work remaining to fix the regression is to relax the
EC keymgmt import function to accept receiving a private key without
the public key. It doesn't actually need to regenerate a public key
either. That
Web:
- [reviewed] Add a new section to the Coding Style about argument ordering
(PR openssl/web#194 by mattcaswell)
- [reviewed] Add a new section to the Coding Style about extending existing
functions
(PR openssl/web#195 by mattcaswell)
--
Richard Levitte levi...@openssl
)
- [not_yet_published] Adapt OpenSSL 3.0 for VMS
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
] Fix PEM_write_bio_PrivateKey_traditional() to not output PKCS#8
(PR openssl/openssl#12729)
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
machine
* Other:
- Performed the release of OpenSSL 3.0.0 alpha5
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
pps/openssl: Fix buffer-overflow for command with no arguments
(PR openssl/openssl#12259)
- apps/openssl: clean-up of unused fallback code
(PR openssl/openssl#12295)
* Other:
- Performed the transition from travis-ci.org to travis-ci.com.
--
Richard Levitte levi...@open
; feature, for instance because we don't want to use it at all or we
> want to reduce the size of the binries.
>
>
> Kurt
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
1_METHOD and all the associated functions
> should be marked
> deprecated in my view.
>
> Tim.
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
cepted: yes/no (for: X, against: Y, abstained: Z, not voted: T)
>
> Matt [+1]
> Mark [ ]
> Pauli [ ]
> Viktor [ ]
> Tim[ ]
> Richard[ ]
> Shane [ ]
> Tomas [ ]
> Kurt [ ]
> Matthias [
s
> opened: 2020-10-08
> closed: 2020-mm-dd
> accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T)
>
> Matt [+1]
> Mark [ ]
> Pauli [ ]
> Viktor [ ]
> Tim[ ]
> Richard[ ]
> Shane [ ]
> Tomas [ ]
> Kurt [ ]
> Matthias [ ]
> Nicola [ ]
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
Cancel that, wrong vote.
For this, 0
On Tue, 13 Oct 2020 10:09:12 +0200,
Richard Levitte wrote:
>
> +1
>
> On Fri, 09 Oct 2020 14:02:29 +0200,
> Tomas Mraz wrote:
> >
> > topic: The PR #11359 (Allow to continue with further checks on
> > UNABLE_TO_VERIFY_
mas [ ]
> Kurt [ ]
> Matthias [ ]
> Nicola [+1]
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
Turkish proverb
> [You'll know whether the road is wrong if you carefully listen to your
> conscience.]
>
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
On Wed, 07 Oct 2020 21:25:57 +0200,
Nicola Tuveri wrote:
>
> On Wed, 7 Oct 2020 at 20:45, Richard Levitte wrote:
> >
> > I'm as culpable as anyone re pushing the "convention" that an EVP_PKEY
> > with a private key should have a public key. I was incorre
ecks on the public key
> component because it is our convention that an EVP_PKEY with key
> material is either a public key or a key pair.
>
>
> Nicola
>
> On Wed, 7 Oct 2020 at 19:52, Richard Levitte wrote:
> >
> > As far as I can tell, the existing "enforcement&
is in
> > the current 3.0 code causing a regression.
> >
> > There are differences of opinion on how this should be handled. Some
> > have the opinion that we should change the model so that we explicitly
> > allow private keys to exists without the public components
s not historically been enforced, and it now is in
> > the current 3.0 code causing a regression.
> >
> > There are differences of opinion on how this should be handled. Some
> > have the opinion that we should change the model so that we explicitly
> > allow private ke
; 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/
welcome.
Cheers,
Richard
--
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
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/
things *must* go in before we can 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
t the 3.0.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/
g how we
characterize certain PRs before beta 1 is released.
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
0.0 milestone. Why would that be
necessary? Just use the milestones.
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
e of which I think is questionable:
#10612
#4930
#12860
#11311
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 *everyth
_fetch function model)
> My context there is for the users of the existing API.
> It becomes especially problematic if you have type equivalence when
> the order is changed around so there are no compiler warnings if the
> user hasn't picked up on reordering of parameters.
That
ld have 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
x27;s an internal default ("default 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/
-
Thoughts?
Cheers,
Richard
[*] The OpenSSL API could do with a re-design, 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/
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
ng it as all of these 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 n
happens rarely and for
> good reasons) seems the one that in the end produces 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/
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
ation.
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/lis
gt; What 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.
> >
> > Matt
Todd wrote:
>
>
> 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 Ca
0 07:55:10 +0200,
SHANE 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
” for ages.
>
> 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 whi
ng 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 Fr
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/
onfusion without 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
heers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
especially popularised
by Microsoft... 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/
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
ctions, making for a bigger
libcrypto.num.
- Pros for 4.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: Booooy that's far away, which means that we solid
patch()
(PR openssl/openssl#11980)
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
the omc-tools repo, as per vote concluded 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..
- EC: 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/
rtain pragmas
(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 h
- Switch final review to be for OTC rather than OMC
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
ussion within the OMC.
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
e an
>alternative 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.
> Proceedin
in this document:
> 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
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
1 - 100 of 393 matches
Mail list logo
