Hacker News new | past | comments | ask | show | jobs | submit login
Making Open Source software safer and more secure (blog.google)
83 points by firstSpeaker 13 days ago | hide | past | favorite | 64 comments





This isn't something unique by Google. It's Google's PR announcement they went to the White House leaders in industry, all talking about open-source security. The list of attendees included representatives from Akamai, Amazon, Apache Software Foundation, Apple, Cloudflare, Facebook/Meta, GitHub, Google, IBM, Linux Open Source Foundation, Microsoft, Oracle, RedHat and VMWare

The only organisation there which really focuses on open source software is Apache.

All the rest specialise in proprietary software, and only do open source software as a side thing. They represent open source as much as the gas industry represents renewable energies.


They represent the risk. Apache may write the software, but the commercial companies are the ones that actually deploy it and touch sensitive data. Also, IBM owns Red Hat so I don't really agree with the premise.

Ideally the white house should meet separately with the "consumers" on one hand, and the producers like Apache and Red Hat on the other.

Also, the government should get way more in-house expertise. I am a firm believe in an all-capable administrative state which should be able to do just about anything in the economy, even if it chooses not to or can't do all at once. The government needs way more in-house programmers doing various things, and those civil servants should be in these meetings so it's not just the vultures tricking the politicians.

In general, in-house expertise should be a bulwork aginst regulatory capture. E.g. If HHS/FDA/NSF did its own drug development not just drug research the incentives would be very very different.


Is the Linux Open Source Foundation just a misnomer then? And GitHub actually has a vested interest in open source working and working well.

> really focuses

I disagree. ML and DL have become core parts of Meta and Google, both. And both of them do it very openly.

Meta and Google regularly contribute to open research in AI and all their tools are open source.


Many vendors were at the White House meeting today. Here's Red Hat's statement: https://www.redhat.com/en/about/press-releases/red-hat-state...

This seems like it is the second time we have had to learn about the importance of maintain large open source infrastructure projects like this. log4j and openSSL before it, show that these projects aren't just the responsibility of the maintainers, but all of their users as well. We really need more money being paid by larger users like Google directly to the maintainers.

Google doesn't use Log4j; they built an in-house logger.

