-
Notifications
You must be signed in to change notification settings - Fork 97
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
feat: add support for proof of absence in certificate lookups #878
feat: add support for proof of absence in certificate lookups #878
Conversation
@krpeacock it would be good to get your opinion on the interface here. I've kept it so that Would you prefer to keep it like this or to propagate the new behaviour to the It's also possible now to make the agent more robust by retrying requests when requested certificate entries are |
throw new Error('Time was not found in the response or was not in its expected format.'); | ||
} | ||
|
||
if (!(timeLookup instanceof ArrayBuffer) && !ArrayBuffer.isView(timeLookup)) { | ||
if (!(timeLookup.value instanceof ArrayBuffer) && !ArrayBuffer.isView(timeLookup)) { |
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.
Not related to your changes, but would be worthwhile simplifying this check / making it more robust using the bufFromBufLike
util up here instead of relying on instanceof
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.
timelookup.value
is either an ArrayBuffer
or a HashTree
. So if we pass timelookup.value
into bufFromBufLike
when timelookup.value
is a HashTree
, it will pass the Array.isArray
test in bufFromBuflike
and be returned as an ArrayBuffer
. This ArrayBuffer
will then be passed to decodeTime
which may actually succeed in decoding a timestamp from it, depending on the format of the HashTree
. This results in returning an incorrect timestamp when we shouldn't.
It's more robust to exist early if we receive a malformed response in my opinion.
@@ -20,6 +19,24 @@ function pruned(str: string): ArrayBuffer { | |||
return fromHex(str); | |||
} | |||
|
|||
function bufferEqualityTester(a: unknown, b: unknown): boolean | undefined { |
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.
We already have compare
and bufEquals
utils in packages/agent/src/utils/buffer.ts
@@ -20,6 +19,24 @@ function pruned(str: string): ArrayBuffer { | |||
return fromHex(str); | |||
} | |||
|
|||
function bufferEqualityTester(a: unknown, b: unknown): boolean | undefined { |
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.
Again, is duplicative of other buffer utils that we already have
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.
huh... I had understood returning undefined
was important to tell Jest to use a different equality tester, but this works:
(expect as any).addEqualityTesters([bufEquals]);
Thanks!
@@ -122,6 +120,17 @@ function isBufferEqual(a: ArrayBuffer, b: ArrayBuffer): boolean { | |||
return true; | |||
} | |||
|
|||
function isBufferGreaterThan(a: ArrayBuffer, b: ArrayBuffer): boolean { |
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.
Can use compare
instead.
isBufferGreaterThan
is equivalent to compare(a, b) > 0
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.
They're not the same because compare
checks for the length of the buffers, which is important for equality, but when we're navigating the tree, we need to know if the current label is greater or less than the label we're searching for in an alphabetical sense. So b
should be considered "greater" than aa
, but compare
will return -1
in that case.
Altering the implementation of compare
to work for the tree navigation too would break the hashOfMap
and some other hashing utilities.
I can remove the isBufferEqual
function in this file in favor of the common utils though.
@nathanosdev I think that extending the changes to the I'd rather not also introduce the retry logic for |
Sounds good, I'll extend the changes to |
03cda41
to
2ef1692
Compare
@krpeacock I've extended the changes to the There seems to be something up with the |
Oh, you just have to remove the exclamation mark from the pr title, even though it's proper semantics for conventional commits. Leave it in the change log though |
bce01f6
to
2ef1692
Compare
It doesn't seem happy with it still, the error message is |
Description
Adds support for proof of absence in certificate lookups. Previously a lookup with either return a value or
undefined
if the value cannot be found. Now the result of a lookup will differentiate betweenFound
,Unknown
andAbsent
, which allows clients to tell the difference between a value that is provably absent from the tree, or one that might have been pruned from the tree (maliciously or otherwise).Fixes # SDK-1219
How Has This Been Tested?
I've added new unit tests to cover the new lookup functionality.
Checklist: