Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Sunday June 23 2019, @04:11PM   Printer-friendly
from the curling-in-software dept.

Submitted via IRC for Bytram

Google to reimplement curl in libcrurl

Not the entire thing, just “a subset”. It’s not stated very clearly exactly what that subset is but the easy interface is mentioned in the Chrome bug about this project.

The Chromium bug states that they will create a library of their own (named libcrurl) that will offer (parts of) the libcurl API and be implemented using Cronet.

Cronet is the networking stack of Chromium put into a library for use on mobile. The same networking stack that is used in the Chrome browser.

There’s also a mentioned possibility that “if this works”, they might also create “crurl” tool which is then their own version of the curl tool but using their own library. In itself is a pretty strong indication that their API will not be fully compatible, as if it was they could just use the existing curl tool…

“Implementing libcurl using Cronet would allow developers to take advantage of the utility of the Chrome Network Stack, without having to learn a new interface and its corresponding workflow. This would ideally increase ease of accessibility of Cronet, and overall improve adoption of Cronet by first-party or third-party applications.”

Logically, I suppose they then also hope that 3rd party applications can switch to this library (without having to change to another API or adapt much) and gain something and that new applications can use this library without having to learn a new API. Stick to the old established libcurl API.


Original Submission

Related Stories

Half of Curl's Security Vulnerabilities Due to C Mistakes 83 comments

curl developer Daniel Stenberg has gone through his project's security problems and calculated that 51 out of curl's 98 security vulnerabilities have been C mistakes. The total number of bugs in the database is about 6.6k, meaning that not quite 1.5% have been security flaws.

Let me also already now say that if you check out the curl security section, you will find very detailed descriptions of all vulnerabilities. Using those, you can draw your own conclusions and also easily write your own blog posts on this topic!

This post is not meant as a discussion around how we can rewrite C code into other languages to avoid these problems. This is an introspection of the C related vulnerabilities in curl. curl will not be rewritten but will continue to support backends written in other languages.

It seems hard to draw hard or definite conclusions based on the CVEs and C mistakes in curl's history due to the relatively small amounts to analyze. I'm not convinced this is data enough to actually spot real trends, but might be mostly random coincidences.

After the stats and methodology, he goes into more detail about the nature of the 51 bugs and the areas in the program (and library) where they occur. In general, the problems sort out into buffer overreads, buffer overflows, use after frees, double frees, and NULL mistakes.

