Closed sirjonasxx closed 2 years ago
@sirjonasxx just for the first packet?
Since the extension server only handles one packet, that being: https://github.com/sirjonasxx/G-Earth/blob/8cd429cc2313af2dece44a21688b7ef4f002cb06/G-Earth/src/main/java/gearth/services/extension_handler/extensions/implementations/network/NetworkExtensionInfo.java#L99 Can we not base the cap for any incoming packet on that (so not just the first one)?
Currently I set the cap as max 100 characters per string encoded in the packet. This might be a bit of a lowball estimate, thoughts?
It's not the only packet the server also get's huge packets like inventory, catalog etc. back from extensions, so putting on a character limit on all incoming packets isn't really a good idea
It's not the only packet the server also get's huge packets like inventory, catalog etc. back from extensions, so putting on a character limit on all incoming packets isn't really a good idea
I want to add the check only in NetworkExtensionsProducer, since this only handles the extension info packet it should be fine right? It doesn't do anything with other packets. Or am I missing something?
Ah yeah there it only handles that yes, but I think it would be better to add an else to this if
So that it just terminates the connection when it doesn't give the correct ID
When the received packet does have the correct ID but invalid content the code within the current if already causes it to terminate (I think)
When the received packet does have the correct ID but invalid content the code within the current if already causes it to terminate (I think)
The main issue is that a diff app connecting to the port, may send some data that is read as the size of the packet, which may allocate an humongous byte array for the packet read buffer.
So unless it reads the header at the start, the check has to be before the packet is being read. If the header is encoded at the start, then we could also first read the header, check if the ID is valid and then do the check in the code u linked. Can also do that!
PR looks good, I think the boundary is a bit low though since we don't know how the future of that packet looks like, and there's technically no restraints on title/description size etc, perhaps we could do the header check first and then be less strict about the size
PR looks good, I think the boundary is a bit low though since we don't know how the future of that packet looks like, and there's technically no restraints on title/description size etc, perhaps we could do the header check first and then be less strict about the size
Cheers! I increased the max string size to 4_000
, so the final max cap for the packet is now roughly 48kb ((8000 * 6) + 4
). If the packet where to change structurally in the future, we'll have to modify the constants I defined, though I think this is preferable over maintaining magic numbers.