On Thu, Jun 01, 2006 at 02:55:31PM -0700, Steve Langasek wrote: > unmerge 367058 > reopen 367058 > reassign 367058 gnupg-agent > severity 367058 grave > thanks
Thanks for doing this. > On Thu, Jun 01, 2006 at 10:50:08PM +0200, Adeodato Sim? wrote: > > severity 367058 wishlist > > reassign 367058 x11-common 6.8.2.dfsg.1-7 > > close 367058 1:7.0.19 > > merge 367058 331553 > > thanks > > > * Robin Haunschild [Sat, 13 May 2006 11:03:48 +0200]: > > > > Package: gnupg > > > Version: 1.4.3-1 > > > Severity: critical > > > Tags: security > > > Justification: breaks unrelated software > > > Hello Robin, > > > > An exsiting file ~/.gnupg/gpg-agent.conf that is syntactically wrong > > > disables the window manager from starting. The display manager and x.org > > > are still running. Even > > > $ startx /usr/bin/startfluxbox -- :1 > > > does not start a working Fluxbox. > > > This happened because the exit status of /etc/X11/Xsession.d/90gpg-agent > > was non-zero, and the script was executed from /etc/X11/Xsession, which > > runs with set -e, thus aborting the X11 startup process. > > > Some months ago, developer Eduard Bloch submitted a wishlist bug against > > x11-common, the package responsible for /etc/X11/Xsession*, asking that > > external scripts under set +e, so that failures to start like the one > > you experienced. > > > The bug was fixed in version 7.0.19 of x11-common (see #331553), so I'm > > merging your report with Eduard's, and marking it as closed, since the > > X11 startup process does not fail anymore even if an incorrect > > gpg-agent.conf is present. > > Well, I don't agree that the change to x11-common was a correct fix; we have > every reason to demand the same high quality of error handling for Xsession > scripts as we do for other scripts in Debian, which is undermined by this > casual use of set +e as a workaround. Isn't it reasonable to expect that I > may *want* a failed Xsession script to cause the session to abort? You may, but I think you're in the minority. I don't think a user who installs some rogue package with a broken script deserves to have the ability to log in to X ripped out from under them. It's the maintainer's job to ensure that the script works, and the user shouldn't have to suffer unnecessarily for mistakes. While I'm all for forcing devices to ensure quality, bringing down all of X because gpg-agent doesn't start is pretty extreme. > Either way, there is still a bug in gnupg-agent here; at most, the > x11-common workaround affects the severity of the gnupg-agent bug, but it's > still a gnupg-agent bug. And it's still a bug that would manifest when > installing gnupg-agent on a sarge system (partial upgrades), so it should > still be fixed. Indeed. If the change that I made is causing maintainers to divest themselves of responsibility for their packages, then I'll revert it, no questions. The goal is to protect users, not maintainers. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
