Hacker News Reader

""Don't trust user input" hass been a fundamental rule of security for a long time, and it was reasonable to assume the log4j authors were aware of it. So the current situation is not that requirements have suddenly became stricter, it's simply that log4j broke a fundamental assumption about its API."

Once you see it this way, the whole "open source is broken" debate goes out the window. It was just a bug. A bad one, but not anything that hasn't happened before and won't happen again, open source or not.

"Yes, free software devs can smugly repeat their stance of "it's a gift so don't complain, no guarantees about anything" - but if everyone took this serious, no one could use free software for anything critical, so the free software movement would be mostly dead."

Free software devs have to smugly repeat "no guarantees about anything" in the same way that non-free software development has to do it: Otherwise all software development would be mostly dead.

>Yes, free software devs can smugly repeat their stance of "it's a gift so don't complain, no guarantees about anything" - but if everyone took this serious, no one could use free software for anything critical, so the free software movement would be mostly dead.

I don't think they have to smugly reply, it's included in the licence[1] of the software that folks chose to use. See sections 7 and 8

1: https://logging.apache.org/log4j/2.x/license.html

There is social context to licenses.

My employment contract states that I am an at-will employee, so my boss could technically fire me because they didn't like my haircut. If they were to _actually_ do this, I would certainly be slighted by this, probably post about it publicly and forewarn others against working for them, although they would not have violated the letter of the contract nor my understanding of its literal meaning.

> There is social context to licenses.

What is the social context in terms of open source software and licences?

> so my boss could technically fire me because they didn't like my haircut. If they were to _actually_ do this, I would certainly be slighted by this

If we translate this to the log4j scenario: log4j says there is no support or warranty provided in their licence, however if they _actually_ do not provide support or warrant, you would be slighted by this.

To me this does not sound fair at all. Your boss at least pays you for your time as part of your contract. What do the log4j developers get for their time? Absolutely nothing. Yet it is expected they should provide support even when the licence says they won't? That's just comes off as entitled.

Drew DeVault has blog post that covers this better than I can: https://drewdevault.com/2021/06/14/Provided-as-is-without-wa...

Right, and I disagree with that post in this sense: there is a social expectation of fitness for a purpose that cannot be disclaimed with a license.

Many projects under licenses providing no warranty are nevertheless of high quality and well-maintained. Making the category in question precise is difficult, but it includes log4j. Projects by organizations such as Apache and eminent individuals like Bellard or Valsorda fall in this category. There is therefore an expectation that if you are such a project, yet unwilling to hold yourself to that standard of quality, you should make it clear for your users. Using a license with a no-warranty clause does not achieve it because it is not a distinguishing factor. The license, of course, protects from legal liability and so on, but no one is talking about legal matters here -- only about whether we should be collectively unhappy with the log4j maintainers.

The reason for this unhappiness would not be that they aren't willing to donate more of their time, but that their stewardship of the project is poor. Vulnerabilities are found in FOSS all the time; this instance was special because the misfeature in question was an egregious inclusion in the first place. It appears to be not a case of lack of time for review, but a lack of sense to say, "no, interpreting strings after formatting is insane and will never be part of this library." Obviously, they are entitled to include whatever code they want in their project, but some code is incompatible with it being useful -- if they do not aim to clear that bar, they should make it clear, because others in their position do.

I would say that something like opening your README with "this is not a serious project, you should not use this in prod" would be reasonable. This warning needs to be front and center and explicit, not merely sating "we are unpaid volunteers" or similar. There is precedent for this. Yes, some ignore such warnings and complain -- as long as this verbiage creates a useful distinction, such people are wrong and we should ridicule them. This warning would stand in contrast with the great many projects which aim to be fit for a purpose in practice, such as Postgres, Linux, Blender, etc. Obviously, such projects are usually better funded than log4j -- making it clear that you're not funded well enough to dedicate much time to the project an important part of this warning's content.

To continue the workplace analogy, I would be the unreasonable one to complain if the company specifically warned that they were significantly more trigger-happy that the normal company hiring at-will.

