Hi! It's been a long long time :-)
On Sun, Dec 01, 2024 at 03:02:52PM +0100, Chris Hofstaedtler wrote: > On Sun, Jul 07, 2024 at 03:17:51PM -0300, Carlos Henrique Lima Melara wrote: > > Hi, > > > > On Sun, Jul 07, 2024 at 09:45:51AM GMT, Johannes Schauer Marin Rodrigues > > wrote: > > > I am not using the schroot backend and when I did in the past, I used it > > > exclusively with tarballs. You seem to be creating directory-based > > > chroots for > > > schroot. This is nothing that I am using in my daily sbuild usage, which > > > probably explains why I'm not running into bugs like these. > > > > > > If you can supply a patch that does the right thing, that'd make me very > > > happy. > > > As I'm not using schroot anymore, my motivation to fix this is low but > > > it'll be > > > put on the TODO list. > > > > I'd love to provide a patch, but I don't speak perl :-( Maybe a simple > > solution is to invoke sbuild-update instead of chrooting since it > > already do the proper setup. Actually I was just Ctrl-C and running > > sbuild-update afterwards. > > So isn't this a bug in gpg then, which shouldn't manually close all > possible FDs? (Instead use the close range function/syscall?) Actually, that might be a suitable solution on GPG's side, at least for the simple case where one wants to close all FDs from 3 to max_fds. They do have an usecase where one can pass an exception list of FDs that shouldn't be closed and here close_range would require more logic to work. The original GPG code is from 2010 [1], using /proc/self/fd to speed up things is from 2016 [2] and close_range was only introduced in Linux in 2019 [3], so it's understandable why they are not using it. I'll file an issue on GPG and see how it goes. Cheers, Charles [1] https://github.com/gpg/gnupg/commit/d1591a97f4ea9705f18185c95775afeb965af68f [2] https://github.com/gpg/gnupg/commit/512c56af43027149e8beacf259746b8d7bf9b1a2 [3] https://lwn.net/Articles/789023/
signature.asc
Description: PGP signature
