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

implement fromstr trait to netaddress #2134

Merged
merged 4 commits into from
Sep 7, 2023

Conversation

jbesraa
Copy link
Contributor

@jbesraa jbesraa commented Mar 28, 2023

resolves #2056

@tnull tnull self-requested a review March 28, 2023 11:24
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
@jbesraa
Copy link
Contributor Author

jbesraa commented Mar 29, 2023

@TheBlueMatt @tnull any recommendation on how to decode the onionv3 address? I could potentially use https://crates.io/crates/base32 but im not sure about adding a new package just for that?

@TheBlueMatt
Copy link
Collaborator

Hmm, yea, that's a good question - I took a brief glance at the base32 code, it looks fine, though could use one or two trivial changes (and a fuzzer, it has an obvious panic in the decode!). Luckily its the same license so we'd have to add a notice that it includes code which is "Copyright (c) 2015 The base32 Developers" but that's nbd. We should pull it in by coping their lib.rs, though, not taking the dependency, there's no need for a dep here.

@jbesraa
Copy link
Contributor Author

jbesraa commented Apr 4, 2023

made some changes(main functionality is implemented and tests are passing) to the code and updated the top comment accordingly

lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/Cargo.toml Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/util/base32.rs Outdated Show resolved Hide resolved
lightning/src/util/base32.rs Outdated Show resolved Hide resolved
lightning/src/util/base32.rs Outdated Show resolved Hide resolved
lightning/src/util/base32.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/util/base32.rs Outdated Show resolved Hide resolved
@jbesraa jbesraa force-pushed the add_fromstr_to_netaddress branch 4 times, most recently from 362a9b4 to d807a53 Compare April 8, 2023 17:02
@jbesraa
Copy link
Contributor Author

jbesraa commented Apr 24, 2023

i can see the fuzzer failing locally as well, but not sure what to make from the error message
Screenshot from 2023-04-24 16-10-24

lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
@jbesraa jbesraa force-pushed the add_fromstr_to_netaddress branch from b6f5ae6 to 471c5d7 Compare May 1, 2023 09:55
use crate::prelude::*;

/// Alphabet used for encoding and decoding.
#[derive(Copy, Clone)]
Copy link
Collaborator

Choose a reason for hiding this comment

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

(a) we can drop the crockford encoding, we don't use it. (b) we should move the zbase32 stuff we already have to here - its the same code anyway, but just a different alphabet.

lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
@jbesraa jbesraa force-pushed the add_fromstr_to_netaddress branch 2 times, most recently from a092195 to cf72e89 Compare May 11, 2023 08:16
@TheBlueMatt
Copy link
Collaborator

TheBlueMatt commented May 11, 2023

Let me know when you're ready for another look here, looks like you're in the midst of merging the two base32s.

@jbesraa jbesraa force-pushed the add_fromstr_to_netaddress branch from cf72e89 to ea1b296 Compare May 12, 2023 12:09
@codecov-commenter
Copy link

codecov-commenter commented May 12, 2023

Codecov Report

Patch coverage: 93.17% and project coverage change: +0.01% 🎉

Comparison is base (e9d9711) 90.58% compared to head (529a09f) 90.60%.

❗ Current head 529a09f differs from pull request most recent head 9a8b7e3. Consider uploading reports for the commit 9a8b7e3 to get more accurate results

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the GitHub App Integration for your organization. Read more.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2134      +/-   ##
==========================================
+ Coverage   90.58%   90.60%   +0.01%     
==========================================
  Files         110      110              
  Lines       57526    57555      +29     
  Branches    57526    57555      +29     
==========================================
+ Hits        52112    52149      +37     
+ Misses       5414     5406       -8     
Files Changed Coverage Δ
lightning/src/ln/msgs.rs 86.20% <89.77%> (+0.38%) ⬆️
lightning/src/util/message_signing.rs 92.30% <90.47%> (ø)
lightning/src/util/base32.rs 96.63% <96.63%> (ø)

... and 19 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@jbesraa
Copy link
Contributor Author

jbesraa commented May 15, 2023

@TheBlueMatt can u please give this another round of review? also, any tips on how to debug the fuzzer locally would be much appreciated

lightning/src/util/base32.rs Outdated Show resolved Hide resolved
lightning/src/util/base32.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
@TheBlueMatt
Copy link
Collaborator

Re: fuzzer reproduction, the fuzz/README.md file has a section on ## A fuzz test failed on Travis, what do I do?

