[
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
