-
Notifications
You must be signed in to change notification settings - Fork 768
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement PKCS#7 signature verification. #706
Open
roysjosh
wants to merge
7
commits into
digitalbazaar:main
Choose a base branch
from
roysjosh:ImplementPkcs7Verify
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 1 commit
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
cfff1d7
Implement PKCS#7 signature verification.
roysks c1f5084
Add certificate chain verification.
roysks fd656a1
Add callback for each PKCS#7 signature verification.
roysks 43ff714
Support arbitrary attributes (e.g. S/MIME caps)
roysks 25c7b12
pkcs7: allow for null validityCheckDate for consistency with x509
fergusean b4385e2
Add example of PKCS#7 verification to README
roysks fce10da
Add util.compareDN documentation and update variable names
roysks File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Add certificate chain verification.
- Loading branch information
commit c1f5084eb81c00b0e6810c0767b85216ddaa1da1
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see you're providing for
options.callback
. This seems to me to be an unconventional way of implementing a callback which would not be compatible withutil.promisify
implementations which expect the last param to be a callback function.That said, can you say more about the use case for callbacks here? Given that all the code here is synchronous, does the callback add value?
If the callback is going to remain part of this API, it appears to me that it is not being called in a number of situations. For example, if the conditional on L556 fails we end up at L677
retrurn rval;
and the callback is never called. Also, for the most part this function is written to throw errors at various times when it may be appropriate to call the callback withcallback(err);
instead.Do you think it would be simpler to eliminate the callback functionality?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a callback so that as a part of the verification process you would get information on good signatures to display to the user. I would like to keep it for that reason. I'll clean it up and make it promisifyable and we'll see how it looks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushed, let me know what you think. Double check the code flow? L556-573 is a contained if/else block.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello, are you saying you implemented the callback in order to return different values from a synchronous call vs a callback call? It does appear that is what is happening? I think we need the sync/callback versions to return the same data structure, is there something preventing consistency here? And if the synchronous version can return the same data structure as the callback, do we still need the callback? https://github.com/digitalbazaar/forge/pull/706/files#diff-d4c741d422d58aea2d7ffefe1687abd2R678
Also, without a
process.nextTick
or something to defer execution, I believe this code effectively runs synchronously with or without the callback.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose of the callback isn't to get a result so much as status updates on each signature processed. The verify function could return an array of results, yes. At that point I would just eliminate the callback. Is that what you would prefer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand now that my confusion has been caused by referring to this passed in function as a
callback
. I think of acallback
as a function that is called when the called function completes/errors. This is reflected in theutil.promisify
API such that the Promise is resolved when the callback is invoked, which is not what you are attempting to do here.If this were a long running asynchronous process, a solution involving event emitters might be appropriate.
Now that I understand what you're trying to do and
options.onSignatureVerificationComplete
handler might be appropriate.Do you have some use case that requires there to be status updates on each signature? If not, then I think removing the status callback function would be best.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I modify the return to contain the same info as the status callback/emitter then no, I don't need it. I'll do that now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up going with the per-signature event emitter vs a return of an array of results. Let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be a common pattern in the whole lib for events and more detailed results. That's a bigger project. This does do the common return true/false and that will work for now.