hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alejandro Abdelnur (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-10611) KeyVersion name should not be assumed to be the 'key name @ the version number"
Date Tue, 27 May 2014 15:55:01 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-10611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009828#comment-14009828

Alejandro Abdelnur commented on HADOOP-10611:

Owen, I'm ok with some implementations choosing to use <NAME>@<COUNTER> as the
version ID. However, I don' think we can mandate that, specially when integrating with 3rd
party key management solutions which generate their own opaque key version IDs.

The purpose of this JIRA is to ensure that KeyProvider/KeyShell/KMS don't assume the version
ID is <NAME>@<COUNTER>, rather threat it as an opaque value.

Regarding the existing methods in the public API, such as {{buildVersionName()}}, I would
propose moving them to a {{KeyProviderUtils}} class for KeyProvider implementations that choose
to use the <NAME>@<COUNTER> version ID format.

> KeyVersion name should not be assumed to be the 'key name @ the version number"
> -------------------------------------------------------------------------------
>                 Key: HADOOP-10611
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10611
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 3.0.0
>            Reporter: Alejandro Abdelnur
>            Assignee: Alejandro Abdelnur
> The KeyProvider public API should treat keyversion name as an opaque value. Same for
the KMS client/server.
> Methods like {{KeyProvider#buildVersionName()}} and {KeyProvider#getBaseName()}} should
not be part of the {{KeyProvider}} 

This message was sent by Atlassian JIRA

View raw message