mike bayer <mike...@zzzcomputing.com> added the comment:
> I don't really know why it would be a "security vulnerability", but presumably a library could either convert their datetimes to UTC as soon as they get them from the user if they want to use them as UTC in the future, or they could simply refuse to accept any datetimes outside the range `datetime.datetime.MINYEAR + timedelta(hours=48) < dt.replace(tzinfo=None) < datetime.datetime.MAXYEAR - timedelta(hours=48)`, this is absolutely correct, but I'm not sure if you're aware, there's kind of a whole subsection of the tech community that considers anything that a user might do without understanding all the consequences which could in any way allow untrusted input to affect things to be a "security risk". In SQLAlchemy i had CVEs posted because we have a method called order_by() that accepted a string, and the notion was, someone will write a web app that takes an arbitrary string as input and send it there! CVE! For you and me that would of course be crazy as this is obviously part of the SQL string being sent to the database, but this is a particular programming subculture that has the ability to create a lot of havoc by filling up the CVE system with "Security Vulnerabilities" based on what many of us consider obviously wrong. > Can you clarify why this crashes? Is it because it always returns the > datetime value in UTC? it returns the datetime value in the default timezone set up for the server which could be UTC or a local timezone, but the idea is it's potentially different from the timezone that's been put in. > I'll note that I don't actually understand the difference between > "abstraction layer" and "psycopg2 driver", so I may be conflating those two, from my POV I have always thought PostgreSQLs' TIMESTAMP WITH TIMEZONE datatype is nuts, and that you should only be sending UTC timestamps to a database. But people want to use PG's type and IMO they need to understand what they're doing. thanks for the response. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue43484> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com