Package: sudo Version: 1.8.2-1 Severity: normal The latest version closes Bug#85123 and Bug#85917. However the resulting change in behavior of secure_path is significant and needs a NEWS entry. Most users with sudo installed will have a modified /etc/sudoers file and will need to manually merge a secure_path entry into the file. If not then it will break anyone who already has a customized /etc/sudoers file, fails to notice this change, and doesn't merge in the new package maintainer's version when upgrading, and does not include sbin paths in their user PATH. At that point they will have two problems.
1. If their user path did not include the /usr/sbin:/sbin directories then the sudo path won't either and commands such as apt will fail to find their utilities. For example the following errors to make this found by search engines: dpkg: warning: 'ldconfig' not found in PATH or not executable. dpkg: warning: 'start-stop-daemon' not found in PATH or not executable. dpkg: error: 2 expected programs not found in PATH or not executable. Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin. 2. If the user path is insecure then they will now have an insecure root path. Arguably this is under their control. But the change should be more visible than it is now. Let me suggest the following NEWS entry, or something similar: sudo (1.8.2-1) unstable; urgency=low The default setting for secure_path has been changed. The new setting is off by default. Previously it was not possible to unset secure_path and the compiled in value was used by default. It was only possible to change the value of it. See Bug#85123 and Bug#85917. Now if the administrator desires to have it unset they need only to avoid setting it. To preserve the previous behavior in new installs a new setting of secure_path with a default path has been added to /etc/sudoers. But that only handles new installations. If you have a customized conffile, most do, and you wish to preserve the previous behavior, most will, then action is needed on your part. You will need to merge entries of these files to include a secure_path setting into your /etc/sudoers file. Alternatively the sudo package could include a new conffile file in the package /etc/sudoers.d/00-secure_path or some such that includes the new secure_path setting. Being a new file it would be installed by default without dialog and become available. Being a conffile if an admin desired it to not be set then they could edit that file and unset it. I don't like the proliferation of packaged conffiles in that directory but that might be a solution. But in that case a new NEWS entry would be needed. :-) Bob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org