From nobody Wed Aug 6 18:50:46 2025 X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4bxzs95tdxz645Bq; Wed, 06 Aug 2025 18:51:09 +0000 (UTC) (envelope-from devnull@apt322.org) Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com [136.143.188.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4bxzs82yg2z3my8; Wed, 06 Aug 2025 18:51:08 +0000 (UTC) (envelope-from devnull@apt322.org) Authentication-Results: mx1.freebsd.org; none ARC-Seal: i=1; a=rsa-sha256; t=1754506265; cv=none; d=zohomail.com; s=zohoarc; b=cF2DKQ8dYXIpLp9T1kNXqTvh0SGP25SvqEtsqUXOjMHRzVWVmY+FvTUNrQpJayn4bA9TthrY8HwYB/61dtBuLZuUzNnjzRN0StcScZXE5SUWkBttVVYxe579JdTQKcdan8BoRXQAOs1pgTJSB1X3ElehjObELvxexeFm/2xgA6Y= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1754506265; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=EqQBhccdXV0ZDqBIUI/bpiNMR82hZfAEfjP2DGSTi5w=; b=PayiRNgV+euzBqTOZF01/69SR2HI0Hz6zeJwzY4tEP1EIL5rUDc/X2g38RAdreWmrJbKqer82iXSUyg5KYFIIN38IZ/Am3UlhLLaofrrDhKjjBY0nTddoG0V7zEaeabzVdwYv5h0D9wneWBynhxItU9kbGNB4z10wXUpznd0r0Q= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=apt322.org; spf=pass smtp.mailfrom=devnull@apt322.org; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1754506265; s=zmail; d=apt322.org; i=devnull@apt322.org; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc; bh=EqQBhccdXV0ZDqBIUI/bpiNMR82hZfAEfjP2DGSTi5w=; b=TJ5tFhxpeMNeh4/cT82D87ie2DX6OPRSkvcAS3YGza8JOI1H9/DdH3iZrmUo0vDS BbKzymAtY2mV855pwf+6daX3o8yTc5hTHMaDn6yK17gP03bdjUd8e4leCnmrvNAoFLP MQv6GOmBFUpgIYMUSqt7idFRTpUDbzYuvqHO3yKg= Received: by mx.zohomail.com with SMTPS id 175450624921784.73809262973259; Wed, 6 Aug 2025 11:50:49 -0700 (PDT) Message-ID: Date: Wed, 6 Aug 2025 15:50:46 -0300 List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: RFC: Adopting OSV for Vulnerability Database To: Ed Maste , freebsd-security@freebsd.org, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org References: Content-Language: en-US From: devnull Autocrypt: addr=devnull@apt322.org; keydata= xjMEZKB4ohYJKwYBBAHaRw8BAQdAHoyFWZNChm06vDuOWf+TuWHsGzTNml/f/R77g1vokuDN IE51bGwgRGV2aWNlIDxkZXZudWxsQGFwdDMyMi5vcmc+wpMEExYKADsWIQR3aLfEpnoYuWtq 6NCI9V8iO+DbXwUCZKB4ogIbAwULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAKCRCI9V8i O+DbXxjUAP4mvfNs77iZXF0PzHjVCiAP4zuLcSYKp0UCBUPX04YBxQD+K6Dj3/9MNX30gBh5 3/XTjSGDr3455V8bJ/kM2S8YXA3OOARkoHiiEgorBgEEAZdVAQUBAQdA/GzaUAaYuJxzSPjc 6CKI/IeH2uewx0QGi0ZP+2A/BXMDAQgHwngEGBYKACAWIQR3aLfEpnoYuWtq6NCI9V8iO+Db XwUCZKB4ogIbDAAKCRCI9V8iO+DbX2FmAP0Y/+rE6VPRieYwGpSqfuYT+uJ0TtWWe9VjatG3 SN7KTwEAzVtRVIe3khl02FbgcJQS3XJcTTLmEFfCKrRnunbRDQo= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-Rspamd-Queue-Id: 4bxzs82yg2z3my8 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/24, country:US] I totally agree! +1 This is defined in our goal: https://freebsdfoundation.org/blog/freebsd-ports-and-packages-security-project/ Also, the change makes strategic sense: puts FreeBSD on the radar of modern supply-chain tools. I think, making the considerations and implementation on FreeBSD Phabricator (https://reviews.freebsd.org) is a good start to share ideas, backlog and (offcourse) code. On 06/08/25 10:49, Ed Maste wrote: > Hello everyone, > > The Foundation has been evaluating the benefits of migrating FreeBSD > vulnerability data from our bespoke VuXML format to an > industry-recognized format. Such a migration would involve some new > workflows, tools, processes, and documentation, so I'm sharing this > proposal for comments. > > Adopting an industry-recognized format offers significant benefits as > it simplifies how external parties can consume and utilize FreeBSD > vulnerability data, and allows us to manage data with a broader range > of existing upstream tools, reducing the need for custom development. > > Providing vulnerability data in a standard format increases the > security of the FreeBSD ecosystem by facilitating seamless consumption > by a wider array of security tools and services, which will accelerate > the detection and mitigation of threats for all users of FreeBSD and > its derivatives. > > Proposed Standard: OSV (Open Source Vulnerability)[1] > > After evaluating available vulnerability standards, we recommend > adopting OSV for the following reasons: > - Broad Industry Support: OSV is supported by organizations of all > sizes, including AlmaLinux, Android, Debian, GIT, Go, PyPI, and Red > Hat. > - Existing OSV Databases: Several organizations already generate > OSV-compatible vulnerability databases. > - Independent Adoption: Organizations don't need to be under the Open > Source Vulnerability Database (OSV) umbrella, though there may be > future benefits to joining. > - Seamless Data Conversion: Bidirectional conversion is possible > between VuXML and OSV, without loss of metadata. > > Implementation Considerations > > Proof of Concept > > A proof-of-concept implementation is underway, showcasing various > ID-tag examples and potential database arrangements. Ideas for > database structure are drawn from projects like the PYPI (Python > Package Index) vulnerability database and the openSUSE OSV index. > > Repository [2]: You can explore the implementation and different ideas > in the README.md of this repository: > https://github.com/illuusio/vuln-test. This is intended to spark > discussion. > > Alternative Standards Considered > > We considered other standards but did not pursue them due to their > limitations in meeting our expected needs: > > - CSAF (Common Security Advisory Framework): While backed by OASIS and > entities like CISA and Red Hat, CSAF is more complex to implement > (e.g., file signing requirements) and has less mature tooling. While > OSV and CSAF aren't mutually exclusive, implementing an OSV database > first is significantly easier. > - OpenVEX (simplified Vulnerability Exploitability eXchange > implementation): Different purpose - used to indicate that a > vulnerability does not apply in a certain configuration (for example, > a feature that is not enabled at compile time). > > Next Steps > > We've opened a pull request adding an OSV parser to FreeBSD pkg [3]. > We would appreciate your feedback and questions on the following: > - The choice of OSV as the standard for FreeBSD vulnerability data. > - The current proof-of-concept implementation approach. > - Any concerns or suggestions for the proposed migration. > > Your input will help us refine the implementation before submitting > the necessary changes to the FreeBSD tree. > > Thanks in advance for your time and consideration. > > Ed Maste > > [1] OSV Schema: https://ossf.github.io/osv-schema/ > [2] OSV FreeBSD POC repo https://github.com/illuusio/vuln-test > [3] pkg(8) Parser PR: There's an existing pkg(8) parser pull request: > https://github.com/freebsd/pkg/pull/2453 >