[
https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140037#comment-15140037
]
Blake Eggleston commented on CASSANDRA-9633:
--------------------------------------------
bq. Are you good with separate tickets for that work, or does it make sense to
lump it here?
I'd prefer to keep it in this ticket, only because I don't think sstable
encryption should be committed without index file encryption. That said, it
probably makes sense to get the sstable stuff fleshed out, then do the index
files.
bq. Not sure I understand the suggestion here. Can you clarify a bit?
I just meant that, in my hypothetical index file compression approach, it
wouldn't make sense to compress the index files unless you were encrypting
them. So you'd want the compressor to tell the sstable writer whether it should
compress the index file. Just getting ahead of myself :)
> Add ability to encrypt sstables
> -------------------------------
>
> Key: CASSANDRA-9633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9633
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jason Brown
> Assignee: Jason Brown
> Labels: encryption, security, sstable
> Fix For: 3.x
>
>
> Add option to allow encrypting of sstables.
> I have a version of this functionality built on cassandra 2.0 that
> piggy-backs on the existing sstable compression functionality and ICompressor
> interface (similar in nature to what DataStax Enterprise does). However, if
> we're adding the feature to the main OSS product, I'm not sure if we want to
> use the pluggable compression framework or if it's worth investigating a
> different path. I think there's a lot of upside in reusing the sstable
> compression scheme, but perhaps add a new component in cqlsh for table
> encryption and a corresponding field in CFMD.
> Encryption configuration in the yaml can use the same mechanism as
> CASSANDRA-6018 (which is currently pending internal review).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
