You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 6, 2020. It is now read-only.
I can't see the problem directly but wonder that the launcher/proxy is not checking URLs put to it and instead relying on the network's response.
Also, I notice that certain characters appear to see the launcher hang and they get no quick reply.. or likely none at all.
The usual reply to a non-existent domain appears to be of the form:
ERROR 21:36:51.503097038 [safe_core::ffi mod.rs:330]
--------------------------------------------------
| FfiError::DnsError -> DnsError::CoreError -> No such dataCoreError::GetFailure::{ reason: NoSuchData, request: Structured(dc641a.., 5)}
--------------------------------------------------
I would have expected a different type of error for malformed urls, like abc_def.safenet or uvw#xyz.safenet
So, a PublicID.safenet and I would expect also Subdomain.PublicID.safenet containing # ! * appear to hang waiting forever, while other characters like _ and - get a quick not found error.
Could launcher proxy filter invalid publicID and subdomain names in safenet URLs? To be clear, it seems the error response is identical to nonexistent domain reply and perhaps that's an unneeded request for the network to deal with. Obviously, the network would still need capability to reject those bad requests but surely it's better not see normal sending of those.
Note: I'm seeing this when using wget to request files and the response in the launcher's terminal. I can't tell a difference between the hanging requests that follow from characters like # ! * in .safenet requests and that which occurs for bad urls outside of .safenet - so .safetynet hangs in the same way and perhaps those characters cause a confusion in wget rather than in the launcher. Still, I worry that the characters not being handled might risk user input interactions in the launcher, if that input is being trusted or put to the network without filtering for only [a-z0-9].
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I can't see the problem directly but wonder that the launcher/proxy is not checking URLs put to it and instead relying on the network's response.
Also, I notice that certain characters appear to see the launcher hang and they get no quick reply.. or likely none at all.
The usual reply to a non-existent domain appears to be of the form:
I would have expected a different type of error for malformed urls, like abc_def.safenet or uvw#xyz.safenet
So, a PublicID.safenet and I would expect also Subdomain.PublicID.safenet containing # ! * appear to hang waiting forever, while other characters like _ and - get a quick not found error.
Could launcher proxy filter invalid publicID and subdomain names in safenet URLs? To be clear, it seems the error response is identical to nonexistent domain reply and perhaps that's an unneeded request for the network to deal with. Obviously, the network would still need capability to reject those bad requests but surely it's better not see normal sending of those.
Note: I'm seeing this when using wget to request files and the response in the launcher's terminal. I can't tell a difference between the hanging requests that follow from characters like # ! * in .safenet requests and that which occurs for bad urls outside of .safenet - so .safetynet hangs in the same way and perhaps those characters cause a confusion in wget rather than in the launcher. Still, I worry that the characters not being handled might risk user input interactions in the launcher, if that input is being trusted or put to the network without filtering for only [a-z0-9].
The text was updated successfully, but these errors were encountered: