On Mon, May 20, 2024 at 10:15 AM Jacob Champion <jacob.champ...@enterprisedb.com> wrote: > This is just restating the "you can already do bad things" argument. I > understand that if your query gets executed, it's going to consume > resources on the thing that's executing it (for the record, though, > there are people working on constraining that). But introducing > disproportionate resource consumption into all traffic-inspecting > software, like pools and bouncers, seems like a different thing to me. > Many use cases are going to be fine with it, of course, but I don't > think it should be hand-waved.
I can't follow this argument. I think it's important that the startup message is always sent uncompressed, because it's a strange exception to our usual message-formatting rules, and because it's so security-critical. I don't think we should do anything to allow more variation there, because any benefit will be small and the chances of introducing security vulnerabilities seems non-trivial. But if the client says in the startup message that it would like to send and receive compressed data and the server is happy with that request, I don't see why we need to postpone implementing that request until after the authentication exchange is completed. I think that will make the code more complicated and I don't see a security benefit. If the use of a particular compression algorithm is going to impose too much load, the server, or the pooler, is free to refuse it, and should. Deferring the use of the compression method until after authentication doesn't really solve any problem here, at least not that I can see. It does occur to me that if some compression algorithm has a buffer overrun bug, restricting its use until after authentication might reduce the score of the resulting CVE, because now you have to be able to authenticate to make an exploit work. Perhaps that's an argument for imposing a restriction here, but it doesn't seem to be the argument that you're making. -- Robert Haas EDB: http://www.enterprisedb.com