Previously:
(2020) curl up 2020 and Other Conferences Go Online Only
(2019) Google to Reimplement Curl in Libcrurl
(2018) Daniel Stenberg, Author of cURL and libcurl, Denied US Visit Again
(2018) Twenty Years of cURL on March 20, 2018
(2018) Reducing Year 2038 Problems in curl
(2017) Eric Raymond: "The long goodbye to C"


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 4, Insightful) by Anonymous Coward on Sunday June 23 2019, @04:43PM (3 children)

    by Anonymous Coward on Sunday June 23 2019, @04:43PM (#859095)

    Huh, page out of the book of M$.

    • (Score: 2) by Runaway1956 on Sunday June 23 2019, @04:50PM (2 children)

      by Runaway1956 (2926) Subscriber Badge on Sunday June 23 2019, @04:50PM (#859097) Journal

      You beat hundreds of us to that post - good job!

      • (Score: 0) by Anonymous Coward on Sunday June 23 2019, @07:51PM (1 child)

        by Anonymous Coward on Sunday June 23 2019, @07:51PM (#859130)

        "dont be evil" really meant dont be like microsoft.

        Turns out they got rid of that slogan years ago... There is money to be made.

        It is obvious from the outside there was a major tectonic shift in the way google was run a few years ago. Even MS still supports junk they made in the 90s. What does google support more than a few years? If you need to get ahold of them to talk to them for some reason how do you do so other than making a stink on twitter? I posit that google is not a good partner to have anymore. They drug us from the clutches of MS. Then decided they were in charge. Meet the new boss worse than the old boss.

        • (Score: 2, Informative) by Anonymous Coward on Sunday June 23 2019, @08:54PM

          by Anonymous Coward on Sunday June 23 2019, @08:54PM (#859142)

          That shift wasn't a few years ago, that shift goes back to the very instant they gobbled up doubleclick.net.

  • (Score: 0) by Anonymous Coward on Sunday June 23 2019, @05:05PM

    by Anonymous Coward on Sunday June 23 2019, @05:05PM (#859103)

    They should found a way to make that acronym work

  • (Score: 2, Insightful) by Anonymous Coward on Sunday June 23 2019, @05:17PM (4 children)

    by Anonymous Coward on Sunday June 23 2019, @05:17PM (#859104)

    Monolithic applications like web browsers in current era is a true catastrophic disaster at global scale. Any web browser is a gigantic piece of junk-glued functionality. Practically, they became operating systems on its own. We should reconsider such software at system architectural scale: decompose all the functionality not to just a portfolio of component libraries, but introduce a set of command line tools providing separable functionality, replacable and upgradable themselves alone as simple purposeful components. Compiling the whole browser every day is doable on big desktop, but still is a pain. Impossible for daily operations on small platforms. It is not just about network protocols, we need to decouple storage backend, history, bookmarks, filtering, sandboxing, rendering, anything which is hidden inside, to separate tools. If we do this, we will appreciate it when VR epoch comes.

    • (Score: 3, Informative) by takyon on Sunday June 23 2019, @05:41PM (3 children)

      by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Sunday June 23 2019, @05:41PM (#859108) Journal

      "Big pile of Not Happening."

      - Google and Mozilla

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 0) by Anonymous Coward on Sunday June 23 2019, @08:37PM

        by Anonymous Coward on Sunday June 23 2019, @08:37PM (#859140)

        Mozilla too. I hack on both browsers professionally, and in both cases the projects appear to consist of a core group of fewer than 100, who likewise hack around. Putative performance gains are chased, additional tracking implanted according to their bosses' demands, all without any regard to code clarity, stability or any software engineering guidelines. In fact, it appears one of their private goals is to prevent any outsider from being productive with the source.

        Say you want to keep stats on how many DOM nodes are created. In more rigidly developed software, you may find the constructor for a DOM node, or its factory, and maintain count through there.

        Browser X has something like that, but then you find out that sometimes nodes are constructed incomplete, filled in later or discarded. Fine, you do stuff to handle those cases. Two years later when you retarget your work to the newest version, everything has changed. For example, classes helpful to your work have been removed or hidden, they add a complex destruction process where nodes are put in limbo, then restored from there if a node with the same parameters happens to need construction again. Supposedly because it happens a lot and saves a few milliseconds. You need to pretty much rewrite everything.

        The Linux kernel also has performance needs, but AFAICT they will not needlessly complicate things to save a minor amount of time (SystemD is not Linux). Kernel developers regard performance redesign to come with a significant amount of commitment to that design over the following years. Browser design needs a messias like Linus. :)

      • (Score: 3, Interesting) by darkfeline on Sunday June 23 2019, @11:47PM (1 child)

        by darkfeline (1030) on Sunday June 23 2019, @11:47PM (#859189) Homepage

        Uh, isn't this exactly what is happening? They're taking the networking stack which was bundled in a monolithic application, and exposing it as a standalone library and potentially a separate utility.

        Personally, I don't see the point; I'm all for having one standard (one libcurl, yes, but also, one Linux, one systemd, one browser engine, etc). However, I'd wager that a lot of SoylentNews readers who will poo-poo this ("why make a new library when libcurl already exists") are also hypocritically demanding more web browser diversity.

        --
        Join the SDF Public Access UNIX System today!
  • (Score: 2, Disagree) by TheRaven on Sunday June 23 2019, @05:18PM (7 children)

    by TheRaven (270) on Sunday June 23 2019, @05:18PM (#859105) Journal

    The curl project provides a library called libcurl [curl.haxx.se], which is what most things actually use. So the Google libcurl is different from the curl libcurl.

    Aside from that, I'm quite glad to see someone doing this. Curl is embedded in a huge number of other things, handles untrusted data, and has a terrible security track record.

    --
    sudo mod me up
    • (Score: 0) by Anonymous Coward on Sunday June 23 2019, @06:00PM

      by Anonymous Coward on Sunday June 23 2019, @06:00PM (#859110)

      Is there some sort of mind-altering substance causing this sort of naivety, or what?

    • (Score: 3, Insightful) by digitalaudiorock on Sunday June 23 2019, @06:14PM

      by digitalaudiorock (688) on Sunday June 23 2019, @06:14PM (#859112) Journal

      I think you missed the extra "r" in the Google library name "libcrurl"...which I can only assume means something like libcurl only significantly more cruel...

    • (Score: 5, Insightful) by Rosco P. Coltrane on Sunday June 23 2019, @08:27PM (4 children)

      by Rosco P. Coltrane (4757) on Sunday June 23 2019, @08:27PM (#859139)

      I'd rather have libcurl and whatever its security track record is, than libcrurl and the Google mothership doing god-know-what with the data handled by the library.

      • (Score: 4, Insightful) by The Shire on Sunday June 23 2019, @09:29PM (2 children)

        by The Shire (5824) on Sunday June 23 2019, @09:29PM (#859159)

        Couldn't agree more. There's no reason to have a library with the same name that does things the original was not designed to do. If you want additional functionality for your own systems then you create a new library and call to that, you don't supplant the existing one with something entirely different. That's called malware.

        • (Score: 0) by Anonymous Coward on Sunday June 23 2019, @10:27PM (1 child)

          by Anonymous Coward on Sunday June 23 2019, @10:27PM (#859171)

          It's not the same name. It's a confusingly similar name. Trademark infringement lawsuit coming in 3, 2, 1...

          • (Score: 4, Funny) by Anonymous Coward on Sunday June 23 2019, @11:36PM

            by Anonymous Coward on Sunday June 23 2019, @11:36PM (#859185)

            Malrware.

      • (Score: 0) by Anonymous Coward on Monday June 24 2019, @03:11PM

        by Anonymous Coward on Monday June 24 2019, @03:11PM (#859367)

        Also the premise is false. You can't just make libcrurl a drop in replacement if it removes features. I must admit that I haven't ever built curl myself, but looking at the configure script it is insanely modular already, so much that it would be spam posting the optional features here.

        Got to this: https://salsa.debian.org/debian/curl/raw/master/configure [debian.org]

        Search for the line: "Optional Features:"

        Holy shit!

        Scroll a bit further down to: "Optional Packages:"

        Holy more shit!

        That's pretty modular library.

  • (Score: 3, Interesting) by J_Darnley on Monday June 24 2019, @02:50PM

    by J_Darnley (5679) on Monday June 24 2019, @02:50PM (#859361)

    Will this one report all transfers to Google's spying network? Will Google be consulted to ensure you have permission to download the file? Will Google check that the resource is "safe" before allowing the download?

(1)