verify on Windows about lrsignature HOT 4 CLOSED

I just tried this. Since I don't have the actual errors I can't do much.

From what I can tell, GPG should be installed on a users path, there seems to be problems in general executing applicatons with spaces.

When I did it with gpg on the path, I had no problems with it signing or validating.

from lrsignature.

jimklo

I just walked through the 20 minute guide and ran into the same issue. I have gpg on my path. I'm using gpg4win 2.1.0.

Walking through the code, there's two issues I've run into...

1. Verify's _getSignature function wasn't finding "digital_signature" in the document. This function was looking for the key "digital_signature" on the root of the document (named in the function as envelope). Since digital_signature is part of the records' resource_data, this key wasn't found and would return None. I changed that to dig down to the resource_data before looking for digital_signature and that worked.
2. Sign's get_message function doesn't produce the right hash during verify. It pulls the correct one from the signature but the generated one doesn't match. Unfortunately I don't know enough about this hashing process to really look into how to fix this.

To be clear, I get a result. It's just that the result is not what's shown in the 20 minute guide. Before the 'fix' to 1., the verify command would return {"results": [{"verified": null}]} After the 'fix' to 1., I get {"results": [{"verified": false}]}, with the verifiedHash from line ~121 in Verify not matching self.get_message(envelope).

from lrsignature.

1. Envelope is the internal name for a Resource Data Document - It's looking for it in the right place. Verify looks the envelope only... not the response. The Pipetool is supposed to dissect envelope out of the response. What is probably wrong is that I think the harvest interface used to have the wrong output format (note it's Verify 0.21.0 NOT 0.23.0). I vaguely recall that it was looking for a list of envelopes - NOT a OAI-like response, which harvest now has. I've not checked, but I think it expects it in the old response format, hence if it's not finding the envelope in the response then that's where the problem is.
2. Since the hash is dependent upon reading the envelope, I suspect its not finding the envelope right for 0.23.0.

On Sep 20, 2011, at 6:58 AM, creighton wrote:

jimklo

I just walked through the 20 minute guide and ran into the same issue. I have gpg on my path. I'm using gpg4win 2.1.0.

Walking through the code, there's two issues I've run into...

1. Verify's _getSignature function wasn't finding "digital_signature" in the document. This function was looking for the key "digital_signature" on the root of the document (named in the function as envelope). Since digital_signature is part of the records' resource_data, this key wasn't found and would return None. I changed that to dig down to the resource_data before looking for digital_signature and that worked.
2. Sign's get_message function doesn't produce the right hash during verify. It pulls the correct one from the signature but the generated one doesn't match. Unfortunately I don't know enough about this hashing process to really look into how to fix this.

To be clear, I get a result. It's just that the result is not what's shown in the 20 minute guide. Before the 'fix' to 1., the verify command would return {"results": [{"verified": null}]} After the 'fix' to 1., I get {"results": [{"verified": false}]}, with the verifiedHash from line ~121 in Verify not matching self.get_message(envelope).

Reply to this email directly or view it on GitHub:
#1 (comment)

from lrsignature.

Fixed with 0.1.8 release.

from lrsignature.