Refuse redirects when fetching a key, and read a naive now as UTC - #5
Merged
Conversation
Found in review after the fetch was merged. The fetch followed redirects. urllib follows a redirect to any host and to any of http, https or ftp, so a creator whose domain answered 302 to some other place, or to plain http, would have that other place's key trusted as its own, and a network attacker able to bend the creator's DNS, or a creator that was simply misconfigured, could put a key there and have forgeries verify. The Java port refuses a change of protocol, so the Python port was the weaker of the two. The default transport now uses an opener whose redirect handler refuses every redirect, so the 3xx comes back as the response code and the caller reads the key as unavailable, which is what it is. The stand in end point learned to answer with a redirect to another host, and the test proves the key is not fetched from there. The test fails when redirects are followed again. public_key_url now checks the scheme where the URL is built, not only before the request, so a caller who only wants the URL cannot be handed one whose scheme is really a prefix naming some other host. public_key_response_at raised TypeError when given a naive datetime as now, because it compared it with an aware date, while the schedule reads a naive datetime as UTC. The two now agree. The README's fetch example asked a real resolver for creator.invalid and asserted the answer. RFC 6761 only says resolvers should refuse the name, and under a TLS intercepting proxy the answer is a block page, which reads as an unreadable key rather than an unavailable one and fails the README test. The example now passes a transport that refuses, so it shows the same shape and makes no request. Added the two pass check that tells selecting by start from anything else: the genuine identifier verifies under the published schedule and reads as not matching when every start is moved a week later. 163 tests, up from 161.
Automation51D
pushed a commit
to 51Degrees/pipeline-python
that referenced
this pull request
Sep 6, 2026
…-python to the commit that refuses redirects when fetching a key' The 51Degrees fork of owid-python now carries SWAN-community/owid-python#5, which stops the fetch following a redirect from a creator domain, so a creator whose domain answered 302 could no longer have some other host's key trusted as its own. It also reads a naive now as UTC on the creator side and makes the README example run without a network. The pin moves from 5fe9a7cc to 740c59ca, the fork's main after the sync, and the build time copy into the package picks the new source up unchanged. fiftyone_pipeline_did tests: 145 passed, 2 skipped.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found in review after the fetch was merged.
The fetch followed redirects. urllib follows a redirect to any host and
to any of http, https or ftp, so a creator whose domain answered 302 to
some other place, or to plain http, would have that other place's key
trusted as its own, and a network attacker able to bend the creator's
DNS, or a creator that was simply misconfigured, could put a key there
and have forgeries verify. The Java port refuses a change of protocol,
so the Python port was the weaker of the two. The default transport now
uses an opener whose redirect handler refuses every redirect, so the 3xx
comes back as the response code and the caller reads the key as
unavailable, which is what it is. The stand in end point learned to
answer with a redirect to another host, and the test proves the key is
not fetched from there. The test fails when redirects are followed
again.
public_key_url now checks the scheme where the URL is built, not only
before the request, so a caller who only wants the URL cannot be handed
one whose scheme is really a prefix naming some other host.
public_key_response_at raised TypeError when given a naive datetime as
now, because it compared it with an aware date, while the schedule reads
a naive datetime as UTC. The two now agree.
The README's fetch example asked a real resolver for creator.invalid and
asserted the answer. RFC 6761 only says resolvers should refuse the
name, and under a TLS intercepting proxy the answer is a block page,
which reads as an unreadable key rather than an unavailable one and
fails the README test. The example now passes a transport that refuses,
so it shows the same shape and makes no request.
Added the two pass check that tells selecting by start from anything
else: the genuine identifier verifies under the published schedule and
reads as not matching when every start is moved a week later.
163 tests, up from 161.
Produced with AI assistance after an adversarial review of #4, and needs human review before merging. Both fixes were proved by mutation: the redirect test fails when redirects are followed again.