It would be very helpful if we could gauge the extension-breaking risk of branch core changes by doing an actual grep over the various extensions that are up on AMO (unjarring jars, etc) looking for possibly-affected code patterns. For example, for one of the bugs we were thinking about for 1.8.1.5, it would have been good to know whether we have extensions that load data: or javascript: URIs from chrome in content windows, and if so what behavior they expect for them. That could be handled by a grep for "javascript:" and "data:", followed by hand-examination of the (hopefully not many) hits, I think. Thoughts?

I personally think this is a good idea, but duping to a WONTFIXed. If you have a specific request you'd like run (like the one mentioned above), you can file a bug for that. (Yes, I realize I'm saying we'll do the grep but not build a tool to make the grepping easier)

Why in the world would you volunteer to do the grep but not build the tool? These questions come up constantly in the end-game of every security update, and generally at a point when we need very fast turn-around to make a decision.

Because running a grep is a lot easier, and every time we build a tool we end up in a maze of decisions about what sets of features it needs to support, feature-creep pain, not having access to the servers that run the tool in production, etc. I don't think it's a WONTFIX except as part of AMO, though -- if someone wrote the tool, and anyone can because the public files are on public FTP, we'd be fine with that, it just wouldn't be part of AMO. (There's no good reason to couple it and introduce risk to something that's a core app dependency when someone makes a change to the scanner for some last-minute security check.) So, yeah, feel free to write such a tool -- you'd need help from IT much more than from the AMO team, should you need the help at all.