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 the naev repository on GitHub
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 analyzes the interfaces of the lower and higher versions of code.
Zach wrote this part so I will have him fill it in tomorrow.
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
This part of the site is coming soon (the paper and abstract aren't finished yet).