There is no such context. The licence specifies clearly and completely the terms of use. You cannot handwave an unwritten "social context" into existence, that adds and obligation to the creators that their licence explicitly refused to accept. What you get, of course, is the actual source code.

It's understandable that you would assume such a spurious obligation, human history is full of references to such obligations, up until the age of Big Data, which is when we realized that most of these assumptions were false. It's been a painful time for all of us.

In fact, the actual obligation is yours, if you decided to use this logging library. Seems there was a severe vulnerability in the code. It also seems that the people who responsibly forked the code, ran their own security audit, discovered the vulnerability and then patched decided not to make their contributions known to the general community of users of the software. They, if they exist, seem to be acting as if no obligations exist with respect to the code they acquired.

Speaking of assumptions, your proposed actions regarding your employment assume that your boss was obligated to tell you the reason your contract was terminated. Again, no such obligation exists. They can't fire you out of disgust for your Satanism, or because of your Innuit heritage, or because there are ambiguities regarding your gender. Luckily for them, at-will employees can be terminated, well, at-will, so there is no need for them to specify that it was not, in fact, because of your quite stylish haircut. Your public postings might in fact earn you a letter from the legal department, since you have no way of knowing the real reason was that you downloaded logging code on to mission critical servers, and lacked either the inclination or capacity to verify this internet code, and then when asked about your decision to do this thing, you quoted an imaginary "social context," an unwritten, unknown construct, that in this case silently tacks on the term "users of this library will receive free, unpaid support in perpetuity" that functioned exactly like Adam Keynes "invisible hand," that is, some rationalization to absolve you of the responsibility for explaining problematic aspects of the mental model used in your decision making. This was a vast surprise to the administrators of your company, who, understandably, know very little about logging libraries, which is why they hired someone to provide the required functionality.

