On 4/27/19 8:39 AM, Lukas Fleischer wrote:
> On Sun, 06 Jan 2019 at 18:56:04, Eli Schwartz wrote:
>> php's parse_url does not handle proper rfc3986 URIs, specifically, it
>> does not handle the case of an empty authority such as file:/// or
>> local:/// and only handles the case of file by applying a special case
>> for file itself. These URIs are deemed "malformed" and return false.
>>
>> When such URIs were used, we would end up always treating the package
>> source as a filename (despite that this is incorrect, since plain files
>> will be correctly handled by parse_url, we will correctly determine that
>> there is no schema, and we will go to the source_file_uri).
>>
>> Instead, handle the case of a "malformed" URI by treating it as another
>> example of a source with a schema, and linking it as-is.
> 
> Sorry for replying only now, this somehow slipped through the cracks.
> But I realized it's not yet in master, so it's probably not too late!
> 
> What happens if somebody uses "javascript:alert('XSS!')" in their
> sources? I hope it is not converted to a link?
> 
> I think we shouldn't create links for anything other than HTTP and HTTPs
> schemes (and maybe FTP as well). These links are just for convenience
> and probably not used very often. So it's likely a good idea to err on
> the safe side.

Ah... yeah, that is a pretty good point. I'd probably want to display
that as straight up plaintext.

It definitely should not be appended to the cgit url if it is a valid
schema, though. And regarding not making a link at all (e.g. for the
common git:// protocol), how would that play with renamed sources like
"$pkgname::git://example.com/project-something"?

I wish php had a schema validator that wasn't broken... python's
urlparse cleverly handles all this nonsense, and you can just refuse to
print urls with ParseResult(scheme='javascript',...). Maybe we should do
string comparisons to reject javascript schemes? Is there anything else
which matters in this context?

-- 
Eli Schwartz
Bug Wrangler and Trusted User

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to