Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Fri, 1 Feb 2013 19:36:13 +0000 (UTC)
From: "Keith Turner (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12628553.1358777758049.231019.1359747373418@arcas>
In-Reply-To: <JIRA.12628553.1358777758049@arcas>
References: <JIRA.12628553.1358777758049@arcas>
Subject: [jira] [Commented] (ACCUMULO-980) support pluggable codecs for
 RFile
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Keith Turner commented on ACCUMULO-980:
---------------------------------------

Some thoughts on storing block un-encrypted in memory.   The data has to be decrypted and stored in memory at some point to be read.  Not storing it decrypted in cache just reduces the probability of that data swapping.  I would think if someone is using encryption, they would appropriately configure swap.  I am thinking we should not concern ourselves with swap or scrubbing all memory that ever held encrypted data.   I suppose one other consideration with the cache is that the decrypted data could still be floating around there even after a table was deleted.  This data would be available to anyone that could do a heap dump.
                
> support pluggable codecs for RFile
> ----------------------------------
>
>                 Key: ACCUMULO-980
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-980
>             Project: Accumulo
>          Issue Type: Improvement
>            Reporter: Adam Fuchs
>            Assignee: Adam Fuchs
>             Fix For: 1.6.0
>
>         Attachments: RFile-Changes-Proposal-V1.pdf
>
>
> As part of the encryption at rest story, RFile should support pluggable modules where it currently has hardcoded options for compression codecs. This is a natural place to add encryption capabilities, as the cost of encryption would likely not be significantly different from the cost of compression, and the block-level integration should maintain the same seek and scan performance. Given the many implementation options for both encryption and compression, it makes sense to have a plugin structure here.

--
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