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..
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
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
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/
heers,
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
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/
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
” 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
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
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
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
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
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
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/
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
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
-
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/
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/
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
_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
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
0.0 milestone. Why would that be
necessary? Just use the milestones.
--
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/
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/
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
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/
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
; 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/
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
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
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&
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
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/
mas [ ]
> Kurt [ ]
> Matthias [ ]
> Nicola [+1]
>
--
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_
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/
cepted: yes/no (for: X, against: Y, abstained: Z, not voted: T)
>
> Matt [+1]
> Mark [ ]
> Pauli [ ]
> Viktor [ ]
> Tim[ ]
> Richard[ ]
> Shane [ ]
> Tomas [ ]
> Kurt [ ]
> Matthias [
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/
; 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/
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
machine
* Other:
- Performed the release of OpenSSL 3.0.0 alpha5
--
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/
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/
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
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/
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/
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
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/
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/
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/
vote passes.
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
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
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
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
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
penssl/web#216)
--
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/
buildbot master development / configuration / setup
--
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
voted: T)
>
> Matt [+1]
> Pauli [ ]
> Tim[ ]
> Richard[ ]
> Shane [ ]
> Tomas [ ]
> Kurt [ ]
> Matthias [ ]
> Nicola [ ]
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
=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/
/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]
>
--
-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 [ ]
>
t; Matt [ ]
> Pauli [ ]
> Tim [ ]
> Richard [ ]
> Shane [ ]
> Tomas [+1]
> Kurt [ ]
> Matthias [ ]
> Nicola [ ]
>
>
>
--
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/
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/
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/
renewal scripts
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
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
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
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/
a specific group
in OMC tools OpenSSL::Query, QueryApp
--
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/
eople and CLA databases being moved
--
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/
a specific group
in OMC tools OpenSSL::Query, QueryApp
--
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
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/
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/
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
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: 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: 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: 2e5697419515a0a25eb0820998123a9f325ea153
https://github.com/openssl/general-policies/commit/2e5697419515a0a25eb0820998123a9f325ea153
Author: Richard Levitte
Date: 2022-10-12 (Wed, 12 Oct 2022
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
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
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
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: 2de222ffce6c32685988c7dac091c55415c96dea
https://github.com/openssl/general-policies/commit/2de222ffce6c32685988c7dac091c55415c96dea
Author: Richard Levitte
Date: 2024-05-17 (Fri, 17 May 2024
301 - 393 of 393 matches
Mail list logo