Rick Delaney <rick@bort.ca> wrote: :While waiting for opinions on my questions I've formed my own opinions. [...] :Note 2: If we were to add these tests: : : test 221, !eval { "x".$TAINT, $notaint =~ /(1)/, kill 0; 1 }; : test 222, !eval { "x".$TAINT, $notaint =~ /($notaint)/, kill 0; 1 }; : test 223, !eval { "x".$TAINT, $notaint =~ s/(1)/1/, kill 0; 1 }; : test 224, !eval { "x".$TAINT, $notaint =~ s/($notaint)/1/, kill 0; 1 }; : :they would all fail after my patch while only 221 and 223 fail before my :patch. This does not mean the patch is wrong; the only reason 222 and :224 pass pre-patch is because the regexp is wrongly tainted. My :interpretation of perlsec is NOT that these tests SHOULD all pass (i.e. :the kill should bail with an "Insecure dependency") but rather that :there is no guarantee that the kill will succeed if it is in a larger :expression that contains tainted data, even when the args to kill are :untainted. So the above tests should not be included and the patch :below is sufficient, IMO. I didn't fully understand that, and it made me worry that something like this: $should_taint = ("x".$TAINT, $notaint =~ /($notaint)/)[0]; would result in an untainted $should_taint, but trying it I find that it doesn't. Are we talking only about whether complexity of expressions _preceding_ that pattern match will cause taintedness to propagate into otherwise untainted values _following_ the pattern match? If so, I think that is fine: tainting safe values in complex expressions is something I believe we do only for simplicity of implementation, not because it makes anything more secure, and I don't think it should be a problem if we reduce the number of situations in which safe values get marked tainted. HugoThread Previous | Thread Next