Find places where we don't/shouldn't need to crash from unwrap/expect/panic and fix those #36

Closed
opened 2023-12-24 19:01:42 +00:00 by girlbossceo · 1 comment
girlbossceo commented 2023-12-24 19:01:42 +00:00 (Migrated from github.com)

This codebase seems to rely on a pinky-promise that the system it's running on is 100% perfect with no errors, and relies on clients being 100% implement correctly, with the absurd amount of .expect() and .unwrap()'s it has.
Some of these have resulted in potential denial of service vectors, random unexplainable crashes, and I'm pretty certain this is why gradual database corruption occurs even on shutdowns. The RocksDB WAL recovery mode to ignore corrupted tail records just shows the problem in the form of temporary federation issues.

Upstream and said community/contributors are keen on keeping this unusual behaviour, so getting this fixed upstream without making a PoC showing it can be used for remote denial of service isn't really possible.

This codebase seems to rely on a pinky-promise that the system it's running on is 100% perfect with no errors, and relies on clients being 100% implement correctly, with the absurd amount of .expect() and .unwrap()'s it has. Some of these have resulted in potential denial of service vectors, random unexplainable crashes, and I'm pretty certain this is why gradual database corruption occurs even on shutdowns. The RocksDB WAL recovery mode to ignore corrupted tail records just shows the problem in the form of temporary federation issues. Upstream and said community/contributors are keen on keeping this unusual behaviour, so getting this fixed upstream without making a PoC showing it can be used for remote denial of service isn't really possible.
girlbossceo commented 2024-07-04 21:39:09 +00:00 (Migrated from github.com)

This is a pretty open-ended issue with no clear direction or goal, and was made in December 2023.

Significant codebase improvements, cleanup, fixes, etc have been done and are still being done.

This is a pretty open-ended issue with no clear direction or goal, and was made in December 2023. Significant codebase improvements, cleanup, fixes, etc have been done and are still being done.
This discussion has been locked. Commenting is limited to contributors.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
continuwuation/continuwuity#36
No description provided.