I did file a Chromium bug last week, #472347. I filed under security (as I was unsure) so it's not public, but it was pretty much immediately marked as 'Won't Fix'. Hence the repo ;)
Sorry, last night HN didn't show me a "reply" button on the thread, so I thought maybe it tapped out at a depth of four? I'm not dodging :) [edit: does HN have account score thresholds at which different features get enabled?]
I don't have security-bugs access, but I explained offline to the OP that "Won't Fix" covers a lot of cases, including "already fixed" / "duplicate", not simply "your bug report is being ignored".
OP also sent me some more information about the BrowserStack setup, and it looks like both the M42 and M43 builds that OP was testing against are nearly a month old and before the fix (merged to M42 late in beta phase, M43's still in dev/canary stage).
>Sorry, last night HN didn't show me a "reply" button on the thread, so I thought maybe it tapped out at a depth of four?
Aha, the automatic flamewar limiter I guess. Happens to me as well. (clicking on the xx minutes ago link seems to help most of the time.)
> I don't have security-bugs access, but I explained offline to the OP that "Won't Fix" covers a lot of cases, including "already fixed" / "duplicate", not simply "your bug report is being ignored".
I don't know what I'd do if anyone reporting to me used wontfix for all those kind of cases. It doesn't exactly encourage bug reporting.
TY, I'll update the readme.md when I get home tonight.
And you are right, it was initially marked as "Won't Fix" because it was not immediately reproducible, but further research yielded it being discovered as an "already fixed" dupe.
FYI it seems there is a minimum age (a minute or so) to a comment in order to reply. At least that was my experience last night.
Tangentially related, I was performing an analysis of the billions of links available in Common Crawl[1] and ran across an interesting error: there was one link where the port number was 18779690999[2].
The library I was using converted the port text into a 32 bit integer but the library didn't account for the possibility that someone supplied a port well over the 32 bit int limits. I was curious how many tools that use URLs would suffer similar fates and whether there might be any interesting security vulnerabilities.
Just goes to show, no matter how much crazy you've seen, there's likely crazier things hidden from you across the Internet ;)
Agreed that it's malformed. My point was more that I'm curious how many other libraries fail badly when confronted with an unexpectedly large port. It's the edge cases / "no-one would ever be silly enough to do that" that quite frequently lead to security issues =]
Yes, that's why I feel like this is more significant than a simple crash at first glance- no one would purposefully craft a 256+ unchecked character URL, unless they are being malicious, in which case they absolutely will craft a 256+ unchecked character URL.
URLs can definitely get rather long if they contain lots of query data, and the de-facto limit seems to be around 2KB[1]. It's still not acceptable for such URLs to crash the browser though.
Pushing browsers to their resource limits is fun... and makes me think that we should really have configurable limits to stop the browser consuming all RAM and crashing or affecting other applications' performance. A policy like "maximum 75% of available RAM" with a suitable cessation of further rendering when that limit is reached, with an error message, would be far better than forcing itself and all other apps into swapping and then crashing.
Hah, that click was definitely my karma for today, ty.
But the reason I posted this is because it doesn't rely on Javascript to eat up memory- anyone can post a malformed/long link to a web forum and crash the thread/site for other Chrome users immediately, without clicking thru.
I hope this doesn't come across as negative but why post this on HN? Why not just file a bug on crbug.com? Browsers have bugs, all them. It seems kind of negative to turn it into a spectacle rather than just be kind and report the bug to the team.
Browser makers need pressure to prioritize robustness. Otherwise, to be competitive with each other, they will prioritize features much more highly, and we can see the results today. "Browsers have bugs, all of them." ...but we're not talking about very-tricky-to-trigger bugs found a couple of times a year, we're talking about 30 every 6 weeks, in various subsystems.
I was initially turned off from Chrome in its early versions because it seemed that tabs crashed much more easily, since it wasn't as big a deal to have a tab crash. Firefox crashes as a whole, so it has much more motivation to diligently make sure its subsystems are not prone to crashing on high-level documents / languages, however malformed they may be.
But as was posted below, it's still quite easy to lock up Firefox. So I applaud crashfirefox.com as well as this Chrome demonstration, they're needed to keep the balance between robustness and new features.
Interestingly enough the links on Reddit don't seem to crash Chrome but the cortexture.net link from Github does. I'm running Chrome 41.0.2272.101 m (64-bit) on Windows 8.1
Interesting. Confirmed crash on Ubuntu 14.04, version 42.0.2311.50 beta (64-bit). It crashes only the tab ("He's dead, Jim"), not parent Chrome process.
<a href="http://Lorem ipsum Culpa labore qui culpa enim nostrud eiusmod ullamco anim in dolor consequat voluptate in in laboris consequat dolor occaecat minim aliqua quis id in Duis eiusmod amet id do ex do dolore dolor anim sit deserunt do.">Hello World!</a>
