Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
ethomson merged 8 commits intolibgit2:mainfrommathworks:proxy_invalid_url_crash
Aug 2, 2023

Conversation

lrm29
Copy link
Contributor

@lrm29lrm29 commentedJul 17, 2023
edited
Loading

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.

@lrm29lrm29 changed the titleReturn an error for invalid proxy URLs instead of crashing.proxy: Return an error for invalid proxy URLs instead of crashing.Jul 19, 2023
lrm29and others added6 commitsJuly 19, 2023 14:33
Refactor url parsing to simplify the state-passing (introducing astruct) and add a path parser for future reusability.
Introduce a url parser that defaults to treating poorly specified URLsas http URLs. For example: `localhost:8080` is treated as`http://localhost:8080/` by the http-biased url parsing, instead of aURL with a scheme `localhost` and a path of `8080`..
The common format for specifying proxy URLs is just 'host:port'. Handlethe common case.
Test proxies specified by both host:port format in configurationoptions, environment variables, and `http.proxy` configuration.
@ethomson
Copy link
Member

Yikes. Thanks for this - we should definitelynot 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
ContributorAuthor

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

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 in38b60fd 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 avery long time, nor has anybody asked (yet).

@lrm29
Copy link
ContributorAuthor

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 avery 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

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 💯

@ethomsonethomson merged commit804506b intolibgit2:mainAug 2, 2023
@ethomsonethomson added the v1.7 labelAug 2, 2023
@ethomsonethomson mentioned this pull requestAug 2, 2023
@ethomsonethomson added the bug labelAug 14, 2023
@lrm29lrm29 deleted the proxy_invalid_url_crash branchJanuary 7, 2025 12:02
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@lrm29@ethomson

[8]ページ先頭

©2009-2025 Movatter.jp