Skip to content
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

Merge DirectoryProof and DirectoryProofs into one #179

Merged
merged 1 commit into from
Jul 20, 2017
Merged

Merge DirectoryProof and DirectoryProofs into one #179

merged 1 commit into from
Jul 20, 2017

Conversation

vqhuy
Copy link
Member

@vqhuy vqhuy commented Jul 7, 2017

A series of pulls towards #173.

@@ -76,14 +76,10 @@ func (cc *ConsistencyChecks) HandleResponse(requestType int, msg *Response,
return err.(ErrorCode)
}
switch requestType {
case RegistrationType, KeyLookupType:
case RegistrationType, KeyLookupType, MonitoringType, KeyLookupInEpochType:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Keep order of types in case statement consistent (e.g. L38 in client/encoding.go is different).

AP: ap,
STR: str,
AP: append([]*m.AuthenticationPath{}, ap),
STR: append([]*DirSTR{}, str),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should update the documentation to specify that the length of AP and STR is expected to be equal to 1. Same goes for NewKeyLookupProof below.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

ap := df.AP
str := df.STR
ap := df.AP[0]
str := df.STR[0]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to validate dfat this point and fail early if len(df.AP) != 1 || len(df.STR) != 1. For now, we should do the same in verifyRegistration although this will probably change when we verify the prior history on a registration.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is validated in

if err := msg.validate(); err != nil {

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

message.validate() only checks that the lengths are > 0. I was asking about an additional registration- and lookups-specific validation that checks the lengths are == 1.

Copy link
Member Author

@vqhuy vqhuy Jul 13, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got it. I think even a malicious server has no reasons to do such an invalid response. I will add a TODO here, since I fixed it in the next pulls.

Copy link
Member

@masomel masomel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -186,6 +175,7 @@ func NewRegistrationProof(ap *m.AuthenticationPath, str *DirSTR,
// NewKeyLookupProof creates the response message a CONIKS directory
// sends to a client upon a KeyLookupRequest,
// and returns a Response containing a DirectoryProof struct.
// The length of `AP` and `STR` must to be equal to 1.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why keep them as arrays then?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only the case for registrations and key lookups. Monitoring and LookupInEpochs return more than one auth path and/or STR. And even registrations are going to return multiple auth paths and STRs when we implement prior history verification.

@vqhuy
Copy link
Member Author

vqhuy commented Jul 17, 2017

Can we merge this now?

@vqhuy
Copy link
Member Author

vqhuy commented Jul 20, 2017

Please open new issue if you have any further comments.

@vqhuy vqhuy deleted the gh173 branch July 20, 2017 04:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants