I'm in the market for a replacement for BTCPay. I want a web interface to accept donations on-chain with a unique address each time, accept LN donations, and ideally be able to take payments for an e-commerce platforms like CS-Cart. If it could also just BE the store, and that'd be fine. Self hostable, without reliance on 3rd party servers (e.g. nostr relays) and without having to run extra services (e.g. a public nostr relay). Simple and open source. That's what I'm after. This is not because BTCPay had a vulnerability, but because of their handling of it. They intentionally omitted that vulnerability fix from their release notes, making it look like the 2FA fix was the "critical vulnerability" fix. The people who admin servers need to be able to trust the release notes to be an honest account of what has changed. We're not going to look at every line of code that has changed. We don't have time for that. You know who does have time for that? The attackers. Had the authors just put a single line in the release notes that said "unauthenticated attacker can get the .macaroon file for LND", I would feel like I could still trust them. Doing so would not have made it any easier for the attackers, they'd still have to read the patch, just the same as they had to do without proper disclosure. I've worked in infosec for 15+ years, most of that time finding 0-days. We can debate about whether the details and exploit should be released before the patch, at the same time, 30 days later or 90 days later. Reasonable people can draw different conclusions there, even when looking at the same information. What's not debatable is whether it's good practice to do what they did. Don't take my word for it. Ask anyone who works in the field professionally. Is it okay to say there was a critical vulnerability fixed in a release and then only list one vulnerability fix in the changelog and omit another, mire serious vulnerability that was fixed?