Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

2022-11-09 Thread Robie Basak
Thank you for the report. Adding debian-devel@ and the libpam-tmpdir maintainer for wider discussion. On Thu, Nov 10, 2022 at 12:54:34AM +, brian m. carlson wrote: > On my systems, I use libpam-tmpdir, which provides each user with a > private temporary directory owned and accessible only by

Bug#1022994: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

2022-11-13 Thread Robie Basak
On Sun, Nov 13, 2022 at 04:16:29PM +0100, Marco d'Itri wrote: > And I think that it would be wrong to have dpkg generally unset $TMPDIR, > because if root sets it then it would be reasonable to expect that also > dpkg and the maintainer scripts use it (as long as they are not dropping >

Bug#1022994: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

2022-11-13 Thread Robie Basak
On Sun, Nov 13, 2022 at 02:58:47PM +, Simon McVittie wrote: > If the maintainer script is *dropping* privileges from root down to a > system user, then I think the maintainer script is/should be responsible > for doing that privilege drop in a way that works... Agreed, but amongst various

Bug#1022994: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

2022-11-13 Thread Robie Basak
On Sun, Nov 13, 2022 at 05:46:00PM +0100, Marco d'Itri wrote: > On Nov 13, Robie Basak wrote: > > > This seems inconsistent to me. Where is the expectation that TMPDIR must > > be unset if dropping privileges coming from? Obviously for users of > Where is the expectation tha

Bug#1024016: mysql-8.0: CVE-2022-39400 CVE-2022-39402 CVE-2022-39403 CVE-2022-39408 CVE-2022-39410 CVE-2022-21594 CVE-2022-21599 CVE-2022-21604 CVE-2022-21608 CVE-2022-21611 CVE-2022-21617 CVE-2022-21

2022-11-13 Thread Robie Basak
On Sun, Nov 13, 2022 at 08:31:24PM +0100, Moritz Mühlenhoff wrote: > The following vulnerabilities were published for mysql-8.0. FTR, an update to 8.0.31 to fix these is already prepared and being tested at https://salsa.debian.org/mariadb-team/mysql/-/merge_requests/65 signature.asc

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

2022-11-13 Thread Robie Basak
On Thu, Nov 10, 2022 at 05:37:53PM +0100, Tollef Fog Heen wrote: > I think it's more wide than that: If you change UID, you need to > sanitise the environment. Your HOME is likely to be wrong. PATH might > very well be pointing at directories which are not appropriate for the > user you're

Bug#1022994: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

2022-11-13 Thread Robie Basak
On Sun, Nov 13, 2022 at 02:21:58AM +0100, Marco d'Itri wrote: > On Nov 12, Otto Kekäläinen wrote: > > > Instead of manually trying to manage TMPDIR env variable in various > > places, we should have a standardized way to run maintainer scripts in > > clean shell sessions that have all env

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

2022-11-13 Thread Robie Basak
On Thu, Nov 10, 2022 at 12:08:55PM +0100, Marco d'Itri wrote: > > But are you in essence saying that libpam-tmpdir requires that *every > > maintainer script* that runs things as non-root, or starts processes > > that do that, unset TMPDIR first? > This would not be right, because it is totally

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

2022-11-13 Thread Robie Basak
On Thu, Nov 10, 2022 at 10:46:55PM +, brian m. carlson wrote: > > I think it's more wide than that: If you change UID, you need to > > sanitise the environment. Your HOME is likely to be wrong. PATH might > > very well be pointing at directories which are not appropriate for the > > user

Bug#1033606: Add dep8 tests for mosh

2023-03-28 Thread Robie Basak
+ + [ Sergio Durigan Junior ] + * d/t/upstream-tests: New dep8 test which runs the upstream test +suite against a system mosh. + + [ Robie Basak ] + * d/t/smoke: smoke test for mosh using pexpect. + + -- Robie Basak Wed, 22 Mar 2023 13:36:00 + + mosh (1.4.0-1build1) lunar; urgency=medium

Bug#1030487: python-trustme: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

2023-02-05 Thread Robie Basak
clone 1030487 -1 reassign -1 python3-service-identity 18.1.0-7 retitle -1 Missing dependency on python3-six makes package unusable thanks On Sat, Feb 04, 2023 at 08:58:30AM +0100, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. [...] > >

Bug#1037016: mk-build-deps fails if the package version is 0

2023-06-01 Thread Robie Basak
to reproduce: # mkdir debian # cat > debian/changelog test (0) UNRELEASED; urgency=medium * Test mk-build-deps -- Robie Basak Thu, 01 Jun 2023 16:03:13 + # cat > debian/control Source: test Build-Depends: hello # mk-build-deps -i -r dpkg-buildpackage: info: source package test-build-dep

Bug#1061410: python3-trio: AttributeError: module 'eventlet.green.select' has no attribute 'epoll'

2024-01-24 Thread Robie Basak
severity 1061410 wishlist thanks This doesn't seem like a bug in python-trio to me. It's simply using select.epoll(). If that's being monkey patched by gevent in a way that breaks things then that seems like either a gevent problem or a fundamental incompatibility in trying to use Trio at the

<    1   2   3   4