r/LinuxUncensored

Google is making Pixel source code unnecessarily difficult to obtain — and GrapheneOS says this may violate GPLv2

If you haven't been following this, Google has changed how it distributes some of the source code needed to build and port Android for Pixel devices.

Previously, Google would publish the relevant source code through its Git repositories and push release/Beta tags. This is the normal workflow: when a new Pixel Android Beta comes out, projects like GrapheneOS can fetch the exact corresponding Git tag, port it, and begin testing.

Google has gradually changed this process.

First, Google started squashing the Git history into a single commit before pushing release tags. The source code itself was still there, but the full Git history was no longer available.

Now, for some of the source, Google has gone a step further: instead of pushing the release tags to Git, Google puts tarballs on Google Drive.

To get those tarballs, GrapheneOS has to submit a Google Form requesting access to specific files, after which someone at Google has to manually provide access.

The source code in the tarballs is apparently the same source code that would otherwise be available through Git. The issue is the completely unnecessary process around obtaining it.

According to GrapheneOS:

> "Initially, Google would usually provide access to the tarballs within a couple hours. Lately, they're often taking weeks to get back to us."

This is particularly problematic because GrapheneOS needs each Beta release. They use the Beta source to port and test upcoming releases in advance. Waiting weeks for Google to approve access can therefore directly interfere with development.

Google could simply push signed Git tags like it did before.

Or, if it insists on using Google Drive, it could automate access or give access to folders rather than requiring individual requests for individual files.

Instead, someone at Google apparently has to go through a growing backlog of requests and manually grant access.

GrapheneOS's position is that Google is obligated to provide the corresponding GPLv2 source, and that this increasingly slow and cumbersome process is Google's responsibility. If Google doesn't want to deal with repeated requests for every release, the obvious solution is simply to publish the Git tags again.

There is an important distinction here: GPLv2 doesn't require Google to use Git specifically. The mere fact that Google switched from Git to Google Drive isn't automatically a GPL violation. The legal question is whether Google is actually making the complete corresponding source available in a manner that satisfies the GPL's requirements.

But if the source corresponding to distributed GPL-covered software is effectively sitting behind a manual request system where access can take weeks, that's where the GPL compliance question becomes much more interesting.

And this isn't just an inconvenience for GrapheneOS. It makes the Pixel development process less reproducible and less automatable for anyone depending on Google's release source.

GrapheneOS also says this won't negatively affect its upcoming Motorola devices. Their partnership with Motorola allows them to prepare releases early and host the necessary Android Git repositories themselves.

So, ironically, the people most immediately hurt by this change are Pixel developers — including GrapheneOS — while Google is also making its own Pixel platform harder for third-party developers to work with.

Google could solve this extremely easily: Just push the signed Git tags.

reddit.com
u/anestling — 1 day ago

Is "open source = more secure" actually a useful rule of thumb?

Okay, a genuinely stupid question.

Why do we treat "it’s open source" as if that automatically means “there are more eyeballs checking it, therefore it's safer”?

I keep thinking about the supply-chain part of this, rather than the usual "Linux permissions v. Windows permissions" argument.

Take a big Linux distribution. A package gets updated because upstream released a new version. The distro may verify signatures/checksums, build it in controlled infrastructure, run tests, etc. Fedora and Arch absolutely have security/integrity procedures around this. But none of that means some security-qualified human has sat down and gone through the upstream diff and said:

>"Yep, I've personally established that this code isn't malicious."

Because, obviously, how the hell would anyone do that for something like glibc, GCC, LLVM, etc.?

At some point you're trusting the upstream project, its developers, its repository, its CI, its release process, its signing keys, etc. If an upstream developer's account/workstation gets compromised and a malicious change lands, "but the source is open!" doesn't magically detect it.

So, let's talk for a second about the big proprietary or not fish.

At least in a huge company with a lot to lose, there are actual institutional controls around the code. Microsoft, for example, documents mandatory review by someone other than the author, automated security checks, and additional approval/security gates before release. (Microsoft Learn)

In other words, there are actual meatbags in the loop with security clearances, real identities and contracts involved, etc.

Not just:

>"The maintainer pushed v1.2.7."

but more like:

>developer → review → automated checks → more review/gates → release

And yes, humans can miss things. Humans can collude. Accounts can get compromised. Nothing is magic. I'm not claiming Microsoft has discovered a mystical state of software purity.

I'm asking whether we've been oversimplifying the "open source is inherently more secure" argument.

Because "anyone can inspect the source" and "the software is subject to strong security controls before it reaches millions of machines" are two completely different propositions.

And this is not me saying every closed-source company is safer.

A tiny two-person ISV can absolutely ship a backdoored update, screw up its signing infrastructure, have a compromised developer account, or accidentally distribute malware. It has actually happened. It's even happened to quite big companies such as Realtek and may happen again.

That's a completely different risk profile from Microsoft or Google, where the company has crazy big financial, legal, reputational and operational incentives to put layers of review and controls around its software supply chain.

So I'm wondering:

Are we over-hyping source-code availability as a security property, while underrating the boring institutional stuff—separation of duties, mandatory review, release gates, protected build infrastructure, signing, monitoring, accountability, etc.?

Because if the answer is "yeah, whatever, open source gives you transparency, not inherently better security," then a lot of the usual Linux-vs-Windows security arguments suddenly look a lot less simple.

