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
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/
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
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
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
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/
.
Thoughts?
Cheers,
Richard
[1] https://github.com/openssl/openssl/pull/7630
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~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
"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
'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/
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/
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..
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
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
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/
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/
(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/
- 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/
)
* 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/
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/
)
* 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/
/openssl#10187)
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~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/
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
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
>
,
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/
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.
>
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/
> 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/
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
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/
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/
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
>
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/
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
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
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/
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/
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
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
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
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. Others feel
> > that w
w 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. O
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 algorithm
> > implement
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_VER
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/
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/
cepted: yes/no (for: X, against: Y, abstained: Z, not voted: T)
>
> Matt [+1]
> Mark [ ]
> Pauli [ ]
> Viktor [ ]
> Tim[ ]
> Richard[ ]
> Shane [ ]
> Tomas [ ]
> Kurt [ ]
> Matthias [
all or we
> want to reduce the size of the binries.
>
>
> Kurt
>
--
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 incorrect.
&
nd all the associated functions
> should be marked
> deprecated in my view.
>
> Tim.
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~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
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
; 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/
--
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
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/
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/
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
,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~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
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
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
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/
: 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/
review to be for OTC rather than OMC
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~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
openssl/openssl#11980)
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
n within the OMC.
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~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/
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
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...
>
>
>
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,
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
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/
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:
>
;
> 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
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
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
b 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 levi...@openssl.org
OpenSSL Project http://www.openssl
nt / configuration / setup
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
on
(PR openssl/web#214)
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
ource/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 to extend GHE storage space
(dir admin/admin) [4d95719e6fef8bc50f20ad7dc0df
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
: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 [ ]
>
r
* 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/
nternal:
- Worked on more details of the FIPS buildbot master
--
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
--
Richard
dmin:
- Decomissioned the Stockholm server
- Wrote an Administrator Handbook for our staff
--
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
and renewal scripts
--
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
--
Richard
t; Matt [ ]
> Pauli [ ]
> Tim [ ]
> Richard [ ]
> Shane [ ]
> Tomas [+1]
> Kurt [ ]
> Matthias [ ]
> Nicola [ ]
>
>
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
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/
and CLA databases being moved
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
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/
for a specific group
in OMC tools OpenSSL::Query, QueryApp
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
201 - 300 of 313 matches
Mail list logo
