public-read denied")I agree, will have to go in a 2.0 release. I've been lax about breaking changes because they are usually smaller and not in widely used backends. This would not be that in any way.
By default it shouldn't set ACL at all (boto's default behaviour), and defer to the bucket's ACL? Or as a non-breaking change, there should be an option to not explicitly set an ACL on the object. That way you could give an application's IAM role PutObject without having to also give it PutObjectAcl.
Just to follow up: looks like we can work around this by explicitly setting AWS_DEFAULT_ACL to None in settings.
We will now warn about the insecure defaults with a recommendation to update.
Most helpful comment
By default it shouldn't set ACL at all (boto's default behaviour), and defer to the bucket's ACL? Or as a non-breaking change, there should be an option to not explicitly set an ACL on the object. That way you could give an application's IAM role
PutObjectwithout having to also give itPutObjectAcl.