Hey Tim,
Appreciate the link. It looks like we're trying to have it go both ways here. If we don't want to allow it into production then make it explicit and break it - just as before. If we want to recommend that it not go into production but then let users actually do it, don't silently break it - just let it work and buyer beware. Requiring --insecure is fine but without it the explicit exception should be thrown I believe. In other words the original behaviour seems correct to me.
I think silently absorbing exceptions is more dangerous than just outright breaking and exposing the root problem early. Many of the issues with the ORM have been due to a misapplication of this policy. I get the intent of the change but I'm not sure of the risk security-wise and have just experienced the impact of the misleading exception result personally.
-- Ben