Software composition and dependency management
Package URL and Version range spec
Towards mostly universal dependency resolution
<p>Package URLs are a compact way to identify software packages across multiple ecosystems.
Together with the new "vers" Version Range Specifier, these two mini specs will offer a
new way to create new, mostly universal dependency resolvers and installers, working
across ecosystems.</p>
Because no tech stack is an island running on a single programming language and in a single package ecosystem, we need a way to talk about packages across ecosystems: talk about their type, name, location, version and dependent version ranges. purl and vers are an attempt to solve this problem.
How to talk about packages, dependencies and vulnerabilities using a common language?
I will present Package URL, a way to references package across ecosystems which is emerging as a de-facto standard. And I will introduce a new work-in-progress, mostly universal notation to express version ranges to be used in resolving package dependencies such as "I require package foo, version 2.0 or later versions" and referencing affected vulnerable packages versions as in "vulnerability CVE-123 affects package bar, version 3.1 and version 4.2 but not version 5".
These two will show a way to create new, mostly universal dependency resolvers and installers, working across ecosystems and we will promote the rise of universal package managements where one tool and one unified spec can rule them all.
Additional information
| Type | devroom |
|---|
More sessions
| 2/6/22 |
<p>The devroom intro by devroom organization team!</p>
|
| 2/6/22 |
<p>Legal Risk Mitigation is one of the three main functions of an <a href="https://github.com/todogroup/ospodefinition.org">OSPO</a> (designated places where open source is supported, nurtured, shared, explained, and grown inside an organization). OSPOs often oversee aspects of a company’s open source license compliance process and supply chain as one of the first activities. The responsibilities include:</p> <ul> <li>Maintaining open source license compliance reviews and oversight</li> ...
|
| 2/6/22 |
<p>This talk aims at presenting our trials and tribulations as well as our achievements in designing a compliance software project for open source licenses.</p> <p><em>"Are all module licenses in our software project compliant with each other ?"</em> Many of our customers have asked us this question even though they already had a plethora of software solutions (not always FOSS software) dealing with this topic. This surprised us, and led us to seek out the cause of their uncertainty. We then ...
|
| 2/6/22 |
<p>The management of SBoM (software bill of material) is very important for companies to comply with the OpenChain specification.The latest features of SW360 support the management of license obligations and the management of SBOMs in SPDX format. In this presentation, I will introduce and demonstrate the features of SW360.</p>
|
| 2/6/22 |
<p>Granted that software composition and dependency processing are very relevant for software engineering. The presentations have pointed out how such processing is embedded into activities of an organization. We would like to gather feedback about how the current status of adoption and integration looks like.</p>
|
| 2/6/22 |
<p>break</p>
|
| 2/6/22 |
<p>A Linux distribution is a great playing field for testing tools for vulnerability scanning. It is even a better playing field if it includes more operating system kernels, like the Eclipse Oniro project does. Eclipse Oniro targets the Internet of Things (IOT) domain, where fixing security issues is critical.</p> <p>In this talk, Marta is going to present a return on experience of scanning for known vulerabilities (CVEs) in the Eclipse Oniro project. The presentation is going to start with an ...
|