@jbesraa
Copy link
Contributor Author

jbesraa commented Jun 28, 2023

apologies for the slow execution, life got in the middle (:
did some improvements to from_str, will handle the base32 code and the fuzzer in the next days hopefully!

...and ill cleanup commits

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

Okay, really just one nit left!

lightning/src/util/base32.rs Outdated Show resolved Hide resolved
lightning/src/util/base32.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Show resolved Hide resolved
TheBlueMatt
TheBlueMatt previously approved these changes Aug 27, 2023
Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

A few minor nits, but nothing blocking.

];

const RFC4648_TEST_VECTORS: &[(&[u8], &[u8])] = &[
(b"", b""),
Copy link
Collaborator

Choose a reason for hiding this comment

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

data type for the second element in the tuple should be a str, which you're currently doing in the tests with std::str::from_utf8...unwrap.


for (_, encoded) in RFC4648_TEST_VECTORS {
let decoded = &Alphabet::RFC4648 { padding: true }.decode(std::str::from_utf8(encoded).unwrap()).unwrap();
assert_eq!(&Alphabet::RFC4648 { padding: true }.encode(decoded).as_bytes(), encoded);
Copy link
Collaborator

Choose a reason for hiding this comment

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

This test is redundant - we already test that if we decode we get the expected value and if we encode we get the expected value, there's no need for an additional round-trip test.

@@ -3296,10 +3403,10 @@ mod tests {
let shutdown = msgs::Shutdown {
channel_id: [2; 32],
scriptpubkey:
if script_type == 1 { Address::p2pkh(&::bitcoin::PublicKey{compressed: true, inner: pubkey_1}, Network::Testnet).script_pubkey() }
if script_type == 1 { Address::p2pkh(&::bitcoin::PublicKey{compressed: true, inner: pubkey_1}, Network::Testnet).script_pubkey() }
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why did you remove the alignment here and below?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmm this was a space, now it looks like this:
Screenshot from 2023-08-27 21-37-37

Copy link
Collaborator

Choose a reason for hiding this comment

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

Indeed, it was a space to align the opening { nicely no matter the users' configured tabstop.

fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
match self {
NetAddressParseError::SocketAddrParse => write!(f, "Socket address (IPv4/IPv6) parsing error"),
NetAddressParseError::InvalidInput => write!(f, "{}", "Invalid input format. \
Copy link
Collaborator

Choose a reason for hiding this comment

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

You can drop the , "{}" part.

@TheBlueMatt
Copy link
Collaborator

Oh, if you push again, please fix the commit title on the last commit - commit description text must include a blank line between the title and the first non-title line (otherwise git treats it as a really long title, which breaks lots of things).

@TheBlueMatt
Copy link
Collaborator

Also, the description in the first commit doesn't tell me anything " restructure encode function restructure decode function" doesn't tell me what the commit is doing or why its doing that, though the title itself is pretty clear. Commit descriptions shouldn't include the history of that commit, by the time we merge it we don't care too much about the history of the PR's review.

Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

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

Mostly looks good from my side, but have yet to go over the base32 logic stuff one last time.

lightning/src/util/base32.rs Show resolved Hide resolved
lightning/src/util/message_signing.rs Show resolved Hide resolved
lightning/src/ln/msgs.rs Show resolved Hide resolved
@tnull
Copy link
Contributor

tnull commented Aug 29, 2023

Also needs a minor rebase now it seems.

@TheBlueMatt
Copy link
Collaborator

Any update here, would really love to land this for 0.0.117 but its gonna get over the line in the next week or two.

@jbesraa jbesraa force-pushed the add_fromstr_to_netaddress branch 4 times, most recently from c9750ce to 03e4ac8 Compare September 4, 2023 15:29
@jbesraa
Copy link
Contributor Author

jbesraa commented Sep 4, 2023

@tnull split the indentation to a separate commit and added short docs for the numbers

Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

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

Generally looks good, mod some nits/minor comments.

@@ -58,3 +58,4 @@ pub mod test_utils;
#[cfg(any(test, feature = "_test_utils"))]
pub mod test_channel_signer;

pub mod enforcing_trait_impls;
Copy link
Contributor

Choose a reason for hiding this comment

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

This file was removed on main and we shouldn't re-add the module here.

@@ -143,4 +143,4 @@ mod test {
assert!(verify(c[1].as_bytes(), c[2], &PublicKey::from_str(c[3]).unwrap()))
}
}
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Don't remove the trailing newline.

impl Alphabet {
/// Encode bytes into a base32 string.
pub fn encode(&self, data: &[u8]) -> String {
// This line calculates the length of the output string, which is equal to the original data length * 8 / 5, rounded up. The + 4 at the end is to account for the extra padding characters that may be added.
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: might want to wrap the comment lines also.

if *padding {
let len = ret.len();
let num_extra = len - output_length;
for i in 1..num_extra + 1 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't this just the same as the following, which is a lot less confusing?:

for i in output_length..len {
    ret[i] = b'=';
}

// If the string has more characters than are required to alphabet_encode the number of bytes
// decodable, treat the string as invalid.
match data.len() % 8 { 1|3|6 => return Err(()), _ => {} }
let mut ret = Self::decode_data(data, alphabet)?;
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Doesn't need to be mut.

let cap = (data.len() + 4) / 5 * 8;
let mut ret = Vec::with_capacity(cap);
for chunk in data.chunks(5) {
let buf = {
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think we need this additional let binding? Why not just use the mut buf below?

let cap = (data.len() + 7) / 8 * 5;
let mut ret = Vec::with_capacity(cap);
for chunk in data.chunks(8) {
let buf = {
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here, why do we need this additional let binding?

@jbesraa
Copy link
Contributor Author

jbesraa commented Sep 5, 2023

Fixed Up:

  • Wrapped comments into multiple lines
  • Removed unnecessary mut and let bindings
  • Improved readability of if
  • Reverted EOL removal

pub fn encode(&self, data: &[u8]) -> String {
// This line calculates the length of the output string,
// which is equal to the original data length * 8 / 5, rounded up.
// The + 4 at the end is to account for the extra padding characters that may be added.
Copy link
Collaborator

Choose a reason for hiding this comment

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

No, the +4 is the "rounded up" part - rounding up with integer division is generally done by doing (numerator + divisor - 1) / divisor

Copy link
Contributor Author

Choose a reason for hiding this comment

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

wdyt about this?

    1         pub fn encode(&self, data: &[u8]) -> String {
| 45                  // output_length is calculated as follows:
|   1                 // / 5 divides the data length by the number of bits per chunk (5),
|   2                 // * 8 multiplies the result by the number of characters per chunk (8).
|   3                 // + 4 rounds up to the nearest character.
    4                 let output_length = (data.len() * 8 + 4) / 5;
    ```

Copy link
Collaborator

Choose a reason for hiding this comment

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

Sure.


/// Encode a byte slice into a base32 string.
fn encode_data(data: &[u8], alphabet: &'static [u8]) -> Vec<u8> {
// The + 4 at the end is to account for the padding characters that may be needed,
Copy link
Collaborator

Choose a reason for hiding this comment

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

No, the +5 is to round up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

wdyt about this?

  102         fn encode_data(data: &[u8], alphabet: &'static [u8]) -> Vec<u8> {
|   1                 // cap is calculated as follows:
|   2                 // / 5 divides the data length by the number of bits per chunk (5),
|   3                 // * 8 multiplies the result by the number of characters per chunk (8).
|   4                 // + 4 rounds up to the nearest character.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Sure



fn decode_data(data: &[u8], alphabet: [i8; 43]) -> Result<Vec<u8>, ()> {
// The + 7 at the end is to account for the padding characters that may be needed,
Copy link
Collaborator

Choose a reason for hiding this comment

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

No, the +7 is to round up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

wdyt about this?

  129         fn decode_data(data: &[u8], alphabet: [i8; 43]) -> Result<Vec<u8>, ()> {
|   1                 // cap is calculated as follows:
|   2                 // / 8 divides the data length by the number of characters per chunk (8),
|   3                 // * 5 multiplies the result by the number of bits per chunk (5),
|   4                 // + 7 rounds up to the nearest byte.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Sure


fn decode_data(data: &[u8], alphabet: [i8; 43]) -> Result<Vec<u8>, ()> {
// The + 7 at the end is to account for the padding characters that may be needed,
// The / 8 divides the Base64 string length by the number of characters per chunk (8),
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: here, and a few places, you have excess whitespace at the end of your line. A local git show should highlight these depending on your terminal settings.

Comment on lines 947 to 949
match {
addr
} {
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
match {
addr
} {
match addr {

@tnull tnull merged commit b5e9594 into lightningdevkit:main Sep 7, 2023
12 of 14 checks passed
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.

Implement FromStr for NetAddress
4 participants