Page MenuHomePhabricator

FloatingUI: Internal due-diligence security review
Closed, ResolvedPublic5 Estimated Story Points

Description

Background

DST will request an official review of the FloatingUI library from the WMF Security Team (per the process outlined here: https://www.mediawiki.org/wiki/Security/SOP/Application_Security_Reviews) – this will be tracked in a separate task.

However, we understand that these reviews take time and we may not be able to wait until such a formal review is complete (we have problems we need to solve within Codex now in order to make the library production-ready, and it's not feasible to simply re-implement everything from scratch within our own codebase here).

Given these considerations, the Design Systems Team will perform its own preliminary review of the FloatingUI library using processes similar to those used by the Security Team. If we don't find any red flags, we will proceed with use of this library within Codex while we wait for the outcome of the official review. In the unlikely situation that DST moves ahead with this library and the Security Team later flags it as unsafe, we will remove it from Codex and figure out a different solution.

Review Process
  • DST reviews FloatingUI's library governance and policies around 3rd-party dependencies, bug-fixes, etc
  • DST performs static analysis of the latest release of FloatingUI using some industry-standard tool
  • DST manually reviews the diff produced in Codex output by adding FloatingUI as a dependency

Results of these evaluations should be posted in this task, with the goal of making a decision on whether to move ahead with preliminary adoption before the end of the current sprint.

Event Timeline

egardner renamed this task from FloatingUI: internal due-dilligence security review to FloatingUI: internal due-diligence security review.Sep 11 2023, 8:54 PM

scc report:

───────────────────────────────────────────────────────────────────────────────
Language                 Files     Lines   Blanks  Comments     Code Complexity
───────────────────────────────────────────────────────────────────────────────
TypeScript                 236     26653     3319      1077    22257       3339
SVG                         63       862        3         1      858          0
JavaScript                  48      6332      368       103     5861        143
JSON                        14     42123        0         0    42123          0
Markdown                    11       286       73         0      213          0
YAML                        10       174       11         1      162          0
License                      7       147       28         0      119          0
TypeScript Typings           6         6        0         0        6          0
CSS                          4       418       62         0      356          0
HTML                         3        43        3         0       40          0
Patch                        1        34        2         0       32          0
Vue                          1        54        6         0       48          0
gitignore                    1        17        0         0       17          0
───────────────────────────────────────────────────────────────────────────────
Total                      405     77149     3875      1182    72092       3482
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $2,411,996
Estimated Schedule Effort (organic) 19.22 months
Estimated People Required (organic) 11.15
───────────────────────────────────────────────────────────────────────────────
Processed 2849296 bytes, 2.849 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────

npm audit:

# npm audit report

semver  <5.7.2 || >=6.0.0 <6.3.1
Severity: moderate
semver vulnerable to Regular Expression Denial of Service - https://github.com/advisories/GHSA-c2qf-rxjj-qqgw
semver vulnerable to Regular Expression Denial of Service - https://github.com/advisories/GHSA-c2qf-rxjj-qqgw
fix available via `npm audit fix`
node_modules/make-dir/node_modules/semver
node_modules/patch-package/node_modules/semver
node_modules/semver

1 moderate severity vulnerability

One concern is the amount of new code that floating-ui pulls in.

Before adding floating-ui:

dist/codex.umd.js  88.50 kB │ gzip: 23.26 kB

After:

dist/codex.umd.js  105.97 kB │ gzip: 30.35 kB

That's a 19.7% increase pre-gzip and a 30.5% increase post-gzip.

git-secrets, gitleaks and whispers found nothing.

npm audit (see above) only found one moderate severity vulnerability in semver, which only affects floating-ui's build process, not our usage of it.

npm outdated did not find anything meaningful, only outdated versions of other subpackages in the @floating-ui/ namespace.

snyk found only a regex DoS vulnerability in semver, but again that only affects floating-ui's build process.

semgrep only found things in the .github and website directories, both of which only affect floating-ui's internal development process or website.

Stats:

Statistic/InfoValue
Repositoryhttps://github.com/floating-ui/floating-ui
Last commit reviewed99de6d1
Recent contributions (past 6 months)206
Active developers with > 10 commits2
Current overall usage26.6k stars, 1.5k forks
Current open security issues0
Methods for reporting security issuessecurity policy

What stands out is that this project was largely written by two people, and only one of them is still very active (176 commits in the last 6 months) while the other one is semi-active (11 commits in the last 6 months). Only those two contributors have more than 10 commits in the last 6 months, and only 3 people have more than one(!) commit in the past 6 months.

CCiufo-WMF renamed this task from FloatingUI: internal due-diligence security review to FloatingUI: Internal due-diligence security review.Sep 13 2023, 7:10 PM

I have reviewed the code that adding floating-ui adds to the Codex build output, and it looks good.

My only remaining concern is how much adding floating-ui increases the size of the Codex builds, per T346097#9161129. Code splitting will help somewhat, but every build that includes a menu-using component will be affected. As a mitigation measure, we decided not to apply floating-ui to TypeaheadSearch for now, so that the codex-search build will not be affected.

In the future, we could potentially look at writing a lighter version of floating-ui ourselves, but for now I think using the library is the best way to go.