[
https://issues.apache.org/jira/browse/NIFI-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15020256#comment-15020256
]
Andre commented on NIFI-1209:
-----------------------------
[~joewitt]
If you leave the hash tree aside, a sidecar signature alongside with the signed
file would the easiest way of achieving it and the less disruptive to existing
workflows. It would also be quite natural workflow for those used in dealing
with signed files (e.g. developer getting tarballs from the internet).
The only point that I would like to point out is that pure Hadoop folks (I use
mostly MapR) around here will be a bit thrown off by the size of the file and
is potential long term impact on namenode (the well known small files plague).
We could simply accept this, after all both files could always be merged into a
HAR file without issues - something HDFS admins already do back to front - or...
It came to me that perhaps the best way would be having a "SignContent"
processor, similar to EncryptContent, but that instead of encrypting the
flowfile and pushing it via success/failure relationship, you would:
1. Pass the original flowfile to the next hop via success
2a. Create a signature flowfile and "publish" it via a "signed" relationship.
or
2b. Append a signature attribute to the original flowfile (that can then exit
via Success/Failure relationship).
This would allow people to deal with the signed data they way they wish:
* a simple approach for option 2b would be using Log Attribute to keep track of
the signature;
* While option 2a could be saved via PutFile, PutHDFS (although matching
filenames would be sort of a pain, but I think possible).
> Add the ability to sign files to PutFile / PutHDFS
> --------------------------------------------------
>
> Key: NIFI-1209
> URL: https://issues.apache.org/jira/browse/NIFI-1209
> Project: Apache NiFi
> Issue Type: New Feature
> Reporter: Andre
>
> NiFi allows the Dataflows to be signed, however, this causes some
> complexities in processing data downstream.
> Furthemore, frequently, entities are happy to forfeit dataflow encryption for
> the use of hashing mechanisms + public keys that can "guarantee" (e.g. GPG
> signatures) the integrity of a resultant file once it has been stored for
> long term archival (e.g. HDFS).
> it would be great to have the ability to sign files being written by PutFile
> and PutHDFS as they are written to disk.
> PS-A added bonus would be to in addition to public key encryption, using
> Merkle Hash Trees for providing non-repudiation of data flows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)