Ivan Shmakov <ivan@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.]
Richard Kettlewell <invalid@invalid.invalid> writes:
Ivan Shmakov <ivan@siamics.net> writes:
Wouter Verhelst <w@uter.be> writes:
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.
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.
In 2018 the obvious objection to adopting curl is that it’s written
in C, a poor choice for security-critical code.
Richard Kettlewell <invalid@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.
Richard Kettlewell <invalid@invalid.invalid> writes:
Ivan Shmakov <ivan@siamics.net> writes:
Richard Kettlewell <invalid@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”.
Richard Kettlewell <invalid@invalid.invalid> writes:
Ivan Shmakov <ivan@siamics.net> writes:
Richard Kettlewell <invalid@invalid.invalid> writes:
Ivan Shmakov <ivan@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.
Richard Kettlewell <invalid@invalid.invalid> writes:
Ivan Shmakov <ivan@siamics.net> writes:
Richard Kettlewell <invalid@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.
Richard Kettlewell <invalid@invalid.invalid> writes:
Ivan Shmakov <ivan@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.
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 <invalid@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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 470 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 82:52:58 |
| Calls: | 9,457 |
| Calls today: | 1 |
| Files: | 13,599 |
| Messages: | 6,115,098 |