I kept seeing tweets about a future OSTIF audit, and just saw that they now
have funding:
https://twitter.com/OSTIFofficial/status/989421638960713728
Is this interesting to us? Should we synchronize with them?
Cheers
Richard
--
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordigh
Like I think I mentioned a few days ago, I'm currently on a conference. I'll
take this up in more depth later this week.
I have a question, though... Kurt said at some point that all that was needed
on the VMS side was to collect data, the rest can be done elsewhere
(thankfully). However, I don
provide a means for
openssl-users> users to turn that off.
With our current version scheme, you should use the compatibility mask
0xFFF0
(maybe we should have that value in opensslv.h... Matthias St. Pierre
might have an idea or two on the matter, too)
Cheers,
Richard
--
Richard Levitte
like to know
how
openssl-users> > applications behave with the current version.
openssl-users>
openssl-users> It is perhaps unclear in the last sentence what "the current
version"
openssl-users> means.
I took that to mean "the 1.1.0 series"
--
Richard Levitte
I will be pretty much absent starting now and until tuesday. Monday
and Tuesday, I'm attending this event:
https://www.eventbrite.com/e/hp-connect-sweden-vms-sig-annual-meeting-tickets-42639545027
I might be responding to email sporadically. Don't wait up ;-)
Cheers,
Richard
-
openssl-users> We don't have much time before release, what do we do?
If we can't resolve this, there is the option of delaying the
release. The release strategy is clear on this: "This may be amended
at any time as the need arises."
(https://www.openssl.org/policies
filter that says "find my PR's" It's just
rsalz> on the left side of the search box.
Thanks... Now to remember to go there ;-) (I usually start from the
notifications page and relatively seldom go to the PR list... it's a
habit I probably should change)
--
Richar
.Pierre> we could make this a general pattern?
This has actually varied a bit. What I've observed is that the first
to approve is oftentimes the one that merges, unless something else is
said (there have been some PRs where people have asked each other).
Self assigning is a good habit
When someone with write access to the main repo makes a PR and it gets
approved, we usually wait for the person to do the final merge. This
is perfectly fine to expect from us who are so called fellows, i.e.
who are payed directly to work on OpenSSL... but to ask this of
everyone else, when their
In message on Tue, 17 Apr
2018 14:32:37 -0400, Viktor Dukhovni said:
openssl-users>
openssl-users>
openssl-users> > On Apr 17, 2018, at 2:15 PM, Richard Levitte
wrote:
openssl-users> >
openssl-users> > Depends on what "the best thing you know to do&quo
In message <87d0yxq0m7@fifthhorseman.net> on Tue, 17 Apr 2018 09:05:52
-0700, Daniel Kahn Gillmor said:
dkg> On Mon 2018-04-16 08:22:59 +0200, Richard Levitte wrote:
dkg> > Generally speaking, I don't necesseraly agree. If the use of an API
dkg> > is perfectly
OpenSSL 1.1.1 pre release 5 done!
Repository is now unfrozen.
Thank you Matt for the review!
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
Hi,
just a reminder that we're scheduled to release openssl-1.1.1-pre5
today.
I'll do the release this time.
If someone could freeze the repo for me, I'd be grateful:
ssh openssl-...@git.openssl.org freeze openssl levitte
Cheers,
Richard
--
Richard Levitte levi
.
dkg> I'm all for making a breaking changes in the OpenSSL API to discourage
dkg> use of bad/legacy API.
That calls for a major version change (in OpenSSL versioning, that
would be 1.2.0). I think we've all come to some kind of agreement
that doing this isn't desirable
also valid in TLSv1.3) or is that essentially
wrong, even though easier to deal with in code? Is that what libssl
is doing, or does it have more of a "look at all the facts" approach
before choosing the proto range to negotiate with the other end?
Cheers,
Richard
--
Richa
take that in a separate email.
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
cannot remember having seen
tests that specifically targets the case of programs built with 1.1.0
that get implicitly relinked with 1.1.1 libraries (that's what you
call "going forward", isn't it?), or data collection for that matter.
I may have missed something, but I am inter
In message on Sat, 14 Apr
2018 16:46:56 -0400, Viktor Dukhovni said:
openssl-users> > On Apr 14, 2018, at 4:40 PM, Richard Levitte
wrote:
openssl-users> >
openssl-users> > Would you say that it's an application bug if it stumbles on a
change
openssl-users> > i
In message <44fe0745-31df-41c3-b697-97025643c...@dukhovni.org> on Sat, 14 Apr
2018 16:24:56 -0400, Viktor Dukhovni said:
openssl-users>
openssl-users>
openssl-users> > On Apr 14, 2018, at 4:18 PM, Richard Levitte
wrote:
openssl-users> >
openssl-users> >> Wi
openssl-users>
openssl-users> 1. Fix any issues so that it is safe to upgrade.
openssl-users> 2. Make the library version 1.2
openssl-users> 3. Hack the API to cap the protocol version based on
compile-time
openssl-users> maximum.
openssl-users>
openssl-users> --
In message <20180414194244.ga27...@roeckx.be> on Sat, 14 Apr 2018 21:42:45
+0200, Kurt Roeckx said:
kurt> On Sat, Apr 14, 2018 at 09:32:31PM +0200, Richard Levitte wrote:
kurt> >
kurt> > a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests
kurt> >
InternalError
alert, but gets ClientFail instead. So the question here is, what
if some program actually pays attention to them? ... and it also
begs the question if the alert type change was a bug fix, and in
that case, why didn't it propagate to
mpatible changes (other than
matt> the draft version number itself).
matt>
matt> If someone gives me a +1 I'll create the above.
+1
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
at
Matthias.St.Pierre> > on appropriately, without butchering the current DRBG
code?
Matthias.St.Pierre>
Matthias.St.Pierre> Hold the line, I'm currently working on it...
Cool, I'll hold.
--
Richard Levitte levi...@openssl.org
OpenSS
A for this release.
Hold that thought a moment more...
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
In message <83ae9015-a766-4497-a71d-d537837cf...@openssl.org> on Sun, 08 Apr
2018 19:15:16 +0200, Richard Levitte said:
levitte>
levitte>
levitte> Kurt Roeckx skrev: (8 april 2018 17:36:27 CEST)
levitte> >On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote:
levit
Kurt Roeckx skrev: (8 april 2018 17:36:27 CEST)
>On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote:
>> On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote:
>> > > Because
>> > > - It is not clear we need to do so
>> >
>> > >That we need to do what?
>> >
>>
lz> Who is going to ensure that we improve the code?
All things considered, I think "we" will. There seems to be enough
discussion going on among interested parties, and it does sound like
we want to find a common ground.
Cheers,
Richard
--
Richard
In message <20180408080942.gb3...@roeckx.be> on Sun, 8 Apr 2018 10:09:42 +0200,
Kurt Roeckx said:
kurt> On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote:
kurt> > In message <20180407190250.ga27...@roeckx.be> on Sat, 7 Apr 2018
21:02:51 +0200, Kurt Roeckx
In message <20180407190250.ga27...@roeckx.be> on Sat, 7 Apr 2018 21:02:51
+0200, Kurt Roeckx said:
kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
kurt> > H... case 4 shouldn't pose too much problems unless you restart
kurt> > the applic
forms that
kurt> provide it.
I'm sorry, I'm lost. "the syscalls"? You started refering to
syscalls when discussing getrandom(), so I'm going to assume that it's
related, but I fail to understand how it's related to platforms that
break, and most specificall
In message <20180407174527.gc20...@roeckx.be> on Sat, 7 Apr 2018 19:45:28
+0200, Kurt Roeckx said:
kurt> On Sat, Apr 07, 2018 at 07:00:21PM +0200, Richard Levitte wrote:
kurt> > In message <20180407160031.gb12...@roeckx.be> on Sat, 7 Apr 2018
18:00:32 +0200, Kurt Roeckx
In message <20180407160031.gb12...@roeckx.be> on Sat, 7 Apr 2018 18:00:32
+0200, Kurt Roeckx said:
kurt> On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
kurt> > > Can I suggest you try something like
kurt> > > https://github.com/usnistgov/SP800-90B_En
t by default. You can keep the behaviour that if no get_nonce
kurt> function is set that it increases the entropy requirement.
Aha ok! Yeahok, I see, so if I implement a rand_drbg_get_nonce in
rand_vms.c, we're basically set... but that means we need to
implement a generic one as well, no
2fcc8d2d...@akamai.com> on Sat, 7 Apr 2018
14:15:51 +, "Salz, Rich" said:
rsalz> I would like to see this put on hold until we fix the ‘now requires 50%
more random seeding’ issue.
rsalz>
rsalz> What should I do to force that issue?
rsalz>
rsalz> From: Richard Levitte
rs
I don't have to port a C++11 program to VMS, 'cause unfortunately,
the existing C++ compiler hasn't had a real update for quite a while
:-/ (I'm sure that VSI is quite busy updating all they can, but they
haven't let anything out yet)
But either way, creating a bette
to try to port to anything that
doesn't look like a POSIX environment. I tried, about 20 years ago.
Cmake, which was otherwise a strong candidate i my book, has presented
some challenges to port to VMS as well... others have tried. I don't
know so many others that have becom
So, uhmmm, why didn't you make a PR from this?
In message on Thu, 5 Apr 2018
17:18:13 +, "Salz, Rich" said:
rsalz> Making update
rsalz> CONF function code 122 collision at CONF_F_SSL_MODULE_INIT
rsalz>
rsalz> diff --git a/crypto/err/openssl.txt b/crypto/err/openssl.txt
rsalz> index d1cc03
t 128. Raising
rsalz> it to 384 is wrong.
Note that with a nonce, that'll be 192 bits, unless I'm thinking
wrong... But I agree with you, at least from a very practical point
of view.
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~l
t; page, or similar, which links to
matt> commits or other information about how to patch or work around an issue.
matt>
matt> I see no reason to make a new release unless we think the issue is
matt> sufficiently serious and/or affects large numbers of users.
matt>
matt> Matt
matt
In message <20180404.103237.14102346559301117.levi...@openssl.org> on Wed, 04
Apr 2018 10:32:37 +0200 (CEST), Richard Levitte said:
levitte> The attached report talks about CPP being required, but that's not the
levitte> intention. Rather, this is an unnoticed mistake wh
The attached report talks about CPP being required, but that's not the
intention. Rather, this is an unnoticed mistake when cherry-picking
from master to 1.1.0.
The fix itself is easy (just add a line saying 'CPP=$(CC) -E'), and
that's not what I'm here to talk about, but rather how we want to ac
While I totally agree with the direction Tim is taking on this, we
need to remember that there's another condition as well: access to the
platform in question, either directly by one of us, or through someone
in the community. Otherwise, we can have as many tests as we want, it
still won't test *t
een by itself make sense. The combined result, though,
leaves me wondering...
(I'm tempted to try this with /dev/random only on Unix... do I
remember it right, that it blocks for a while after every 8 byte chunk
on some Unixen?)
--
Richard Levitte levi...@
In message <20180402213936.ga29...@roeckx.be> on Mon, 2 Apr 2018 23:39:36
+0200, Kurt Roeckx said:
kurt> On Mon, Apr 02, 2018 at 10:13:53AM +0200, Richard Levitte wrote:
kurt> > Hi,
kurt> >
kurt> > A reminder, we're releasing beta 2 tomorrow. In preparat
Hi,
A reminder, we're releasing beta 2 tomorrow. In preparation, we will
do as usual, freeze the repo, which will happen some time this evening
(Swedish time).
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~le
ery personal point of view, it's *my* time,
and Matt's, and whoever else's who tests for releases, that
gets substantially less wasted! )
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
at least 3 OMC members approve the change"
I can get behind that.
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.
.
Thoughts? Comments? (Kurt?)
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
appro> implementation, these are just ideas to ponder about. They
appro> might turn unusable (or give a spark for some other idea :-)
Agreed, and I have the same intention.
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
__
..
appro> (*) Obviously modulo fact that we probably want to keep CPPFLAGS,
appro> because that's what users would expect they can affect.
Yes.
You know, while bouncing ideas, whatever we end up doing will be
post-1.1.1, so we have time to argue some more and hopefully end up
with a b
ait until OpenSSL 1.2 to
implement it), and it is some work to get through with it. I see
enough benefits to want to, though, and am currently in the mood of
bouncing ideas as time permits (*).
Cheers,
Richard
(*) no, I haven't forgotten that we have a primary focus in fixing
stuff that n
using the linker
directly instead of using cc as a frontend:
https://github.com/openssl/openssl/issues/5087
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
e that also could be
tjh> considered.
tjh>
tjh> We should discuss this separate from any specific PR and vote to
tjh> set a policy one way or the other in my view.
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
Why do you want to rush it? A month earlier than what we've currently
scheduled is in 4 weeks. I think the added stress will do nothing
good for us, or our community.
In message on Tue, 20 Mar
2018 17:57:45 +, "Salz, Rich" said:
rsalz> Therefore, we could have the release done a month ea
In message <1ab966c8-02d4-cf1f-504a-a54999a7c...@openssl.org> on Mon, 19 Mar
2018 16:33:57 +, Matt Caswell said:
matt> Let me know asap...
#5662 #5663
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org
I'm willing to approve it as it stands. Everything that stung my eye
earlier has been changed to something a lot better. The only thing
that still stings my eye is those public SM2 functions, but I would
see their removal as a fix, so...
Cheers,
Richard
--
Richard Levitte lev
w that I was wondering about, and I
hope I at least pinged them.
There's one I know where we need to make a judgement call. PR 4793
"(WIP) An implementation of the Chinese SM2 ECC". I intended to have
a look last week, but didn't. That one's a lot for me to take in, and
E
ot; side. Also the risk is
matt> significantly mitigated by it only impacting VMS.
matt>
matt> Matt
matt>
matt>
matt> On 19/03/18 11:52, Richard Levitte wrote:
matt> > In message <7aa44215-febf-73d2-3d0f-12f99b44b...@openssl.org> on Mon,
19 Mar 2018 11:14:27 +,
In message <7aa44215-febf-73d2-3d0f-12f99b44b...@openssl.org> on Mon, 19 Mar
2018 11:14:27 +, Matt Caswell said:
matt>
matt>
matt> On 19/03/18 10:58, Richard Levitte wrote:
matt> > Andy has indicated that the rather special construction to get command
line C macro de
ated like a bugfix and be mergeable past the beta freeze?
I'd categorically say that missing documentation is a bug. That
should make categorisation a bit easier...
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
_
Andy has indicated that the rather special construction to get command line C
macro definitions and include paths specs collected in one place (*) is perhaps
too special and could be handle by parsing CPPFLAGS and extra multiple
definitions to get them collected in one spot.
I have some ideas o
In message <20180315.090502.2143972695067215526.levi...@openssl.org> on Thu, 15
Mar 2018 09:05:02 +0100 (CET), Richard Levitte said:
levitte> So can I assume there's a PR coming up?
Ah, saw it!
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://w
d internally.
So in some cases, OIDs are more "nice to have" than useful, although
they might become useful in the future, so it's never wrong to include
the actual official OIDs when they're available.
So can I assume there's a PR coming up? Policy wise, I think that&#x
: 15th May 2018)
See https://www.openssl.org/policies/releasestrat.html for a reminder
of all details.
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing
g> on Sat, 10
Mar 2018 11:45:46 +0100 (CET), Richard Levitte said:
levitte> I started a vote moments ago on the OMC list with the content that
levitte> follows. The OMC will vote on it, hopefully on time, and the
levitte> resulting tally will be posted here.
levitte>
levitte> Vot
In message <20180310124318.ga26...@roeckx.be> on Sat, 10 Mar 2018 13:43:18
+0100, Kurt Roeckx said:
kurt> On Sat, Mar 10, 2018 at 11:45:46AM +0100, Richard Levitte wrote:
kurt> > Vote text:
kurt> >
kurt> > NOTE: THREE DAY VOTE
kurt> > Why? Because beta1 is c
.
All other current future release dates will be pushed one week as well.
https://www.openssl.org/policies/releasestrat.html will be updated.
An official announcement should be made.
Proposed by Richard Levitte
Public: yes
opened: 2018-03-10
closed: -mm-dd
THREE DAY VOTE
t to show a commitment to the larger community.
I agree.
rsalz> One way to do this is to say that we will extend the BETA date
rsalz> by a week, and in that week no new code from the team, only
rsalz> third-party existing pull requests will be considered
I like this idea. +1
oes* work. So question is rather if it should keep working [and if
appro> not, is it appropriate that stops working in minor release].
I'll side with that it should continue to work... and most
definitely should NOT stop working in a minor release.
--
Richard Levitte le
by this weekend.
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
ented on the
project list.
Now, the initial posting went to both the OMC and the project list,
and some chose to vote with a simple "Reply All" without editing the
recipients. If that was on purpose or because attention wasn't payed
to that detail, I cannot say.
Cheers,
Richar
reeze openssl matt
matt>
matt> Thanks
Done
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
requires a bit of a rethink of config attributes and
the make variables we do use in the end.
- I'm trying to build ia64 assembler stuff on VMS. This also requires
a bit of a rethink how we use the make variables (not as hard as it
sounds).
Just wanted to let you know what I'v
Andy Polyakov skrev: (11 februari 2018 20:42:49 CET)
>> (side note: I've just started compiling the ia64 code on VMS. It
>currently bombs for reasons I haven't fathomed yet, but am thinking
>it's a pointer size thing...
>
>You ought to generate assembly listing for 'int foo(int *p) {return
>*p;}
"Salz, Rich" skrev: (11 februari 2018 14:07:13 CET)
>> Those same systems will probably not have the newest OpenSSL
>either,
>and OpenSSH on those machines will certainly not be linked with a
>newer OpenSSL...
>
>I apologize for not being clear enough.
>
>I do not want to remove a
val of blowfish
viktor> ASM at this time...
Those same systems will probably not have the newest OpenSSL either,
and OpenSSH on those machines will certainly not be linked with a
newer OpenSSL...
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://ww
fact)
two years ago, and removed it (them) entirely last autumn. So one can
say that even in the OpenSSH world, blowfish support has decreased.
Ref: http://www.openssh.com/releasenotes.html
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
, https://en.wikipedia.org/wiki/Blowfish_(cipher)
mentions some weaknesses, and also that the author recommends moving
away from Blowfish (use Twofish instead, but we haven't implemented
that)
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.o
Yeah. And it's wrong, I will soon correct the script
"Salz, Rich" skrev: (10 januari 2018 18:36:23 CET)
>This is too too funny.
>
>On 1/10/18, 12:24 PM, "openssl-...@dev.openssl.org"
> wrote:
>
>The following files seem to need a copyright year update:
>util/openssl-update-copyright
I would say on the contrary, that long lines in code section should be flagged,
because they aren't wrapped in the final output.
For the rest, warning on long lines is still nice for the readability of the
original file, but to my judgment, that's slightly less important than the code
sections.
Matt Caswell skrev: (18 januari 2018 15:59:32 CET)
>
>
>On 18/01/18 14:43, Matt Caswell wrote:
>> ok/B1h/b96gGE1fnxPUU4dtr31EZGX0L2oHLwLxvjrsh+whkiviIH7aA4G1/7F35
>>
>> ^^
>> Is the ok here confusing TAP?
>
>
>A quick test proves to me that it does confuse it. The chances of 2
>characters of ba
sl-users> support perhaps (any Crays?), but that's just a coincidence.
>From those errors, it looks to me like uintmax_t isn't 64-bit on that
Mac OS/X machine, unless 'unsigned long' and 'unsigned long long' are
the same.
(that error do
ppro> information that we would appreciate in problem report.
Now this is a good point. There is a flag --dump that dumps quite a
bit chunk of info... One thing I didn't think of was that the final
config target attributes could be a useful addition, that could be
added in the dump as
I want to approve the PR that you're gonna submit any time now 😉
(I would like to see that in just one statement if possible)
Cheers
Richard
"Salz, Rich" skrev: (1 februari 2018 18:52:26 CET)
>Fine.
>
>How about this change?
>iff --git a/Configure b/Configure
>index cad25bb..a994876 100755
>--
Me, I've noticed that quite a lot of people don't read CHANGES, so this is to
avoid getting a ton of reports about Configure not displaying all the stuff it
used to do.
Also, the message is geared to disappear with 1.1.1a or above.
Cheers
Richard
"Salz, Rich" skrev: (1 februari 2018 18:00:
ze=alignment -fsanitize=undefined
-fno-sanitize-recover=all -fno-omit-frame-pointer
I just tried a fresh master and hacked reordered CFLAGS in Makefile to
-fno-sanitize=alignment last, and suddenly, the tests work.
So, err, I screwed up with the recent changes in Configure, in adding
the use
I think I said it earlier, that prefixing the output with '#' is a TAP
compatible way to fix this. One way is to pipe the execution of the
program through a "sed -e 's|^|# |'", except that it's not exactly
portable... Another way *might* be to open("program |") and handle
the output in OpenSSL::T
In message on Fri, 26 Jan
2018 14:06:27 +, Matt Caswell said:
matt> - Use size_t for sizes of things
... and, it seems, as array index.
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levi
z> Instead do this:
rsalz> If (some_long_text
rsalz> && foo(a, b, c,)
rsalz> && bar())
YES!
rsalz> What else needs to be updated?
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
e plan before we
receive a clear signal that publication *will* happen and when it
will... after all, we *are* putting ourselves in a kind of hostage
situation)
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
__
.
Time to reiterate this, perhaps?
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
In message on Tue, 23 Jan
2018 16:35:02 +, "Salz, Rich" said:
rsalz> In a little while, Richard should have his SSH keys integrated
rsalz> into our systems, and will email him some more detailed
rsalz> instructions.
Done and done! Welcome, Matthias
--
Richard L
301 - 393 of 393 matches
Mail list logo
