Re: [Tails-dev] Proposal: Add support for curl (does ALL_PRO…

このメッセージを削除

このメッセージに返信
著者: David A. Wheeler
日付:  
To: The Tails public development discussion list
題目: Re: [Tails-dev] Proposal: Add support for curl (does ALL_PROXY fix it?)


> On Feb 6, 2023, at 2:44 AM, segfault <segfault@???> wrote:
> I agree that it might be useful to document in the Additional Software docs that some applications need to be run via torsocks. I'll let our UX and documentation person decide on that.
>
>> However, in the case of *curl*, using torsocks has drawbacks.
>> The torsocks program uses the LD_PRELOAD trick that is
>> sometimes unreliable
>
> I'm not aware of torsocks being unreliable. It's used in Tails for many applications and I use it myself for others and in my experience when it works once it works every time.


LD_PRELOAD has its uses, but it works by intercepting lower-level function calls.
This means that future "minor" changes to a program or library can cause
things to unexpectedly break. E.g., If a function call is internally added or changed
that should be intercepted (but isn't) the interception won't work.
Calls that get statically linked don't get intercepted.
Also, glib will just plow ahead if loading LD_PRELOAD libraries fails
<https://github.com/cloudflare/sandbox/issues/1>.
I've written several programs that use LD_PRELOAD, and found it's
remarkably fiddly & that upgrades can easily make things go wrong.
I don't think Debian designs or tests its programs to work with LD_PRELOAD.

So while LD_PRELOAD certainly has its uses, I think it's better to use
more reliable alternatives where they're sensible. E.g.,
configuring a tool to directly use SOCKS (if it can do so) and/or
implementing a transparent proxy (again, so it reliably works).
Implementing a transparent proxy takes some effort,
so I was trying to find a simple but reliable solution.


> On Feb 6, 2023, at 4:08 AM, boyska <boyska@???> wrote:
> oh yeah, we all like curl. I wonder what kind of user needs curl, though.
> You mentioned that some packages in Debian will "just work" if curl is working. Can you name any of them? I think that would be very valuable info!


Sorry, what I meant was, "I expect that some packages in Debian will "just work" if curl is working".
I don't have a specific list. That said, as you stated, *many* people like curl, so
I expect a lot of tools use curl internally. I think a reverse dependency lookup
(of the Debian metadata, not of a running instance) would show a long list.

--- David A. Wheeler