Bug 16102

Summary: Document risks and assumptions for shared "downloads" directories
Product: [Documentation] Development Manual Reporter: Randy MacLeod <randy.macleod>
Component: developmentAssignee: Paul Barker <paul>
Status: ACCEPTED --- QA Contact:
Severity: normal    
Priority: Medium CC: antonin.godard, daniel.ammann, richard.purdie
Version: 6.0   
Target Milestone: 6.2   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Yes (doc changes required)

Description Randy MacLeod 2025-12-16 16:50:47 UTC 
In the Dec 16, 2025 YP Tech call, 
Peter pointed out that for for builds that share the downloads directory, 
git recipes, could corrupt the local copy of a git clone.
I think this involves a malicious user more than two builds racing.

Peter plans to document this risk and explain how people should deal 
with the risk and verify their local downloads directory.
Comment 1 Peter Kjellerstedt 2025-12-16 16:59:49 UTC 
The case we have is that we have a shared download cache. The we have normal CI builds that use it and also official release builds. The assumption has been that it is fine to share the download cache between these types of builds since everything is protected by either Git SHA-1s, or SRC_URI[sha256sum] checksums. 

However, what we have realized is that a malicious user can modify the actual Git blobs that are stored in the download cache without Git noticing this has happened when fetching the repository into the build tree. Thus the malicious user can run a developer build in CI that does this, and it will later affect an official release build.
Comment 2 Randy MacLeod 2026-06-11 15:20:33 UTC 
Do you have a proposal for how we should detect this rather than only documenting the risk?
Comment 3 Randy MacLeod 2026-08-06 15:21:16 UTC 
Paul and Richard to write a draft for Antonin.