[
https://issues.apache.org/jira/browse/HDFS-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14050664#comment-14050664
]
Charles Lamb commented on HDFS-6605:
------------------------------------
In general, this looks pretty good to me. I have a few comments:
CryptoCodec:
Style question: Is there any reason you didn't make suite be SUITE since it's a
final constant? Is that because it is protected and might someday not be static
final?
FileEncryptionInfo:
You introduced a blank line in the imports section.
FSNamesystem:
We'll have a minor merge headache because getEncryptionZoneForPath is moving to
FSD in HDFS-6516.
FSNamesystem.java:
I wonder if we shouldn't extract the ciphersuite matching logic into a method
of its own.
CryptoCodec:
At some point we're going to support more than one suite. Does it make sense to
have a getCipherSuites() method that returns all of the suites that are
supported on the client side? That way, in DFSClient, we can just do
cipherSuites.add(getCipherSuites()).
Is it worth thinking about a unit test that would test a new client against an
old NN version (one that doesn't have this patch) or is that not typically done?
> Client server negotiation of cipher suite
> -----------------------------------------
>
> Key: HDFS-6605
> URL: https://issues.apache.org/jira/browse/HDFS-6605
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: security
> Affects Versions: fs-encryption (HADOOP-10150 and HDFS-6134)
> Reporter: Andrew Wang
> Assignee: Andrew Wang
> Attachments: hdfs-6605.001.patch
>
>
> For compatibility purposes, the client and server should negotiate what
> cipher suite to use based on their respective capabilities. This is also a
> way for the server to reject old clients that do not support encryption.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
