G.O.S.S.I.P 学术论文推荐 2021-07-27

今天为大家推荐的是来自OOPSLA 2020的一篇论文——“Detecting locations in JavaScript programs affected by breaking library changes”。

NPM registry包含了1.2M包，平均每个包依赖大约80个其他包，大多数库会经常更新，增加一些新特性，修复一些bug和安全漏洞等。然而考虑到更新可能会破坏现有的代码，开发者需要查看changelog并手动定位被影响的代码的位置，所以开发者往往不愿意切换到新版本。

现有的工具migrate tools，rxjs-compat，npm audit等都无法很好定位具体受影响的代码位置。在本文中，作者引入了简单的模式语言来表示API access point，并基于静态分析开发了模式匹配工具TAPIR来减少开发者的手工工作。

首先来看一个例子，npm包postal每周超过20,000次的下载量，在2016年，postal决定更新lodash依赖到最新版本，postal的维护者首先意识到lodash库中debounce方法的breaking changes，push了一个patch来更新postal库。随后维护者又发现了其他地方的breaking change，几周后一个使用者又发现了另一个影响postal库的breaking change。在两周后postal的新版本才最终适应新版本的lodash。

上面的例子说明，开发人员只能阅读依赖库的changelogs，找出相关的breaking changes，然后手动修改，这非常花费时间，而且可能会漏掉一些修改。而使用TAPIR工具可以自动列出相关的9个changes，并且只有两个是false positive。

作者对10个常用的库，手动分析了changelogs，列出了库中的breaking changes的类别和数量。

根据上面的分析，作者设计了一种简单的模式语言来描述发生breaking changes的API access point。在库开发者进行一个重要的更新时，需要按照该模式语言来写更新日志。虽然这增加了库开发者的工作，但是作者提到更新是较少的，且该模式非常容易书写。

然后，TAPIR扫描代码，找出和发生breaking change的API access point匹配的表达式。该匹配过程分为别名分析，access paths推断和模式匹配。

作者在15个npm包上评估了TAPIR：

• 该模式语言可以十分简单的表达几乎所有类型的breaking changes

  
  

• 可以达到100%的recall，以及较低的false positive

  
  

论文PDF：

https://dl.acm.org/doi/pdf/10.1145/3428255

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 学术论文推荐 2021-07-27