-
Notifications
You must be signed in to change notification settings - Fork 278
ngclient: consistently encode URLs #1634
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
Labels
1.0.0 blockers
To be addressed before 1.0.0 release
backlog
Issues to address with priority for current development goals
ngclient
Milestone
Comments
I want to work on this issue. |
kairoaraujo
pushed a commit
to kairoaraujo/python-tuf
that referenced
this issue
Jan 6, 2022
This commit explicitly encodes role names. Also, a slight change in the RepositorySimulator will align with the tests. This commit partially covers issue theupdateframework#1634 Signed-off-by: Kairo de Araujo <[email protected]>
kairoaraujo
pushed a commit
to kairoaraujo/python-tuf
that referenced
this issue
Jan 13, 2022
This commit explicitly encodes role names. Mostly this encoding is already happening in ``requests`` for what is not a URL. The "/" in a role name will now be encoded. Also, a slight change in the RepositorySimulator will align with the tests. This commit partially covers issue theupdateframework#1634 Signed-off-by: Kairo de Araujo <[email protected]>
kairoaraujo
pushed a commit
to kairoaraujo/python-tuf
that referenced
this issue
Jan 13, 2022
This commit explicitly encodes role names. Mostly this encoding is already happening in ``requests`` for what is not a URL. The "/" in a role name will now be encoded. Also, a slight change in the RepositorySimulator will align with the tests. This commit partially covers issue theupdateframework#1634 Signed-off-by: Kairo de Araujo <[email protected]>
kairoaraujo
pushed a commit
to kairoaraujo/python-tuf
that referenced
this issue
Jan 17, 2022
This commit explicitly encodes role names. Mostly this encoding is already happening in ``requests`` for what is not a URL. The "/" in a role name will now be encoded. Also, a slight change in the RepositorySimulator will align with the tests. This commit partially covers issue theupdateframework#1634 Signed-off-by: Kairo de Araujo <[email protected]>
kairoaraujo
pushed a commit
to kairoaraujo/python-tuf
that referenced
this issue
Jan 17, 2022
This commit explicitly encodes role names. Mostly this encoding is already happening in ``requests`` for what is not a URL. The "/" in a role name will now be encoded. Also, a slight change in the RepositorySimulator will align with the tests. This commit partially covers issue theupdateframework#1634 Signed-off-by: Kairo de Araujo <[email protected]>
MVrachev
pushed a commit
to MVrachev/tuf
that referenced
this issue
Jan 17, 2022
This commit explicitly encodes role names. Mostly this encoding is already happening in ``requests`` for what is not a URL. The "/" in a role name will now be encoded. Also, a slight change in the RepositorySimulator will align with the tests. This commit partially covers issue theupdateframework#1634 Signed-off-by: Kairo de Araujo <[email protected]>
MVrachev
pushed a commit
to MVrachev/tuf
that referenced
this issue
Jan 18, 2022
This commit explicitly encodes role names. Mostly this encoding is already happening in ``requests`` for what is not a URL. The "/" in a role name will now be encoded. Also, a slight change in the RepositorySimulator will align with the tests. This commit partially covers issue theupdateframework#1634 Signed-off-by: Kairo de Araujo <[email protected]>
Should we close this one? 🤔 or at least remove the |
I think it's done:
Closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
1.0.0 blockers
To be addressed before 1.0.0 release
backlog
Issues to address with priority for current development goals
ngclient
Uh oh!
There was an error while loading. Please reload this page.
Currently we do not explicitly URL-encode rolenames (or target paths) when we use them in URLs. Let's review this code and make a conscious decisions about this.
My original thinking on this was that it's a specification issue: we can't just start encoding e.g. rolenames if the spec does not say we should... but thinking on it further I've started to believe that
The latter point is true because requests (the http library) already encodes everything that would be illegal in a URL behind our backs: so emojis, non-ascii characters, most symbols are already being encoded, just not explicitly by us. Only some specific symbols that may be valid in URLs are maybe not encoded (examples: /, #, ?, &).
My current thinking is:
I am not as sure about target paths: they are URL-paths and we could just require them to be URL-encoded already (and maybe even validate that they are encoded?). At the very least we can't encode "/" in target paths because it's valid in a path: this leads me to think we should just require the target path to be correctly encoded already? An additional wrinkle for target paths is that the spec requires us to actually modify the path in quite tricky ways for consistent targets...
The text was updated successfully, but these errors were encountered: