hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brock Noland (JIRA)" <>
Subject [jira] [Commented] (HIVE-9167) Enhance encryption testing framework to allow create keys & zones inside .q files
Date Fri, 19 Dec 2014 17:28:13 GMT


Brock Noland commented on HIVE-9167:

bq. do we real need add the crypto command for the beeline? 

Sergio mentioned this to me offline and my understanding is that we would not have the crypto
command to beeline. It'd only be enabled for tests and thus not be a public API.

bq.  What I am trying to do with the crypto commands is that we can create encryption zones
for specific tables during our tests. Users will have tables with different encryption zones,
and I'd like to test different queries that work with these tables.

If we can do this without exposing the command to the end user (i.e. only in tests), I think
this is a good approach. My reasoning is:

# We need to test db level encryption in addition to each table being a different encryption
# I feel like being able to create the ez's in the q-file is a little less error prone than
creating the ez's in a separate location. It'd be very easy to mis-name the location of a
table and thus not actually test with an encrypted location.

> Enhance encryption testing framework to allow create keys & zones inside .q files
> ---------------------------------------------------------------------------------
>                 Key: HIVE-9167
>                 URL:
>             Project: Hive
>          Issue Type: Sub-task
>            Reporter: Sergio Peña
>            Assignee: Sergio Peña
> The current implementation of the encryption testing framework on HIVE-8900 initializes
a couple of encrypted databases to be used on .q test files. This is useful in order to make
tests small, but it does not test all details found on the encryption implementation, such
as: encrypted tables with different encryption strength in the same database.
> We need to allow this kind of encryption as it is how it will be used in the real world
where a database will have a few encrypted tables (not all the DB).
> Also, we need to make this encryption framework flexible so that we can create/delete
keys & zones on demand when running the .q files. 

This message was sent by Atlassian JIRA

View raw message