control: severity -1 normal Hi,
On Wed, Mar 09, 2016 at 02:22:04PM +0000, Daniel Shahaf wrote: > Osamu Aoki wrote on Tue, Mar 08, 2016 at 23:08:58 +0900: ... > There are two different issues being discussed in this thread. One of > them is a wishlist item and one of them is not. OK > The root problem is that I ran «bts --sendmail=foo» and > /usr/sbin/sendmail was executed. This can happen not only when the > argument contains spaces (as in my original example) but also when the > argument is an absolute path to an executable or a script that > accidentally lacks the +x permission: If it does not have +x permission, then script is not executed as expected. So what is wrong? I do not understand. > for example, «chmod -x > ~/bin/mysendmail && bts --sendmail="$HOME/bin/mysendmail"» would > reproduce the bug. > > As I said earlier, using the wrong sendmail binary can lead to an email > being sent using incorrect settings (e.g., using the wrong relayhost or > from address), which IMHO merits a greater-than-wishlist severity. Yah but if that happend due to wrong file permission, who do you blame? I am a bit intrigued. ... > A separate issue is how the argument to the --sendmail option should be > handled. There are several sensible options.¹ Currently, the code > validates the argument, splits it on whitespace, and passes it to > execve(). As you say, asking to add a mode whereby the argument would > be passed to system() instead would be a wishlist item. However, I did > not request that; I simply asked to change bts(1)'s behaviour when the > validation fails. Are you asking better error message? Aha, ... OK. But that is wishlist though. > I suggested that either the validation should not be > done in the first place (just call execve() and let it error out), or > a failed validation should result in a die() rather than in proceeding > with a different sendmail binary than specified by the user. OK. I see. > Perhaps the "consider interpreting the argument to the --sendmail option > using Text::ParseWords(3perl) or system(3)" discussion should be spun off > into a separate bug report? After all, it is mostly orthogonal to the > "Change the behaviour upon validation failure" issue. Thanks, Osamu _______________________________________________ devscripts-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/devscripts-devel
