[gentoo-dev] [PATCH] 2021-09-24-possible-failure-to-preserve-libraries: add item
Bug: https://bugs.gentoo.org/811462 Signed-off-by: Hank Leininger Signed-off-by: Sam James --- ...sible-failure-to-preserve-libraries.en.txt | 103 ++ 1 file changed, 103 insertions(+) create mode 100644 2021-09-24-possible-failure-to-preserve-libraries/2021-09-24-possible-failure-to-preserve-libraries.en.txt diff --git a/2021-09-24-possible-failure-to-preserve-libraries/2021-09-24-possible-failure-to-preserve-libraries.en.txt b/2021-09-24-possible-failure-to-preserve-libraries/2021-09-24-possible-failure-to-preserve-libraries.en.txt new file mode 100644 index 000..4b4758b --- /dev/null +++ b/2021-09-24-possible-failure-to-preserve-libraries/2021-09-24-possible-failure-to-preserve-libraries.en.txt @@ -0,0 +1,103 @@ +Title: Possible failure to preserve libraries +Author: Sam James +Author: Hank Leininger +Posted: 2021-09-24 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/portage + +Possible inconsistency of Portage's internal database (VDB) has been +observed in some cases, usually when glibc has been upgraded to a new +major version, but pax-utils has not yet been upgraded to a version +compatible with it. + +While this largely only affects users of Portage's FEATURES="preserve-libs", +it also affects those who may choose to use it in future given the database +is corrupt even if certain files are not being used for preserving libraries +at present. + +The full technical details and investigation can be found on a Wiki page +[0] and on Bugzilla [1]. Work is underway to prevent this happening +again both within Portage [2] (possibly more to come) and within the +glibc and pax-utils ebuilds [3][4]. + +To detect whether a system is affected, emerge the +app-portage/recover-broken-vdb package: +``` +$ emerge --ask --verbose --oneshot app-portage/recover-broken-vdb +``` +which provides two tools: recover-broken-vdb-find-broken.sh and +recover-broken-vdb. + +Then run recover-broken-vdb-find-broken.sh: +``` +$ recover-broken-vdb-find-broken.sh | tee broken_vdb_packages +``` + +It is recommended that this check be run on all Gentoo systems. + +If you have any output, read on. + +Fixing a broken system is not always straightforward. It is strongly +recommended to take a backup of your full system before proceeding, +as well as a copy of /var/db/pkg (the VDB): + +1. A tool has been developed [5] to attempt to fix the consistency + of the Portage database. Using this tool to modify the VDB is NOT + mandatory (read the full news item before proceeding) - you can skip + to Step 2 if you wish, but fixing the integrity of the VDB + makes it as safe as reasonably possible to proceed with + rebuilding packages. + + Run: + ``` + # Take a backup of /var/db/pkg before proceeding, such as by doing: + $ cp /var/db/pkg /var/db/pkg.orig + + # And then: + $ emerge --ask --verbose --oneshot --noreplace \ + app-portage/recover-broken-vdb + + $ recover-broken-vdb + + # The tool will output to a random temporary directory. + # Inspect the results, and then update the real /var/db/pkg/ + # by doing either: + + $ recover-broken-vdb --output /var/db/pkg + + # Or, manually copying the new files from the temporary directory tree + # into your real /var/db/pkg/ directory tree. + ``` + + If you choose not to use this recovery tool, please re-emerge + the affected packages (next step) and then -e @world, but + there is more risk attached if not all packages can + be rebuilt at their current versions. + +2. Attempt to rebuild the affected packages, first upgrading + app-portage/pax-utils to the latest version: + ``` + $ emerge --ask --verbose --oneshot ">=app-misc/pax-utils-1.3.3" + $ emerge --ask --verbose --oneshot $(cat broken_vdb_packages) + ``` + +Given that there are possible other side-effects of the corruption/bug, +it is strongly recommended that if any corruption is detected, all +packages on the system should be rebuilt, after following the above +steps: +``` +$ emerge --ask --emptytree @world +``` + +Please see the wiki [0] for a full description of the background +of this problem and handling corner cases such as e.g. already +being affected by system breakage [6] as a result of the bug. + +[0] https://wiki.gentoo.org/wiki/Project:Toolchain/Corrupt_VDB_ELF_files +[1] https://bugs.gentoo.org/811462 +[2] https://github.com/gentoo/portage/pull/744 +[3] https://bugs.gentoo.org/811462#c6 +[4] https://bugs.gentoo.org/811462#c7 +[5] https://github.com/thesamesam/recover-broken-vdb +[6] https://wiki.gentoo.org/wiki/Fix_my_Gentoo -- 2.33.0
[gentoo-dev] [PATCH] 2021-09-24-possible-failure-to-preserve-libraries: add item
Bug: https://bugs.gentoo.org/811462 Signed-off-by: Hank Leininger Signed-off-by: Sam James --- ...sible-failure-to-preserve-libraries.en.txt | 98 +++ 1 file changed, 98 insertions(+) create mode 100644 2021-09-24-possible-failure-to-preserve-libraries/2021-09-24-possible-failure-to-preserve-libraries.en.txt diff --git a/2021-09-24-possible-failure-to-preserve-libraries/2021-09-24-possible-failure-to-preserve-libraries.en.txt b/2021-09-24-possible-failure-to-preserve-libraries/2021-09-24-possible-failure-to-preserve-libraries.en.txt new file mode 100644 index 000..00a209d --- /dev/null +++ b/2021-09-24-possible-failure-to-preserve-libraries/2021-09-24-possible-failure-to-preserve-libraries.en.txt @@ -0,0 +1,98 @@ +Title: Possible failure to preserve libraries +Author: Sam James +Author: Hank Leininger +Posted: 2021-09-24 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/portage + +Possible inconsistency of Portage's internal database (VDB) has been +observed in some cases, usually when glibc has been upgraded to a new +major version, but pax-utils has not yet been upgraded to a version +compatible with it. + +The full technical details and investigation can be found on a Wiki page +[0] and on Bugzilla [1]. Work is underway to prevent this happening +again both within Portage [2] (possibly more to come) and within the +glibc and pax-utils ebuilds [3][4]. + +To detect whether a system is affected, emerge the +app-portage/recover-broken-vdb package: +``` +$ emerge --ask --verbose --oneshot app-portage/recover-broken-vdb +``` +which provides two tools: recover-broken-vdb-find-broken.sh and +recover-broken-vdb. + +Then run recover-broken-vdb-find-broken.sh: +``` +$ recover-broken-vdb-find-broken.sh | tee broken_vdb_packages +``` + +It is recommended that this check be run on all Gentoo systems. + +If you have any output, read on. + +Fixing a broken system is not always straightforward. It is strongly +recommended to take a backup of your full system before proceeding, +as well as a copy of /var/db/pkg (the VDB): + +1. A tool has been developed [5] to attempt to fix the consistency + of the Portage database. Using this tool is NOT mandatory + (read the full news item before proceeding) - you can skip + to Step 2 if you wish, but fixing the integrity of the VDB + makes it as safe as reasonably possible to proceed with + rebuilding packages. + + Run: + ``` + # Take a backup of /var/db/pkg before proceeding, such as by doing: + $ cp /var/db/pkg /var/db/pkg.orig + + # And then: + $ emerge --ask --verbose --oneshot --noreplace \ + app-portage/recover-broken-vdb + + $ recover-broken-vdb + + # The tool will output to a random temporary directory. + # Inspect the results, and then update the real /var/db/pkg/ + # by doing either: + + $ recover-broken-vdb --output /var/db/pkg + + # Or, manually copying the new files from the temporary directory tree + # into your real /var/db/pkg/ directory tree. + ``` + + If you choose not to use this recovery tool, please re-emerge + the affected packages (next step) and then -e @world, but + there is more risk attached if not all packages can + be rebuilt at their current versions. + +2. Attempt to rebuild the affected packages, first upgrading + app-portage/pax-utils to the latest version: + ``` + $ emerge --ask --verbose --oneshot ">=app-misc/pax-utils-1.3.3" + $ emerge --ask --verbose --oneshot $(cat broken_vdb_packages) + ``` + +Given that there are possible other side-effects of the corruption/bug, +it is strongly recommended that if any corruption is detected, all +packages on the system should be rebuilt, after following the above +steps: +``` +$ emerge --ask --emptytree @world +``` + +Please see the wiki [0] for a full description of the background +of this problem and handling corner cases such as e.g. already +being affected by system breakage [6] as a result of the bug. + +[0] https://wiki.gentoo.org/wiki/Project:Toolchain/Corrupt_VDB_ELF_files +[1] https://bugs.gentoo.org/811462 +[2] https://github.com/gentoo/portage/pull/744 +[3] https://bugs.gentoo.org/811462#c6 +[4] https://bugs.gentoo.org/811462#c7 +[5] https://github.com/thesamesam/recover-broken-vdb +[6] https://wiki.gentoo.org/wiki/Fix_my_Gentoo -- 2.33.0
Re: [gentoo-dev] Guidance on distributed patented software
On Mon, Sep 20, 2021 at 08:41:21PM +0200, Ulrich Mueller wrote: > > On Mon, 20 Sep 2021, Robin H Johnson wrote: > > > RedHat's legal team clearly know something there that they aren't > > disclosing the details of publicly, because the patches said the > > patents expire in 2020, but when I asked off-list if EC could be > > re-enabled based on the expiry dates in the files, they claimed that > > patent issues were still present, without giving any detail. > > If there are remaining patent issues then they should be able to support > their claim by facts, like a patent number. Why would this be difficult, > or what reason would they have not to disclose it? I don't have any answer from them, but my own research did turn up a few current patents around EC (sorted by expiry): US8462944B2 exp 2021-12-26 US8189772B2 exp 2023-05-28 US9160530B2 exp 2024-10-28 US8213605B2 exp 2025-11-14 US10756893B2 exp 2026-01-23 US10284370B2 exp 2026-03-03 US20100023775A1 exp 2031-08-02 US8631240B2 exp 2031-08-02 US8572367B2 exp 2031-12-25 US8918648B2 exp 2032-01-31 US10079673B2 exp 2032-02-15 ** not specifically EC, more general about Entropy US9800418B2 exp 2035-07-17 IANAL, but the difficult question is: does any open-source end up implementing those algorithms? -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2021-09-20-busybox-removal-from-system: add item
On Mon, Sep 20, 2021 at 2:51 PM Ulrich Mueller wrote: > > > On Mon, 20 Sep 2021, Mike Gilbert wrote: > > > +The sys-apps/busybox package has been removed from @system for Linux > > Maybe "from the system set" or "from the system set (@system)" would > make this even clearer. I updated the paragraph text to "from the system set (@system)", and updated the title to read "system set" instead of "@system".
Re: [gentoo-dev] [PATCH] 2021-09-20-busybox-removal-from-system: add item
> On Mon, 20 Sep 2021, Mike Gilbert wrote: > +The sys-apps/busybox package has been removed from @system for Linux Maybe "from the system set" or "from the system set (@system)" would make this even clearer. signature.asc Description: PGP signature
Re: [gentoo-dev] Guidance on distributed patented software
> On Mon, 20 Sep 2021, Robin H Johnson wrote: > RedHat's legal team clearly know something there that they aren't > disclosing the details of publicly, because the patches said the > patents expire in 2020, but when I asked off-list if EC could be > re-enabled based on the expiry dates in the files, they claimed that > patent issues were still present, without giving any detail. If there are remaining patent issues then they should be able to support their claim by facts, like a patent number. Why would this be difficult, or what reason would they have not to disclose it? > [1] > https://src.fedoraproject.org/rpms/openssl/c/347681c6b246d9b6a08c73bb40e5eefaf8596d71?branch=rawhide > [2] https://www.spinics.net/linux/fedora/fedora-legal/msg03673.html signature.asc Description: PGP signature
[gentoo-dev] Re: Guidance on distributed patented software
> On Mon, 20 Sep 2021, Alec Warner wrote: > The devmanual discusses licensing as a core concept > (https://devmanual.gentoo.org/general-concepts/licenses/index.html) > but does not cover patents. My understanding is that we: > - set RESTRICT=bindist when we are unable to redistribute binaries > (e.g. due to a license or patent restriction.) > - set RESTRICT=mirror when we are unable to redistribute source code > (e.g. due to a license of patent restriction.) IANAL, but IIUC patents only apply to programs that can run on a computer. This is the case for binaries but not for source code. In other words, we don't need mirror restriction for source tarballs because of patents. > - Sometimes, we remove patent encumbered source code from packages > (e.g. with USE=bindist) so that we can build redistributable binaries > with the patented features removed. We do, but normally this doesn't prevent us from distributing the source code. > Could we add some text to the license concepts covering patents? It > seems to have been omitted? > Is my understanding of how we manage patented software correct? signature.asc Description: PGP signature
Re: [gentoo-dev] Guidance on distributed patented software
On Mon, Sep 20, 2021 at 01:27:37PM -0400, Rich Freeman wrote: > On Mon, Sep 20, 2021 at 12:46 PM Alec Warner wrote: > > > > Could we add some text to the license concepts covering patents? It > > seems to have been omitted? > > Is my understanding of how we manage patented software correct? > > I think you have the gist of it. Is there actually anything in the > repo these days which is patent-encumbered? I realize this is a > little tangential, but I think this is probably why we don't have a > well-thought policy: it just doesn't come up much. Elliptic Curve cryptography is the most topical & impactful thing I'm aware of. RedHat have for many years stripped parts of it out of their OpenSSL & libgcrypt packages, and continue to do it with OpenSSL-3 [1] (I note that somebody has dropped these patches from Gentoo's openssl as of v3 and I intend to restore them). RedHat's legal team clearly know something there that they aren't disclosing the details of publicly, because the patches said the patents expire in 2020, but when I asked off-list if EC could be re-enabled based on the expiry dates in the files, they claimed that patent issues were still present, without giving any detail. Somebody else ALSO asked about the Brainpool EC curves specifically and similarly got nowhere [2]. [1] https://src.fedoraproject.org/rpms/openssl/c/347681c6b246d9b6a08c73bb40e5eefaf8596d71?branch=rawhide [2] https://www.spinics.net/linux/fedora/fedora-legal/msg03673.html I feel that generally software patents as an issue for FOSS became less common because of patent grant programs: grants existed to encourage broad adoption of newer ideas from patents. > Things that used to be patent-encumbered that were prevalent in FOSS > in the past include: > 1. The GIF file format. > 2. FAT-based filesystems. > 3. MPEG-related codecs (codecs might be a space where patents are > still relevant). > 4. RSA I have some more fields for patents to add, where I believe active patents DO still exist: 5. Elliptic Curve cryptography 6. "Quantum" cryptography 7. 3D Printing 8. DRM 9. UAVs/Drones (also hits EAR/ITAR) 10. Rocketry (also hits EAR/ITAR) Other past patent stuff touching open source: 11. Model Trains (see JMRI vs Katzer) -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] Guidance on distributed patented software
On Mon, Sep 20, 2021 at 12:46 PM Alec Warner wrote: > > Could we add some text to the license concepts covering patents? It > seems to have been omitted? > Is my understanding of how we manage patented software correct? I think you have the gist of it. Is there actually anything in the repo these days which is patent-encumbered? I realize this is a little tangential, but I think this is probably why we don't have a well-thought policy: it just doesn't come up much. The situation comes up less often since everything is copyrighted by default, but software patents in FOSS are relatively rare. (Partially because they're such a minefield that it discourages even creating FOSS in the first place. Partially because they're such a minefield that people tend to favor non-encumbered algorithms for things that are commonplace now.) Things that used to be patent-encumbered that were prevalent in FOSS in the past include: 1. The GIF file format. 2. FAT-based filesystems. 3. MPEG-related codecs (codecs might be a space where patents are still relevant). 4. RSA I'm sure there are others I'm not thinking of offhand. All of these helped drive adoption of more open standards, which is why we don't run into this stuff as often. Another topic like this are encryption keys like for DVDCSS and so on. Those fall outside both copyright and patent law, but are legally troublesome. Then there are export controls like ITAR/etc - less of an issue today but might still apply to some things. -- Rich
[gentoo-dev] Guidance on distributed patented software
The devmanual discusses licensing as a core concept (https://devmanual.gentoo.org/general-concepts/licenses/index.html) but does not cover patents. My understanding is that we: - set RESTRICT=bindist when we are unable to redistribute binaries (e.g. due to a license or patent restriction.) - set RESTRICT=mirror when we are unable to redistribute source code (e.g. due to a license of patent restriction.) - Sometimes, we remove patent encumbered source code from packages (e.g. with USE=bindist) so that we can build redistributable binaries with the patented features removed. Could we add some text to the license concepts covering patents? It seems to have been omitted? Is my understanding of how we manage patented software correct? -A
[gentoo-dev] [PATCH] 2021-09-20-busybox-removal-from-system: add item
Signed-off-by: Mike Gilbert --- ...1-09-20-busybox-removal-from-system.en.txt | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 2021-09-20-busybox-removal-from-system/2021-09-20-busybox-removal-from-system.en.txt diff --git a/2021-09-20-busybox-removal-from-system/2021-09-20-busybox-removal-from-system.en.txt b/2021-09-20-busybox-removal-from-system/2021-09-20-busybox-removal-from-system.en.txt new file mode 100644 index 000..27917d8 --- /dev/null +++ b/2021-09-20-busybox-removal-from-system/2021-09-20-busybox-removal-from-system.en.txt @@ -0,0 +1,19 @@ +Title: busybox removal from @system +Author: Mike Gilbert +Posted: -mm-dd +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/busybox +Display-If-Profile: default/linux/* + +The sys-apps/busybox package has been removed from @system for Linux +profiles. It was decided that this package is not necessary for a basic +system install. + +If you would like to keep this package installed, please ensure it is +present in your Portage world file. + + emerge --select --noreplace sys-apps/busybox + +As well, the "static" USE flag has been disabled by default. It may be +re-enabled locally via package.use if so desired. -- 2.33.0
