Untitled attachment

Notices where this attachment appears

1. MMN-o ✅⃠ (mmn@social.umeahackerspace.se)'s status on Monday, 10-Jul-2017 19:00:02 UTC MMN-o ✅⃠
   @headcrack !GNUsocial stalls because the underlying HTTPS request never times out, which only happens with PHP sockets as the backend for HTTP_Request2 and not with the CURL backend. This is reproducible outside of the GNUsocial framework as well: https://git.gnu.io/gnu/gnu-social/issues/281#note_5674
   
   
   I am fully aware of the snail-pace type DoS attack and that's why there is a "full spectrum timeout" set in deeper parts of the code (HTTP_Request2_SocketWrapper runs stream_set_timeout - and PHP itself has a default_socket_timeout of 60s), which if the socket timeouts worked (in PHP) would kill the connection _regardless_ of how many or few bytes have been received since the last fread():
2. MMN-o ✅⃠ (mmn@social.umeahackerspace.se)'s status on Monday, 10-Jul-2017 18:53:49 UTC MMN-o ✅⃠
   @sen @headcrack Unless I'm horribly mistaken, that's an entirely separate timeout. I.e. for the daemon->subprocess. The subprocess on its own has its entirely own timeouts for each individual instruction it runs.
   
   Also, if this is supposed to relate to the hash.my ordeal, it doesn't explain why CURL as a backend handles it perfectly fine while PHP sockets don't.
   
   Also I have run tests entirely separate of the !GNUsocial framework and can recreate the issue of inconsistent timeouts with PHP sockets: https://git.gnu.io/gnu/gnu-social/issues/281#note_5674