accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ACCUMULO-958) Support pluggable encryption in walogs
Date Thu, 31 Jan 2013 19:01:17 GMT

    [ 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

Mime
View raw message