Open ghost opened 5 years ago
Thanks. I will chase these up, unless @SebastinSanty gets to it first
No Github #69 only fixed one problem
@SebastinSanty I think we should just remove DataOneV1()
we have like 4 other APIs to get the same information.
most of the information in DataOneV1()
is actually using dcterms
etc in the DataDryad HTML, rather than the actual DataOneV1()
And DataDryad has recently completely changed how they use dcterms
breaking it utterly.
It could be fixed, but I am not sure the point since it is redundant for DataDryad, which is all that it works for.
I think later we should consider making something that robustly works with dcterms
, and works across sites.
Yes, we can safely remove DataOneV1()
specially because as far as we know this DataOne version is only used by DataDryad. Also, DataDryad based registration blocks are generated even without that as you said.
2/3 fixed. (well 1 fixed, 1 deleted) All that is left is DataDepsV2 re: https://github.com/JuliaWeb/HTTP.jl/issues/342
According to Twitter on that DataOne wants to talk about the problem on there slack so I'll go talk to them.
DataONE services use SSLVerifyClient optional
for clients to optionally authenticate using a client certificate which is one reason for TLS renegotiation occurring. RFC 5746 identifies the TLS renegotiation extension that addresses the vulnerability described in CVE-2009-3555. RFC 5746 is implemented in OpenSSL versions 0.9.8m and 1.0.0a. Our systems are currently at OpenSSL 1.0.1f, so my understanding is that the vulnerability is resolved and hence the guidance to avoid TLS renegotiation should probably be revised.
Edit: The issue seems to be around TLS 1.3 which will not support renegotiation. It is not clear yet how Apache will support optional SSLVerifyClient with TLS 1.3.
Some appear to be HTTP issues and others possible syntax changes in Gumbo.
DataOneV1
DataOneV2
Figshare