Re: [OT] Firefox

[Ivan Shmakov]

>>>>> Ivan Shmakov <iv...@siamics.net> writes:

> [Belatedly cross-posting to news:comp.infosystems.www.misc,
> as the question at hand doesn't seem specific to Debian GNU/Linux.]

... Rather unexpectedly, I've failed at that. I'm not going to
post a copy there now, but kindly request that the followups to
this news:alt.os.linux.debian thread are cross-posted to
news:comp.infosystems.www.misc (perhaps with Followup-To: set
there as well, unless there's anything Debian-specific there.)

TIA.

[...]

--
FSF associate member #7257 http://am-1.org/~ivan/

[Ivan Shmakov]

>>>>> Richard Kettlewell <inv...@invalid.invalid> writes:
>>>>> Ivan Shmakov <iv...@siamics.net> writes:
>>>>> Wouter Verhelst <w...@uter.be> writes:

[Cross-posting to news:comp.infosystems.www.misc.]

>>> libcurl is great for its purpose: to provide downloads of URLs for
>>> applications whose primary purpose is not that. It abstracts away
>>> much of the internals of getting things from the network, and just
>>> gives the application that uses it a simple interface, but one
>>> without features, allowing simple one-way data transfers.

>> All HTTP/1.1 transfers are "one-way," are they not?

> No. For instance a POST request with a body may receive a response
> with a body - a two-way transfer.

Definitions. It can hence be argued that all HTTP/1.1 transfers
are two-way; for instance, a GET request without a body is still
transferred client-to-server, and the response goes the opposite way.

The point is, whatever it is called, Libcurl appears to support it.

(Frankly, by "two-way" I've assumed it's meant "both directions
in parallel.")

>>> Finally, the libcurl API does not really work well for pipelining
>>> multiple transfers over multiple connections to the same host,
>>> which browsers tend to do.

>> Then that would remain the responsibility of the calling
>> application. Or Libcurl may be improved in this regard. Or
>> (perhaps the best solution of these) there may be a separate library
>> on top of Libcurl to multiplex requests across connections.

> It does have a pipelining option, I’ve not tried using it though.

Neither have I. But I imagine it won't necessarily be able to
see that the request to /bigsearch.cgi has stalled, and thus the
request to /static/about.html on the same server should go over
a new connection.

> In 2018 the obvious objection to adopting curl is that it’s written
> in C, a poor choice for security-critical code.

Yeah. The same kind of utterly insecure software that no one uses
anymore, like GnuTLS, OpenSSL, Linux, GnuPG, Apache httpd, etc.

[Richard Kettlewell]

Ivan Shmakov <iv...@siamics.net> writes:

> Richard Kettlewell <inv...@invalid.invalid> writes:
>> In 2018 the obvious objection to adopting curl is that it’s written
>> in C, a poor choice for security-critical code.
>
> Yeah. The same kind of utterly insecure software that no one uses
> anymore, like GnuTLS, OpenSSL, Linux, GnuPG, Apache httpd, etc.

I didn’t say “the objection to continuing to use”, I said “the objection
to adopting”.

--
https://www.greenend.org.uk/rjk/

[Ivan Shmakov]

But I won’t be “adopting” Libcurl! I would continue to use it,
like I had for years, as part of my system, which will now
include RifleBox™ – the new and improved ‘no-nonsense’
revolutionary modular browser.

PS. SCNR.

[Richard Kettlewell]

Ivan Shmakov <iv...@siamics.net> writes:
> Richard Kettlewell <inv...@invalid.invalid> writes:
>> Ivan Shmakov <iv...@siamics.net> writes:
>>> Richard Kettlewell <inv...@invalid.invalid> writes:
>>>> In 2018 the obvious objection to adopting curl is that it’s written
>>>> in C, a poor choice for security-critical code.
>>>
>>> Yeah. The same kind of utterly insecure software that no one uses
>>> anymore, like GnuTLS, OpenSSL, Linux, GnuPG, Apache httpd, etc.
>>
>> I didn’t say “the objection to continuing to use”, I said “the
>> objection to adopting”.
>
> But I won’t be “adopting” Libcurl! I would continue to use it, like I
> had for years, as part of my system, which will now include RifleBox™
> – the new and improved ‘no-nonsense’ revolutionary modular browser.

The context seemed to be whether Firefox should adopt curl or not.

--
https://www.greenend.org.uk/rjk/

[Ivan Shmakov]

>>>>> Richard Kettlewell <inv...@invalid.invalid> writes:
>>>>> Ivan Shmakov <iv...@siamics.net> writes:
>>>>> Richard Kettlewell <inv...@invalid.invalid> writes:

>>>>> Ivan Shmakov <iv...@siamics.net> writes:

>>>> Yeah. The same kind of utterly insecure software that no one uses
>>>> anymore, like GnuTLS, OpenSSL, Linux, GnuPG, Apache httpd, etc.

>>> I didn’t say “the objection to continuing to use”, I said “the
>>> objection to adopting”.

>> But I won’t be “adopting” Libcurl! I would continue to use it, like
>> I had for years, as part of my system, which will now include
>> RifleBox™ – the new and improved ‘no-nonsense’ revolutionary modular
>> browser.

> The context seemed to be whether Firefox should adopt curl or not.

Indeed, I wasn’t entirely clear. This subthread started with
a mention of Firefox forks, and the observation that as a rule,
they aren’t viable. So, my suggestion was that we need a more
modular codebase (as in: it is actually feasible for a third
party to fork one module while retaining the upstreams for others.)

Somehow, I doubt that Mozilla will go that way (although I’d be
delighted to be proven wrong on this point), so my idea was
indeed about forking Firefox one more time.

That said, Libcurl is in development for over two decades now;
and personally, I’m going to use it whether it’s adopted by a
browser or not. So, will it indeed be any more secure to use
Libcurl in some contexts and some brand new HTTP connectivity
module in others, as opposed to using Libcurl only?

Not to mention that new crypto functions are still being added
to GnuTLS and OpenSSL, – and are still written in the same old C.
How does it not irk, say, the Mozilla developers, I wonder?

[Richard Kettlewell]

Ivan Shmakov <iv...@siamics.net> writes:
> That said, Libcurl is in development for over two decades now;
> and personally, I’m going to use it whether it’s adopted by a
> browser or not. So, will it indeed be any more secure to use
> Libcurl in some contexts and some brand new HTTP connectivity
> module in others, as opposed to using Libcurl only?

If you use something written in a memory-safe language in those other
contexts then your total risk is likely to be reduced.

> Not to mention that new crypto functions are still being added
> to GnuTLS and OpenSSL, – and are still written in the same old C.
> How does it not irk, say, the Mozilla developers, I wonder?

Mozilla are putting considerable effort into escaping C, and are already
making some progress within Firefox itself.

--
https://www.greenend.org.uk/rjk/

[Ivan Shmakov]

>>>>> Richard Kettlewell <inv...@invalid.invalid> writes:
>>>>> Ivan Shmakov <iv...@siamics.net> writes:

>> That said, Libcurl is in development for over two decades now; and
>> personally, I’m going to use it whether it’s adopted by a browser or
>> not. So, will it indeed be any more secure to use Libcurl in some
>> contexts and some brand new HTTP connectivity module in others, as
>> opposed to using Libcurl only?

> If you use something written in a memory-safe language in those other
> contexts then your total risk is likely to be reduced.

While memory-safe languages make one kind of bugs impossible
(assuming a bug-free implementation – and that’s a huge
assumption already), there’re bugs that are not related to
invalid memory access.

Speaking of implementations; AIUI, Emacs Lisp is “memory safe.”
Still, I had Emacs Lisp code that resulted in SIGSEGV, and I’ve
certainly seen Emacs entering infinite loop more than once.

>> Not to mention that new crypto functions are still being added to
>> GnuTLS and OpenSSL, – and are still written in the same old C. How
>> does it not irk, say, the Mozilla developers, I wonder?

> Mozilla are putting considerable effort into escaping C, and are
> already making some progress within Firefox itself.

Well, I can only wish them good luck. When the current 52 ESR
reaches EOL, I’m afraid I won’t be actively interested in
Firefox anymore.

I loosely consider switching to Basilisk, but it’s quite likely
that it won’t be viable in the long term as well.

[Richard Kettlewell]

Ivan Shmakov <iv...@siamics.net> writes:
> Richard Kettlewell <inv...@invalid.invalid> writes:

>> If you use something written in a memory-safe language in those other
>> contexts then your total risk is likely to be reduced.
>
> While memory-safe languages make one kind of bugs impossible (assuming
> a bug-free implementation – and that’s a huge assumption already),
> there’re bugs that are not related to invalid memory access.

Yes. So what? Eliminating the bug classes associated with C is still a
major improvement.

--
https://www.greenend.org.uk/rjk/