Comment 6 for bug 1415160

I reviewed angular.js 1.2.28-1ubuntu2 as checked into Ubuntu wily (carried
forward unchanged from vivid). This should not be considered a full
security audit; I reviewed rather less code than typical for a MIR and
JavaScript is relatively new to me.

Angular.js is incredibly complicated:
- there's HTML parsers built in
- there's a compiler of some sort built in
- there's localization built in
- there's entire MVC framework built in
- there's a build system / dependency manager built in
- there's vast amounts of browser-specific knowledge built in

Google is a mixed-case when they are a software upstream author; while
the code quality looks good, and explanatory comments throughout are more
useful than the average comments, and there's a strong culture of testing
apparent in the package, I'm very concerned that Google has a history of
supporting what it needs and little else. I'm also concerned that five
years of support is nearly impossible in the front-end javascript world.

Even though there's over a hundred files in test/, I saw no evidence that
the tests are run during the build. It's probably impossible to run these
tests during the build. What runs the tests? How could the tests be used
under maintenance?

We cannot support using npm / io.js / node.js. There's multiple references
throughout the codebase to these and I hope they aren't actually required
(the debian/control doesn't list any dependencies).

version-info.js, compare-master-to-stable.js, changelog.js may execute
arbitrary content from git repositories and cannot be supported as it is.
(Shell injection issues in getCodeName(), getTaggedVersion(),
getPreviousVersions().)

htmlparser.js looks careful but may not be suitable for untrusted inputs.

The only way to support angular.js is probably to perform entire new
upstream updates periodically. This almost certainly means that e.g. MAAS
and anything else that depends upon angular.js may need significant
interface work done periodically in order to function. This may require
new headcount to address both support and business requirements.

We may become solely responsible for the upkeep and maintenance of this
package with our LTS lifetimes -- which team will be responsible for
maintaining this package should upstream abandon it?

I realize the client-side JS framework world forces us to pick among
least-bad options but I need to make sure our management understands
the risk that we may inherit this system entirely and decides this risk is
worth the benefits provided by the package.

Security team ACK for promoting angular.js to main conditional upon:
- positive verification that no npm / io.js / node.js components are not
  used in deployment
- positive verification that version-info.js, compare-master-to-stable.js,
  and changelog.js are not used in deployment
- a team promising to maintain angular.js in the event upstream becomes
  unresponsive to our needs
- a team promising to perform full regression testing of all in-house
  applications that use angular.js on every angular.js update. (See e.g.
  http://www.ubuntu.com/usn/usn-2746-2/ for a case when even a simple
  update of in-house software wasn't properly tested against all dependant
  software. Angular.js feels much more likely to cause issues than
  simplestreams.)

Thanks