[ 
https://issues.apache.org/jira/browse/PIRK-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404709#comment-15404709
 ] 

ASF GitHub Bot commented on PIRK-29:
------------------------------------

Github user ellisonanne commented on a diff in the pull request:

    https://github.com/apache/incubator-pirk/pull/43#discussion_r73229816
  
    --- Diff: 
src/main/java/org/apache/pirk/querier/wideskies/QuerierDriver.java ---
    @@ -91,7 +91,7 @@ public static void main(String... args) throws 
IOException, InterruptedException
         int dataPartitionBitSize = 0;
         int paillierBitSize = 0;
         int certainty = 0;
    -    String queryName = null;
    --- End diff --
    
    The queryName corresponds to the schemaName in the query-schema.xsd file 
*not* to the user-given identifier for the  query -- the identifier for this 
query is actually the queryNum. Notice that queryNum is currently a double -- 
if we want to start appending dates or whatever else to it, we need to change 
its type to String throughout.


> User should be notified when attempting to decrypt with wrong querier.
> ----------------------------------------------------------------------
>
>                 Key: PIRK-29
>                 URL: https://issues.apache.org/jira/browse/PIRK-29
>             Project: PIRK
>          Issue Type: Improvement
>          Components: Querier
>            Reporter: Chris Harris
>            Assignee: Joseph Kovba
>
> Encrypting a query produces a Query and a Querier object that are saved as 
> files.  The Query file is then passed to the Responder and used to generate 
> Response files, i.e. the encrypted results of the query.  The user can then 
> decrypt these results via the QuerierDriver after specifying the Querier file 
> along with the Response file.  If the user specifies an incorrect Querier 
> file, meaning one different than the one that was produced alongside the 
> Query file that was given to the driver, then decryption will produce no 
> results.  The problem is that the user will not know that there are no 
> results as a result of an error, rather than that there were no legitimate 
> results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to