Skip to content

Conversation

@UdjinM6
Copy link
Contributor

@UdjinM6 UdjinM6 commented Jul 23, 2016

Ports should always be 16 bit numbers so use proper type (uint16_t) and format (%u).
Also changing unsigned short to uint16_t for such cases for consistency.

Reference: https://tools.ietf.org/html/rfc793#section-3.1

Copy link
Member

Choose a reason for hiding this comment

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

This needs a larger type because it can be -1, which is not equal to 65535.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

True! Changed to use 0 instead.

@laanwj
Copy link
Member

laanwj commented Jul 23, 2016

This probably overlaps a lot with @theuni's net code overhaul.

@UdjinM6
Copy link
Contributor Author

UdjinM6 commented Jul 23, 2016

Addressed test issue and changed SplitHostPort to return bool and fail if port is 0 or negative. Also added checks to SplitHostPort calls to further reassure that ports provided in strings are legit.

@theuni
Copy link
Member

theuni commented Jul 27, 2016

yes, this conflicts somewhat, mostly in net/netbase. I can deal with that though.

More concerning though is the lack over overflow handling on input in a few places. For example:

uint16_t port = GetArg("-rpcport", BaseParams().RPCPort());

what will "-rpcport=65537" do?

I see a few of those, though admittedly some of them likely already exist. Also looks like a few are fixed, though :)

@UdjinM6 Would you mind first ensuring that all input ports are sanitized (including those coming over the net) before doing the replacement?

@UdjinM6
Copy link
Contributor Author

UdjinM6 commented Jul 27, 2016

Thanks for the review @theuni !
If that starts to overlap with your work too much, just tell me - I'm completely fine with closing this PR in favor of your more global work especially if this PR brings some pain in conflicts resolving and such. I would be glad if you any parts of this PR would be useful for your work in some way though.

Meanwhile:

  • addressed GetArg inputs
  • added test cases for TestSplitHost for ports above upper bound

I'm not sure which parts of code you were referencing by

(including those coming over the net)

Could you provide some guidance pls?

@theuni
Copy link
Member

theuni commented Aug 5, 2016

@UdjinM6 by "parts coming over the net", i meant serialized addresses coming from net messages (version, addr, etc). Looks like that's already taken care of.

Concept ACK, and quick review ACK, but It'd be nice to get #8128 in first.

@maflcko
Copy link
Member

maflcko commented Aug 18, 2016

Needs rebase after #8128

@UdjinM6
Copy link
Contributor Author

UdjinM6 commented Aug 19, 2016

Rebased and (re)added fixes to new code and to code which was moved in #8128.

std::string host = GetArg("-rpcconnect", DEFAULT_RPCCONNECT);
int port = GetArg("-rpcport", BaseParams().RPCPort());

int portTmp = GetArg("-rpcport", BaseParams().RPCPort());
Copy link
Member

Choose a reason for hiding this comment

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

Nit: GetArg returns int64_t. I think the goal of the pull was not to cast without check?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agree, will fix

@laanwj
Copy link
Member

laanwj commented Aug 19, 2016

To be honest, I'm not entirely convinced that merging this is worth the risk (smaller integers are easier to overflow, for example).
There's a huge number of changes but no user-facing improvement.

- use int64_t to get result from GetArg
- use int64_t for IsPortValid()
- remove manual numbers conversion to uint16_t
@maflcko
Copy link
Member

maflcko commented Aug 19, 2016

@laanwj Agree that there are a lot of changes, but I think in the long run we should make sure that arguments are parsed correctly and sanitized. I think this pull improves parsing of port numbers passed in by users.

@laanwj
Copy link
Member

laanwj commented Aug 19, 2016

Improving parsing is a good thing, if we can factor that out I'd have no problem with it.

@laanwj
Copy link
Member

laanwj commented Oct 18, 2016

Closing this for now.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants