Nuke *notify options from Bitcoin Core [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2022-01-01T23:29:15+00:00


Summary:

In the email conversation, Prayank responds to Daniel regarding certain points that may have been overlooked. Prayank expresses that many fancy features won't function in Windows shortcut target and it is even more suspicious if someone attempts to wrap it in notify options provided by Bitcoin Core. He emphasizes that this approach does not offer the option to run a command based on events like received transactions in the wallet. On the contrary, these notify options provide opportunities for malware to exploit. Prayank suggests that there is ample time to conduct further research on the issue and provide a fresh and helpful response for documentation purposes.The email thread revolves around a proposal to eliminate specific options from Bitcoin Core, specifically the notify options. The writer of the email argues that these options can be utilized by attackers through social engineering tactics to gain control over machines running Bitcoin Core. They further explain their attempts to bring attention to this matter with project maintainers and reviewers, but have encountered resistance. To facilitate deeper understanding, the author provides links to various pull requests (PRs) and issues related to this topic. They also mention being instructed not to review or comment on one particular PR, a directive they disagree with. The email concludes with the author sharing their public key.The author of the email advocates for the complete removal of all notify options from Bitcoin Core due to their potential to aid attackers in compromising machines running the software. To address this concern, the author proposes three potential solutions: removing notifications.dat, refraining from using system() in runCommand(), and introducing a new setting called notifypolicy in the settings.json file. This new setting would be restricted by default but could be adjusted to unrestricted when necessary. The author asserts that these issues have been thoroughly explained in multiple PRs and discussions with various individuals, including reviewers who rejected proposals due to a lack of comprehension regarding the underlying problems. The author provides specific links to two PRs where these issues were debated. Expressing frustration with the lack of interest in addressing these concerns, the author hopes that this email will help raise awareness about the issue. The author also mentions being asked to refrain from reviewing and commenting on a specific PR. Lastly, the author notes that this email will contribute to their security project and extends New Year wishes to everyone.


Updated on: 2023-08-02T05:20:36.978071+00:00