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

bpo-38686: fix HTTP Digest handling in request.py #17045

Merged
merged 4 commits into from Nov 22, 2019
Merged

Conversation

@PypeBros
Copy link
Contributor

PypeBros commented Nov 4, 2019

There is a bug triggered when server replies to a request with WWW-Authenticate: Digest where qop="auth,auth-int" rather than mere qop="auth". Having both auth and auth-int is legitimate according to the qop-options rule in §3.2.1 of https://www.ietf.org/rfc/rfc2617.txt:

 qop-options       = "qop" "=" <"> 1#qop-value <">
 qop-value         = "auth" | "auth-int" | token

qop-options: [...] If present, it is a quoted string of one or more tokens indicating the "quality of protection" values supported by the server. The value "auth" indicates authentication; the value "auth-int" indicates authentication with integrity protection

This is description confirmed by the definition of the [n]#[m]rule extended-BNF pattern defined in §2.1 of https://www.ietf.org/rfc/rfc2616.txt as 'a comma-separated list of rule with at least n and at most m items'.

When this reply is parsed by get_authorization, request.py only tests for identity with 'auth', failing to recognize it as one of the supported modes the server announced, and claims that "qop 'auth,auth-int' is not supported".

https://bugs.python.org/issue38686

There is a bug triggered when server replies to a request with `WWW-Authenticate: Digest` where `qop="auth,auth-int"` rather than mere `qop="auth"`. Having both `auth` and `auth-int` is legitimate according to the `qop-options` rule in §3.2.1 of [[https://www.ietf.org/rfc/rfc2617.txt|RFC 2617]]:
>      qop-options       = "qop" "=" <"> 1#qop-value <">
>      qop-value         = "auth" | "auth-int" | token
> **qop-options**: [...] If present, it is a quoted string **of one or more** tokens indicating the "quality of protection" values supported by the server.  The value `"auth"` indicates authentication; the value `"auth-int"` indicates authentication with integrity protection

This is description confirmed by the definition of the [//n//]`#`[//m//]//rule// extended-BNF pattern defined in §2.1 of [[https://www.ietf.org/rfc/rfc2616.txt|RFC 2616]] as 'a comma-separated list of //rule// with at least //n// and at most //m// items'.

When this reply is parsed by `get_authorization`, request.py only tests for identity with `'auth'`, failing to recognize it as one of the supported modes the server announced, and claims that `"qop 'auth,auth-int' is not supported"`.
@the-knights-who-say-ni

This comment has been minimized.

Copy link

the-knights-who-say-ni commented Nov 4, 2019

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

CLA Missing

Our records indicate the following people have not signed the CLA:

@PypeBros

For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

If you have recently signed the CLA, please wait at least one business day
before our records are updated.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

@brandtbucher

This comment has been minimized.

Copy link
Member

brandtbucher commented Nov 4, 2019

Thanks for your time @PypeBros, and welcome to CPython! 😎

I assume that you've seen the bot's message about the CLA? Also, if the issue will properly link if you add "bpo-" to the start of this PR's title!

Copy link
Member

brandtbucher left a comment

I'm not a urllib expert, but the code itself looks good.

This PR should also have a NEWS entry. Just something simple, like:

Added support for multiple ``qop`` values in :class:`urllib.request.AbstractDigestAuthHandler`.

I think this also needs a test or two, in Lib/test/test_urllib2.py.

@PypeBros PypeBros changed the title 38686: fix HTTP Digest handling in request.py bpo-38686: fix HTTP Digest handling in request.py Nov 5, 2019
@PypeBros

This comment has been minimized.

Copy link
Contributor Author

PypeBros commented Nov 6, 2019

@brandtbucher : thanks for the welcome and for the help.
I had a look at test_urllib2, but I'm unsure I could write appropriate test cases myself as I don't even see code testing how the DigestAuthHandler would process a valid 'Digest' reply, only code that check it wouldn't prevent BasicAuthHandler from grabbing basic authentication requests.

Copy link
Member

brandtbucher left a comment

Ah, I see there's not many tests for this class at all. I'll leave that for the core reviewer to decide!

@brandtbucher

This comment has been minimized.

Copy link
Member

brandtbucher commented Nov 6, 2019

CC @orsenthil

@PypeBros

This comment has been minimized.

Copy link
Contributor Author

PypeBros commented Nov 13, 2019

Any follow up ? Afaik, in its current state, it makes python clients unable to inter-operate securely with gSOAP clients.

Copy link
Member

orsenthil left a comment

Hi @PypeBros - Thank you for your contribution.

Please see my review comments on this ticket and let me know what your thoughts are.

Lib/urllib/request.py Show resolved Hide resolved
@PypeBros

This comment has been minimized.

Copy link
Contributor Author

PypeBros commented Nov 18, 2019

@orsenthil, does the replies above address your concern with the proposed change ?

@PypeBros

This comment has been minimized.

Copy link
Contributor Author

PypeBros commented Nov 22, 2019

here you are. I haven't repeated the "XXX: implement auth-int", as this is already on line 1154

Copy link
Member

orsenthil left a comment

Thank you!

@PypeBros

This comment has been minimized.

Copy link
Contributor Author

PypeBros commented Nov 22, 2019

anybody understands why https://travis-ci.org/python/cpython/jobs/615649384?utm_medium=notification&utm_source=github_status failed with "Please fix the 1 file(s) with whitespace issues" ?

Lib/urllib/request.py Outdated Show resolved Hide resolved
Co-Authored-By: Brandt Bucher <brandtbucher@gmail.com>
@orsenthil orsenthil merged commit 14a89c4 into python:master Nov 22, 2019
4 checks passed
4 checks passed
Azure Pipelines PR #20191122.51 succeeded
Details
bedevere/issue-number Issue number 38686 found
Details
bedevere/news News entry found in Misc/NEWS.d
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@bedevere-bot

This comment has been minimized.

Copy link

bedevere-bot commented Nov 22, 2019

@orsenthil: Please replace # with GH- in the commit message next time. Thanks!

@miss-islington

This comment has been minimized.

Copy link

miss-islington commented Nov 22, 2019

Thanks @PypeBros for the PR, and @orsenthil for merging it 🌮🎉.. I'm working now to backport this PR to: 3.7, 3.8.
🐍🍒🤖

miss-islington added a commit to miss-islington/cpython that referenced this pull request Nov 22, 2019
* fix HTTP Digest handling in request.py

There is a bug triggered when server replies to a request with `WWW-Authenticate: Digest` where `qop="auth,auth-int"` rather than mere `qop="auth"`. Having both `auth` and `auth-int` is legitimate according to the `qop-options` rule in §3.2.1 of [[https://www.ietf.org/rfc/rfc2617.txt|RFC 2617]]:
>      qop-options       = "qop" "=" <"> 1GH-qop-value <">
>      qop-value         = "auth" | "auth-int" | token
> **qop-options**: [...] If present, it is a quoted string **of one or more** tokens indicating the "quality of protection" values supported by the server.  The value `"auth"` indicates authentication; the value `"auth-int"` indicates authentication with integrity protection

This is description confirmed by the definition of the [//n//]`GH-`[//m//]//rule// extended-BNF pattern defined in §2.1 of [[https://www.ietf.org/rfc/rfc2616.txt|RFC 2616]] as 'a comma-separated list of //rule// with at least //n// and at most //m// items'.

When this reply is parsed by `get_authorization`, request.py only tests for identity with `'auth'`, failing to recognize it as one of the supported modes the server announced, and claims that `"qop 'auth,auth-int' is not supported"`.

* 📜🤖 Added by blurb_it.

* bpo-38686 review fix: remember why.

* fix trailing space in Lib/urllib/request.py

Co-Authored-By: Brandt Bucher <brandtbucher@gmail.com>
(cherry picked from commit 14a89c4)

Co-authored-by: PypeBros <PypeBros@users.noreply.github.com>
@bedevere-bot

This comment has been minimized.

Copy link

bedevere-bot commented Nov 22, 2019

GH-17357 is a backport of this pull request to the 3.8 branch.

@bedevere-bot

This comment has been minimized.

Copy link

bedevere-bot commented Nov 22, 2019

GH-17358 is a backport of this pull request to the 3.7 branch.

miss-islington added a commit to miss-islington/cpython that referenced this pull request Nov 22, 2019
* fix HTTP Digest handling in request.py

There is a bug triggered when server replies to a request with `WWW-Authenticate: Digest` where `qop="auth,auth-int"` rather than mere `qop="auth"`. Having both `auth` and `auth-int` is legitimate according to the `qop-options` rule in §3.2.1 of [[https://www.ietf.org/rfc/rfc2617.txt|RFC 2617]]:
>      qop-options       = "qop" "=" <"> 1GH-qop-value <">
>      qop-value         = "auth" | "auth-int" | token
> **qop-options**: [...] If present, it is a quoted string **of one or more** tokens indicating the "quality of protection" values supported by the server.  The value `"auth"` indicates authentication; the value `"auth-int"` indicates authentication with integrity protection

This is description confirmed by the definition of the [//n//]`GH-`[//m//]//rule// extended-BNF pattern defined in §2.1 of [[https://www.ietf.org/rfc/rfc2616.txt|RFC 2616]] as 'a comma-separated list of //rule// with at least //n// and at most //m// items'.

When this reply is parsed by `get_authorization`, request.py only tests for identity with `'auth'`, failing to recognize it as one of the supported modes the server announced, and claims that `"qop 'auth,auth-int' is not supported"`.

* 📜🤖 Added by blurb_it.

* bpo-38686 review fix: remember why.

* fix trailing space in Lib/urllib/request.py

Co-Authored-By: Brandt Bucher <brandtbucher@gmail.com>
(cherry picked from commit 14a89c4)

Co-authored-by: PypeBros <PypeBros@users.noreply.github.com>
miss-islington added a commit that referenced this pull request Nov 22, 2019
* fix HTTP Digest handling in request.py

There is a bug triggered when server replies to a request with `WWW-Authenticate: Digest` where `qop="auth,auth-int"` rather than mere `qop="auth"`. Having both `auth` and `auth-int` is legitimate according to the `qop-options` rule in §3.2.1 of [[https://www.ietf.org/rfc/rfc2617.txt|RFC 2617]]:
>      qop-options       = "qop" "=" <"> 1GH-qop-value <">
>      qop-value         = "auth" | "auth-int" | token
> **qop-options**: [...] If present, it is a quoted string **of one or more** tokens indicating the "quality of protection" values supported by the server.  The value `"auth"` indicates authentication; the value `"auth-int"` indicates authentication with integrity protection

This is description confirmed by the definition of the [//n//]`GH-`[//m//]//rule// extended-BNF pattern defined in §2.1 of [[https://www.ietf.org/rfc/rfc2616.txt|RFC 2616]] as 'a comma-separated list of //rule// with at least //n// and at most //m// items'.

When this reply is parsed by `get_authorization`, request.py only tests for identity with `'auth'`, failing to recognize it as one of the supported modes the server announced, and claims that `"qop 'auth,auth-int' is not supported"`.

* 📜🤖 Added by blurb_it.

* bpo-38686 review fix: remember why.

* fix trailing space in Lib/urllib/request.py

Co-Authored-By: Brandt Bucher <brandtbucher@gmail.com>
(cherry picked from commit 14a89c4)

Co-authored-by: PypeBros <PypeBros@users.noreply.github.com>
miss-islington added a commit that referenced this pull request Nov 22, 2019
* fix HTTP Digest handling in request.py

There is a bug triggered when server replies to a request with `WWW-Authenticate: Digest` where `qop="auth,auth-int"` rather than mere `qop="auth"`. Having both `auth` and `auth-int` is legitimate according to the `qop-options` rule in §3.2.1 of [[https://www.ietf.org/rfc/rfc2617.txt|RFC 2617]]:
>      qop-options       = "qop" "=" <"> 1GH-qop-value <">
>      qop-value         = "auth" | "auth-int" | token
> **qop-options**: [...] If present, it is a quoted string **of one or more** tokens indicating the "quality of protection" values supported by the server.  The value `"auth"` indicates authentication; the value `"auth-int"` indicates authentication with integrity protection

This is description confirmed by the definition of the [//n//]`GH-`[//m//]//rule// extended-BNF pattern defined in §2.1 of [[https://www.ietf.org/rfc/rfc2616.txt|RFC 2616]] as 'a comma-separated list of //rule// with at least //n// and at most //m// items'.

When this reply is parsed by `get_authorization`, request.py only tests for identity with `'auth'`, failing to recognize it as one of the supported modes the server announced, and claims that `"qop 'auth,auth-int' is not supported"`.

* 📜🤖 Added by blurb_it.

* bpo-38686 review fix: remember why.

* fix trailing space in Lib/urllib/request.py

Co-Authored-By: Brandt Bucher <brandtbucher@gmail.com>
(cherry picked from commit 14a89c4)

Co-authored-by: PypeBros <PypeBros@users.noreply.github.com>
jacobneiltaylor added a commit to jacobneiltaylor/cpython that referenced this pull request Dec 5, 2019
* fix HTTP Digest handling in request.py

There is a bug triggered when server replies to a request with `WWW-Authenticate: Digest` where `qop="auth,auth-int"` rather than mere `qop="auth"`. Having both `auth` and `auth-int` is legitimate according to the `qop-options` rule in §3.2.1 of [[https://www.ietf.org/rfc/rfc2617.txt|RFC 2617]]:
>      qop-options       = "qop" "=" <"> 1#qop-value <">
>      qop-value         = "auth" | "auth-int" | token
> **qop-options**: [...] If present, it is a quoted string **of one or more** tokens indicating the "quality of protection" values supported by the server.  The value `"auth"` indicates authentication; the value `"auth-int"` indicates authentication with integrity protection

This is description confirmed by the definition of the [//n//]`#`[//m//]//rule// extended-BNF pattern defined in §2.1 of [[https://www.ietf.org/rfc/rfc2616.txt|RFC 2616]] as 'a comma-separated list of //rule// with at least //n// and at most //m// items'.

When this reply is parsed by `get_authorization`, request.py only tests for identity with `'auth'`, failing to recognize it as one of the supported modes the server announced, and claims that `"qop 'auth,auth-int' is not supported"`.

* 📜🤖 Added by blurb_it.

* bpo-38686 review fix: remember why.

* fix trailing space in Lib/urllib/request.py

Co-Authored-By: Brandt Bucher <brandtbucher@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.