On Sun, Nov 05, 2023 at 12:57:40AM +0000, kaizushi@xxxxxxx wrote: > They blatantly don't care and deny the issue, and don't care that it breaks > a feature Tor has had for over a decade. They respond with fallacies and > irrational garbage. They don't acknowledge that an environment variable > would fix the issue and tacitly admit not to care. > > Fortunately I run Gentoo and this stupid bit of code is very easy to fix on > that distribution. I made this patch and used /etc/portage/patches to fix > it, which is a page on the Gentoo Wiki: https://bpa.st/Q4VQc - I think this > illustrates how simple this issue is as well as fixing it for all users. > > However, the transproxy feature allows for people to idiot proof their > systems and share with people which is supposed to be what open source is > about. I hope as many people call out this kind of ignorant behavior for > what it clearly is. You can see the depths of their stupidity and denial > here... The prohibition of .onion in libcurl presents a problem for existing production HardenedBSD deployments in certain environments where transparent proxying is used rather than SOCKS. Systems living in such environments now cannot be updated, even to patch security vulnerabilities. HardenedBSD provides Tor Onion Service endpoints for all its publicly-facing infrastructure. Users can go from zero to dev to prod completely behind a fully Tor-ified network (via transparent proxying). But now that libcurl, which the HardenedBSD package manager uses, prohibits .onion DNS record resolutions, our users are not able to access our Tor Onion Endpoints, leaving them insecure and vulnerable to exploitation by bad actors. With the curl project's unwillingness to compromise, HardenedBSD is now forced to maintain a patch to revert the prohibition. But that only applies to HardenedBSD users. What about users of other operating systems with similar transparent proxy deployments? I would strongly suggest to officially clarify the RFC or strike the relevant section altogether. Without doing so, the curl project seems unwilling to make the prohibition a choice that can be made at runtime by the user, even. Please remember that these kinds of things have real and tangible human consequences. Some of our users remain in harms way to this day because of this. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev