From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by mx.groups.io with SMTP id smtpd.msgproc01-g2.6402.1793912760073474949 for ; Thu, 05 Nov 2026 13:06:00 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20260707 header.b=gnCfzxIY; spf=pass (domain: gmail.com, ip: 209.85.128.44, mailfrom: stondo@gmail.com) Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4a59100fa83so23625965e9.0 for ; Thu, 05 Nov 2026 13:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1793912758; x=1794517558; darn=lists.openembedded.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=nTlZiXU6e5t4lK+GyDSMX8RLYbTOFFlFC927BiStm6Y=; b=gnCfzxIYouFxSuQlJyfrEMY2uqs/PdGRJGx22pb027RIorSnSnHn0qe6jFTVn8HH8X fVOTZVmRvxwMC/tCV6mOvjXW8O5rhzVudMzKoLr38lCjhAdDv1URFvnEO/YTvLn06jL/ Vk6RJV0TAZ/Q4gI2yge1fzps1ygz6xLcu7Yr3SBrE/Jr7XkCQLmEtWdbv0ZlU26ROVGX Zi2/39wPcQLv2EbaXqOgry4c+r8ZoPU+OO02SJL/8LW41moGIRjDEKqv2JwE3xB4Gxkk vEtQSZ8mfaPdL8XoUnInD0XfBvxeEYqyfjyYcBiovol47kDX0zWaaphEFHd4KtPOFVIv y1HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793912758; x=1794517558; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=nTlZiXU6e5t4lK+GyDSMX8RLYbTOFFlFC927BiStm6Y=; b=IVjIExNo5OkLCkRuB0eDAbW6uzPMy6VvLvjRxJUakMWUnArhonnjii46is+VLQgT0z HmID+FqKw4+TWAlphFQP8Esz/dVXVR9Ulup5fEUcJbwUuqXmYeZn6bxJep/d6hIPulDG SYLOxruYoMQznPHZRsB+pbvqrErejBUHh8Vqgz5+RS3BvDWmslj2CvKs6AdzVQq7aQ/s NuGe2DyVumwThBEpKvSvbKnWhc5SB8PCez3cTVBRebc9DqAx149lTyDXgbfOwsC8ykGS DwvDZ3qcewRoHi2TnkHhUbJtLH2OoVmrgj4Pb8E/ffYWeYD4LHcbeH0F7+UuJMRPNRBy DkZA== X-Gm-Message-State: APuU4Z/CEZ5Ss52NfZ8UhuXSxM0HtX5+85vHaX2wBhvimNqCqVcW5zL9 3vJI5/un8KQvfA9kDtvJyEzPkuS89REDXZblf30Na5tUQvmLsuT3IcHg X-Gm-Gg: AYBFou1PFECHngZ4N12LBiooRYVEzof2CCXBYwns8ehhKFN/Q+Vl5e1suZikW+FIKUG 0ydsoDHCo8jYhSZdtjdr8HuKdk9xx2BSsgNsHbLoNYxL/OwlmvX6YE3yybEBFoIjMFmbUOSY7Pc d+O4eLU+FP5wYZxVZQkEEIfxJxIwmgFUwjfUBcviiUoV3Cw3lXxEcOoYg/skzC+Yo49/QjLvoO8 CaUG07dd5iWb0auyBHguS9CBWHGcdpZj6bxewBo5nPWg8ZPqgo84/zXdIFhbtkUjPf+9q73EfUr Vwh0N2MjCzYQJaHJRzbIN5tdtlZ4KnKKTEDSvgjAaysJMUs0pQyiatFoF1DMjJrfPqcYNNqRSOA TKE93gsaLJHL+AdHJIHPTPgq+TE341Y4QVBbcJU4v1NvOz+ewvhRGf10XH6zjJWXUrmCJLAUBkC 6tlktwZjOezG9GbHwOcaowXYU6LlocAWwdkFWgHjSt+7d2ZHYnx10jtQmLu8iUeZCp64m+lNXJ5 naGy97r0p6ZlsYI5bUvHV2LxeYamGZ2TjqxbT7pbYGo/x8+DrYEU2v6fjguuBbeJVabPWyb2dDe ppHdXMnWMpvP8NfY9u1/B1G99g+2PAEpeCfm7gaDIuVPJA== X-Received: by 2002:a05:600c:c168:b0:4a1:9078:911 with SMTP id 5b1f17b1804b1-4b6e054a43fmr4420175e9.31.1793912758051; Thu, 05 Nov 2026 13:05:58 -0800 (PST) Return-Path: Received: from fedora ([165.225.94.251]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4b6af5f0c63sm16507095e9.6.2026.11.05.13.05.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Nov 2026 13:05:55 -0800 (PST) From: Stefano Tondo To: Alexander Kanavin Cc: openembedded-core@lists.openembedded.org, bitbake-devel@lists.openembedded.org, Joshua Watt , Stefan Herbrechtsmeier , Peter Marko , Adrian Freihofer , Patrick Wicki , stefano.tondo.ext@siemens.com Subject: Re: [RFC] spdx30: name, version and purl for dependency downloads Date: Thu, 5 Nov 2026 22:05:54 +0100 Message-ID: <20261105210554.1648512-1-stondo@gmail.com> X-Mailer: git-send-email 2.56.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by lin-tor-korg-lkml-alma10-1 with HTTPS for ; Thu, 05 Nov 2026 21:06:09 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/249580 Content-Type: text/plain; charset="utf-8" On Thu, 5 Nov 2026 at 21:26, Alexander Kanavin wrote: > I'm afraid I am missing context, which is hardly surprising because I > did no spdx work until now. What are the language dependencies? Does > something require or recommend them? Is there a normative document > that defines them? The email talks about how the implementation > works, but says nothing about what the problem is. Hi Alex, You are right: I jumped straight into the how and never explained the why. Let me start from the problem. Take crucible from meta-oe. It is a Go program, and besides its own code it compiles in 36 Go modules fetched with gomod://, one of them golang.org/x/net v0.39.0. Now imagine the next advisory for golang.org/x/net comes out, and whoever ships a device with crucible on it is asked: "Is your product affected?" The SPDX that Yocto writes for the image should answer that, but it can't. The module is in there, but only as a downloaded file named "golang.org.x.net@v0.39.0.zip" with the location gomod://golang.org/x/net: no version field and no package URL, so no scanner recognises it. cve-check does not see it either, because it only knows the CPEs of recipes. The answer ends up being someone reading file names by hand, for every advisory and every image. That is what I meant by language dependencies: the packages of a language's own package manager that a recipe compiles in without having a recipe of their own. Rust crates (crate://), Go modules (gomod://) and npm packages (npmsw://) are the cases Yocto can fetch today. For the first two the problem is the one above: present, but not identifiable. Git submodules and the dependencies listed in an npm shrinkwrap file are worse off: they are not recorded at all. Why this matters now, with the documents that ask for it: - The EU Cyber Resilience Act (Regulation (EU) 2024/2847), Annex I, Part II, point 1, requires manufacturers to identify and document the components of their products, including by drawing up an SBOM in a commonly used, machine-readable format covering at the very least the top-level dependencies. It applies from December 2027 to products sold in the EU, so many Yocto users will have to deliver one. - BSI TR-03183-2, the German technical guideline that spells out what such an SBOM contains, asks for the dependencies of everything that is delivered (section 5.1), each with a name, a version and an identifier such as a purl or CPE (section 5.2). - The "2026 Minimum Elements for a Software Bill of Materials", published in July by CISA together with BSI, ANSSI and other agencies, asks for transitive dependencies and an identifier per component, and gives the example above as its reason: a recipient should be able to conclude that a new vulnerability does not affect them when the SBOM does not list the component. Yocto already knows all of this at fetch time; the RFC is only about writing it into the SPDX it already produces, without changing how anything is fetched. I hope that makes the context clearer, and I am happy to go into more detail on any of it. Thanks, Stefano