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

feat: implements input validation functions for HashNode and HashLeaf to prevent panics #113

Merged
merged 41 commits into from
Feb 28, 2023

Conversation

staheri14
Copy link
Contributor

@staheri14 staheri14 commented Feb 24, 2023

Overview

An incremental PR toward #109
Next: The validation utility functions developed in this PR must be further integrated into both the tree construction and proof verification process to detect invalid inputs and notify the caller of any errors. This will close #109 and is in line with the objectives outlined in issues #99 and #97. I will address this in a subsequent pull request.

Checklist

  • New and updated code has appropriate documentation
  • New and updated code has new and/or updated testing
  • Required CI checks are passing
  • Visual proof for any user facing features like CLI or documentation updates
  • Linked issues closed with keywords

@codecov
Copy link

codecov bot commented Feb 24, 2023

Codecov Report

Merging #113 (aa5a48b) into master (1d69de9) will increase coverage by 0.04%.
The diff coverage is 97.56%.

❗ Current head aa5a48b differs from pull request most recent head 177d317. Consider uploading reports for the commit 177d317 to get more accurate results

@@            Coverage Diff             @@
##           master     #113      +/-   ##
==========================================
+ Coverage   96.27%   96.31%   +0.04%     
==========================================
  Files           6        6              
  Lines         429      461      +32     
==========================================
+ Hits          413      444      +31     
- Misses         10       11       +1     
  Partials        6        6              
Impacted Files Coverage Δ
hasher.go 96.29% <97.56%> (+0.24%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@staheri14 staheri14 self-assigned this Feb 24, 2023
@staheri14 staheri14 added the enhancement New feature or request label Feb 24, 2023
@staheri14 staheri14 marked this pull request as ready for review February 24, 2023 19:55
@staheri14 staheri14 changed the title (WIP) feat: implements panic condition prediction functions for HashNode and HashLeaf to prevent panics (WIP) feat: implements input validation functions for HashNode and HashLeaf to prevent panics Feb 24, 2023
@staheri14 staheri14 changed the title (WIP) feat: implements input validation functions for HashNode and HashLeaf to prevent panics feat: implements input validation functions for HashNode and HashLeaf to prevent panics Feb 24, 2023
Copy link
Collaborator

@rootulp rootulp left a comment

Choose a reason for hiding this comment

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

👍

hasher.go Outdated Show resolved Hide resolved
hasher.go Outdated
// namespaced hash values.
func (n *Hasher) validateSiblingsNamespaceOrder(left, right []byte) (err error) {
// each NMT node has two namespace IDs for the min and max
totalNameSpaceLen := 2 * n.NamespaceLen
Copy link
Collaborator

Choose a reason for hiding this comment

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

[uber nit] in some scenarios the "S" in namespace is capitalized and in other scenarios it isn't. For codebase consistency, would it help to consolidate on no capitalization per https://en.wikipedia.org/wiki/Namespace

Suggested change
totalNameSpaceLen := 2 * n.NamespaceLen
totalNamespaceLen := 2 * n.NamespaceLen

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Resolved b1f17fb.

hasher_test.go Outdated
Comment on lines 293 to 294
{ // mismatched namespace size
"invalid node: mismatching namespace sizes",
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
{ // mismatched namespace size
"invalid node: mismatching namespace sizes",
{
"invalid node: length",

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed faf4e50

hasher.go Outdated
@@ -14,6 +16,11 @@ const (

var _ hash.Hash = (*Hasher)(nil)

var (
ErrUnorderedSiblings = errors.New("NMT sibling nodes should be ordered lexicographically by namespace IDs")
ErrInvalidNodeLen = errors.New("Invalid NMT node size")
Copy link
Collaborator

Choose a reason for hiding this comment

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

[nit][optional]

https://github.com/golang/go/wiki/CodeReviewComments#error-strings

Suggested change
ErrInvalidNodeLen = errors.New("Invalid NMT node size")
ErrInvalidNodeLen = errors.New("invalid NMT node size")

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed faf4e50

Copy link
Member

@evan-forbes evan-forbes left a comment

Choose a reason for hiding this comment

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

It is important to note that returning an error from this method is not possible as it would violate the interface it is intended to fulfill i.e., NodeHasher and Hash.

The validation utility functions developed in this PR must be further integrated into both the tree construction and proof verification process to detect invalid inputs and notify the caller of any errors.

I'm wondering about the first statement. We might need to break the api, and that's ok imo. In fact, I assumed that we would have to to close #109. It would require significantly changes downstream, but I'm not sure that's avoidable even if we don't break the API.

I guess I just have questions over how we actually plan to call these ahead of time in order to avoid panics, but we can discuss that synchronously if that would be faster 🙂. Ideally, we would incorporate this into the code so that this was the default, since the panics here are purely to handle errors. We're still going to have to handle those errors downstream in order to write safe code, so might as well handle it here imo

otherwise LGTM, I like this change

@staheri14
Copy link
Contributor Author

I guess I just have questions over how we actually plan to call these ahead of time in order to avoid panics, but we can discuss that synchronously if that would be faster

I agree that some of the APIs will inevitably have to change. However, my aim was to keep the HashNode and HashLeaf signatures intact, instead, delegate error handling to the caller methods i.e., Push, and proof verification. That is, they will check the nodes validity before calling HashNode and HashLeaf, and if there was an invalid node, they will return an error.
I can elaborate on this during our 1:1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

feat: Handling Panics in HashNode Method
3 participants