> > Can you look at https://github.com/openssl/openssl/pull/1044 and see if it
> addresses the issues?
> Yes.
Great, thanks!
> May be with some definitions for backward compatibility. I mean for
> renamed pre 1.1 functions - with inserted ..._CTX into name of :
> - X509_STORE_get_by_subject
We've updated our preferred way to submit patches. Please see the CONTRIBUTING
file, which you can find here (among other places):
https://github.com/openssl/openssl/blob/master/CONTRIBUTING
The summary could be phrase as "just open a GitHub PR, no need to deal with RT"
We hope this will mak
> I haven't been keeping my PR #512 up to date since the 1.1 code freeze, is
> now a good time to start again?
If it's a feature, wait until after 1.1 and then rebase. If it's a bug or doc
fix or similar, please update now and ping.
--
openssl-dev mailing list
To unsubscribe: https://mta.openss
So Matt already mentioned that it's too late for our upcoming 1.1 release. But
do you think there'd be interest in adding this at an IETF hackathon? I can be
there FWIW. Keeping a separate ietf-openssl branch that has the changes, for
example, shouldn't be onerous.
--
Senior Architect, Ak
> (2) We need to validate signatures on I-Ds and RFCs with the standard
> release. I’m okay with needing 1.1 or later, but I’m not okay with users
> having to fetch a special version.
It would show up a release after 1.1, but it would be in a regular release.
--
openssl-dev mailing list
To u
> > It would show up a release after 1.1, but it would be in a regular release.
>
> s/1.1/1.2/
No, it would be in a release after 1.1 :) Maybe that's 1.1.1 or maybe that's
1.2, we haven't figured it out yet.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/
Not currently supported.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
... in case you haven't noticed :) Our announced release date for 1.1 has come
and gone.
We want to close many more bugs before we release it. In the meantime, please
test against master or a daily snapshot or the last beta release.
Thanks for your patience!
--
Senior Architect, Akamai Te
> https://www.openssl.org/docs/manmaster/apps/s_client.html
> has a link to
> https://www.openssl.org/docs/manmaster/apps/SSL_CONF_cmd.html
>
> the latter doesn't exist.
>
> Seems the correct URL is:
> https://www.openssl.org/docs/manmaster/ssl/SSL_CONF_cmd.html
>
> I assume these are somehow a
FIPS does not allow NULL ciphers, so no.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
From: Mody, Darshan (Darshan) [mailto:darshanm...@avaya.com]
Sent: Tuesday, May 31, 2016 11:54 PM
To: openssl-dev@openssl.org
Subject: [openssl-dev] Null Ciphers in FIPS mode
> That's usually true, but the topic of this thread is about how to get OpenSSL
> working well on Cortex-M microcontrollers. In those situations, we cannot
> really afford the dynamic detection or the many different implementations of
> the same algorithm to exist in the final image.
Other trad
I think OpenSSL needs to decide if SSLv2 bugs will be getting fixed. Matt and
I disagree :)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> It still seems like pqueue out to be excised from the source base and replace
> with something simpler.
Agree.
Could you go to Github and open an issue on this?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Defensive programming is about handling gracefully the cases when the
> user/caller does something he “is not supposed to do”.
There is a limit.
Should we return an error code that will most likely be ignored?
Should the C library be defensive about fprintf, strcpy, etc., etc.?
> Software tha
We are not going to check for NULL pointers in all arguments. Ever.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This is not supported.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Sometimes I report bugs and/or fix bugs which get fixed in [1] and/or [2].
> Please make sure you consider the impact of those changes on your own
> projects.
Not sure what you're asking for.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> In general, I noticed that OpenSSL and LibreSSL don't seem to pay attention
> to the bugs that are fixed in BoringSSL and *ring*. See, for
> example:
We don't have the time to follow other forks, basically.
I don't see that changing.
--
openssl-dev mailing list
To unsubscribe: https://mta.ope
This feedback is very useful.
> 1) There is no accessor for the "num" field in the BIO struct.
> This is typically used to store a file descriptor or similar value. As can be
> seen
> by its explicit access in BIO_dup_chain(), there may be legitimate reasons to
> get at its value, even if you are
> But obviously I was expecting too much...
Sorry you're not pleased. Not sure what to say -- you get what you pay for?
Maybe someone will come up with a "openssl-102-compat" package?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> > That sounds like a bug we need to fix. Perhaps something like
> > int BIO_meth_new_index([int flags?])
> But I think even just some advice on _how_ to pick a value here would be
> sufficient. As long as the space is sufficiently sparse, picking a static
> value
> with reasonably low pro
>Will you be releasing 1.0.2i soon to address this issue?
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-2177
Please see
https://www.openssl.org/blog/blog/2016/06/27/undefined-pointer-arithmetic/
Short answer: this is a LOW issue, and does not justify a release by itself.
--
Sen
> Also, under the x86 no problem.Now how to solve this problem?
The same way you debug any C problem. Start by running it under the debugger?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
e changes
> to our existing 1.0.2h code?
>
> Thanks,
> Phil
>
>
>
> -Original Message-
> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of
> Salz, Rich
> Sent: Tuesday, June 28, 2016 11:23 AM
> To: openssl-dev@openssl.org
> Subject: Re:
> Specify neither if you want most stuff to be installed in /usr/local and
> config
> files/default cert/keystore in /usr/local/ssl
>
> Specify just --openssldir if you want just config files/default cert/keystore
> to
> go into and everything else in /usr/local
>
> Specify just --prefix if y
I don't know what 1.1 beta source you downloaded. The code on GitHub is the
latest version of what will be 1.1 It *is* fixed, just later than the version
you downloaded.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> undefined symbol: EVP_PKEY_CTX_set_rsa_oaep_md
>
> Since when version it is in the libs??
It is in 1.0.2
> Do I need to link against other than -lssl and -lcrypto?
No, those are the only two libraries OpenSSL has.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/l
> install ./doc/crypto/BIO_set_callback.pod ->
> /Users/ur20980/src/openssl-1.1/share/man/man3/BIO_set_callback.3
> IO::File=IO(0x7f896a02d1c0) around line 42: =over should be: '=over' or
> '=over positive_number'
I don't understand this error message. "=over" should be "=over"?
Does addi
> In the POD format, everything is a paragraph, each separated from the
> others with a blank line.
Time to add something to find-doc-nits, perhaps.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> rsalz> Time to add something to find-doc-nits, perhaps.
>
> man podchecker
Find-doc-nits calls podchecker and saw no complaint.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> perl util/find-doc-nits.pl -s
>
> (I don't know what -s is for, but apparently, podchecker isn't run unless you
> use that option)
Forgot my own code :(
-s for stricter checking.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
We'll have a moment of silence ;)
Seriously, glad your subject line referred to systems, and not to you helping
test snapshots!
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> I have earlier raised an issue on how openssl is not looking up for newer
> CRLs in each lookup. The only CRL files it is taking into consideration are
> the ones present in the cache.
> Could you please provide some inputs on this as I am blocked on the
> implementation front.
You mean i
> It is not re-checking the files (new CRL for the same issuer) in the CRL
> directory
I believe that is working as designed and what you want is a new feature.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This was also reported as https://github.com/openssl/openssl/pull/1312 and
fixed with commit 2a5f907 moments ago.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I understand, and I think Richard will provide the hooks you need.
But this is, as you say, stuff that is eight years old
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Shouldn't this be EC_KEY *EC_KEY_dup(const EC_KEY *src);
I think the reason it is not is because the EC_KEY has an ENGINE* and that
can't be const.
Sigh, C needs 'mutable' :)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Perhaps the GRID folks can just write their own validation routine completely?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> That's exactly what we currently do, we provide a verification callback, but
> we do need to be able to set the failing cert in a chain for that.
Stick it in EXDAT?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I am not sure what to suggest. This conversation is bouncing across two ticket
systems and is all about a legacy certificate format that is, what, outdated
since 2002?
I am hard-pressed to see why OpenSSL 1.1 has to do anything other than what
Richard proposed.
--
openssl-dev mailing list
To
> I meant to ask, should I make tickets for this and the missing DSA_bits()?
Tickets. Or ideally PR with code:)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Just to let you know that today's master fails to build when option
> no-nextprotoneg is used.
This will be fixed shortly; the fix is being reviewed. Thanks.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
--
openssl-dev mailing list
To unsubscribe: htt
Ask Cavium.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
From: neutrino network [mailto:neutrino.netwo...@gmail.com]
Sent: Monday, August 08, 2016 11:57 PM
To: openssl-us...@openssl.org; openssl-dev@openssl.org
Subject: [openssl-users] OPENSSL provided by Cavi
Try it, it will be a huge invasive change.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
It's the weekend :)
> This still exists from Opensl 1.0.2 SNAP 20160821
It will be fixed soon :)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Fixed with commit 71da19b050ba67c489b6c5f2543bf239c1947543 which should show up
in the next snapshot.
Thanks.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
You didn't fully initialize your RSA key, such as by adding the private or
public parts.
It shouldn't crash, but then again this is like doing an fprintf() without
first checking if the fopen() succeeded.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
--
op
> I use PEM_read_bio_RSAPrivateKey to read a key into a RSA and all return-
> values are ok.
That's the first and most important test. One other thing you can do is use
the "rsa" tool to print out the contents.
> But I get a crashes when I use it afterwards.
The code you posted isn't what you
When the RFC says “a line comprising” it means ONLY having that text.
Otherwise it would have said “a line including.”
The file is mis-formatted.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.or
> Wondering whether we could consider "?" as the data.
No, it is part of the prolog line, and since such a line must be made of the
parts defined (and only those parts), the file is malformed.
The RFC does not allow arbitrary data after the newline and before the prolog,
nor after the epilog a
Yeah, something like that for 1.0.2; simpler for 1.1.0. I'll do it.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> I've started collecting a certificate torture test suite at
> http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/
> Makefile.am
I think this is cool, and splitting it off is a good idea. I think some IETF
folks would be interested, too.
--
Senior Architect, Akamai Technol
> Maybe you like it. I haven't tried it, but see no reason why it
> shouldn't work. It also adjusts headline tags in secpolicy.html, which don't
> comply to the rest of the site yet.
It's good enough. None of us our web developers. I just pushed the updated
repo to https://github.com/openssl
I am thinking of standardizing the syntax for dates, times, and durations used
by the applications in the next releases, based on
http://www.w3schools.com/xml/schema_dtypes_date.asp (with the extension that
lowercase letters can also be used).
Objects that need dates (x509 etc) will have a stan
> It's not a huge step to support full blown ISO 8601 (which has a few more
> alternatives to specify time intervals *). I like the idea.
No, it *is* a huge step. There's a reason why W3C XML schema language (XSD),
not known for being lightweight, profiled the ISO standard.
--
openssl-dev ma
> Sorry, I was unclear. What I meant was that it's not a huge step from the XSD
> to full blown ISO 8601.
No, sorry, *I* was unclear. I think it is a huge step to go full-blown. E.g.,
all the missing fields and the 'w' duration.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl
> Support RFC3339[1] is relative easy.
But it's not enough, as folks are asking for the ability to specify durations.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I would suggest the LAMPS WG (https://datatracker.ietf.org/wg/lamps/charter/),
which is the closest thing to PKIX these days, and perhaps cross-post to the
SAAG mailing list the general catch-all for security area
https://trac.tools.ietf.org/area/sec/trac/wiki.
--
Senior Architect, Akamai Tec
This is advice from one team member, hope it helps. My personal opinion, don’t
take it as gospel.
I don’t know if we have any interest in supporting WEC7, it would depend on how
big the changes are – the fewer the better -- and if anyone on the team has a
particular interest (and can run the
> The majority of servers (71%) support *only* prime256v1 curve and of the
> ones that default to ECDHE key exchange nearly 83% will also default to this
> curve.
That's because most people have not moved to OpenSSL 1.1.0 yet. I'm not
joking, I think that's a major reason.
> OpenSSL 1.0.2h als
> When we added X25519 to BoringSSL, we at the same time started made the
> server require clients supply a curve list (and otherwise we'd just pick a
> non-ECDHE cipher), because of this issue. That went in back in December 2015
> and it's been running just fine. I'd recommend OpenSSL do the sa
> > In other words: only use ECDHE if client specifies a curve list. WFM.
>
> If a client offers ECDHE ciphers with no curve list, one might alternatively
> just
> use P-256. It is likely better than the other choices. Most clients will
> send a
> curve list.
Most will, and I'd rather get p
> Won't work for "normal" user. This was change in commit fc6076ca272f
> ("rand/randfile.c: make it non-ASCII-savvy."). Was this change on purpose?
The change was on purpose and a slightly different fix is in progress and will
show up soon.
--
openssl-dev mailing list
To unsubscribe: https://mt
We do have assembler versions for most CPI's.
Closing ticket.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Yes, in 1.1.0 we made many structures opaque. You will have to use
accessors/settor functions.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> EVP_ENCODE_CTX base64;
> base64 = EVP_ENCODE_CTX_new();
You can't do this kind of thing anymore. You can only have pointers, and the
contents of those pointers are hidden from your program. This is what we mean
by 'opaque' pointers. In this case, for example you do
EVP_ENCOD
> Is there currently any documentation at all on these Chinese algorithms?
> I'm certainly curious, and I'm sure others in the OpenSSL community will be.
Also, please know that we are already looking at several large projects (TLS
1.3, FIPS, etc). In my personal opinion, I would be surprised if
> Neither of these two looks like it would be difficult to implement.
Again, I strongly recommend that if anyone works on this, they do it as an
externally-provided ENGINE, like GOST.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> [0]:
> https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_CTX_set_keylog_callback
That seems like a reasonable thing to put into the next release.
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz
--
op
(I subscribed you to openssl-dev; I hope it works.)
ISO standards are “pay to play.” That is, any member organization can get
something as an ISO standard with not much effort. :)
>> "I strongly recommend that if anyone works on this, they do it as an
>> externally-provided ENGINE, like GOST.
> signal BUS (invalid address alignment) in _time at 0x7e5c1944
> 0x7e5c1944: _time+0x0014: stx %o0, [%i0]
> Current function is main (optimized)
> 776 time((void *)server_random);
We have a fix that will go in shortly.
--
openssl-dev mailing list
To unsubscrib
Sorry, we didn't think to put this out earlier...
The OpenSSL dev team is having a face-to-face meeting this week in Berlin,
co-located with LinuxCon. If you're in the area, feel free to stop by. In
particular, on Tuesday from 16:50-17:40 - "Members of the openssl development
team will be avai
> And the *only* justification for the fact that bug continues to exist — and in
> fact we introduced a *new* bug in OpenSSL 1.1 instead of fixing it — is for
> backward compatibility with older releases.
>
> So how can we be so sanguine about the above failure report?
Because backward compatib
https://github.com/openssl/openssl/pull/1762
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Is electric fence even available any more? Just kill it.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
(came in via mixmaster anonymous remailer)
$ openssl version
OpenSSL 1.0.2j 26 Sep 2016
Typo in NEWS file:
Major changes between OpenSSL 1.0.2g and OpenSSL 1.0.2h [3 May 2016]
...
o Remove LOW from the DEFAULT cipher list. This removes singles DES from
the default.
Replace "sing
> Why is this not solved?
It will be solved before the next release. No further promises.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Still It is a good thing to gripe if you see an issue.
Yup. But maybe every other day? :)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I hope that Daniel from CURL will speak up, and perhaps Richard from Qt.
I think a new header file, like “openssl110compat.h” or something, hosted in a
public repo would be great. We could point to it in the 1.0.2 README, for
example.
--
Senior Architect, Akamai Technologies
Member, OpenSSL De
You can decrypt old files by adding -md5 flag.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Just go ahead a file a pull request anyway...that's the best way of getting
> comments. If changes are needed you can update the PR as required.
Like, for example, documenting this new function. :)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Unless I overlooked something the new OpenSSL-1.1.0 does not allow access
> to the ex_nscert data of the X509 object. Would it be possible to add such
> function to the API?
Yes. Missing accessors are bugfixes and can go into a 1.1.0 update.
Please open an issue or even better a PR.
--
opens
No, thanks, that looks good!
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> What are the chances that the OpenSSL devs would be interested in upgrading
> this API?
Pretty good.
We’re looking at adding a new API for 1.1.1 that is like the one in boring --
it gives full acess to the hello message. The 1.1.0 API is frozen. But what
can we do for the next release, whi
It is a heck of a lot easier for everyone if you make pull requests and not
just mail big patches. Can you do that?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> would much rather have seen a patch where OpenSSL's PEM module is
> tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing
Yes, that would be much more consistent with the existing OpenSSL code which --
like it or not -- works that way.
> My vote goes to a URI based spec
> dwmw2> It should work out what the contents are for *itself*. Whether
> dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.
I disagree with this approach, but that's just my opinion. I am worried about
"keep trying something until it works" because you'll get strange errors y
> The more interesting part is when it tries to load files it guesses are raw
> DER.
And this part worries me. I do not think a "security library" should be
guessing.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> > It does this by trying to interpret the blob against known ASN.1
> > definitions, and will only succeed when there's a complete match. I'm
> > not terribly worried...
I am. With locales and UTF8, the old simple days of text/binary are probably
long gone. And if any ASN.1 definition has ext
> That's not the proposal. The proposal is to use PEM form because we can
> make it uniquely self describing using the guard tags which obviates the
> problem above.
Well that's what you want. David wants more than that :)
> On the larger issue of non-self describing formats like ASN.1: if you
> Uh... the d2i functions are already both in one. Are you saying they
> should be split in two, one part that does all the checking and the other that
> just decodes, trusting that all checks are already done? What you're gonna
> do there is double part of the work.
Well, not double, but
> Why is it different if we do exactly that in libcrypto?
Because *we* are not guessing. We are telling the application "we think it's a
FOO" and then letting the application decide what to do.
Security libraries *should not guess.*
--
openssl-dev mailing list
To unsubscribe: https://mta.open
> Essentially, you're suggesting that we split out the matching part of the d2i
> functions and put that to good use. Or do you have some other idea, along
> the lines if magic?
NO. I am suggesting add one new routine that tries varies "convert to native"
and returns which conversion worked.
> FWIW I am perfectly content for applications *not* to automatically work
> with such keys. Making the user jump through extra hoops to use them
> would be perfectly fine in my book.
oh I see. "Users shouldn't care, it should just work" But only for some keys.
Part of my I am opposed to guess
How do you configure?
> test_dtls1_not_bleeding failed: expected return value -1, received 0
> ** test_dtls1_not_bleeding failed **
...
> 4 tests failed
> *** Error code 1
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> How long for this to get fixed?
>
> ../util/shlib_wrap.sh ./heartbeat_test
I posted yesterday, what's your config. I standard config/make does not do
this for me.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Can you get his fixed?
>
> ../util/shlib_wrap.sh ./heartbeat_test
> test_dtls1_not_bleeding failed: expected return value -1, received 0
> ** test_dtls1_not_bleeding failed **
Again: How are you configuring ?
It does not fail for me.
--
openssl-dev mailing list
To unsubscribe: https://mta.o
Thanks for working to improve openssl.
It is probably easier for you to do a GitHub pull request and then have
discussion here, pointing to that PR.
And also, before any of this code could be used, we'll need the appropriate CLA.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.or
> Actually, being a kernel developer, email is far easier. I'll send a pull
> request
> when everyone's OK with the mechanism, plus it will need tests and other
> things.
Well... okay. I don't know how the community will react. But I *do* know that
the team prefers things as PR's.
> Groan
> Plus the DCO is industry best practice: even OpenStack is adopting it after a
> long struggle.
Great. Good for them.
This is what we're doing.
:)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
301 - 400 of 1133 matches
Mail list logo
