On Jun 14, 2007, at 11:00, Kyle Wheeler wrote:
On Monday, June 11 at 06:52 PM, quoth Ken Raeburn:In some MIT applications there was a conscious choice to that effect. The MIT library's interface for verifying credentials has a flag that can be set to indicate whether it should return success or failure for this specific case. (Though personally, I think the default should be the more paranoid one, it would be an incompatible break from previous versions.)Maybe I'm misunderstanding here, but so what? This sounds like the equivalent of this: My program respects the $ALLOW_ROOT_COMPROMISE environment variable. You may think root compromises are bad, and that theenvironment variable is ludicrous, and I agree (that "feature" wasadded before I took over), but if I removed it then that would be an incompatible break from previous versions.
Don't forget, "... and we have a trivial way to turn it off, though some programs can't be bothered to use it".
And, as I indicated, in a few environments (including certain parts of the environment in which the code was developed), root compromises actually aren't considered a problem.
Just because older programs allowed it doesn't make it sacrosanct.
No, it doesn't. But backwards compatibility isn't irrelevant either. Both sides were considered in the decision, years ago. I'm not saying we've got the best solution -- just that there were reasons we wound up with the more open default and a function to tighten it up, rather than the other way around. Perhaps it's time to revisit it -- but the existing code is out there and is in use, generally using the APIs correctly...
Ken