
Un-upstreamed Patches: Implications and Challenges
Explore the significance of un-upstreamed patches, the impact on software development cycles, and the potential issues arising from non-alignment with upstream projects.
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
How big of a problem are Un-upstreamed patches? Jon Mason
The Upstream Project Distro - Collection of packages Project Source Code Configure and Build Package
What are patches? Modification of original source code
Why do we need patches? Fix Critical vulnerabilities (CVEs)! Fix other bugs Add features Integrate source code into build environment
The upstreaming process Find Issue Fix issue Patch Submit Upstream Accepted/Release Software Iterate until accepted
Why not use only upstream? Time delta between upstream release and distro release Upstream won t take it Unique to build environment Feature/Fix isn t fully baked Upstream is dead/no maintainer/unresponsive
So, we must keep patches in our distro tree? Sure, but the upstreamed versions will make it so eventually can run only "just upstream"
Drive-by (Drive thru) patches in distro Patches that are created for the distro and not submitted for inclusion upstream These are the problem! Whose problem are these patches? The patch submitter or the distro package maintainer Will the upstream project ever even know there is a problem?
Problems of not using only upstream Duplication of effort Bit rot of patches
All of this is theoretical, right? Is this actually a problem?
Story of why I went down this path? (redacted to protect the guilty)
So, we have patches living in our trees forever? This cannot be true...
Types of Patches For nanbield (v4.3) 1186 total 200 Backport 253 Pending 452 Inappropriate 232 Submitted 19 Denied 21 Inactive-Upstream 69 CVEs?
Upstream-Status? Pending Submitted [where] Backport [version] Denied Inactive-Upstream [lastcommit: when (and/or) lastrelease: when] Inappropriate [reason] https://docs.yoctoproject.org/contributor-guide/recipe-style- guide.html#patch-upstream-status
2 1 1 1 1 3 1 1 1 Year 9 dropbear gnu-efi pam tcltk tcp-wrappers texinfo 6 1 1 1 1 1 1 9 1 1 1 1 1 1 1 1 1 9 1 1 1 1 1 1 1 1 1 Year 13 tcltk xorg-app Year 11 automake Year 10 gmp iptables python Year 8 avahi busybox connman cronie gdbm ifupdown quota swig xorg-lib Year 7 at bash e2fsprogs gdb ghostscript gnutls libacpi newt ruby
2 1 1 2 1 1 8 1 1 1 1 1 1 1 1 7 1 1 1 1 1 1 1 9 1 1 1 1 1 1 1 1 1 Year 13 tcltk xorg-app Year 9 gmp iptables Year 8 avahi busybox cronie gdbm ifupdown quota swig xorg-lib 2920-3284 dropbear gnu-efi pam python tcltk tcp-wrappers texinfo Year 7 apmd at bash e2fsprogs gdb gnutls libacpi newt ruby
2 2 1 1 8 1 1 1 1 1 1 1 1 5 1 1 1 1 5 1 1 1 1 1 Year 10 tcltk Year 9 gmp Year 8 avahi busybox cronie gdb gdbm python xorg-app xorg-lib 2920-3284 dropbear gnu-efi pam tcltk tcp-wrappers1 Year 7 apmd at bash libacpi swig
2 2 1 1 3 1 1 1 7 1 1 1 1 1 1 1 6 1 1 1 1 1 1 Year 11 tcltk Year 10 gmp Year 9 pam tcltk tcp-wrappers Year 8 avahi busybox cronie gdbm python xorg-app xorg-lib Year 7 apmd at bash gdb libacpi swig
2 2 1 1 2 1 1 7 1 1 1 1 1 1 1 12 2 1 3 1 1 1 2 1 Year 11 tcltk Year 10 gmp Year 9 pam tcltk Year 8 avahi busybox cronie libxml python xorg-app xorg-lib Year 7 at bash glibc libacpi libgpg-error libxml logrotate tcf-agent
Year 10 gmp 1 1 Year 9 pam 1 1 Year 8 avahi cronie tcltk xorg-app xorg-lib 5 1 1 1 1 1 Year 7 at bash busybox libacpi libgpg-error 1 logrotate tcf-agent 9 2 1 1 1 2 1
Year 10 gmp 1 1 Year 9 1 pam Year 8 avahi cronie libaio tcltk xorg-app xorg-lib 6 1 1 1 1 1 1 Year 7 busybox 1 libacpi logrotate 2 tcf-agent 1 5 1 1
Year 10 1 gmp Year 9 1 pam Year 8 avahi cronie ghostscript libaio tcltk xorg-app xorg-lib 7 1 1 1 1 1 1 1 Year 7 libacpi tcf-agent 2 1 1 1 1
Types of Patches For 2023.08.02 1643 Patches 35 with Upstream-Status set 2 with CVE
Times Changed 1400 1315 1200 1000 800 Count 600 400 190 200 63 32 12 10 6 3 3 3 2 2 0 0 2 4 6 8 10 12 14 16 Times Changed
Types of Patches Release 36 17618 patches 13 CVEs 2 Upstream-Status
Things we can commonly fix to track this issue: Adopt to using patches that are generated via `git format-patch` or similar so that we have an actual date to see how old these things are; better yet use git Add an Upstream-Status field (or similar) to know if the patches in question should be upstreamed
Stretch goals: Only allow patches in that have been submitted, perhaps even accepted