NAEV, or Nonlinear Automatic Equivalence Verification is a package manager feature set that utilizes functional equivalence
to enable and encourage the use of Nonlinear Versioning within code projects.
What is NAEV? (click to expand)
NAEV is an abstraction of a package manager feature set, which means it is a set of instructions that can be applied to all package managers. It is designed to enable security patches on old versions of code in a way such that users are assured the patches will not break their code, and thus they can update safely.
NAEV consists of three feature sets: nonlinear versioning, automatic version selection, and functional equivalence verification.
Nonlinear Versioning allows code to be published to older versions retroactively. This encourages security patches for older and more popular versions of code. While this is currently used by many organizations, there is no standardization, and actually publishing packages nonlinearly leads to many issues. Establishing a standard allows for package managers, version control systems etc. to adopt the features, lowering the barrier to entry.
Automatic Version Selection
Upon enabling NAEV, users can select if they wish to receive security patches for the version of a package they are on, or if they wish to receive the highest functionally equivalent version. Following a new package release, NAEV will run several functional equivalence tests and report back how confident it is that the new package is non-breaking. If it is past a user defined threshold, the package will automatically update.
Functional Equivalence Verification
NAEV also comes with a feature set to enable functional equivalence verification. This includes both static analysis and comparative test analysis. Static analysis is completed by looking at the package's import and export statements (function and variable definition) and determining if any changes between versions will be detrimental to the capabilities of the code that was developed with that package. Comparative test analysis works by taking the old test versions, and injecting them into the new package version, the old test suite is then run on both the old and new versions, and the test results are compared for differences. If the result differences pass a certain threshold, the packages differ.
TLDR: NAEV checks to make sure Version 5 and Version 5.2 are compatible, so developers can update from 5.1 to 5.2 without worrying about breaking their projects.
Why does it matter?
Users often do not update their packages while developing their own. This creates something known as technical lag. Technical lag is the delay between the release of newer, more secure package versions and when users actually adopt those new patches. Technical lag can be inconsequential, but it can also have a cascading effect on an entire package manager ecosystem*. NAEV strives to reduce technical lag by encouraging developers to add functionally equivalent security patches, while encouraging users to enable automatic updating of packages, which would reduce technical lag by around 20%*
TLDR: Running outdated and insecure code is bad, NAEV helps people not do that.
View A Presentation on NAEV
NAEV enables and encourages users to retroactively publish patch versions for old code. If versions 4.1 4.2 and 5.0 were released and a vulnerability was found in v4.2, NAEV easily allows the inserting of version 4.3 retroactively. This is valuable for software that sees significant use for outdated versions. With nonlinear versioning, code does not have to be split into multiple projects, the old versions can be maintained on a branch of the main repository. (Again, this is currently done but no standard exists)
NAEV can analyze package source code to extract important features such as the interface and compare this between versions. This provides a decent heuristic for quickly approximating how similar, or functionally equivalent, two package versions are. This is less accurate than comparative test analysis, but is much faster.
Comparative Test Analysis
NAEV can compare every version of code with every other version of code and generate a compatibility graph / tree. An arrow from vX to vY dictates that users can update form vX to vY without any worry that the changes will break your project. Currently, this has been implement on top of node.js's package manager npm, utilizing jest as a testing framework.
Read the NAEV whitepaper
"Modern day package ecosystems lack sufficient support for patching security vulnerabilities. A combination of lack of patch mechanisms for old versions and user aversion to update packages over fear of breaking current code can cause severe technical lag where many users use old, insecure versions. We propose NAEV, a package manager feature set abstraction that serves two functions: directly support nonlinear versioning for security patches of previous versions of packages, and utilize functional equivalence to support automatic user updates. To demonstrate NAEV’s viability in a generalized environment, we create a test package utilizing npm and evaluated it based on interface and unit test functional equivalence. We find that despite the limited scope of our current tools, NAEV’s core ideas are sound and can be further generalized given additional resources."