[
https://issues.apache.org/jira/browse/HADOOP-10632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14011344#comment-14011344
]
Alejandro Abdelnur commented on HADOOP-10632:
---------------------------------------------
Thanks Yi, looks good, a few follow ups for your consideration:
CryptoInputStream#freeBuffers(), not sure we should tap into SUN internal APIs
here. do we gain something by cleaning up the buffers? And if we do, we should
first check that the DB is a sun.nio.ch.DB instance. (Sorry, I’ve missed this
one in my first passed)
CryptoInputStream#decrypt(), you changed the signature to take the outBuffer as
param, wouldn’t make sense to take both input and output buffers as parameters
then, then the usage form the read-pos would be simpler. What I’m thinking is
that the read-pos/readFully should leave alone all instance vars related to
normal stream reading and use a complete different set of vars that are
instantiated on their first use and reset before every use.
CryptoInputStream, read-pos() and readFully(), wouldn’t we have to consider the
padding based on the requested pos there? If so, the decrypt(), following
previous comment, would have to receive the padding as param as well, no?
On failing the Crypto streams constructors if the buffer size is not a multiple
of the block size, I’ve thought about that initially, but that seemed a too
strong requirement to me, that is why I suggested flooring the request buffer
to the closest previous block size multiple.
> Minor improvements to Crypto input and output streams
> -----------------------------------------------------
>
> Key: HADOOP-10632
> URL: https://issues.apache.org/jira/browse/HADOOP-10632
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: security
> Affects Versions: fs-encryption (HADOOP-10150 and HDFS-6134)
> Reporter: Alejandro Abdelnur
> Assignee: Yi Liu
> Fix For: 3.0.0
>
> Attachments: HADOOP-10632.1.patch, HADOOP-10632.patch
>
>
> Minor follow up feedback on the crypto streams
--
This message was sent by Atlassian JIRA
(v6.2#6252)
