[jira] [Comment Edited] (ACCUMULO-958) Support pluggable encryption in walogs

["Christopher Tubbs (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ACCUMULO-958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13567939#comment-13567939 ] 

Christopher Tubbs edited comment on ACCUMULO-958 at 1/31/13 7:01 PM:
---------------------------------------------------------------------

If this is going to make it in to the existing code (and stay), however polished it will be by the next release, I'd like to see it clearly marked as experimental, until it is available as a complete and coherent framework for encrypting table contents.

So, I suggest moving the relevant classes into an "experimental" sub-package, and minimizing references to them in other code. I looked for a built-in "@Experimental" annotation, but couldn't find one, so we could create one for this sort of thing (but I still prefer the sub-package until it is no longer experimental). I do *not* think that they should be marked as "@Deprecated" because that implies a completely different point in the life cycle of the code (in fact, it implies the opposite end of that life cycle).

That said, what exactly are the next actions, and the timeline for polishing this feature? From the previous comment, I gather "tests", and "tidiness" (which I interpret to mean QA refactorings, but not functional changes that incorporate critical feedback). Are there more anticipated actions that I've overlooked?
                
      was (Author: ctubbsii):
    If this is going to make it in to the existing code, however polished it will be by the next release, I'd like to see it clearly marked as experimental, until it is available as a complete and coherent framework for encrypting table contents.

So, I suggest moving the relevant classes into an "experimental" sub-package, and minimizing references to them in other code. I looked for a built-in "@Experimental" annotation, but couldn't find one, so we could create one for this sort of thing (but I still prefer the sub-package until it is no longer experimental). I do *not* think that they should be marked as "@Deprecated" because that implies a completely different point in the life cycle of the code (in fact, it implies the opposite end of that life cycle).

That said, what exactly are the next actions, and the timeline for polishing this feature? From the previous comment, I gather "tests", and "tidiness" (which I interpret to mean QA refactorings, but not functional changes that incorporate critical feedback). Are there more anticipated actions that I've overlooked?
                  
> Support pluggable encryption in walogs
> --------------------------------------
>
>                 Key: ACCUMULO-958
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-958
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: logger
>            Reporter: John Vines
>            Assignee: Michael Allen
>             Fix For: 1.5.0
>
>         Attachments: ACCUMULO-958-actual-changes.patch, accumulo-958.diff
>
>
> There are some cases where users want encryption at rest for the walogs. It should be fairly trivial to implement it in such a way to insert a CipherOutputStream into the data path (defaulting to using a NullCipher) and then making the Cipher pluggable to users can insert the appropriate mechanisms for their use case.
> This also means swapping in CipherInputStream and putting in a check to make sure the Cipher type's match at read and write time. Possibly a versioning mechanism so people can migrate Ciphers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira