@palmer - I know this is not necessarily your area of ownership anymore, but you have the most historical knowledge.  Please defer to someone else though, but really looking for insight from security on this topic.

dcheng@, would you like to chime in? GURL is probably preferred for being secure, but calling into native has its downsides, including not being able to use Robolectric for unit testing. What do you think?

Is the unit testing performance hit so bad that it's really a deal-breaker?

Another option is to write a Java version of GURL that passes exactly the same test cases as does GURL. Sounds like a lot of work for humans though, and there would still be risk of divergence unless there was also an integration test. (And that test would need to straddle the Java/native line.)

What I'd really enjoy (...'enjoy') seeing is something like http://seriot.ch/parsing_json.php but for all of the UR? parsers that Chromium uses (at least: GURL, KURL, Origin, SecurityOrigin, java.net.URL, java.net.URI, android.net.Uri, ad hoc string sniffers, ...). There's basically no chance that the ways in which they disagree have no security implications. :)

I'd even go as far as to say Hotlist-GoodFirstBug, for someone who wants to dig into a trouble zone. :) We could evangelize this bug in the open source community perhaps.

Hello!

I'd like to work on this bug. I agree with one of the ideas suggested by palmer@, to create a similar testing infrastructure as the one used to test json parsing in the link that he provided.

Another possible solution that I see plausible is to try to start reducing the amount of URL parsers that are in use, however I am not sure how much effort that would require (maybe a lot). 

I am open to any opinions on this. 

Let's defer reducing parsers until later, after we fully know what we've got. I'd say a good plan is:

* enumerate all parsers
* gather test cases
* write a test suite that feeds each test case to each parser and records the results

Roger that,

I will prepare a patch and send it to review ASAP

Thanks

JJ

I'm creating an Origin class in Java so we can avoid bugs arising because of origins being represented in Uris (eg forgetting to copy over the port). I think for simplicity and security I'm just going to call GURLUtils.getOrigin, but it would be nice if this was replaced by a pure Java class in the future.

#8: I'd like to get down to as few implementations as possible, rather than ad new ones.

#9: The problem is that we don't have an enforceable way of getting an origin and since we want to compare origins for things like post message this can be a problem - eg [1] where we create an Uri representing an origin but don't to include the port. What's more the origin generated in [1] won't be equal to an origin from GURLUtils.getOrigin because the latter has '/' on the end while the former doesn't.

We could just manually call GURLUtils.getOrigin and stuff that into an Uri or String, but we'd have to manually make sure that everything compared to that also has GURLUtils.getOrigin called on it, which seems prone to bugs. I think it's fairly reasonable to have an Origin class (like we do in C++) so we enforce this in code.

[1] - https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappActivity.java?l=177

The assigned owner "jjlopezjaimez@google.com" is not able to receive e-mails, please re-triage.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot