Portage doesn't preserve libffi.so.7 in some cases when upgrading dev-libs/libffi-3.3-r2 (0/7) -> dev-libs/libffi-3.4.2 (0/8). I've seen reports of this sporadically but until now, it's been from users who have then immediately "fixed" the problem and have no backups to roll back to a pre-broken state in [0]. Fortunately, I've now got access to a case where we can reproduce it reliably thanks to some backups and well-timed snapshots. In this case, FEATURES="preserved-libs" is definitely enabled which helps matters too (it's not always been clear in other reports). This would be a valid bug anyway, but it's especially problematic given dev-lang/python depends on libffi and this causes both emerge and revdep-rebuild to be broken: ``` # emerge --info python Traceback (most recent call last): File "/usr/lib/python-exec/python3.8/emerge", line 46, in <module> from _emerge.main import emerge_main File "/usr/lib/python3.8/site-packages/_emerge/main.py", line 21, in <module> from portage.sync import _SUBMODULE_PATH_MAP File "/usr/lib/python3.8/site-packages/portage/sync/__init__.py", line 9, in <module> from portage.sync.controller import SyncManager File "/usr/lib/python3.8/site-packages/portage/sync/controller.py", line 21, in <module> from portage.package.ebuild.doebuild import _check_temp_dir File "/usr/lib/python3.8/site-packages/portage/package/ebuild/doebuild.py", line 81, in <module> from portage.util.compression_probe import _compressors File "/usr/lib/python3.8/site-packages/portage/util/compression_probe.py", line 4, in <module> import ctypes File "/usr/lib/python3.8/ctypes/__init__.py", line 7, in <module> from _ctypes import Union, Structure, Array ImportError: libffi.so.7: cannot open shared object file: No such file or directory ``` Findings so far: - The VDB is intact before and after the failure-to-preserve: ``` /var/db/pkg # egrep libffi */*/NEEDED.ELF.2 dev-lang/python-3.8.10/NEEDED.ELF.2:X86_64;/usr/lib/python3.8/lib-dynload/_ctypes.cpython-38-x86_64-linux-gnu.so;_ctypes.cpython-38-x86_64-linux-gnu.so;;libffi.so.7,libdl.so.2,libpthread.so.0,libc.so.6;x86_64 dev-libs/glib-2.68.1/NEEDED.ELF.2:X86_64;/usr/lib64/libgobject-2.0.so.0.6800.1;libgobject-2.0.so.0;;libglib-2.0.so.0,libffi.so.7,libc.so.6;x86_64 dev-libs/glib-2.68.1/NEEDED.ELF.2:386;/usr/lib/libgobject-2.0.so.0.6800.1;libgobject-2.0.so.0;;libglib-2.0.so.0,libffi.so.7,libc.so.6;x86_32 dev-libs/libffi-3.4.2/NEEDED.ELF.2:X86_64;/usr/lib64/libffi.so.8.1.0;libffi.so.8;;libc.so.6;x86_64 dev-libs/libffi-3.4.2/NEEDED.ELF.2:386;/usr/lib/libffi.so.8.1.0;libffi.so.8;;libc.so.6;x86_32 dev-libs/libffi-3.4.2/NEEDED.ELF.2:X86_64;/usr/lib/debug/usr/lib64/libffi.so.8.1.0.debug;libffi.so.8.1.0.debug;;;x86_64 dev-libs/libffi-3.4.2/NEEDED.ELF.2:386;/usr/lib/debug/usr/lib/libffi.so.8.1.0.debug;libffi.so.8.1.0.debug;;;x86_32 dev-python/cffi-1.14.5/NEEDED.ELF.2:X86_64;/usr/lib/python3.8/site-packages/_cffi_backend.cpython-38-x86_64-linux-gnu.so;_cffi_backend.cpython-38-x86_64-linux-gnu.so;;libffi.so.7,libc.so.6,ld-linux-x86-64.so.2;x86_64 ``` (I'd previously speculated it was related to e.g. glibc upgrade and pax-utils being unable to correctly populate NEEDED and it being in a corrupted state) - preserve-libs is working for other packages during this time, as libcrypt is preserved when going through the libxcrypt migration. [0] https://marc.info/?l=gentoo-user&m=162943441928898&w=4
Created attachment 737203 [details] libffi-3.4.2-build.log
(In reply to Sam James from comment #1) > Created attachment 737203 [details] > libffi-3.4.2-build.log We can see that Portage unmerges and doesn't think .so.7 is needed: >--- replaced obj /usr/lib64/libffi/include/ffitarget.h >--- replaced obj /usr/lib64/libffi/include/ffi.h >--- replaced dir /usr/lib64/libffi/include ><<< obj /usr/lib64/libffi.so.7.1.0 ><<< sym /usr/lib64/libffi.so.7 >--- replaced sym /usr/lib64/libffi.so >--- replaced dir /usr/lib64/libffi The expected (and normal) output is something like: >--- replaced obj /usr/lib64/libffi/include/ffitarget.h >--- replaced obj /usr/lib64/libffi/include/ffi.h >--- replaced dir /usr/lib64/libffi/include >>>> needed sym /usr/lib64/libffi.so.7 >>>> needed obj /usr/lib64/libffi.so.7.1.0 >--- replaced sym /usr/lib64/libffi.so >--- replaced dir /usr/lib64/libffi
[Blocking libxcrypt migration because I'm not comfortable proceeding with unleashing it onto stable users until we've figured out whatever issue is going on with preserve-libs.] Additional notes: - Using a stage3 from 2021-05-02 [0] and a Portage snapshot from the same day [1] (emulating the state of the original box which hit this) wasn't enough to reproduce. The original box was ~arch so I upgraded to that too (using the same tree snapshot). - Using a set of binpkgs from the broken box on top of ^^ does reproduce it, but no idea which trigger it yet. [0] https://mirror.reenigne.net/gentoo-snapshots/2021-05-20-0600/releases/amd64/autobuilds/20210502T214503Z/hardened/stage3-amd64-hardened-20210502T214503Z.tar.xz [1] https://mirror.reenigne.net/gentoo-snapshots/2021-05-02-0600/snapshots/gentoo-20210501.tar.xz
With a ridiculous number of print()s, I've at least identified where things go wrong (but it's kind of obvious, I guess) [0]: >objs = set([obj]) >obj_key = self._obj_key(obj) >if obj_key not in self._obj_properties: > raise KeyError("%s (%s) not in object list" % >(obj_key, obj)) Currently trying to understand the _ObjectKey [1] and self._obj_properties structures (although I'm not really getting the later yet). Note that I mentioned in #gentoo-toolchain previously that this wasn't reproducible with a standalone emerge -v1O libffi, but it is (at least now). I've currently got a snapshot of the chroot which I can revert back to before upgrading libffi, upgrade libffi, then it breaks. Further avenues that could be taken: - Obviously try to figure out why self.obj_properties doesn't end up containing libffi.so.7 or w/e. - Try with/without each binpkg from the contaminated/broken host; - See if this still occurs after rebuilding world (twice? to avoid contamination). Note that bug 521968 touches the same exception but it's probably not relevant? Bit stuck for now. [0] https://github.com/gentoo/portage/blob/5ec443ed7dab583f3c654ee81fff563cbda5a9d4/lib/portage/util/_dyn_libs/LinkageMapELF.py#L857 [1] https://github.com/gentoo/portage/blob/5ec443ed7dab583f3c654ee81fff563cbda5a9d4/lib/portage/util/_dyn_libs/LinkageMapELF.py#L104
1. check if you have any bundled copy of libffi on your system, i.e.: find / -name 'libffi.so*' 2. grep vardb for libffi: grep -R libffi.so /var/db/pkg Not saying you should paste the latter, just analyze its output for libffi.so.7 vs libffi.so.8.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e9860542af9f167452bb551237115e2100d87c7b commit e9860542af9f167452bb551237115e2100d87c7b Author: Sam James <sam@gentoo.org> AuthorDate: 2021-09-05 05:32:14 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-09-05 05:47:48 +0000 app-misc/pax-utils: add note to adjust glibc ebuild on bumps If we're bumping pax-utils to add new syscalls/reflect changing syscalls used by glibc, we need to make sure to update the glibc ebuild too to ensure the right version is used and avoid possible VDB corruption (e.g. when Portage calls scanelf). Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James <sam@gentoo.org> app-misc/pax-utils/pax-utils-1.3.3.ebuild | 3 +++ 1 file changed, 3 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dc67add1a5356531eaaec698807661461abc27e4 commit dc67add1a5356531eaaec698807661461abc27e4 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-09-05 05:28:55 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-09-05 05:47:47 +0000 sys-libs/glibc: add comment on bumping pax-utils bound It's important that we remember to do this when bumping glibc releases. Added a comment as a reminder and used a variable so that both uses are consistent within *DEPEND. Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/glibc/glibc-2.34.ebuild | 7 +++++-- sys-libs/glibc/glibc-9999.ebuild | 11 +++++++---- 2 files changed, 12 insertions(+), 6 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1ee6e5850273f238a83f71426d60f08c48d32659 commit 1ee6e5850273f238a83f71426d60f08c48d32659 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-09-08 23:47:24 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-09-08 23:48:07 +0000 sys-libs/glibc: add comment referencing wiki page .. to refer to a list of things to do when bumping glibc. Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/glibc/glibc-2.34.ebuild | 3 +++ sys-libs/glibc/glibc-9999.ebuild | 3 +++ 2 files changed, 6 insertions(+)
Fairly sure at this point that it's caused by scanelf corrupting the VDB. Working on Portage patches now. Also looking at somewhat of a recovery tool to detect (and correct?) such situations if you're already a victim. (In reply to Sam James from comment #0) > [...] > (I'd previously speculated it was related to e.g. glibc upgrade and > pax-utils being unable to correctly populate NEEDED and it being in a > corrupted state) > Lesson learned: double check the data. emerge.log from a few victim boxes showed the timeline matches (glibc, (many packages), pax-utils). Packages in-between have a corrupt VDB.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e90110a0a63cb9177bb529d61b3a70f9797b82d6 commit e90110a0a63cb9177bb529d61b3a70f9797b82d6 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-09-08 21:55:12 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-09-12 23:19:01 +0000 dev-libs/libffi: use preserve-libs.eclass 1. Revision bump to re-install libffi now that glibc definitely has the correct version bounds on pax-utils. See linked bug for more information. This is unrelated to the preserve-libs eclass change, but we figured we should do this just as a nudge to help people in a "damaged" situation (see bug). 2. Use preserved-libs.eclass because SONAME of libffi changed from 7 -> 8. FEATURES="preserved-libs" (distinct from the eclass) is not required to be used (even if encouraged) and is not part of PMS, so alternative package managers to Portage don't have to implement it. Use the eclass to perserve libffi.so.7 to keep dev-lang/python working. Runtime failures will occur without Python being rebuilt in time. (Unfortunately, the same is true for the rewritten-in-Python revdep-rebuild, so revdep-rebuild.sh may help folks who are already bitten by this.) Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James <sam@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/22247 Signed-off-by: Sam James <sam@gentoo.org> .../{libffi-3.4.2.ebuild => libffi-3.4.2-r1.ebuild} | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=987fa4cca49b3a230588fb785b606a6b0bb99ab6 commit 987fa4cca49b3a230588fb785b606a6b0bb99ab6 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-09-20 21:10:34 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-09-20 21:11:10 +0000 app-portage/recover-broken-vdb: initial import Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James <sam@gentoo.org> app-portage/recover-broken-vdb/metadata.xml | 17 ++++++++++++++ .../recover-broken-vdb-9999.ebuild | 27 ++++++++++++++++++++++ 2 files changed, 44 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=83af7270fafbd7b1eed0031a5e06836ad1edf06d commit 83af7270fafbd7b1eed0031a5e06836ad1edf06d Author: Sam James <sam@gentoo.org> AuthorDate: 2021-09-21 00:56:36 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-09-21 17:27:39 +0000 bin/misc-function.sh: check scanelf return code This is part of a series of fixes for the linked bug (failure to preserve libraries in some situations). We need to check if scanelf failed when calling it in the installed-files QA check as we later use it to populate the VDB. Silently continuing results in either blank e.g. PROVIDES, NEEDED{,.ELF.2} or those files may be missing entirely, resulting in a corrupt state both on the system and in any generated binpkgs. Adds an escape variable (PORTAGE_NO_SCANELF_CHECK) to allow re-emerging pax-utils if it's broken. Bug: https://bugs.gentoo.org/811462 See: https://github.com/gentoo/portage/pull/744 Closes: https://github.com/gentoo/portage/pull/750 Signed-off-by: Sam James <sam@gentoo.org> bin/misc-functions.sh | 64 ++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 50 insertions(+), 14 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=1a196bdef62565e377e90807b8b324547e7d4814 commit 1a196bdef62565e377e90807b8b324547e7d4814 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-09-20 21:13:21 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-09-29 14:32:18 +0000 2021-09-24-possible-failure-to-preserve-libraries: add item Bug: https://bugs.gentoo.org/811462 Signed-off-by: Hank Leininger <hlein@korelogic.com> Signed-off-by: Sam James <sam@gentoo.org> ...9-possible-failure-to-preserve-libraries.en.txt | 101 +++++++++++++++++++++ 1 file changed, 101 insertions(+)
I tried to follow the guide, and `recover-broken-vdb` produces empty directory in /tmp, so I'm not sure how to proceed. The output of recover-broken-vdb-find-broken.sh | tee broken_vdb_packages was this line: =app-text/qpdfview-0.4.18
(In reply to Gleb from comment #13) > I tried to follow the guide, and `recover-broken-vdb` produces empty > directory in /tmp, so I'm not sure how to proceed. > > The output of recover-broken-vdb-find-broken.sh | tee broken_vdb_packages > was this line: > =app-text/qpdfview-0.4.18 What version of recover-broken-vdb? Not very familiar with its issues yet but seen someone have a similar-sounding problem with 0.0.5 and upgrading to 0.0.7 fixed it.
(In reply to Ionen Wolkens from comment #14) > What version of recover-broken-vdb? Not very familiar with its issues yet > but seen someone have a similar-sounding problem with 0.0.5 and upgrading to > 0.0.7 fixed it. It was 0.0.5, I updated it to 0.0.7 and now this first command produces no output at all. $ recover-broken-vdb-find-broken.sh | tee broken_vdb_packages So I suppose there's nothing to fix?
(In reply to Gleb from comment #15) > It was 0.0.5, I updated it to 0.0.7 and now this first command produces no > output at all. > $ recover-broken-vdb-find-broken.sh | tee broken_vdb_packages > > So I suppose there's nothing to fix? I assume there was still the "Checking installed..." status message, but yes. Can forget this tool and carry on with your non-broken Gentoo.
*** Bug 815874 has been marked as a duplicate of this bug. ***
a patch for the issue: --- preserve-libs.eclass.bk 2021-10-03 14:58:14.990000000 +0800 +++ preserve-libs.eclass 2021-10-03 18:38:14.580000000 +0800 @@ -32,7 +32,7 @@ [[ -z $1 ]] && die "Usage: preserve_old_lib <library to preserve> [more libraries to preserve]" # let portage worry about it - has preserve-libs ${FEATURES} && return 0 + has preserve-libs ${FEATURES} || return 0 has "${EAPI:-0}" 0 1 2 && local ED=${D} EROOT=${ROOT}
(In reply to fkhp from comment #18) > a patch for the issue: > > --- preserve-libs.eclass.bk 2021-10-03 14:58:14.990000000 +0800 > +++ preserve-libs.eclass 2021-10-03 18:38:14.580000000 +0800 > @@ -32,7 +32,7 @@ > [[ -z $1 ]] && die "Usage: preserve_old_lib <library to preserve> [more > libraries to preserve]" > > # let portage worry about it > - has preserve-libs ${FEATURES} && return 0 > + has preserve-libs ${FEATURES} || return 0 > > has "${EAPI:-0}" 0 1 2 && local ED=${D} EROOT=${ROOT} this patch has been tested for the glibc upgrade from stage 3, and works.
(In reply to fkhp from comment #18) > a patch for the issue: > > --- preserve-libs.eclass.bk 2021-10-03 14:58:14.990000000 +0800 > +++ preserve-libs.eclass 2021-10-03 18:38:14.580000000 +0800 > @@ -32,7 +32,7 @@ > [[ -z $1 ]] && die "Usage: preserve_old_lib <library to preserve> [more > libraries to preserve]" > > # let portage worry about it > - has preserve-libs ${FEATURES} && return 0 > + has preserve-libs ${FEATURES} || return 0 > > has "${EAPI:-0}" 0 1 2 && local ED=${D} EROOT=${ROOT} this patch has been tested for the libffi upgrade from latest stage 3, and works.
Created attachment 742752 [details] the critical part of the build.log with --debug after patch for preserve_libs.eclass applied
Created attachment 742797 [details, diff] the patch
(In reply to fkhp from comment #18) > a patch for the issue: > > --- preserve-libs.eclass.bk 2021-10-03 14:58:14.990000000 +0800 > +++ preserve-libs.eclass 2021-10-03 18:38:14.580000000 +0800 > @@ -32,7 +32,7 @@ > [[ -z $1 ]] && die "Usage: preserve_old_lib <library to preserve> [more > libraries to preserve]" > > # let portage worry about it > - has preserve-libs ${FEATURES} && return 0 > + has preserve-libs ${FEATURES} || return 0 > > has "${EAPI:-0}" 0 1 2 && local ED=${D} EROOT=${ROOT} I think you may have misunderstood. preserve-libs.eclass has no business doing anything when FEATURES="preserve-libs" is enabled, it's a stop-gap for systems *without* it to avoid critical libraries being removed. Your issue as I explained is more nuanced and related to scanelf failing.
Following the procedure in 2021-09-29-possible-failure-to-preserve-libraries, I believe that the step $ emerge --ask --verbose --oneshot --usepkg=n $(cat broken_vdb_packages) should be $ emerge --ask --verbose --oneshot --usepkg=n $(grep -v '#' broken_vdb_packages) considering that the broken_vdb_packages file contains a comment in the beginning: $ recover-broken-vdb-find-broken.sh | tee broken_vdb_packages # Checking installed packages for inconsistent VDB... =app-admin/gnome-system-log-3.9.90 ...
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=b799e9ed123d65d007fa6496e8b5c5ee4073efbd commit b799e9ed123d65d007fa6496e8b5c5ee4073efbd Author: Sam James <sam@gentoo.org> AuthorDate: 2021-10-06 01:34:00 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-10-06 01:34:00 +0000 2021-09-29-possible-failure-to-preserve-libraries: fix command for comment Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James <sam@gentoo.org> .../2021-09-29-possible-failure-to-preserve-libraries.en.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=216e962ae494e8291b667665007d045788b3e391 commit 216e962ae494e8291b667665007d045788b3e391 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-10-28 04:40:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-10-28 04:52:32 +0000 Binpkg.py: check for inconsistent PROVIDES/image when unpacking binpkg This is part of a series of fixes for the linked bug (failure to preserve libraries in some situations). When unpacking a binpkg to be installed, we should check for the existence of PROVIDES if we're installing any dynamic libraries. If PROVIDES does not exist in that case, this suggests that e.g. scanelf malfunctioned or some corruption occurred. Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James <sam@gentoo.org> lib/_emerge/Binpkg.py | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) https://gitweb.gentoo.org/proj/portage.git/commit/?id=98a8a4af2c77477c327b22621b8a0aed6d15f574 commit 98a8a4af2c77477c327b22621b8a0aed6d15f574 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-10-28 04:40:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-10-28 04:52:22 +0000 doebuild.py: check for inconsistent PROVIDES/image post-src_install This is part of a series of fixes for the linked bug (failure to preserve libraries in some situations). At the point of installation (even if not merging), we need to detect inconsistent metadata: PROVIDES should be populated if we're installing any dynamic libraries. This suggests that e.g. scanelf malfunctioned or some corruption occurred. Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James <sam@gentoo.org> lib/portage/package/ebuild/doebuild.py | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) https://gitweb.gentoo.org/proj/portage.git/commit/?id=cba2156dba89a22f2858238013469b4d80208854 commit cba2156dba89a22f2858238013469b4d80208854 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-10-28 04:40:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-10-28 04:52:18 +0000 portage/util/_dyn_libs/dyn_libs.py: add helper Needed for binpkg/image verification commits coming... Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James <sam@gentoo.org> lib/portage/util/_dyn_libs/dyn_libs.py | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)
I guess we've done enough here so the libxcrypt transition can go stable. Not blocking anymore.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=ef0cfc2c0e68299ddfa355732c76cf7d9ed83fcb commit ef0cfc2c0e68299ddfa355732c76cf7d9ed83fcb Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-22 06:30:45 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-22 06:31:58 +0000 2021-09-29-possible-failure-to-preserve-libraries: mention when it's ok to skip -e It should be okay to skip -e @world and instead only rebuild libraries + their consumers in some cases. Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James <sam@gentoo.org> .../2021-09-29-possible-failure-to-preserve-libraries.en.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=c36f878509108c970907dc391d6562297881b400 commit c36f878509108c970907dc391d6562297881b400 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-12-11 02:47:50 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-12-11 02:54:00 +0000 lib/portage/package/ebuild/doebuild.py: use 'eerror' for blank PROVIDES message This means that it's much harder to miss the error. Bug: https://bugs.gentoo.org/811462 Reported-by: Brian Dolbec <dolsen@gentoo.org> Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> Signed-off-by: Sam James <sam@gentoo.org> lib/portage/package/ebuild/doebuild.py | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=36d5f8de514f2b0ff95ccaf75c60e87441f8c009 commit 36d5f8de514f2b0ff95ccaf75c60e87441f8c009 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-12-14 05:26:05 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-12-14 05:26:05 +0000 profiles: add pax-utils to info_pkgs Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James <sam@gentoo.org> profiles/info_pkgs | 1 + 1 file changed, 1 insertion(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b33da36a7d896d504132b20b4ef0232fbd0b880f commit b33da36a7d896d504132b20b4ef0232fbd0b880f Author: Sam James <sam@gentoo.org> AuthorDate: 2022-01-04 12:17:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-01-04 12:18:04 +0000 sys-apps/portage: add file PDEPEND (partly for seccomp) We use it in QA checks / postinst bits for NEEDED and such for a start, but we also need a minimum good version to avoid "bad system call" errors with e.g. newer glibc. Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/portage-3.0.18.ebuild | 1 + sys-apps/portage/portage-3.0.20-r6.ebuild | 1 + sys-apps/portage/portage-3.0.28-r1.ebuild | 1 + sys-apps/portage/portage-3.0.29.ebuild | 1 + sys-apps/portage/portage-3.0.30-r1.ebuild | 1 + sys-apps/portage/portage-9999.ebuild | 1 + 6 files changed, 6 insertions(+)
We should be able to close this now.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=0f4f85ee3c19ff3acbcf724bf49a52db0766c7a5 commit 0f4f85ee3c19ff3acbcf724bf49a52db0766c7a5 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-12-31 14:40:47 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-12-31 14:45:35 +0000 bin: pass -S to file to disable seccomp Files being installed by Portage are generally trusted but also the syscalls allowed by file are quite broad anyway. Things can go catastrophically wrong if file misses valid input, as we may have invalid VDB metadata. Bug: https://bugs.gentoo.org/811462 Bug: https://bugs.gentoo.org/815877 Bug: https://bugs.gentoo.org/889046 Signed-off-by: Sam James <sam@gentoo.org> NEWS | 16 +++++++++++++--- bin/estrip | 2 +- bin/install-qa-check.d/10ignored-flags | 2 +- bin/misc-functions.sh | 2 +- 4 files changed, 16 insertions(+), 6 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c5d40af3c56436cdbf774707cb36a8cdc832b3dd commit c5d40af3c56436cdbf774707cb36a8cdc832b3dd Author: Sam James <sam@gentoo.org> AuthorDate: 2023-01-03 04:02:24 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-01-05 00:33:06 +0000 unpacker.eclass: pass -S to file to disable seccomp Files being installed by Portage are generally trusted but also the syscalls allowed by file are quite broad anyway. With e.g. new libc or sandbox version (or any number of things...), the syscalls used by file can change which leads to its seccomp filter killing the process. This is an acceptable tradeoff when users are calling file(1), but it makes less sense with trusted input within Portage, especially where it may lead to confusing errors (swallowed within pipes, subshells, etc). Indeed, it might even be the case that file(1) is broken, but the user needs to complete a world upgrade to get a newer file/portage/???, but can't because of various ebuilds (like ones using this eclass) failing. Disable seccomp for these calls to keep working. Bug: https://bugs.gentoo.org/811462 Bug: https://bugs.gentoo.org/815877 Bug: https://bugs.gentoo.org/889046 Signed-off-by: Sam James <sam@gentoo.org> eclass/unpacker.eclass | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=592c4558b9be2f82969ceec835240ebec23ac932 commit 592c4558b9be2f82969ceec835240ebec23ac932 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-01-03 04:02:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-01-05 00:33:06 +0000 mono.eclass: pass -S to file to disable seccomp Files being installed by Portage are generally trusted but also the syscalls allowed by file are quite broad anyway. With e.g. new libc or sandbox version (or any number of things...), the syscalls used by file can change which leads to its seccomp filter killing the process. This is an acceptable tradeoff when users are calling file(1), but it makes less sense with trusted input within Portage, especially where it may lead to confusing errors (swallowed within pipes, subshells, etc). Indeed, it might even be the case that file(1) is broken, but the user needs to complete a world upgrade to get a newer file/portage/???, but can't because of various ebuilds (like ones using this eclass) failing. Disable seccomp for these calls to keep working. Bug: https://bugs.gentoo.org/811462 Bug: https://bugs.gentoo.org/815877 Bug: https://bugs.gentoo.org/889046 Signed-off-by: Sam James <sam@gentoo.org> eclass/mono.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4a52eaeab3ca96b55c45d774dac60d004db8bb39 commit 4a52eaeab3ca96b55c45d774dac60d004db8bb39 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-01-03 03:59:53 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-01-05 00:33:06 +0000 dotnet.eclass: pass -S to file to disable seccomp Files being installed by Portage are generally trusted but also the syscalls allowed by file are quite broad anyway. With e.g. new libc or sandbox version (or any number of things...), the syscalls used by file can change which leads to its seccomp filter killing the process. This is an acceptable tradeoff when users are calling file(1), but it makes less sense with trusted input within Portage, especially where it may lead to confusing errors (swallowed within pipes, subshells, etc). Indeed, it might even be the case that file(1) is broken, but the user needs to complete a world upgrade to get a newer file/portage/???, but can't because of various ebuilds (like ones using this eclass) failing. Disable seccomp for these calls to keep working. Bug: https://bugs.gentoo.org/811462 Bug: https://bugs.gentoo.org/815877 Bug: https://bugs.gentoo.org/889046 Signed-off-by: Sam James <sam@gentoo.org> eclass/dotnet.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