This is what happens as things move more into mainstream from a few technical users using this as intended in sort of a small walled garden so to speak and then as it grows you get non technical users and bad actors. Look how smtp started, open for anyone where open relays were expected, to what we have today - still a large spam problem, compromised accounts with security on top of it. There are lots of rewrites and different smtp programs as things like smail and sendmail were replaced by exim, postfix and qmail (qmail which is free software, but really unmaintained and could be anyone's problem if they wanted).

I'd argue if there is an application that being built on libraries with out a full understanding of keeping them maintained over the years you will get a massive cluster fuck with code rot. These are things that are learned with experience, as a dev starts they take short cuts and learn from the mistakes. It is not a bad system when you are learning from your mistakes. There are simple solutions like using an operating system that is maintained. Log4j and java packages exist for example in operating systems that get security updates - and continue to do so for the life of the operating system.

Yeah, my guess is also that long-term, software development will involve less libraries and more "reinventing the wheel" for those reasons.

> Log4j and java packages exist for example in operating systems that get security updates - and continue to do so for the life of the operating system.

But how does an updated OS help if the packages themselves are not updated?

> Yeah, my guess is also that long-term, software development will involve less libraries and more "reinventing the wheel" for those reasons.

I very much hope not.

I would greatly prefer to see some certification bodies arise that can vet libraries for exploits like this and give a certificate of some sort saying "This library is safe to use".

Of course, that requires them to have some extremely good exploit-finders.

> But how does an updated OS help if the packages themselves are not updated?

Package maintainers apply patches and roll a new package version (e.g., +deb11u1).

At some point the package maintainers themselves may not want to babysit things anymore and deprecate the package. But most packaging systems that I'm aware of have mechanisms for applying patches.

In many cases even if the software itself is still maintained, the package maintainers may only apply a specific patch to ensure maximum compatibility.

It's why many of us prefer 'slow moving' distros with "old" packages: minimal change for a given version and then only when 'necessary'.

It's also a competitive problem.

Log4j commoditized log formatting, appending, and rolling for Java. If all my competitors use it and I don't, then I'm behind them in the market. I spent engineering resources creating my own, and add another layer to the NIH snowball which will eventually start rolling all on its own if I don't constantly invest a small amount of my limited attention into stopping it.

I only win if my competitors don't get away with it. Whole empires have been built in the time between log4j being 'production ready' and the discovery of this RCE bug. I'm reasonably sure that the majority of software companies that have ever existed, existed during this period, and any of them who used Java got away with it, and trillions of dollars to go with 'it'.

> However, it might as well happen that this is not enough to keep security issues from happening. Things are already moving in a direction where it's absolutely expected that a developer understands and takes responsibility for every line of code that is included in their prodiuct, whether they wrote it themself or not. But if that happens, it will fundamentally change the way we deal with libraries and how software ecosystems work.

That's one of the differences between coders and engineers.

Coders just import libraries to avoid re-inventing the wheel. Engineers consider each import as a dependency they'll have to maintain, buy support for or replace. Log4j just highlighted this difference, with some knowing exactly what to patch and others franctically trying to determine if one of the thousands of dependencies they imported into their app actually used it.

> Yes, free software devs can smugly repeat their stance of "it's a gift so don't complain, no guarantees about anything" - but if everyone took this serious, no one could use free software for anything critical, so the free software movement would be mostly dead.

There's a simple alternative: hire the devs.

I have zero sympathy for the library users who got burned by this security defect. It's fine to use free software for critical systems, but only as long as you have developers who can maintain it internally or a paid support contract with a vendor who can do that for you. Those options cost money. If you fail to account for that in your software bill of materials then you deserve the consequences.

Back a few decades ago, companies (at least ones I worked at) did not often use open source libraries in products. Sometimes you'd go through months of lawyer meetings to get some special case approved, but that was rare. So when you needed a library you couldn't write internally, you'd buy it from a vendor. That came with maintenance and a support contract.

As a developer that was a bit of a pain since you had to get purchase approval instead of just adding a dependency to a build file.

But, I'm feeling that is actually the better model the industry should go back to. It meant that developing libraries was actually a viable business. Today companies just leech off the open source everything, externalizing all their costs and dumping the maintenance burden on unpaid volunteers.

"As a developer that was a bit of a pain since you had to get purchase approval instead of just adding a dependency to a build file."

How much of a pain was it when the vendor refused to fix your bug because it, or you, weren't important enough? When the vendor went out of business, or was bought by a company uninterested in the product you were using?

Oh, and when you consider writing a library internally, keep in mind that patents are a thing.

"It meant that developing libraries was actually a viable business."

Yeah, I remember that. I remember when there were a million billion little companies producing C++ libraries. Then C++ started to get really popular, and those companies' customers went from a small group of experts to a large group of, uh, non-experts. Then they discovered that support was hard and all went out of business.

I really wonder what would have happened it HP hadn't open-sourced the STL...

How do you 'leech' off of something intended to be used for the common good? That perspective just doesn't make sense.

> Because for a long time, libraries have been advertised as building blocks that you can quickly integrate into your own application without having to understand in detail how the library works.

Libraries in general have been advertised this way, but it's not true for any given library, unless the library maintainers make that claim. In fact, it's quite common for people to release libraries with the exact opposite claim: They are not liable for anything that goes wrong, and they don't promise any support.

It is a bit offensive to have expectations from someone when the person makes it unambiguous how their SW can be used, and where their responsibility lies.

Now yes, it is true that many major, popular open source libraries do make a show of their libraries being reliable, and do provide support. And those that do tend to have more adoption. But even a number of those do say "Hey, we're putting in this effort, but are not promising bad things won't happen."

> Yes, free software devs can smugly repeat their stance of "it's a gift so don't complain, no guarantees about anything" - but if everyone took this serious, no one could use free software for anything critical, so the free software movement would be mostly dead.

This is transforming a continuum into a fairly worthless binary scenario. You're not going to have every library say "We won't provide support" just as you won't have every library say "We'll follow best security practices" - so why bring it up? It's trivial to show the latter would have likely killed the free SW movement too.

The reality is a continuum. And that is how the free software movement succeeds.