Rich Felker on Nostr: Tip for parties maintaining or considering maintaining a soft fork of software with ...
Tip for parties maintaining or considering maintaining a soft fork of software with upstream malicious behavior, but concerned about burden resolving conflicts when syncing changes:
Instead of removing the malicious code directly (a diff certain to conflict every time upstream changes it), do the following:
1. Patch in a single if(false) on the point(s) that call(s) into the malicious functionality to ensure it's not called.
2. As a safety in case a point is missed or a new point added in an update is overlooked, patch in a call to abort() (or equivalent for the language in a key point inside the malicious functionality before it can do the evil thing.
3. If there are constants for domain names the malicious code contacts, patch them out as a third layer of safety.
All of these are nearly sure to survive upstream changes, and easy to resolve conflicts if they don't.
Instead of removing the malicious code directly (a diff certain to conflict every time upstream changes it), do the following:
1. Patch in a single if(false) on the point(s) that call(s) into the malicious functionality to ensure it's not called.
2. As a safety in case a point is missed or a new point added in an update is overlooked, patch in a call to abort() (or equivalent for the language in a key point inside the malicious functionality before it can do the evil thing.
3. If there are constants for domain names the malicious code contacts, patch them out as a third layer of safety.
All of these are nearly sure to survive upstream changes, and easy to resolve conflicts if they don't.