8000 proxy: Return an error for invalid proxy URLs instead of crashing. by lrm29 · Pull Request #6597 · libgit2/libgit2 · GitHub
[go: up one dir, main page]

Skip to content

proxy: Return an error for invalid proxy URLs instead of crashing. #6597

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 pri 8000 vacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Aug 2, 2023

Conversation

lrm29
Copy link
Contributor
@lrm29 lrm29 commented Jul 17, 2023

I see the following behaviour in 1.7.0 but not in 1.5.0.

If the user's Git config specifies the proxy like this then libgit2 now crashes:

[http]
    proxy = myhost:1234

The scheme (and port) are required but many users leave it off (curl defaults to http I read in the man pages).

In this pull request I propose checking the validity of the url after parsing it. Something similar is done in winhttp.c, so I replaced that with a call to git_net_url_valid but not sure if that's the right thing to do.

@lrm29 lrm29 changed the title Return an error for invalid proxy URLs instead of crashing. proxy: Return an error for invalid proxy URLs instead of crashing. Jul 19, 2023
lrm29 and others added 6 commits July 19, 2023 14:33
Refactor url parsing to simplify the state-passing (introducing a
struct) and add a path parser for future reusability.
Introduce a url parser that defaults to treating poorly specified URLs
as http URLs. For example: `localhost:8080` is treated as
`http://localhost:8080/` by the http-biased url parsing, instead of a
URL with a scheme `localhost` and a path of `8080`..
The common format for specifying proxy URLs is just 'host:port'. Handle
the common case.
Test proxies specified by both host:port format in configuration
options, environment variables, and `http.proxy` configuration.
@ethomson
Copy link
Member
ethomson commented Aug 2, 2023

Yikes. Thanks for this - we should definitely not crash.

However, that's the common format that proxies are usually specified in, in my experience. We shouldn't be so rigid as to require it to be a URL -- especially in the environment variable and configuration options.

I added a few commits on top of this to relax parsing rules -- would you mind taking a look? https://github.com/libgit2/libgit2/tree/ethomson/proxy

@lrm29
Copy link
Contributor Author
lrm29 commented Aug 2, 2023

Thanks for going above and beyond here. Networking is a weak point for me so I'm asking the following questions based on code aesthetics and not from a position of knowledge:

  • Did you intentionally not call git_net_url_parse_http in winhttp.c?
  • I don't know if this generally works with SOCKS proxies at all (git/git@6d7afe0)? If so would a test with a scheme that's not empty or "http" be worth adding to your parser tests?

@ethomson
Copy link
Member
ethomson commented Aug 2, 2023

Did you intentionally not call git_net_url_parse_http in winhttp.c?

Doh. It was not intentional, and I pushed an update, but I think that you beat me to it. Added in 38b60fd but I must have seen that after you pulled. 🙁

I don't know if this generally works with SOCKS proxies at all (git/git@6d7afe0)? If so would a test with a scheme that's not empty or "http" be worth adding to your parser tests?

It does not - I haven't seen a SOCKS proxy in the wild in a very long time, nor has anybody asked (yet).

@lrm29
Copy link
Contributor Author
lrm29 commented Aug 2, 2023

I don't know if this generally works with SOCKS proxies at all (git/git@6d7afe0)? If so would a test with a scheme that's not empty or "http" be worth adding to your parser tests?

It does not - I haven't seen a SOCKS proxy in the wild in a very long time, nor has anybody asked (yet).

I saw it in a .gitconfig once this year and heard nothing since... I'm not asking :D

I've merged your work into this pull request. I can always merge this fix into our codebase first to give it some bake time, let me know.

@ethomson
Copy link
Member
ethomson commented Aug 2, 2023

Cool. I'm going to merge this into main and tag this to backport into the v1.7 branch. If you have any feedback from having it in your codebase, that would be 💯

@ethomson ethomson merged commit 804506b into libgit2:main Aug 2, 2023
@ethomson ethomson added the v1.7 label Aug 2, 2023
@ethomson ethomson mentioned this pull request Aug 2, 2023
@ethomson ethomson added the bug label Aug 14, 2023
@lrm29 lrm29 deleted the proxy_invalid_url_crash branch January 7, 2025 12:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0