Native dependency cache
Native dependency cache
Posted Jan 29, 2025 0:45 UTC (Wed) by bluca (subscriber, #118303)In reply to: Native dependency cache by ibukanov
Parent article: Vendoring Go packages by default in Fedora
Posted Jan 29, 2025 1:12 UTC (Wed)
by ibukanov (subscriber, #3942)
[Link] (42 responses)
My impression with Go discussion in Fedora is that packaging Go dependencies into RPM is precisely the pain point the maintainers complain. The need to maintain separated copies of dependencies on distribution servers I suppose will be much smaller issue if they can just use the native go format.
Posted Jan 29, 2025 1:21 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (41 responses)
Posted Jan 29, 2025 6:40 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (39 responses)
It's trivially easy to package a native Go package into an RPM. Completely, with all the dependencies:
`go mod vendor`
That's it. You can gzip the resulting directory and package it into an SRPM. During the build time, it will not require any network access. Go even embeds the package versions into the resulting binary, giving an easy access to SBOM. This is enough to get Fedora/Debian users access to Go applications.
If you want _development_ to be easier, Fedora or Debian can provide a Go package mirror. Basically, a proxy that allows fetching of the module sources. It's entirely optional, though it will make life easier for developers.
And if Fedora/Debian want to uncrustify their distro and make it genuinely more useful, the SRPMs can install the dependent modules into the shared system-level cache instead of confining them to the source tree of the SRPM. It will require additional tooling from distros, as the same module can be installed by multiple packages, and deleting one package should leave the module available.
However, there's no problem with installing multiple _versions_ of a package. It's perfectly fine if one utility depends on `gorm@v1.9.19` and another one needs a much newer `gorm@v1.25.10`.
Posted Jan 29, 2025 7:00 UTC (Wed)
by gioele (subscriber, #61675)
[Link] (2 responses)
DEBs are pretty much reproducible.
What is the equivalent Go/Rust/any language page of Debian's https://tests.reproducible-builds.org/debian/reproducible... ?
96.4% of the Debian packages can be bit-for-bit reproduced (100% of the essential/core packages).
Posted Jan 29, 2025 19:53 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Cgo builds depend on the underlying build system, the Go part is still automatically reproducible, but the linked C libraries are outside of Go's control.
Rust is more complicated, as it's often more low-level. Cargo guarantees that the build environment is bit-for-bit reproducible, but there are lots of small issues that can cause the resulting binaries to have host-specific bits. You absolutely can make the builds reproducible, and the work is being done to make that automatic. The issues are tracked here: https://github.com/rust-lang/rust/issues/129080
Posted Jan 29, 2025 20:57 UTC (Wed)
by gioele (subscriber, #61675)
[Link]
In other words: after years of fixes to the toolchains, now most packages are reproducible by default, except some that are more problematic and need extra care.
Posted Jan 29, 2025 11:15 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (31 responses)
Yeah except for the tiny problem that none of this is true
> `go mod vendor`
Yes, that's it, you have now ingested, vendored and locked down some malware, as it came from a cesspool with no gatekeeping whatsoever. Success!
> However, there's no problem with installing multiple _versions_ of a package. It's perfectly fine if one utility depends on `gorm@v1.9.19` and another one needs a much newer `gorm@v1.25.10`.
It is very much problematic, as every time gorm has a bug, it needs to be fixed 190238912381 times, instead of once, for the convenience of a handful of developers who don't care about backward compatibility. Again, it's the usual attitude with these language-specific package managers: "I care about me me me, screw everybody else". This is not how Linux distros work. This is not how a sustainable, stable and secure ecosystem gets built.
Posted Jan 29, 2025 12:52 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (13 responses)
And this not how a friendly, sustainable, and popular ecosystem gets built.
For $DEITY's sake, stick your head out the window and smell the coffee. MOST users don't give a monkeys about all that stuff. They have their programs they want to use, and that's why they don't run Linux. Their programs just don't work on Linux because it's a DEVELOPER-friendly system, not a USER-friendly system. FFS most of the software *I* *want* to run typically either (a) doesn't work on *modern* linux (so much for your vaunted stable API), or requires an emulation layer like Wine or VirtualBox.
And that's because of the simple laws of economics - if the majority of people who want the software is a disjoint set from the people capable of writing it - then Linux is just not seen as a viable platform. And like it or not, the majority of FREE software that gets written is by developers scratching developer itches to make developer-friendly software. NOT USER-friendly software. Never forget that the Cathedral in "the cathedral and the bazaar" was not proprietary software, but FREE software.
Oh - and which is better - a system which produces prodigious amounts of buggy code and NEEDS to be updated regularly to fix it, or a system which despite being harder to update actually produces far less buggy code in the first instance! ESPECIALLY for security code I would much prefer the latter - almost certainly far fewer 0-days!
(And no, I'm not saying we necessarily want Linux to be wildly popular, but equally we don't want it occupying a niche where it's forever vulnerable to DRM (the nasty version), or TPMs, or Meta-lomaniacs, and the like.)
Cheers,
Posted Jan 29, 2025 12:57 UTC (Wed)
by pizza (subscriber, #46)
[Link]
This is true of *every* platform.
Or do you think that any bit a tiny minority of iOS, Android, MacOS, and/or Windows _users_ are capable of writing software for that platform?
Posted Jan 29, 2025 14:43 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link] (11 responses)
What program written in go does a end user who isn't a developer need? Can you cite one such program?
The reality is that go is solely used for jsonrpc or CLI kind of things. So the argument here seems completely OT.
Posted Jan 29, 2025 16:02 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
With respect to all the targeted users of linux, not at all. I would prefer to use linux for all of my stuff, but unfortunately, as a USER, I find most of the stuff I want to use needs some sort of emulation layer. I wish either (a) it didn't need that layer, or (b) I could *buy* a version that works on Linux.
I'd like to see far more software available for linux, but actually it's probably this LACK of a stable API (real or perceived) that puts vendors off packaging their stuff for linux, and it's all the assortment of distros that don't help. Can I build a binary, and copy it between distros, and have a reasonable expectation it will "just work" (tm)? Or do I have to run Red Hat, because that's the only thing that works?
When I was on the LSB, my biggest frustration was that all the emphasis was on enabling the distro to tell an application what the distro provided. Completely arse-about-face imho. What I wanted was a mechanism whereby the APPLICATION told the distro what it wanted! What it needed the distro to supply. Without that, it doesn't matter HOW good your distro is at managing all these assorted libraries, the application is going to vendor the lot because they can't tell whether the distro provides it or not. Dynamic linking is irrelevant if the application installs everything "to make sure I've actually got it".
There's far too much linux guys thinking they're doing the world a favour. The world is only too happy to look this gift horse in the mouth, because they can't see how it solves *their* problems. And as bluca said (in a completely different context, but) this gift horse eats too much hay for too little perceived benefit.
Cheers,
Posted Jan 29, 2025 22:53 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link]
Posted Jan 29, 2025 19:21 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Plenty of such programs exist. For example, I was only able to set up secure boot on my Fedora server by using `sbctl`, written in Go. Fedora provides `mokutil` but it was plain broken.
The UI experience with both of the tools is also incomparable. `sbctl` can do this:
> # sbctl verify
I have never been able to get this output before without strange incantations that I copy-paste from Google.
Posted Jan 29, 2025 22:48 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
Posted Jan 29, 2025 23:13 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
So not a "user buying a laptop at Walmart", but still "end-user" functionality.
Posted Jan 29, 2025 23:17 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link]
Posted Feb 7, 2025 19:04 UTC (Fri)
by TheBicPen (guest, #169067)
[Link] (2 responses)
A cursory look at GitHub shows plenty of examples. Syncthing, Alist, AdGuard Home, Photoprism, LocalAI, Croc, lux, filebrowser. I don't know why you think that go is only for writing developer tools.
Posted Feb 8, 2025 20:32 UTC (Sat)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
Posted Feb 8, 2025 21:05 UTC (Sat)
by intelfx (subscriber, #130118)
[Link]
You are obviously arguing in bad faith.
Posted Feb 8, 2025 22:21 UTC (Sat)
by dskoll (subscriber, #1630)
[Link]
What program written in go does a end user who isn't a developer need? Can you cite one such program? Oh, sure. Here are two, in fact:
I know you wrote "need" and could argue that you don't need the above programs, but they are very nice and very useful.
Posted Jan 29, 2025 19:41 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (16 responses)
It is. Sorry to break your entire worldview. It's obsolete and is already showing its age by failing to keep up with the status quo of 10 years ago.
> Yes, that's it, you have now ingested, vendored and locked down some malware, as it came from a cesspool with no gatekeeping whatsoever. Success!
Nope. It will get the locked versions of packages that are specified in the dependency list (go.mod and go.sum). They are cryptographically verified to be the same (go.sum contains the hashes of packages). If you think that the package author is malicious, then don't package the software in the first place.
> It is very much problematic, as every time gorm has a bug, it needs to be fixed 190238912381 times
It's trivially easy to write a tool that goes through all the packages having `gorm`, tries to upgrade its version, and does a test compilation. Which is more than Debian/Fedora do, anyway. These tools already exist, btw.
> instead of once
This is a lie. If something like libffi has a bug or a new feature release, EVERY SINGLE application depending on it has to be checked. For bonus points, one application might depend on features (that are perfectly safe!) that are no longer available in a newer version.
And since C/C++ doesn't have a stable ABI, there's often no way to check that statically. As a result, every Fedora/Debian release is broken at least for some packages.
Posted Jan 29, 2025 19:54 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (3 responses)
It is not. They will be around long after things like golang have faded into obscurity because the one corporation bankrolling it starts chasing the next squirrel instead. How many languages has Google killed by now? Are we in the double-digits already or not yet?
> Nope.
Yep. Because there is no gate keeping and an email address is all that's required, so anything goes. I mean just check Pypi ffs. Golang is just unpopular so it's not worth targeting it - yet.
> It's trivially easy to write a tool that goes through all the packages having `gorm`, tries to upgrade its version, and does a test compilation. Which is more than Debian/Fedora do, anyway. These tools already exist, btw.
Yes, and they are a waste of energy (hello, climate change?), time and effort, and a workaround to sidestep glaring design issues with the ecosystem of these languages. An entirely made up and artificial problem that should not have existed in the first place, had the people designing those ecosystems understood how these things need to work - or cared about it, anyway.
> This is a lie.
If you have to go pick something that is so far removed from the norm that is in fact a bridge to other language runtimes, then you surely understand that the point you are trying to put across doesn't have a leg to stand on.
Posted Jan 29, 2025 20:33 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Like IBM (RedHat) with Fedora? To be clear, Rust has survived the breakup with its parent corporation just fine, by switching to a foundation company model. Go is also large enough to do that.
> How many languages has Google killed by now?
I don't think they have killed a single language outside of internal experiments? Even Dart (used pretty much only in Flutter) is still going strong.
> Yep. Because there is no gate keeping and an email address is all that's required, so anything goes. I mean just check Pypi ffs. Golang is just unpopular so it's not worth targeting it - yet.
Do I need anything more than email to contribute to Fedora or Debian? Python's infrastructure has, unfortunately, been compromised by Linux distros. For too long, people kept pretense that virtual envs are just a tool for development, and distros should take care of packaging.
This is now slowly changing, uv is finally taking the Cargo/Go approach to dependency management.
> Yes, and they are a waste of energy
Go compiles source code about 10-100x times faster than C/C++. A simple `configure` run often requires more time than building the entire K8s. And Rust folks regularly rebuild the _entire_ set of Open Source libraries to check for accidental compiler-induced breakages.
> If you have to go pick something that is so far removed from the norm that is in fact a bridge to other language runtimes, then you surely understand that the point you are trying to put across doesn't have a leg to stand on.
Why? I've been using traditional Linux distros for almost 3 decades, and I'm still not sure how they can rival the status-quo that languages like Rust/Go have established. That of reproducible and reliable build environment.
Posted Jan 29, 2025 20:45 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (1 responses)
Sure? Fedora would face huge challenges if RH evaporated in a puff of smoke tomorrow morning. Don't use it if you don't want to take that very minimal but non-zero risk. A language ecosystem without its developers cannot possibly survive either. And unlike RH -> Fedora, the probability of Google killing a product that is not search/ads at this point are pretty much approaching 100%: https://killedbygoogle.com/
> I don't think they have killed a single language outside of internal experiments? Even Dart (used pretty much only in Flutter) is still going strong.
Let's not joke around - Dart, Flutter, Angular (ok ok not a language, a framework, still) are for all intent and purposes dead. Like those stories about WW2 soldiers in the pacific you might still find someone on a desert island still thinking otherwise, but it's delusion - Google killed them, and they are dead.
> Do I need anything more than email to contribute to Fedora or Debian?
Yes? You seriously don't know how those work?
> Python's infrastructure has, unfortunately, been compromised by Linux distros.
Yeah sure, it's distribution developers who are uploading malware to Pypi. WTF?
Given you are evidently just trolling at this point, I'll stop feeding.
Posted Jan 29, 2025 21:00 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Go also would need to adapt, but it's not dependent on Google anymore. If you look at Go development, it has a robust stream of non-Google contributions. Its governing model is like that of systemd, a "Politburo" group with non-public meetings making decisions on RFCs, but otherwise it's healthy.
Rust is already independent. If I had to put my bet, I'd bet on Rust and Go being around longer than Fedora.
> Let's not joke around - Dart, Flutter, Angular (ok ok not a language, a framework, still) are for all intent and purposes dead.
Angular is a framework, not a language. Dart/Flutter are absolutely alive, and moving up in popularity. They are the most popular combo for mobile development at the moment.
BTW, Fedora/Debian also totally failed on mobile.
> Yes? You seriously don't know how those work?
Hi, my name is Jia Tan. Would you mind taking up this patch to add color output for apt?
> Yeah sure, it's distribution developers who are uploading malware to Pypi. WTF?
No. It's the distro developers who were pushing against robust package management. As a result, PIP is more like APT/RPM than Cargo.
Posted Feb 6, 2025 12:54 UTC (Thu)
by bluca (subscriber, #118303)
[Link] (11 responses)
> Nope. It will get the locked versions of packages that are specified in the dependency list (go.mod and go.sum). They are cryptographically verified to be the same (go.sum contains the hashes of packages). If you think that the package author is malicious, then don't package the software in the first place.
Aged like a fine wine:
https://arstechnica.com/security/2025/02/backdoored-packa...
> A mirror proxy Google runs on behalf of developers of the Go programming language pushed a backdoored package for more than three years
lol, lmao
Posted Feb 6, 2025 13:35 UTC (Thu)
by excors (subscriber, #95769)
[Link] (1 responses)
The novel part is that the attacker removed the malicious code from the corresponding GitHub repository, after publishing the module. Since Go modules are immutable (unlike Git repositories), the mirror kept serving the original code that was first published, and everything was successfully cryptographically verified against that.
The lesson is that anyone wanting to audit a module's code needs to download the crytographically-verified version and read that, instead of downloading the same tag name from the same repository URL and assuming it's still the same code. And of course you also need to be careful of typosquatting, which is a non-trivial problem, but that's nothing new or Go-specific.
Posted Feb 6, 2025 15:16 UTC (Thu)
by bluca (subscriber, #118303)
[Link]
How about "do not allow anyone to upload whatever they want with no gatekeeping whatsoever and requiring just an email address", instead? Like every Linux distro has been doing for 30 years? Just a thought!
Posted Feb 6, 2025 21:30 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Feb 7, 2025 17:50 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
The attack won't work unless you use the proxy service _and_ ignore the sumdb validation.
Posted Feb 7, 2025 18:38 UTC (Fri)
by excors (subscriber, #95769)
[Link] (6 responses)
Posted Feb 7, 2025 20:32 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
Posted Feb 8, 2025 0:54 UTC (Sat)
by excors (subscriber, #95769)
[Link] (4 responses)
Posted Feb 10, 2025 3:55 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
I think a lot of people hold illusions that they wouldn't fall for this, that of course they'd know right away and have a good laugh, but i don't think this is true, a GitHub project with all the assets cloned from the original with just the URL changed is very difficult to spot if you have no prior familiarity and a shallow interaction with the project. The hall of mirrors can be pretty comprehensive and convincing, how could a packager know for sure in a way that would never fail or be missed, or skipped, that wouldn't be subject to human fallibility?
Posted Feb 10, 2025 19:22 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
I was thinking of a case where you would push malicious code to a project's repo, tag it, and let users download it. Then you can force-push a "clean" version, erasing the trace. Go will detect this, once the next person tries to download the module, the Go module proxy will complain about different hashes for the same tag.
It won't help with pure typosquatting.
Posted Feb 11, 2025 15:47 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Feb 11, 2025 15:53 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Feb 3, 2025 11:36 UTC (Mon)
by smoogen (subscriber, #97)
[Link] (3 responses)
Not sure you are still following this, but I am interested in your line:
> RPMs and DEBs are an obsolete way of packaging software, that doesn't provide atomicity or reproducibility.
What is a good way to package software these days? And when you wrote this what were your definitions of :
so I can better understand where you are coming from? [I am not going to argue against your view, I am just trying to get a grasp of what you meant.]
Thank you
Posted Feb 3, 2025 13:14 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
_Thank_you_ for trying to "win" the discussion the right way.
In other words arrive at the CORRECT answer, not at the answer you want to hear.
Cheers,
Posted Feb 3, 2025 18:20 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Not having the two properties below.
> atomicity
The system updates are atomic, they either happen or not, and they don't leave the system in a broken state midway. Reproducibility means that I can recreate the state of the system now, at any point in the future or on another hardware.
The computing world is coalescing around small "immutable" distributions that run Docker/Podman/etc. It is even happening for desktop-based OSes.
The next level is reproducibility for containers. There isn't a good universal solution that works in a general case, mostly because of the "obsolete" status of classic distros. People work around that by using immutable tags in Docker for base images. Nixos is also getting popular.
Posted Feb 4, 2025 4:39 UTC (Tue)
by raven667 (subscriber, #5198)
[Link]
For systems like how go and Rust manage code reuse the bridge tooling could be even more useful, providing a standard way to document build dependencies even when the result is a static binary without dynamic linking to inspect. Ask the package manager what software in the repo was built with git@git.example.org/libfoo.git and what commits were used, because the package format can be made to save that info reliably, so you can patch yourself or help the distro automatically do what needs to be done. OpenBuildService already does d
Posted Jan 29, 2025 16:12 UTC (Wed)
by ibukanov (subscriber, #3942)
[Link]
Except we are talking about Go build dependencies that are only relevant for the Go compiler. If the distro wants to put those dependencies into separated SRPM and require to install them under /usr/src just for the build and ignore all mechanisms that Go provides for managing packages (like GO proxy that allows to put a copy of a package with arbitrary extra meta information like maintainer signature into any HTTP server capable of serving static files), then the distro puts an extra burden on the maintainers.
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
>
> That's it.
Native dependency cache
Wol
Native dependency cache
Native dependency cache
Native dependency cache
Wol
Native dependency cache
Native dependency cache
> Verifying file database and EFI images in /boot/efi...
> ✗ /boot/efi/5133c90315904c4ca2a6986372f9fea5/6.12.8-200.fc41.x86_64/linux is not signed
> ✗ /boot/efi/5133c90315904c4ca2a6986372f9fea5/6.12.9-200.fc41.x86_64/linux is not signed
> ✓ /boot/efi/EFI/BOOT/BOOTX64.EFI is signed
> ✓ /boot/efi/EFI/Linux/linux-6.12.8-200.fc41.x86_64-5133c90315904c4ca2a6986372f9fea5.efi is signed
> ✓ /boot/efi/EFI/Linux/linux-6.12.9-200.fc41.x86_64-5133c90315904c4ca2a6986372f9fea5.efi is signed
> ✓ /boot/efi/EFI/systemd/systemd-bootx64.efi is signed
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
So the question is not what happens to Golang _if_ Google kills it, but _when_.
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
Native dependency cache
obsolete
atomicity
reproducibility
Native dependency cache
Wol
Native dependency cache
> obsolete
> reproducibility
Native dependency cache
full CI and dep tracking across multiple languages for an entire distro of software using RPM spec as the CI language. You can do very slick things for one project on one language with the standard tools for that language, but the distro world has built great tooling for managing a whole runtime that could be made even better, even if the end result is building an OSTree or Flatpak image.
Native dependency cache