Hadoop Common
  1. Hadoop Common
  2. HADOOP-10719

Add generateEncryptedKey and decryptEncryptedKey methods to KeyProvider

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.0
    • Fix Version/s: 2.6.0
    • Component/s: security
    • Labels:
      None
    • Target Version/s:
    • Hadoop Flags:
      Reviewed

      Description

      This is a follow up on HDFS-6134

      KeyProvider API should have 2 new methods:

      • KeyVersion generateEncryptedKey(String keyVersionName, byte[] iv)
      • KeyVersion decryptEncryptedKey(String keyVersionName, byte[] iv, KeyVersion encryptedKey)

      The implementation would do a known transformation on the IV (i.e.: xor with 0xff the original IV).

      1. HADOOP-10719.5.patch
        17 kB
        Arun Suresh
      2. HADOOP-10719.4.patch
        17 kB
        Arun Suresh
      3. HADOOP-10719.3.patch
        15 kB
        Arun Suresh
      4. HADOOP-10719.3.patch
        15 kB
        Arun Suresh
      5. HADOOP-10719.2.patch
        16 kB
        Arun Suresh
      6. HADOOP-10719.1.patch
        15 kB
        Arun Suresh
      7. HADOOP-10719.patch
        12 kB
        Alejandro Abdelnur
      8. HADOOP-10719.patch
        14 kB
        Alejandro Abdelnur
      9. HADOOP-10719.patch
        15 kB
        Alejandro Abdelnur
      10. HADOOP-10719.patch
        16 kB
        Alejandro Abdelnur
      11. HADOOP-10719.patch
        16 kB
        Alejandro Abdelnur

        Activity

        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12651250/HADOOP-10719.patch
        against trunk revision .

        -1 patch. The patch command could not apply the patch.

        Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4097//console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12651250/HADOOP-10719.patch against trunk revision . -1 patch . The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4097//console This message is automatically generated.
        Hide
        Charles Lamb added a comment -

        Alejandro Abdelnur

        In general, LGTM.

        When encrypting the key, what is the reason for calling SHA1PRNG.nextBytes on it? Is that adding entropy to the SecureRNG?

        Javadoc: is it ok to use "key material" as a noun with the indefinite article, as in "a key material". Maybe "new key material" instead of "a key material"? or "generates a byte[] of key material"? Ditto here:

        Decrypts an encrypted key material using the

        The generated key material is of the same length as the <code>KeyVersion</code> material.

        The generated key material is of the same length as the <code>KeyVersion</code> material and is encrypted using the same cipher.

        Show
        Charles Lamb added a comment - Alejandro Abdelnur In general, LGTM. When encrypting the key, what is the reason for calling SHA1PRNG.nextBytes on it? Is that adding entropy to the SecureRNG? Javadoc: is it ok to use "key material" as a noun with the indefinite article, as in "a key material". Maybe "new key material" instead of "a key material"? or "generates a byte[] of key material"? Ditto here: Decrypts an encrypted key material using the The generated key material is of the same length as the <code>KeyVersion</code> material. The generated key material is of the same length as the <code>KeyVersion</code> material and is encrypted using the same cipher.
        Hide
        Alejandro Abdelnur added a comment -

        patch with the suggested javadoc corrections as suggested.

        The use of the SRNG as in the patch is to use a particular algorithm, nothing else. No this will go away when CryptoCodec stuff is merged into trunk.

        Show
        Alejandro Abdelnur added a comment - patch with the suggested javadoc corrections as suggested. The use of the SRNG as in the patch is to use a particular algorithm, nothing else. No this will go away when CryptoCodec stuff is merged into trunk.
        Hide
        Hadoop QA added a comment -

        +1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12651304/HADOOP-10719.patch
        against trunk revision .

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 1 new or modified test files.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 javadoc. There were no new javadoc warning messages.

        +1 eclipse:eclipse. The patch built with eclipse:eclipse.

        +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-common-project/hadoop-kms.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4100//testReport/
        Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4100//console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - +1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12651304/HADOOP-10719.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-common-project/hadoop-kms. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4100//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4100//console This message is automatically generated.
        Hide
        Andrew Wang added a comment -

        Hi tucu, cool patch,

        • Would prefer if the commented out TODO code was put in a follow-on JIRA or on the fs-encryption branch
        • Can we document the xorIV function, and why we do this? Naming it something like flipBits might also be better, naming it xor made me think we were encrypting it.
        • Shouldn't the new KeyProvider methods be abstract? The NN will be calling KMSClientProvider methods, and KMSCP is a KP so these methods will be running on the NN, which based on the HDFS-6134 comments is undesirable.
        • Are there other uses for this method besides generating/decrypting EDEKs? I'm thinking we should name these methods generateEncryptedDataEncryptionKey and so on for consistency (though very verbose) since we are always returning EDEK as the versionName.
        • Can we tighten up the visibility of the EDEK and DEK constants? Probably only useful in tests.
        Show
        Andrew Wang added a comment - Hi tucu, cool patch, Would prefer if the commented out TODO code was put in a follow-on JIRA or on the fs-encryption branch Can we document the xorIV function, and why we do this? Naming it something like flipBits might also be better, naming it xor made me think we were encrypting it. Shouldn't the new KeyProvider methods be abstract? The NN will be calling KMSClientProvider methods, and KMSCP is a KP so these methods will be running on the NN, which based on the HDFS-6134 comments is undesirable. Are there other uses for this method besides generating/decrypting EDEKs? I'm thinking we should name these methods generateEncryptedDataEncryptionKey and so on for consistency (though very verbose) since we are always returning EDEK as the versionName. Can we tighten up the visibility of the EDEK and DEK constants? Probably only useful in tests.
        Hide
        Alejandro Abdelnur added a comment -

        Andrew Wang, thanks. Integrated your comments. On the new methods being abstract, you answered yourself in HADOOP-10720.

        Show
        Alejandro Abdelnur added a comment - Andrew Wang , thanks. Integrated your comments. On the new methods being abstract, you answered yourself in HADOOP-10720 .
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12651543/HADOOP-10719.patch
        against trunk revision .

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 1 new or modified test files.

        -1 javac. The patch appears to cause the build to fail.

        Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4111//console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12651543/HADOOP-10719.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. -1 javac . The patch appears to cause the build to fail. Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4111//console This message is automatically generated.
        Hide
        Andrew Wang added a comment -

        I must have missed this in an earlier review, but very minor nit: the Preconditions checks in KeyProvider are longer than 80-chars.

        +1 pending that though, we should rekick Jenkins too. This compiles for me locally.

        Show
        Andrew Wang added a comment - I must have missed this in an earlier review, but very minor nit: the Preconditions checks in KeyProvider are longer than 80-chars. +1 pending that though, we should rekick Jenkins too. This compiles for me locally.
        Hide
        Andrew Wang added a comment -

        Woops, some longer-than-80-char lines in other places too, please fix those up too while you're at it.

        Show
        Andrew Wang added a comment - Woops, some longer-than-80-char lines in other places too, please fix those up too while you're at it.
        Hide
        Hadoop QA added a comment -

        +1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12651560/HADOOP-10719.patch
        against trunk revision .

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 1 new or modified test files.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 javadoc. There were no new javadoc warning messages.

        +1 eclipse:eclipse. The patch built with eclipse:eclipse.

        +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-common-project/hadoop-kms.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4118//testReport/
        Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4118//console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - +1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12651560/HADOOP-10719.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-common-project/hadoop-kms. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4118//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4118//console This message is automatically generated.
        Hide
        Alejandro Abdelnur added a comment -

        fixing extra long lines, also I've removed redundant new methods leaving one signature for generate and one signature for decrypt.

        Show
        Alejandro Abdelnur added a comment - fixing extra long lines, also I've removed redundant new methods leaving one signature for generate and one signature for decrypt.
        Hide
        Hadoop QA added a comment -

        +1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12651608/HADOOP-10719.patch
        against trunk revision .

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 1 new or modified test files.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 javadoc. There were no new javadoc warning messages.

        +1 eclipse:eclipse. The patch built with eclipse:eclipse.

        +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-common-project/hadoop-kms.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4125//testReport/
        Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4125//console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - +1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12651608/HADOOP-10719.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-common-project/hadoop-kms. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4125//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4125//console This message is automatically generated.
        Hide
        Andrew Wang added a comment -

        Hey tucu, thought about this a little more. I can understand Owen and Larry's hesitations about extending the KeyProvider API like this, since these ops involving EDEKs feels implementation specific to our plan for HDFS encryption. We're also going to need some API for rolling EDEKs, likely a batch one.

        With this in mind, how do you feel about splitting some of this stuff out to a new interface implemented by the KMS (and I guess JKS for testing)? This way we can keep the KeyProvider interface nice and clean, but still have what we need on the HDFS side.

        Show
        Andrew Wang added a comment - Hey tucu, thought about this a little more. I can understand Owen and Larry's hesitations about extending the KeyProvider API like this, since these ops involving EDEKs feels implementation specific to our plan for HDFS encryption. We're also going to need some API for rolling EDEKs, likely a batch one. With this in mind, how do you feel about splitting some of this stuff out to a new interface implemented by the KMS (and I guess JKS for testing)? This way we can keep the KeyProvider interface nice and clean, but still have what we need on the HDFS side.
        Hide
        Alejandro Abdelnur added a comment -

        Mmmhh, I like the idea, let me give it a try.

        Show
        Alejandro Abdelnur added a comment - Mmmhh, I like the idea, let me give it a try.
        Hide
        Alejandro Abdelnur added a comment -

        OK, here is my thinking on how this could be done following Andrew's suggestion.

        • HDFS would wrap the KeyProvider instance with a KeyProviderCryptoExtensions
        • KeyProviders may implement the Extensions interface to provide the extensions functionality
        • KeyProviders not implementing the Extensions interface will work via a default implementation
        • KeyProviders implementing the Extensions interface will be able to do any necessary optimizations (like doing things on the server side, caching, pre-generation of EDEKs)

        The KeyProviderCryptoExtensions API would be something like:

        public class KeyProviderCryptoExtensions extends KeyProvider {
        
          public class EncryptedKeyVersion {
            public EncryptedKeyVersion(KeyVersion encryptionk, byte[] iv, KeyVersion encryptedK) {...}
            public KeyProvider.KeyVersion getEncryptionKey() {...}
            public byte[] getIV() {...}
            public KeyProvider.KeyVersion getEncryptedKey() {...}
          }
        
          public interface Extensions {
            
            public EncryptedKeyVersion generateEncryptedKey(
                KeyVersion encryptionKeyVersion);
        
            public KeyVersion decryptEncryptedKey(
                EncryptedKeyVersion encryptedKeyVersion);
          }
        
          private static class DefaultExtensions implements Extensions {    
            DefaultExtensions(KeyProvider kp) {...}
            ...
          }
        
          private KeyProvider keyProvider;
          private Extensions extensions;
          public KeyProviderCryptoExtensions(KeyProvider kp) {
            keyProvider = kp;
            if (kp instanceof Extensions) {
              extensions = (Extensions) kp;
            } else {
              extensions = new DefaultExtensions(kp);
            }
          }
          
          //all KeyProvider methods should delegate to keyProvider instance
        
          public EncryptedKeyVersion generateEncryptedKey(KeyVersion encryptionKeyVersion) {
            return extensions.generateEncryptedKey(encryptionKeyVersion);    
          }
          
          public KeyVersion decryptEncryptedKey(EncryptedKeyVersion encryptedKeyVersion) {
            return extensions.decryptEncryptedKey(encryptedKeyVersion);
          }
          
        }
        
        Show
        Alejandro Abdelnur added a comment - OK, here is my thinking on how this could be done following Andrew's suggestion. HDFS would wrap the KeyProvider instance with a KeyProviderCryptoExtensions KeyProviders may implement the Extensions interface to provide the extensions functionality KeyProviders not implementing the Extensions interface will work via a default implementation KeyProviders implementing the Extensions interface will be able to do any necessary optimizations (like doing things on the server side, caching, pre-generation of EDEKs) The KeyProviderCryptoExtensions API would be something like: public class KeyProviderCryptoExtensions extends KeyProvider { public class EncryptedKeyVersion { public EncryptedKeyVersion(KeyVersion encryptionk, byte [] iv, KeyVersion encryptedK) {...} public KeyProvider.KeyVersion getEncryptionKey() {...} public byte [] getIV() {...} public KeyProvider.KeyVersion getEncryptedKey() {...} } public interface Extensions { public EncryptedKeyVersion generateEncryptedKey( KeyVersion encryptionKeyVersion); public KeyVersion decryptEncryptedKey( EncryptedKeyVersion encryptedKeyVersion); } private static class DefaultExtensions implements Extensions { DefaultExtensions(KeyProvider kp) {...} ... } private KeyProvider keyProvider; private Extensions extensions; public KeyProviderCryptoExtensions(KeyProvider kp) { keyProvider = kp; if (kp instanceof Extensions) { extensions = (Extensions) kp; } else { extensions = new DefaultExtensions(kp); } } //all KeyProvider methods should delegate to keyProvider instance public EncryptedKeyVersion generateEncryptedKey(KeyVersion encryptionKeyVersion) { return extensions.generateEncryptedKey(encryptionKeyVersion); } public KeyVersion decryptEncryptedKey(EncryptedKeyVersion encryptedKeyVersion) { return extensions.decryptEncryptedKey(encryptedKeyVersion); } }
        Hide
        Andrew Wang added a comment -

        This is pretty cool! A few thoughts:

        If we want to add more methods, we might do so by adding a new e.g. MoreCryptoExtensions interface. Renaming like this might be more future-proof:

        • KeyProviderCryptoExtensions -> KeyProviderExtensions
        • Extensions -> CryptoExtensions
        • Does it make sense to put EncryptedKeyVersion inside the new interface?
        Show
        Andrew Wang added a comment - This is pretty cool! A few thoughts: If we want to add more methods, we might do so by adding a new e.g. MoreCryptoExtensions interface. Renaming like this might be more future-proof: KeyProviderCryptoExtensions -> KeyProviderExtensions Extensions -> CryptoExtensions Does it make sense to put EncryptedKeyVersion inside the new interface?
        Hide
        Arun Suresh added a comment -

        Andrew Wang, Uploading a patch with the suggested refactoring for review.

        Show
        Arun Suresh added a comment - Andrew Wang , Uploading a patch with the suggested refactoring for review.
        Hide
        Alejandro Abdelnur added a comment -
        • UserProvider.java change is not necessary, testcase could get provider via KeyProviderFactory
        • KeyProviderExtension, should override&delegate all methods signatures of KeyProvider
        • KeyProviderExtension, no need to use this.keyProvider in all methods, just keyProvider will do
        • KeyProviderExtension, I'm not fan of exposing protected instances as a subclass could modify it, I prefer using a protected getter.
        • KeyProviderExtension, why passing the extension instance here? is not used at all, it seems this belongs to the KPE subclass itself
        • KeyProviderCryptoExtension.EncryptedKeyVersion constructor should be visible to enable creation by extension implementations outside of the default one. Maybe protected and force extension impls to have its own a subclass? (we are doing that today with KeyVersion)
        • KeyProviderCryptoExtension.CryptoExtension javadoc, wrong param name, keyVersion should be encryptionKeyVersion
        • KeyProviderCryptoExtension, if extension instance var belongs to this class, then no need to cast, i can be CryptoExtension. also, no need to use this. (i guess you IDE is doing that)
        • KeyProviderCryptoExtension, the constructor should detect if the passed provider implements CryptoExtension itself, if so use that instead creating a default one.
        Show
        Alejandro Abdelnur added a comment - UserProvider.java change is not necessary, testcase could get provider via KeyProviderFactory KeyProviderExtension , should override&delegate all methods signatures of KeyProvider KeyProviderExtension , no need to use this.keyProvider in all methods, just keyProvider will do KeyProviderExtension , I'm not fan of exposing protected instances as a subclass could modify it, I prefer using a protected getter. KeyProviderExtension , why passing the extension instance here? is not used at all, it seems this belongs to the KPE subclass itself KeyProviderCryptoExtension.EncryptedKeyVersion constructor should be visible to enable creation by extension implementations outside of the default one. Maybe protected and force extension impls to have its own a subclass? (we are doing that today with KeyVersion) KeyProviderCryptoExtension.CryptoExtension javadoc, wrong param name, keyVersion should be encryptionKeyVersion KeyProviderCryptoExtension , if extension instance var belongs to this class, then no need to cast, i can be CryptoExtension. also, no need to use this. (i guess you IDE is doing that) KeyProviderCryptoExtension , the constructor should detect if the passed provider implements CryptoExtension itself, if so use that instead creating a default one.
        Hide
        Arun Suresh added a comment -

        Alejandro Abdelnur,
        Uploading updated patch..
        I think i've addressed all your comments. Although :

        KeyProviderCryptoExtension.EncryptedKeyVersion constructor should be visible to enable creation by extension implementations outside of the default one. Maybe protected and force extension impls to have its own a subclass? (we are doing that today with KeyVersion)

        I've removed the private but I've decided against having impls having a subclass of EncryptedKeyVersion. I feel it encapsulates everything required.

        Show
        Arun Suresh added a comment - Alejandro Abdelnur , Uploading updated patch.. I think i've addressed all your comments. Although : KeyProviderCryptoExtension.EncryptedKeyVersion constructor should be visible to enable creation by extension implementations outside of the default one. Maybe protected and force extension impls to have its own a subclass? (we are doing that today with KeyVersion) I've removed the private but I've decided against having impls having a subclass of EncryptedKeyVersion. I feel it encapsulates everything required.
        Hide
        Arun Suresh added a comment -

        Alejandro Abdelnur,

        KeyProviderCryptoExtension, the constructor should detect if the passed provider implements CryptoExtension itself, if so use that instead creating a default one.

        I couldn't add any more logic to the constructor, since I have to call super() or this() first.. So I've delegated this to a Factory class..

        Show
        Arun Suresh added a comment - Alejandro Abdelnur , KeyProviderCryptoExtension, the constructor should detect if the passed provider implements CryptoExtension itself, if so use that instead creating a default one. I couldn't add any more logic to the constructor, since I have to call super() or this() first.. So I've delegated this to a Factory class..
        Hide
        Andrew Wang added a comment -

        Hi Arun, thanks for working on this patch. Had a few review comments:

        • If we're targeting trunk rather than the fs-encryption branch with this, we don't have CryptoCodec. I think tucu stubbed this out in an earlier patch.
        • I don't understand the second factory method in KPCE, why do we do the if+cast? I think tucu wanted you to do this in the other factory method, createKPCE(KeyProvider, conf) to avoid the default KPCE.
        • Seems like we're going to have a hard time with multiple extension interfaces, i.e. if we wanted to put the proposed delegation token methods in KPDelegationTokenExtension (HADOOP-10769). Any thoughts there? One idea is to do something with composition and multiple interfaces. Each implementing class could hold an instance of DefaultCryptoExtension and defer to that.

        Nits:

        • Some lines longer than 80 chars
        • typos: "Cytographic", "KeyProvider. that", "KeyProvidetExtension"
        • Could delete the last empty line in your javadocs
        • "provide an implementation for" is a hanging participle, could say "This is a marker interface for the implementing KeyProviderExtension to implement."
        • slightly weird line-breaking in KPCE for flipIV
        Show
        Andrew Wang added a comment - Hi Arun, thanks for working on this patch. Had a few review comments: If we're targeting trunk rather than the fs-encryption branch with this, we don't have CryptoCodec. I think tucu stubbed this out in an earlier patch. I don't understand the second factory method in KPCE, why do we do the if+cast? I think tucu wanted you to do this in the other factory method, createKPCE(KeyProvider, conf) to avoid the default KPCE. Seems like we're going to have a hard time with multiple extension interfaces, i.e. if we wanted to put the proposed delegation token methods in KPDelegationTokenExtension ( HADOOP-10769 ). Any thoughts there? One idea is to do something with composition and multiple interfaces. Each implementing class could hold an instance of DefaultCryptoExtension and defer to that. Nits: Some lines longer than 80 chars typos: "Cytographic", "KeyProvider. that", "KeyProvidetExtension" Could delete the last empty line in your javadocs "provide an implementation for" is a hanging participle, could say "This is a marker interface for the implementing KeyProviderExtension to implement." slightly weird line-breaking in KPCE for flipIV
        Hide
        Alejandro Abdelnur added a comment -

        yep, we have to sort out the composition story, let me mull a bit about an idea and I'll revert back.

        Show
        Alejandro Abdelnur added a comment - yep, we have to sort out the composition story, let me mull a bit about an idea and I'll revert back.
        Hide
        Alejandro Abdelnur added a comment - - edited

        Actually, I think we can go simple here, we do not compose extensions, we simply use multiple extensions:

        KP kp = KP.findProvider();
        KPExtensionA kpea = new KPKExtensionA(kp);
        KPExtensionB kpeb = new KPKExtensionB(kp);
        

        When we need functionality form KPExtensionA we use kpea, and when we need functionality from KPExtensionB we use kpeb.

        The assumption he is that extensions provide disjoint functionality. For the cases where extensions are built on top of each other, then the extension constructor should reflect this contract using the concrete key provider extension it requires.

        thoughts?

        Show
        Alejandro Abdelnur added a comment - - edited Actually, I think we can go simple here, we do not compose extensions, we simply use multiple extensions: KP kp = KP.findProvider(); KPExtensionA kpea = new KPKExtensionA(kp); KPExtensionB kpeb = new KPKExtensionB(kp); When we need functionality form KPExtensionA we use kpea , and when we need functionality from KPExtensionB we use kpeb . The assumption he is that extensions provide disjoint functionality. For the cases where extensions are built on top of each other, then the extension constructor should reflect this contract using the concrete key provider extension it requires. thoughts?
        Hide
        Arun Suresh added a comment -

        That would make things simple.
        Additionally, maybe we should make the constructors of KPExtensionA and KPExtensionB private and allow them to be created only via a factory.. this way, we can probably cache instances of it and control the actual number of instances.

        Show
        Arun Suresh added a comment - That would make things simple. Additionally, maybe we should make the constructors of KPExtensionA and KPExtensionB private and allow them to be created only via a factory.. this way, we can probably cache instances of it and control the actual number of instances.
        Hide
        Alejandro Abdelnur added a comment -

        The extensions classes are ligthweigth classes and in some cases will be implemented by the keyprovider itself, so I wouldn't worry about the caching thing.

        Some additional feedback on the patch:

        KeyProviderCryptoExtension.Factory, I think could get rid of the factory inner class and simply have a static method:

          public static KeyProviderCryptoExtension getCryptoExtension(
              KeyProvider keyProvider, Configuration conf) {
            if (keyProvider instanceof CryptoExtension) {
              return new KeyProviderCryptoExtension(keyProvider,
                  (CryptoExtension) keyProvider);
            } else {
              return new KeyProviderCryptoExtension(keyProvider, 
                  new DefaultCryptoExtension(keyProvider, conf));
            }
          }
        

        Also, we should maybe get rid of the Configuration param and have KeyProvider to have a getConf() method and us that one to crate the DefaultCryptoExtension.

        KeyProviderCryptoExtension.DefaultCryptoExtension should be a private class.

        KeyProviderCryptoExtension.DefaultCryptoExtension#generateEncryptedKey() should be using Cipher instead of CryptoCodec in trunk, in fs-encryption we should change it, both here and in decryptEncryptedKey() to use CryptoCodec.

        Show
        Alejandro Abdelnur added a comment - The extensions classes are ligthweigth classes and in some cases will be implemented by the keyprovider itself, so I wouldn't worry about the caching thing. Some additional feedback on the patch: KeyProviderCryptoExtension.Factory, I think could get rid of the factory inner class and simply have a static method: public static KeyProviderCryptoExtension getCryptoExtension( KeyProvider keyProvider, Configuration conf) { if (keyProvider instanceof CryptoExtension) { return new KeyProviderCryptoExtension(keyProvider, (CryptoExtension) keyProvider); } else { return new KeyProviderCryptoExtension(keyProvider, new DefaultCryptoExtension(keyProvider, conf)); } } Also, we should maybe get rid of the Configuration param and have KeyProvider to have a getConf() method and us that one to crate the DefaultCryptoExtension. KeyProviderCryptoExtension.DefaultCryptoExtension should be a private class. KeyProviderCryptoExtension.DefaultCryptoExtension#generateEncryptedKey() should be using Cipher instead of CryptoCodec in trunk, in fs-encryption we should change it, both here and in decryptEncryptedKey() to use CryptoCodec.
        Hide
        Arun Suresh added a comment -

        Alejandro Abdelnur, The problem with having just the static method you specified is that you are kind of restricting the compos-ability of the KeyProviderCryptoExtension. For Instance, How will you combine a JavaKeyStoreProvider with some different type of CryptoExtension other than DefautlCryptoExtension ?

        Show
        Arun Suresh added a comment - Alejandro Abdelnur , The problem with having just the static method you specified is that you are kind of restricting the compos-ability of the KeyProviderCryptoExtension . For Instance, How will you combine a JavaKeyStoreProvider with some different type of CryptoExtension other than DefautlCryptoExtension ?
        Hide
        Mike Yoder added a comment -

        Crypto-nerd comments - in generateEncryptedKey()...

        • The line "SecureRandom.getInstance("SHA1PRNG").nextBytes(newKey);" - two things: SHA1 is obsolete, can you choose something stronger? I don't know what the set of valid options are, but if there is one that resembles "NIST SP 800-90" then pick that one. Also you're doing the getInstance call every time through this function, better to call it once for the class and then just call nextBytes in this function? We probably also will want to build in new re-seeding logic around this random stream. Key generation is highly scrutinized, trust me!
        • The line "Cipher cipher = Cipher.getInstance("AES/CTR/NoPadding");" - can you please use CBC mode instead of CTR mode? If we use CTR mode we're subjecting the encrypted DEK to all the attacks we're trying to avoid for the data itself. CBC mode has none of the nasty ciphertext attack problems that CTR mode has.
        Show
        Mike Yoder added a comment - Crypto-nerd comments - in generateEncryptedKey()... The line "SecureRandom.getInstance("SHA1PRNG").nextBytes(newKey);" - two things: SHA1 is obsolete, can you choose something stronger? I don't know what the set of valid options are, but if there is one that resembles "NIST SP 800-90" then pick that one. Also you're doing the getInstance call every time through this function, better to call it once for the class and then just call nextBytes in this function? We probably also will want to build in new re-seeding logic around this random stream. Key generation is highly scrutinized, trust me! The line "Cipher cipher = Cipher.getInstance("AES/CTR/NoPadding");" - can you please use CBC mode instead of CTR mode? If we use CTR mode we're subjecting the encrypted DEK to all the attacks we're trying to avoid for the data itself. CBC mode has none of the nasty ciphertext attack problems that CTR mode has.
        Hide
        Alejandro Abdelnur added a comment -

        As mentioned before, I wouldn't worry about composibilty, I would rather say no to it and you have different extensions wrapping the same provider instance, one for each use.

        Show
        Alejandro Abdelnur added a comment - As mentioned before, I wouldn't worry about composibilty, I would rather say no to it and you have different extensions wrapping the same provider instance, one for each use.
        Hide
        Alejandro Abdelnur added a comment -

        Mike Yoder, the use of JDK JCE Cipher is temporary until we integrate with fs-encryption branch where we have all this taken care by the CryptoCodec API.

        Show
        Alejandro Abdelnur added a comment - Mike Yoder , the use of JDK JCE Cipher is temporary until we integrate with fs-encryption branch where we have all this taken care by the CryptoCodec API.
        Hide
        Arun Suresh added a comment -

        Uploading patch with feedbacks addressed.. thank you all for the review !
        This patch is to be applied to trunk

        Show
        Arun Suresh added a comment - Uploading patch with feedbacks addressed.. thank you all for the review ! This patch is to be applied to trunk
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12653974/HADOOP-10719.3.patch
        against trunk revision .

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 1 new or modified test files.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 javadoc. There were no new javadoc warning messages.

        +1 eclipse:eclipse. The patch built with eclipse:eclipse.

        +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        -1 core tests. The patch failed these unit tests in hadoop-common-project/hadoop-common:

        org.apache.hadoop.ha.TestZKFailoverControllerStress

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4206//testReport/
        Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4206//console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12653974/HADOOP-10719.3.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. -1 core tests . The patch failed these unit tests in hadoop-common-project/hadoop-common: org.apache.hadoop.ha.TestZKFailoverControllerStress +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4206//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4206//console This message is automatically generated.
        Hide
        Arun Suresh added a comment -

        Resubmitting to kick-off tests

        Show
        Arun Suresh added a comment - Resubmitting to kick-off tests
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12654114/HADOOP-10719.3.patch
        against trunk revision .

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 1 new or modified test files.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 javadoc. There were no new javadoc warning messages.

        +1 eclipse:eclipse. The patch built with eclipse:eclipse.

        +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        -1 core tests. The patch failed these unit tests in hadoop-common-project/hadoop-common:

        org.apache.hadoop.ha.TestZKFailoverControllerStress

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4210//testReport/
        Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4210//console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12654114/HADOOP-10719.3.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. -1 core tests . The patch failed these unit tests in hadoop-common-project/hadoop-common: org.apache.hadoop.ha.TestZKFailoverControllerStress +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4210//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4210//console This message is automatically generated.
        Hide
        Alejandro Abdelnur added a comment -

        Some corrections:

        • DEK/EDEK constants should be renamed EK/EEK. We should not assume they will be used to encrypt only data. javadocs should not refer to data encryption key but encryption key.
        • The EncryptedKeyVersion inner class should be inner class of the KeyProviderCryptoExtension, not of the CryptoExtension interface, it should be made static as well.
        • The constructor of the DefaultCryptoExtension should be made private.
        • The extension method names in the KeyProviderCryptoExtension should match the method names of the CryptoExtension interface. Also, they should have the same javadocs.
        • The createKeyProviderCryptoExtension impl will simpler doing:
          public static KeyProviderCryptoExtension createKeyProviderCryptoExtension(
              KeyProvider keyProvider) {
            CryptoExtension cryptoExtension = (keyProvider instanceof CryptoExtension)
                                 ? (CryptoExtension) keyProvider
                                 : new DefaultCryptoExtension(keyProvider);
            return new KeyProviderCryptoExtension(keyProvider, cryptoExtension);
          }  
        
        • The createKeyProviderCryptoExtension needs javadocs.
        • The Configuration is not needed for creating the extensions. Though, KeyProvider should expose the configuration used for its creation for extensions to be able to get config from there (please open a JIRA for this).
        • The test for the KeyProviderCryptoExtension should be in its own test class.

        After all this is addressed we are good to go.

        Show
        Alejandro Abdelnur added a comment - Some corrections: DEK/EDEK constants should be renamed EK/EEK. We should not assume they will be used to encrypt only data. javadocs should not refer to data encryption key but encryption key. The EncryptedKeyVersion inner class should be inner class of the KeyProviderCryptoExtension , not of the CryptoExtension interface, it should be made static as well. The constructor of the DefaultCryptoExtension should be made private. The extension method names in the KeyProviderCryptoExtension should match the method names of the CryptoExtension interface. Also, they should have the same javadocs. The createKeyProviderCryptoExtension impl will simpler doing: public static KeyProviderCryptoExtension createKeyProviderCryptoExtension( KeyProvider keyProvider) { CryptoExtension cryptoExtension = (keyProvider instanceof CryptoExtension) ? (CryptoExtension) keyProvider : new DefaultCryptoExtension(keyProvider); return new KeyProviderCryptoExtension(keyProvider, cryptoExtension); } The createKeyProviderCryptoExtension needs javadocs. The Configuration is not needed for creating the extensions. Though, KeyProvider should expose the configuration used for its creation for extensions to be able to get config from there (please open a JIRA for this). The test for the KeyProviderCryptoExtension should be in its own test class. After all this is addressed we are good to go.
        Hide
        Arun Suresh added a comment -

        Thanks Alejandro Abdelnur..
        Uploading patch..

        Show
        Arun Suresh added a comment - Thanks Alejandro Abdelnur .. Uploading patch..
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12654129/HADOOP-10719.4.patch
        against trunk revision .

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 1 new or modified test files.

        -1 javac. The patch appears to cause the build to fail.

        Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4211//console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12654129/HADOOP-10719.4.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. -1 javac . The patch appears to cause the build to fail. Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4211//console This message is automatically generated.
        Hide
        Arun Suresh added a comment -

        Updating with rebased Patch..

        Show
        Arun Suresh added a comment - Updating with rebased Patch..
        Hide
        Hadoop QA added a comment -

        +1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12654131/HADOOP-10719.5.patch
        against trunk revision .

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 1 new or modified test files.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 javadoc. There were no new javadoc warning messages.

        +1 eclipse:eclipse. The patch built with eclipse:eclipse.

        +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-common.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4212//testReport/
        Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4212//console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - +1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12654131/HADOOP-10719.5.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-common-project/hadoop-common. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4212//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4212//console This message is automatically generated.
        Hide
        Alejandro Abdelnur added a comment -

        +1

        Show
        Alejandro Abdelnur added a comment - +1
        Hide
        Alejandro Abdelnur added a comment -

        Thanks Arun. Committed to trunk.

        Show
        Alejandro Abdelnur added a comment - Thanks Arun. Committed to trunk.
        Hide
        Hudson added a comment -

        SUCCESS: Integrated in Hadoop-trunk-Commit #5829 (See https://builds.apache.org/job/Hadoop-trunk-Commit/5829/)
        HADOOP-10719. Add generateEncryptedKey and decryptEncryptedKey methods to KeyProvider. (asuresh via tucu) (tucu: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1607918)

        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderCryptoExtension.java
        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderExtension.java
        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/crypto/key/TestKeyProviderCryptoExtension.java
        Show
        Hudson added a comment - SUCCESS: Integrated in Hadoop-trunk-Commit #5829 (See https://builds.apache.org/job/Hadoop-trunk-Commit/5829/ ) HADOOP-10719 . Add generateEncryptedKey and decryptEncryptedKey methods to KeyProvider. (asuresh via tucu) (tucu: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1607918 ) /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderCryptoExtension.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderExtension.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/crypto/key/TestKeyProviderCryptoExtension.java
        Hide
        Hudson added a comment -

        FAILURE: Integrated in Hadoop-Yarn-trunk #604 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/604/)
        HADOOP-10719. Add generateEncryptedKey and decryptEncryptedKey methods to KeyProvider. (asuresh via tucu) (tucu: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1607918)

        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderCryptoExtension.java
        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderExtension.java
        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/crypto/key/TestKeyProviderCryptoExtension.java
        Show
        Hudson added a comment - FAILURE: Integrated in Hadoop-Yarn-trunk #604 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/604/ ) HADOOP-10719 . Add generateEncryptedKey and decryptEncryptedKey methods to KeyProvider. (asuresh via tucu) (tucu: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1607918 ) /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderCryptoExtension.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderExtension.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/crypto/key/TestKeyProviderCryptoExtension.java
        Hide
        Hudson added a comment -

        FAILURE: Integrated in Hadoop-Hdfs-trunk #1795 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1795/)
        HADOOP-10719. Add generateEncryptedKey and decryptEncryptedKey methods to KeyProvider. (asuresh via tucu) (tucu: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1607918)

        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderCryptoExtension.java
        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderExtension.java
        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/crypto/key/TestKeyProviderCryptoExtension.java
        Show
        Hudson added a comment - FAILURE: Integrated in Hadoop-Hdfs-trunk #1795 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1795/ ) HADOOP-10719 . Add generateEncryptedKey and decryptEncryptedKey methods to KeyProvider. (asuresh via tucu) (tucu: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1607918 ) /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderCryptoExtension.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderExtension.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/crypto/key/TestKeyProviderCryptoExtension.java
        Hide
        Hudson added a comment -

        FAILURE: Integrated in Hadoop-Mapreduce-trunk #1822 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1822/)
        HADOOP-10719. Add generateEncryptedKey and decryptEncryptedKey methods to KeyProvider. (asuresh via tucu) (tucu: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1607918)

        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderCryptoExtension.java
        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderExtension.java
        • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/crypto/key/TestKeyProviderCryptoExtension.java
        Show
        Hudson added a comment - FAILURE: Integrated in Hadoop-Mapreduce-trunk #1822 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1822/ ) HADOOP-10719 . Add generateEncryptedKey and decryptEncryptedKey methods to KeyProvider. (asuresh via tucu) (tucu: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1607918 ) /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderCryptoExtension.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/KeyProviderExtension.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/crypto/key/TestKeyProviderCryptoExtension.java

          People

          • Assignee:
            Arun Suresh
            Reporter:
            Alejandro Abdelnur
          • Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development