Meanwhile, they fund OpenSSL (https://arstechnica.com/information-technology/2014/04/tech-...) but are also funding alternatives (https://www.neowin.net/news/google-provides-funding-for-deve...).


Google does certainly use log4j. They didn't write every single line of code themselves that they're using.

It's possible it's being used somewhere in an open-source external project that Google produces. I can't name anything off the top of my head.

... but in-house, in their running-on-Borg services written in Java, they have their own API for log capturing. Log4j doesn't offer nearly the level of integration to their logging and tracing fabric they need. And the Cloud Logging API has adapters for Log4j, but none maintained first-party, IIUC.


Google's codebase is huge and has many weird corners, but the monolith structure meant that virtually everybody switched over to a different logging framework a while ago.

Anyone serious on this should work with https://www.softwareheritage.org/, Nix, and Guix.

The status quo is negligance for yours, and they are not interested in proposing meaningful standards that would require redoing their stuff in a Nix/Guix style way.


@dang, the title should probably be: "Making Open Source software safer and more secure"

This isn't just a Google thing, lots of companies were at the summit.


It is however google's way of security: "to help prioritize and allocate resources for the most essential security assessments and improvements". Fix one bug, introduce 3.

Only one voice here, but in this case I'd vote for retaining the way that the article has been titled by the poster (and content authors).

It's a bit discouraging that my thoughts fall immediately into suspicious. I can't help it.

Obviously we all want more safer and secure software, but in reality, I feel like vulnerabilities get worked on pretty fast... not sure if we need a saviour. On the other hand, it is good that big companies that do benefit from open source software actively contribute to make it better.

So yeah. Mixed bag of feelings as with everything.


The list of companies in attendance is like a who's who of corporations that should be paying the maintainers of the open source they are using. What is needed is an equitable compensation arrangement for corporate users of open source.

Anyone can write a license with a free until $X in market cap.

It puzzles me a little when large companies adopt names that have reasonably wide recognition already in the free and open source world.

For example, Microsoft's operating system name "Vista" shadows the name of perhaps the longest-running open source software project in existence.

And Google's project name "Salsa" shadows the GitLab version control repository for Debian packages.

It's most likely pure coincidence, or perhaps imitation as a form of flattery; and probably also not infringing in any technical copyright or trademark sense.

Securing open source software will require disambiguation of software by package name. I think they could lead by example by disambiguating their own initiative names; that will be part of the problem space before too long (in other words, knowing more clearly what services and participants are involved in the overall ecosystem).


There aren’t enough simple and nice words for every project to have a unique one. It’s usually pretty easy to find what you want. Just search “salsa Debian”

More-or-less agreed, yep, it's a tricky problem. To compare with technical solutions, I guess the options available are things like namespaces, lexical scoping, or (bleh) more verbose variable naming; perhaps something along those lines could be helpful.

Aka Google wants government contracts too! If it's anything like their DMCA system or customer service this is going to ultimately be bad for citizens.

Would we be better off with

Akamai, Amazon, Apache Software Foundation, Apple, Cloudflare, Facebook/Meta, GitHub, Google, IBM, Linux Open Source Foundation, Microsoft, Oracle, RedHat and VMWare

having more control or total control over open source software? Creating moats that make it harder for the average developer to contribute to the ecosystem seems like a power grab.

On the surface it is a positive with benefits for the user but longterm it could be the death of open source.

Everytime a large corporate or two takes over a space no matter what they never give them back to them. This is turning open source over to existing powerful companies to control or kill.

At least they haven't made 'unregistered open source change' an illegal act yet but we are closer than ever


thank you and I agree with your basic sentiment; that said, there has already been strong evolution by practitioners but that evolution is unpredictable, and perhaps more importantly not trusted. It could be said the penultimate executive function is to decide on change in trust, and then make it so. This is that sort. In my opinion as a US citizen, there is no realistic way out of this in the short term, but instead go to your teams and colleagues and emphasize your own executive privelages, understand what is being asked for "better security" and .. evolve.

this is a nightmare of big govrt plus big tech.

this will turn into yet another government granted monopoly like Telecom. few players control the entire industry and in return, govrt can tap into their network.


Are they trying to centralize open source? If so I'm against that. It would make it easier to file false takedowns like with youtube-dl.

Not centralize, probably more like regulate.

The criticality score in the referenced post about critical projects [1], the resulting projects [2] and the the "combined" list of various other sources of critical projects [3][4] all don't seem particularly on-point to me.

Particularly the criticality score ratings seem just about entirely useless. Mostly seems to reflect different kinds of workflows. Using things like comment frequency etc will never get at the type of projects the xkcd comic in [1] is about.

[1] https://opensource.googleblog.com/2020/12/finding-critical-o... [2] https://github.com/ossf/criticality_score#public-data [3] https://github.com/ossf/wg-securing-critical-projects#how-we... [4] https://docs.google.com/spreadsheets/d/1ONZ4qeMq8xmeCHX03lIg...


If Google is involved, I don't trust it.

Me neither.

Can we trust a for profit company on open source software after IBM/RedHat botched CentOS?

Coming soon to GitHub and npm: KYC and background check.

"secure"

Coming soon to kill your open source project: a current chain of custody and audit certificate that all corporations will require in your repo (along with that MIT license!). Too expensive for you to procure because this is a hobby side project? Don't worry, some other company will fork it and take control--most companies would rather have an OSS library from some other corporation than github.com/fortnitedude anyways. Thank you for your OSS contribution, we'll take it from here.

Which is it: you want them to use the software or not? What do you care if it carries the added label? If they secure your software, stick a label on it and you get to add their changes back to your project if you like them, what's the problem? Normal open source process, in a good way - or do you want open source to be open, but just to people you like?

The only thing you might complain about is the already existing problem that it's damn hard to get paid for writing good open source software, unless you work for a business like these - this doesn't really make that worse though, or at least not for the wrong reasons.


(unless your problem was with someone sticking an MIT license on it in the first place, but that's hardly Google's fault in this case?)

I'd rather have a maintained and secure fork of some library from a corporation than an unmaintained and deteriorating library from someone who can't afford to upkeep it.

Or they charge you to upgrade to the latest version and then lock you out of the software if you aren't up to date because it isn't secure. That could happen to.

If it is open source then we can just fork off of the last free version. Lets at least take advantage of the corporations who also want successfully maintained software.

Corporations don't have to maintain open source software under open source licenses if, for example, that software was released under MIT or BSD licenses. They could very well take an project with an MIT license and make it proprietary, and there won't be any free versions to fork from.

> Corporations don't have to maintain open source software under open source licenses if, for example, that software was released under MIT or BSD licenses.

If they own the copyright and control the only source code available, they can change the license regardless of whether it is permissive or copyleft currently.

If they do only the second, they can shut down the repo regardless of the license, even if they don't change the license, and unless it's something like AGPL continue internal use.

If they don't control the only archive of source code, then even if they can change the license going forward, other people can continue to distribute and fork off from the last Free version (again, irrespective of whether permissive or restrictive.) Unless they both own the copyright and have the legal power to retract the license offer for the earlier code (contrary to the usual express terms of license grants, which may be possible if it is a gratuitous license, but even if it is may not be fully effective in all cases because of promissory estoppel.)


Does the license permit it ? If yes then they're not doing anything that the author didn't want them to do.

They license may permit it but the author may not have envisioned this kind of nefarious use that the license permitted.

If you're outside sweeping your steps and I walk by and ask to see your broom for a second and then I beat you to death with your broom you aren't to blame because you handed me your broom.


Your broom example is flawed and in no way a match to the situation.

If you build a broom and I ask if I can see it and you say yes you can see it and you are free to make another one like it for yourself and make more to sell for everyone else, then you can't complain about them doing it.

As for the "they didn't envision", then it's entirely their fault. If they put their code online using default copyright law, this wouldn't be allowed, they specifically picked a license that allow it.


> can't afford to upkeep it

Address the cause, not the symptom. Make it so these individuals are more capable of upkeeping their projects. Otherwise, over the long term, you'll end up with projects disincentivized to do the maintenance, leading to a weaker open-source community.


You'll have the worst of both worlds.

Can you explain?

Not OP but they probably mean you don't get the competitive advantage of owning your own purpose specific codebase, but your library also doesn't have an agile community that's working on it "for free".

What you’ll have is an unmaintained insecure fork held in place by a company who doesn’t have to do any maintenance, since they, and their code, are declared “secure” by fiat.

I don't see how that's any different than where we started from? Google can't just take over an open source library and declare no one can work on it any more.

If it’s MIT or otherwise permissively licensed, they absolutely can take it over by forking, putting enough work into it that it’s not worth continuing the original version, and then not releasing it openly, or with complicated entanglements.

If it’s GPL or similar, the process is slower. They will probably immediately start a grand redesign which will, incidentally, not use the GPL library. In the short run, they will start a replacement implementation of the GPL library, incidentally permissively licensed. Both will take time, but usually gets there.

Both of these cases are seen all the time.


Honestly, sounds amazing.

If I have code where that isn't literally free labor for my business/project, I'll keep it closed source. If I have code where that's free labor but also competes with or commodifies my business/project, I'll keep it closed source or use GPL.

This sort of boils down to "only use MIT if you really mean it", right?


IBM botched RedHat/CentOS, i won't trust a for profit corporation on open source software

So don't merge their forks?

I am really worried that this is where the focus around "security" is going to end up leading, and in so doing kill the spirit of hacking around. Kill any competitor or software startup by requiring a long checklist of "security" items before any software can be sold, or used.

And most of it will be security theater that looks good but does little to actually support secure computing because at the end of the day Bob is going to plug in a USB that Mallory drops in the parking lot that says "XXX Pics".


Agreed. Most of the "security" I see coming out of these companies serves to secure their own revenue streams, and then it's pitched to users as existing for their own benefit.

Yup, regulatory capture is coming for your software.

> Coming soon to kill your open source project: a current chain of custody and audit certificate that all corporations will require in your repo (along with that MIT license!).

Why would that kill your project? Presumably you’re maintaining it for your own use if it’s a hobby project. Who cares if some for-profit company who wasn’t contributing code or financial support doesn’t use it?


It is already like that for closed OSs: Mac and iOS have required "signed" binaries for years now, which force the developer to register with Apple, use Apple hardware, and pay an annual fee. Similarly for Android. And Windows is on the same track.

> most companies would rather have an OSS library from some other corporation than github.com/fortnitedude anyways.

I think any project that's not a hobby project and is responsible for providing a quality, reasonably secure product to paying customers would prefer this. Be it a mega-evil-corp or a scrappy startup or anything in between.

But if you're a founder of such an open-source project that is getting interest from big companies, that sounds like an opportunity to get funding and turn your hobby project into a startup. Pretty sure most of those mega-evil-corps and scrappy startups would rather pay the project founder and originator than some fork.


> Coming soon to kill your open source project: a current chain of custody and audit certificate that all corporations will require in your repo (along with that MIT license!).

For anyone that thinks this is hyperbole, this is already close to the current standard for shipping any executable to Windows or macOS machines today. If you want your app to run on either operating system, you first must buy certificates every year and sign your apps with them, and then you must remain in good standing with Microsoft or Apple if you don't want those certificates revoked or if you want them to be renewed.


Hopefully, "support" and "investment" are code for "contributions" and "donations".

Because 'do no evil' HAHAHAHAHAHA... sigh. https://gizmodo.com/google-removes-nearly-all-mentions-of-do...



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: