Author | Chu Xingjuan
Daniel Stenberg, author of cURL, received an email from a Fortune 500 company on Jan. 21 asking Stenberg to answer questions about whether cURL was affected by the Log4Shell vulnerability and how to handle it. He then tweeted a screenshot of the email and wrote:
If you're a multibillion-dollar company and still follow Log4j, why not email OSS authors who you've never paid for and ask them to respond to so many of your questions for free within 24 hours?
This incident quickly aroused the attention of netizens.
Think of open source as a vendor
According to the content of the public email, the Fortune 500 company (tentatively known as "NNNN") considered the Daniel team to be a product vendor and asked it to provide a free solution to the Log4j vulnerability within 24 hours. Here are the questions that NNNN asked Stenberg to answer:
If you are using the Java Logstore in your application, what Log4j versions are running?
Has there been any confirmed security incidents in your company?
If so, which applications, products, services, and related versions are affected?
Which NNNN products and services are affected?
Will NNNN's non-public or personal information be affected?
If so, please provide NNNN with details immediately.
When will the repair be completed? Lists each step, including the completion date of each step.
What action does NNNN need to take to complete this fix?
cURL (short for client URL request library) is a command-line interface for retrieving content that can be accessed through a computer network. Resources are specified by URLs and must be of type supported by the software. The cURL program implements a user interface based on the libcurl software library developed in C.
The Apache Log4j logstore is heavily used by vendors of Java/J2EE application development projects and Java/J2EE-based off-the-shelf software solutions. On December 9 of last year, a vulnerability was discovered in Log4j that allowed an attacker to perform remote code execution, including accessing the entire network through an affected device or application, running any code, accessing all data on the affected device or application, deleting or encrypting files, and so on. Arguably, the cURL open source code has nothing to do with the Log4j exploit.
Although Stenberg had never been involved in the development of Log4j or any copyrighted products that used Log4j code, Stenberg replied, "You are not our customer, and we are not your customer." And slightly teasingly said that as long as the two parties signed a commercial contract, they would be happy to answer all the questions.
"Sending emails" is just a routine?
"The level of ignorance and incompetence shown in this email is unbelievable." Stenberg wrote in the blog post, "It's strange that they're only sending an inquiry email about Log4j right now, which seems a bit late. ”
"It's likely just a template email sent to dozens or hundreds of other software vendors/developers. If it does come from larger businesses like the ones I've worked for in the past, they will most likely ask various IT support and development teams to compile a list of all the software/tools used by the business and the email address for each software/tool. So, it's highly likely that someone just sent an email to the vendor as required in the project plan to defer the issue and tick their box stating that the vendor/developer had been contacted. Some netizens speculated.
Netizen "Jack0r" introduced that his company stipulates that there should be an Excel list of dependencies, most of which are open source software, as well as some closed source and paid products. Developers set up a contact for each dependency, so emails related to a piece of software may be put into a list. But this list is often very outdated, and no one has specifically updated it.
"I was once asked to fill out a 3-page details sheet about Oracle databases, but we never used Oracle. Some software runs on Postgres, some runs on MySQL, some runs on NoSQL, but they say, 'MySQL is from Oracle, isn't it?'" Netizens came forward to say it.
And when a serious security breach arises, the person in charge of the Excel worksheet (not the developer, who doesn't know how the dependencies are used, or even what they are) must contact the owner of each dependency and ask them the same question. They don't do it to do something useful, just to tell their customers that "we're doing everything we can to fix this vulnerability." In most cases, these are even written into the contract.
Some netizens on Reddit also said that Stenberg received emails from paralegals who knew nothing about computers or open source. He just has a long list of names to contact so he can build defenses for the company from being prosecuted for hacking. He doesn't even care if the company is hacked or if it's going to be sued, he only cares about his job, which is to be prepared, just in case.
So, some people rejoice, which is why open source licenses are so important. Open source licenses protect the rights and interests of authors while ensuring that governance is the responsibility of the enterprise.
"Only build a house and don't care about the foundation"
"I think this could be a good example of the open source pyramid, where upper-level users don't even think about the maintenance of the underlying facility." Just build a house without caring about the foundation. Stenberg wrote.
At the very bottom of the open source pyramid are the underlying components, operating systems, and libraries, all of which are built on top of that.
The higher you go, the more the product is for end users, and enterprises can make more money, while the product iteration is faster, the language requirements are higher, and the share of open source code is decreasing. At the top, a lot of things are no longer open source. Conversely, the further down you go, the longer the product lasts and the language requirements are not good, but the impact of bugs is greater, and the repair takes longer, so maintenance is more important than refactoring. At the very bottom, almost everything is open source, and every component is relied upon by countless users.
As long as it is possible to make a lot of money without paying a lot for "public infrastructure", then there is little incentive for companies to invest or pay for the maintenance of certain things. But good enough software components also have occasional bugs, but as long as those vulnerabilities don't really threaten the people who make money, that won't change.
Stenberg believes that paying for the maintenance of dependencies helps reduce the risk of future alarms being raised prematurely on weekend mornings. The developers of the underlying components are in their job to convince users who rely on the functionality of their components that if they buy support, they can be more at ease and avoid any hidden pitfalls.
According to a survey of FOSS (free and open source software) contributors by the Linux Foundation and academic researchers, developers spend less than 3% of their time on security issues, and respondents don't want to increase their time on security. "The cause of security is a frustrating chore" "Safety is an unbearable and boring procedural obstacle." Having enough money for engineers to spend time on code maintenance may reduce the incidence of critical failures.
At the same time, the contradiction between the bottom developers and the upper users is deepening. On Jan. 11, Christofer Dutz, the creator of Apache PLC4X, posted on GitHub that he would stop offering free community support to enterprise users of PLC4X because he would not receive any form of return. If no company is willing to stand up and fund the project, he will stop maintaining and supporting PLC4X in any way.
Some components may be used by thousands of companies for a small but important task, and some may be like the Apache PLC4x, which may have only a few organizations forming a natural market. But there is currently no concrete way to measure the benefits of using components for businesses, and there is no one-size-fits-all solution to collect and distribute corporate contributions to open source projects.
The solution to the problem of open source sustainability is imminent.