[
https://issues.apache.org/jira/browse/NIFI-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117781#comment-15117781
]
ASF GitHub Bot commented on NIFI-1364:
--------------------------------------
Github user mcgilman commented on the pull request:
https://github.com/apache/nifi/pull/163#issuecomment-175186780
I had a little trouble merging the PR into the current state of master. I
was able to get the relevant parts of the contribution and can be seen here [1].
Additionally, I added TODO comments to the empty unit tests to be addressed
when incorporating NIFI-1364 [2]. The presence of the empty test indicates key
functionality that will be addressed with that ticket.
Also, I tweak the name of the profile that enables the groovy unit tests to
keep consistent with the other available profiles and added the groovy profile
to the Travis CI config.
@alopresto When running with the tests enabled, everything appears to run
successfully however, I'm seeing checksum and other warnings for
groovy-eclipse-batch. Have you seen these before?
> [WARNING] Checksum validation failed, expected <!DOCTYPE but is
e691b3c825cdd3ebbdd22017300182e953814469 for
http://repository.codehaus.org/org/codehaus/groovy/groovy-eclipse-batch/maven-metadata.xml
> [WARNING] The metadata
~/.m2/repository/org/codehaus/groovy/groovy-eclipse-batch/maven-metadata-codehaus.org.xml
is invalid: entity reference name can not contain character =' (position:
START_TAG seen
...com/main?ParticipantID=euekiz39ksg8nwp7iqj2fp5wzfwi5q76&FailedURI=... @1:269)
Outside of these warnings everything looks good. Let me know if you seen
issues with this artifact before. Other's have asked for these capabilities
before so this is definitely a cool addition. Thanks!
[1]
https://github.com/mcgilman/nifi/commit/82919c1a0cb7b47d8e66045ed0638a992bc4b7ec
[2] https://issues.apache.org/jira/browse/NIFI-1364
> Audit OCSP certificate validation
> ---------------------------------
>
> Key: NIFI-1364
> URL: https://issues.apache.org/jira/browse/NIFI-1364
> Project: Apache NiFi
> Issue Type: Task
> Components: Core Framework
> Affects Versions: 0.4.1
> Reporter: Andy LoPresto
> Assignee: Andy LoPresto
> Labels: certificate, ocsp, security
> Fix For: 0.6.0
>
>
> While upgrading the version of BouncyCastle libraries used, I had to re-write
> the OCSP certificate validation code because BC split the PKIX code into a
> separate module and renamed many classes & methods. During this re-write, I
> made the code compile using the new logic, but I am unsure that OCSP
> validation needs to occur outside of the SSL/TLS negotiation, or that the
> current mechanism is correct.
> Questions:
> * Can we use Java's built-in OCSP validation? [1][2]
> * Is the current mechanism correct, where a local cache is used with custom
> internal classes representing OCSP requests and statuses, and it queries a
> pre-specified OCSP responder as opposed to the per-certificate OCSP responder
> listed in each certificate's Authority Information Access OCSP URI [3]? I
> think this design decision stems from a legacy environment which may not
> apply to current use cases.
> More information: [4]
> [1] https://blogs.oracle.com/xuelei/entry/enable_ocsp_checking
> [2]
> https://stackoverflow.com/questions/8506661/check-x509-certificate-revocation-status-in-spring-security-before-authenticatin
> [3]
> https://blog.ivanristic.com/2014/02/checking-ocsp-revocation-using-openssl.html
> [4]
> https://raymii.org/s/articles/OpenSSL_Manually_Verify_a_certificate_against_an_OCSP.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