u/anestling — 2 days ago

Almost nobody pays attention to web standards anymore

>Nearly 90 percent of the of the 5,000 most widely used web domains were not serving proper HTML, as specified by the World Wide Web Consortium (W3C) and the WHATWG (Web Hypertext Application Technology Working Group).

theregister.com
u/anestling — 3 days ago

The 6-Year Saga of systemd Destroying SSDs: How a "Baseless Claim" Became a Hacker News Front-Page Reality

Remember in 2020 when yours truly opened systemd issue 15292 showing that 500 KB of text logs turned into 700 MB of SSD thrashing, only to be met with maintainer hostility? The maintainers famously declared "I don't think you know what you're talking about," insisted it was non-actionable, and closed the issue while collecting dozens of angry downvotes from the community. Because why fix an architectural design flaw when you can just insult the user's methodology and pretend write amplification doesn't exist?

Fast-forward six years, and nothing changed—except the frustration. In early 2026, a fresh ticket was filed, proving that writing just two lines of log per second in a virtual machine pushed storage to ~50 IOPS continuously. Systemd's memory-mapped hash tables were still dirtying entire 4 KiB pages, triggering filesystem metadata updates, and churning through gigabytes of I/O for a handful of log entries.

Then came the turning point: the new issue blew up on Hacker News, exposing the sheer absurdity of the years-long denial to the broader tech community. Suddenly, faced with public front-page embarrassment, the maintainers' dismissive wall crumbled. @ValdikSS stepped in with exhaustive isolated cgroup and loop-device benchmarking, proving beyond a shadow of a doubt that a single 750-byte log message regularly generates ~50 KB to ~70 KB of underlying disk writes.

Miraculously, once the corporate-backed enterprise maintainers were publicly put on blast, someone on the team finally decided to take a look and start addressing it. It turns out the issue was actionable all along—it just required six years of community pain, a dedicated independent researcher doing the maintainers' profiling for them, and a front-page roasting on Hacker News to make the enterprise overlords care.

This whole saga perfectly distills the systemd experience: a monolithic ecosystem engineered strictly for enterprise container hosts and cloud providers, where real-world desktop and edge hardware constraints are dismissed as "user error" right up until the PR optics become too toxic to ignore.

u/anestling — 7 days ago

uBlock Origin Is Giving Up the Fight to Keep Ads Off Facebook

Facebook employs people on six-figure salaries to keep track of uBlock's source code and filtering rules, specifically to thwart the extension's attempts to hide ads. This is not just mean and disgusting, it's freaking horrendous.

digitalescapetools.com
u/anestling — 8 days ago
▲ 39 r/LinuxUncensored+4 crossposts

I'm building a C++ code generator that helps build distributed systems. It's implemented as a 3-tier system. The back and middle tiers only run on Linux. The front tier is portable. It's free to use; there aren't any trial periods or paid plans.

This past Tuesday another jewelry store was robbed by a bunch of thugs. I saw some of this trouble brewing back in the 1990s and realized SaaS was a gift from above in terms of dealing with corruption. I'm glad I have some open-source code for my portfolio, but I'm glad it's not all I have.

There was another robbery in Freemont, California in June of 2025. Around 24 thieves raided a jewelry store and stole over 1.7 million$ of jewelry in 70 seconds. If the stewards of that store decide to rebuild, I predict they won't replace the display cases that were smashed. It will be a "by appointment only" store and they will frisk you before they show you anything. Of the 24 thieves, only a handful of them have been caught.

In other words, the store managers will replace their open model with a SaaS model. And who can blame them?

u/Middlewarian — 9 days ago

Everything wrong with Linux: Mint Developers Change the Way Linux Kernels Are Tracked

The fact that you need a special manager speaks volumes about the atrocious state of the Linux kernel development.

Either you can use brand new kernels with dozens, sometimes hundreds, of regressions, or you can use an LTS kernel that doesn't support your hardware.

Wait, there's more. What if e.g. audio doesn't work for you and the ALSA driver/module needs a quirk? How are users supposed to do that? I'm not aware of a single distro that allows users to build only parts of the kernel and run them with their existing kernel without rebuilding the entire thing just for your PC which results in a lot of energy being wasted and users having to learn console, make, kernel install and GRUB enablement commands that differ from distro to distro.

What if you need to install or run code that hasn't even hit the mainline? The AMDGPU bug tracker is full of such requests. And this is not an isolated case. Check LKML and kernel bugzilla - you'll see a ton more.

This is a freaking mess of epic propotions.

Essentially we have just few complete/verified kernels:

  • RHEL (for qualified hardware configurations)
  • SteamOS (ditto)
  • ChromeOS (ditto)
  • Android (some continue to insist Android is "Linux" - whatever, let's include it)

No other distro on the list. None whatsoever. You take it or leave it. No warranties. Nothing.

And then there's Secure Boot which makes everything even more complicated. 99.99% of people out there will never touch anything related to MOK. They will simply avoid Linux. Too much hassle for something that's perfectly supported out of the box in a form of Windows.

9to5linux.com
u/anestling — 10 days ago

Valve slowly expands SteamOS support on non-Valve hardware

One of the few actual Linux operating systems along with RHEL, Android and ChromeOS. Cannot think of anything else unfortunately.

arstechnica.com
u/anestling — 11 days ago