Packaging Rust for Fedora [LWN.net]

Packaging Rust for Fedora

Posted Oct 30, 2022 12:26 UTC (Sun) by ssokolow (guest, #94568) [Link] (5 responses)

As I understand it, being someone who maintains a flatpak and helped get another one prepared:

1. Unified auditing. All dependencies have their sources and hashes pinned down in a single, unified record.

2. Separation of sandbox rules between the download phase (only tools like flatpak-builder can run code, network access) and the build phase (arbitrary package code runs, no network access)

Part #2 helps to prevent things like using package code to co-opt your build machine/farm as a vector to skirt around your border firewall and attack softer targets within your LAN. (Assuming, of course, that this is a "this LAN builds distributables for package X but doesn't run them" situation.)

Packaging Rust for Fedora

Posted Oct 30, 2022 15:25 UTC (Sun) by gilnaa (guest, #161422) [Link] (4 responses)

You can achieve this by hosting your own registry, which is basically just another http server.

Packaging Rust for Fedora

Posted Oct 30, 2022 16:16 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Note that my idea (that I've posted about before) is that installing a Rust package puts its crate into a machine-local registry. This would allow for automatic resolution to distro-provided versions based on `BuildRequires:` and the like.

Note that just rehosting `crates.io` might not be preferrable since they can be post-codegen steps (of various kinds) and instead `cargo publish` into this registry that is then pulled out during some `rpm-cargo-*` macro magic would probably be a better mechanism.

Packaging Rust for Fedora

Posted Oct 30, 2022 16:18 UTC (Sun) by ssokolow (guest, #94568) [Link] (2 responses)

How does that solve the "unified" requirement? A flatpak manifest puts all the hashes and URLs in the same JSON or YAML file, regardless of what language each dependency is written in.

Packaging Rust for Fedora

Posted Oct 30, 2022 16:43 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses)

Just because you have the hash doesn't mean you have the source available when you need/want it. If some registry goes down due to a DNS renewal failure, "hostile" acquisition, or other fun things, that hash list is quite useless.

Packaging Rust for Fedora

Posted Oct 30, 2022 17:16 UTC (Sun) by ssokolow (guest, #94568) [Link]

Of course. I'm saying that, just because you have a local Cargo registry, and a Conan registry, and a pip registry, and so on doesn't mean you have a clean, unified, easy-to-use way to check your bill of materials.

Conversely, if you have something like a flatpak manifest, you can use flatpak-builder arguments like --download-only, --disable-download, and --bundle-sources to easily cache and manage access to dependency sources.

Packaging Rust for Fedora

Posted Oct 30, 2022 14:49 UTC (Sun) by kleptog (subscriber, #1183) [Link] (6 responses)

I believe the original issue was GPL: for a given binary you must be able to deliver the source code it was built from. If the build process downloads files randomly from the internet, how can you produce "the original source"?

Nowadays we have the idea that a hash uniquely defines a given release of code and can be used to actually find the corresponding source. And that you can sort of rely on the idea that it will not randomly disappear off the internet. So it might be kind of feasible to carve out an exception there, where the builder has a proxy that registers which creates were downloaded and includes the relevant hashes in the package metadata.

But if a package just downloaded other assets off the internet it could become very difficult to reproduce. Maybe hook the builder into the internet archive and cross your fingers? Easier just to forbid the builder access to the internet and expect the uploader to predeclare dependencies.

People building closed source software are generally less concerned about reproducibility.

Packaging Rust for Fedora

Posted Oct 30, 2022 17:10 UTC (Sun) by khim (subscriber, #9252) [Link]

> And that you can sort of rely on the idea that it will not randomly disappear off the internet.

Please don't. In 10 years it would disappear.

Just put all the crates you need on the server you own. Then you can use hashes to your heart's content.

Packaging Rust for Fedora

Posted Oct 31, 2022 7:22 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (4 responses)

It's not necessarily an issue, because GPL 3 says this:

> The "Corresponding Source" for a work in object code form means all
> the source code needed to generate, install, and (for an executable
> work) run the object code and to modify the work, including scripts to
> control those activities. However, it does not include the work's
> System Libraries, or general-purpose tools or generally available free
> programs which are used unmodified in performing those activities but
> which are not part of the work. For example, Corresponding Source
> includes interface definition files associated with source files for
> the work, and the source code for shared libraries and dynamically
> linked subprograms that the work is specifically designed to require,
> such as by intimate data communication or control flow between those
> subprograms and other parts of the work.

So if the thing you're downloading is a "generally available free program," then it does not need to be included. Since the material in question is *possible* to download from the internet (presumably, from an automated script with no human intervention), that strongly suggests that it is generally available at least.

While the preamble of the license does talk about free software in general terms, neither the preamble nor the definitions section give an explicit description of what exactly qualifies as a "free" program (for example, the four freedoms are nowhere to be found). Courts will use the dictionary definition, and (probably) conclude that a "free" program is one which costs $0. I'm sure this would annoy the hell out of RMS, but that is how courts read contracts and licenses - only the material within the four corners of the document is part of the agreement. The fact that the Free Software Foundation chooses to use the word "free" in a way that is different from the general public is, legally, their problem, and they need to clarify that in the license if they want courts to respect it.

Packaging Rust for Fedora

Posted Oct 31, 2022 8:29 UTC (Mon) by Wol (subscriber, #4433) [Link] (3 responses)

> While the preamble of the license does talk about free software in general terms, neither the preamble nor the definitions section give an explicit description of what exactly qualifies as a "free" program (for example, the four freedoms are nowhere to be found). Courts will use the dictionary definition, and (probably) conclude that a "free" program is one which costs $0.

WHICH dictionary definition? Courts are (supposed to be) intelligent, and given that Free has a clearly defined meaning in the FLOSS world, I'm sure a UK court would conclude this passes the "knew or should have known" test.

Incidentally, that's why I always use the abbreviation FLOSS, not FOSS.

Cheers,
Wol

Packaging Rust for Fedora

Posted Oct 31, 2022 8:55 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (2 responses)

> WHICH dictionary definition? Courts are (supposed to be) intelligent, and given that Free has a clearly defined meaning in the FLOSS world, I'm sure a UK court would conclude this passes the "knew or should have known" test.

There are several different problems with that argument:

0. As I mentioned, the meaning of a legal document is generally determined by its contents, not by other stuff, no matter how relevant that other stuff might seem. If the four freedoms are not in the license, then they are Not In The License. This is already the usual legal rule, but it is reinforced by section 7's ban on "further restrictions."
1. Anyone could be a licensee, not just people "in the FLOSS world."The GPL is routinely presented in installer wizards (on Windows) where an EULA would normally be displayed, and the end user might not have any idea that there is a such thing as "the FLOSS world." So you can't necessarily expect them to be familiar with nonstandard terminology.
2. The GPL is probably[1] a contract. So contra proferentem applies, and common law courts will (usually) prefer to interpret ambiguity in favor of the non-drafting party, meaning you get the more permissive definition if more than one would make sense.
3. Let's use [2] as an example dictionary, because it's the sort of dictionary a court might use (i.e. a regular everyday dictionary, not a specialized law dictionary or something). It gives these senses of the word "free," if we cut out all of the irrelevant senses (of which there are quite a few):

> 1: not costing or charging anything
> a free school
> a free ticket
> 2a: having the legal and political rights of a citizen
> For many African Americans, celebrating the Fourth of July as the day Americans became free from British rule feels inapplicable since our ancestors were not free.
> — Christen A. Johnson
> b: enjoying civil and political liberty
> free citizens
> c: enjoying political independence or freedom from outside domination
> This is a free country.
> d: enjoying personal freedom : not subject to the control or domination of another
> You are free to do whatever you want.
> 3a: not determined by anything beyond its own nature or being : choosing or capable of choosing for itself
> a player free to negotiate a contract with any team
> b: determined by the choice of the actor or performer
> free actions
> c: made, done, or given voluntarily or spontaneously
> gave his free consent

The basic problem here is that (1) is the only sense (of those three) that can obviously be applied to inanimate objects like software, just based on the literal wording of these definitions. It would not make sense, for example, to give software "the legal and political rights of a citizen" or to describe it as "capable of choosing for itself," unless we're talking about some kind of general AI system that doesn't (yet) exist. You can argue that the FSF's use of the term is a perfectly reasonable extension of (2) and/or (3), but it is not literally identical to (2) or (3), so the average court probably isn't going to go out on that limb.

[1]: See e.g. https://lwn.net/Articles/747563/
[2]: https://www.merriam-webster.com/dictionary/free

Packaging Rust for Fedora

Posted Nov 1, 2022 13:30 UTC (Tue) by kleptog (subscriber, #1183) [Link] (1 responses)

> 0. As I mentioned, the meaning of a legal document is generally determined by its contents, not by other stuff, no matter how relevant that other stuff might seem.

AIUI this is a Common Law thing. In much of the world the legal framework takes into consideration what was intended, how the parties understood it and how a reasonable person would understand it. That's why you don't need to add "don't be an asshole" to contracts, it's implied.

Yes, this trips up US/UK companies occasionally when they come up to a European court with the defence: "we adhered to the letter of the contract". Whether courts will understand the correct meaning of "free" is not something I worry about.

Packaging Rust for Fedora

Posted Nov 1, 2022 23:37 UTC (Tue) by ssokolow (guest, #94568) [Link]

It also trips up people from commonwealth and former commonwealth countries when they learn that saying "I'm putting this into the public domain" isn't enough in jurisdictions like Germany.

See this legal review of the CC0 for more on that.

(TL;DR: The CC0 has a license fallback because German law doesn't have a concept of prematurely giving up your copyright, and it has a legally binding promise not to sue, because German law doesn't let you pre-emptively sign away rights and protections that will be written into the law at some future date.)

Packaging Rust for Fedora

Posted Oct 30, 2022 15:14 UTC (Sun) by smoogen (subscriber, #97) [Link]

There were several reasons for not downloading anything during the build
1. For many volunteers, networks are expensive in monetary costs to latency costs. Having the source code local means that recompiles and rebuilds 'cheaper'. Putting the builds in a 'must already be local' says that the environment building the final artifact matched what the developer expected as best as possible. Again it is a tradeoff. [Even today we have volunteers who have low bandwidth networks. Instead of pulling down similar 'cargo' or other packages 1000 times if they are building a lot of things, they would prefer to get it once and use it 1000 times.]
2. security. having the source code local means that someone checked it in at some point. having it automatically pulled in during the build tends to end up getting sidelined with 'X took over Y account and uploaded crapware'. the goal is to have a person making 'informed' choices before it is shipped to others. It isn't 100% foolproof but it is a tradeoff.
3. reproducible and auditable builds. not in the way of you rebuild it again and you get the same binary but that you can find and use every tool that was used to build the artifact. This is a second item towards various attacks which has shown up in Nodejs, PHP, Perl, Python, Ruby, and some other tooling where you find that the version you thought was built was replaced one way or another. [It has been a rare case, but for various developers and 'consumers' bitten once it has been enough to say never again.]
4. Ability to meet specific consumer environment demands. Eventually some code ends up getting used by something which has a high regulatory requirement. Those tend towards capture all the bits, lock them down, and show how it was build 20 to 50 years down the road. [I don't know if it is possible or not but legally it is required to be tried to make possible for various places (medical, automobile, energy production, various government agencies, international organizations, etc)].
5. -> N. the above is not comprehensive and people will point out other reasons

Again this is all about tradeoffs. The method used by older distros doesn't solve all the problems, but it solves the ones that various people wanted to be solved at the time they were important to them. Once built it becomes very hard to change without burning the ocean which is why other distros do show up over time and 'take' over specific developer and user needs. I expect that if someone had to meet the needs in 4 with 'arch' they would build a specific artifact storage that their builders would store every artifact downloaded so it could be reviewed and checked later if needed.

Packaging Rust for Fedora

Posted Oct 30, 2022 15:23 UTC (Sun) by cesarb (subscriber, #6266) [Link]

> Why that rule of not downloading anything during build? If the concern is reproducible builds, then the arch way of using cargo --locked works fine.

The concern is not reproducible builds, but being able to build in the first place. All major distributions consider failure to build from source (FTBFS) a critical bug in a package. Depending on a third-party server for the build means a package could suddenly not be able to be built anymore, if anything happens to that third-party server.

> If the concern is that they don't trust crates.io, then Fedora can easily run their own crates registry which mirrors rust crates.io.

That would put Fedora itself in that "third-party server" position whenever someone else tried to build a Fedora package from source.

Packaging Rust for Fedora

Posted Oct 30, 2022 21:24 UTC (Sun) by Wol (subscriber, #4433) [Link] (10 responses)

> The problem with all these rules like "builds cannot download" is that it is simply not how development is done any more.

So what do you do when you want to do a build, and your internet is shitty or non-existent? (Oh - and I've just spent a week with download speeds measured in kb - that is, if I could get a working connection ...)

Cheers,
Wol

Packaging Rust for Fedora

Posted Oct 31, 2022 4:37 UTC (Mon) by pizza (subscriber, #46) [Link] (9 responses)

> So what do you do when you want to do a build, and your internet is shitty or non-existent? (Oh - and I've just spent a week with download speeds measured in kb - that is, if I could get a working connection ...)

My last gig was in the medical field, where it could take 5+ years to get something in front of the first customer, and needs to be supported for a minimum of 10 years beyond that. The project I was working on involved a lot of 3rd-party Python code, and I am not exaggerating when I say that keeping up with and resolving python module incompatibilities consumed the majority of my time. We would routinely have one build to the next fail because a non-pinned three-layers-deep sub-dependency changed underneath us. On top of different sub components trying to pin different major versions of the same underling library. One of the last things I ran into, just before the whole group was shut down, was a dependency started requiring a newer version of python than our underlying platform provided.

Combine that with researchers just pulling in whatever python libraries they wanted, often (by necessity) on the bleeding edge. So each build would routinely pull down hundreds of python packages from the internet, on top of a custom debbootstrap'd Ubuntu build for our custom boards using bleeding-edge Xilinx SoCs -- It took over three hours to put together the bootable flash image, when everything worked.

I warned the powers that be that this was at best a prototype and that in order for it to be remotely supportable for the 15-year product lifecycle, we'd have to invest a _lot_ more into it, including (at minimum) a complete private mirror of Ubuntu, the python/pip and nodejs ecosystems, and a couple dozen github repos. But really, if we wanted this to be anything other than a toy/tech demo it would need to be rewritten, probably in C++ as that was what most of the rest of the company's long-term-maintained software was written in -- easily tens of millions of lines.

But anyway. In order to pass certification, we'd have to be able to prove the provenance of every bit of code running and guarantee the ability to recreate any given deployed build for fifteen years -- which means we can't rely on _anything_ downloaded from the public internet at build-time.

Packaging Rust for Fedora

Posted Oct 31, 2022 7:53 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> But anyway. In order to pass certification, we'd have to be able to prove the provenance of every bit of code running and guarantee the ability to recreate any given deployed build for fifteen years -- which means we can't rely on _anything_ downloaded from the public internet at build-time.

A practical way to solve it is to just mirror the heck out of artifacts. Since everything is hash-locked, it should be straightforward to just use these hashes for something like IPFS.

This is actually something that FSF should be doing. Just set up a huge mirror that pulls all the artifacts referenced from lockfiles of released projects.

Packaging Rust for Fedora

Posted Nov 2, 2022 16:29 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (1 responses)

The problem is not the mirroring, it's the checking (and maintaining).

If you freeze down a dependency for 15 years, and have any form of liability, you need to check every single fix released during those 15 years upstream to see if it applies to your configuration.

To a layman (judge) not applying a “free, public” fix will make you guilty as hell in case of a problem.

Packaging Rust for Fedora

Posted Nov 2, 2022 18:41 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

If you're working in an environment where you're legally liable for the quality, then you'll have to store all the previous versions and lock dependencies even more. You sure as hell won't just apply random updates from distros without testing them.

Packaging Rust for Fedora

Posted Oct 31, 2022 13:39 UTC (Mon) by khim (subscriber, #9252) [Link] (4 responses)

> On top of different sub components trying to pin different major versions of the same underling library.

Note that in Rust world it's supported use-case. I am not saying it's good idea to have that in your project, but it works. Rust and cargo support that combo just fine.

Except when you need to use two versions in one component, but that's next level of crazyness.

Packaging Rust for Fedora

Posted Nov 3, 2022 19:22 UTC (Thu) by mb (subscriber, #50428) [Link] (3 responses)

> Except when you need to use two versions in one component, but that's next level of crazyness.

You can also use two different versions of the same dep-crate in one crate simultaneously, as long as you map at least one of the deps to a different name (under which it is then accessible in the Rust code). That's easily possible with Cargo.toml:

[dependencies]
thedep02 = { version = "0.2", package = "thedep" }
thedep = { version = "1.0" }

Packaging Rust for Fedora

Posted Nov 3, 2022 19:50 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

Touché. This is minor improvement, though: if you are already at the point where you have different versions of the same component as immediate dependency if your code then you are half-step from trying to use types defined in one version for the other version.

This doesn't work in Rust and I don't think it's worth introducing meta-object protocol to allow that (although some languages [actually do that](https://www.gnu.org/software/guile/manual/html_node/The-Metaobject-Protocol.html)) but I just don't think it's what Rust needs.

Packaging Rust for Fedora

Posted Nov 3, 2022 21:11 UTC (Thu) by mb (subscriber, #50428) [Link]

> but I just don't think it's what Rust needs.

It's a feature that types and traits from incompatible versions of the same crate are in fact different types and traits.
That enables you to implement multiple versions of a trait on one single struct simultaneously.
That is sometimes useful, if you want to implement a library crate that must provide multiple different versions of an API (a foreign trait) to its users.

Packaging Rust for Fedora

Posted Nov 4, 2022 13:31 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> if your code then you are half-step from trying to use types defined in one version for the other version.

There are ways around this. For example, log 0.3.9 depends on 0.4 to serve as a bridge between the two nominally semver-incompat versions and not force an ecosystem-wide upgrade.

https://crates.io/crates/log/0.3.9/dependencies

Packaging Rust for Fedora

Posted Oct 31, 2022 14:57 UTC (Mon) by taladar (subscriber, #68407) [Link]

To me that seems very much like a problem with your company promising things that are practically impossible while using third party open source code unless you pay each maintainer of each of those pieces of code.

Packaging Rust for Fedora

Posted Nov 2, 2022 15:04 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (3 responses)

> Why that rule of not downloading anything during build?

Distribution build systems do download things before build but from the pile of things already packaged and audited not a blind internet pull. The magmas do exactly the same their stuff is not pulling from the internet but from internal audited repositories (giant curated monorepos).

The reason the stupid gratuitous inflation of artifact numbers and versions works for the magmas but not for distributions is that the magmas have more (paid) people to hurl at checking their repositories than distributions. And, more managers to hurl at devs that try to use non-blessed artifacts. And, more lawyers to hurl at people seeking damages if stuff fails. And, finally, a software world where they are the only ones able to provide trusted binaries suits them just fine.

The reason the stupid gratuitous inflation of artifact numbers and versions works for Joe nobody developer is that his liability if his stuff does not work is limited, so he does not feel the need to check the things his build systems pulls from everywhere, and he does not understand nor supports or helps the idiots that try to pull out this Sisyphean task distro-side.

Packaging Rust for Fedora

Posted Nov 2, 2022 15:40 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

Also, finally, not a problem to develop with whatever artifact version you want as long as you are able to clamp down at end-release time and rebase on the version the release team blessed (be it the one Google chose to release its latest kubernetes version with or the one Debian of Fedora chose to base their distro on).

It’s this clamping down devs object to, even though it happens the same way distro and magma-side, because it is materially impossible to check every possible artifact version under the sun, and even the magmas are not rich enough yet to attempt it.

Packaging Rust for Fedora

Posted Nov 2, 2022 16:39 UTC (Wed) by seanyoung (subscriber, #28711) [Link] (1 responses)

> > Why that rule of not downloading anything during build?
>
> Distribution build systems do download things before build but from the pile of things already packaged and audited not a blind internet pull. The magmas do exactly the same their stuff is not pulling from the internet but from internal audited repositories (giant curated monorepos).

So my proposal was to use cargo --locked with a distribution-owned copy of crates.io. That means exactly the opposite of a "blind internet pull". I means neatly a curated listed of packages that distribution can audit and lock down precisely.

> The reason the stupid gratuitous inflation of artifact numbers and versions works for the magmas but not for distributions is that the magmas have more (paid) people to hurl at checking their repositories than distributions.

Not at all. Modern tooling like rust is finally getting the reusability of software components right. Many rust crates do one thing, and do one thing very well. Some crates are very sophisticated and some serve a simple purpose; either way, you don't want to open-code all these components yourself. Do you want to open-code how to get the terminal size, for all the unixes and Windows etc or use a simple crate? I do, I don't want to waste time getting some icky ioctl right on some little-used OS, and even if I did, my code will almost certainly have bugs in it because it is not as widely tested.

The tooling provided by distributions is no good for software development. I want to be able to select versions of libraries, not just the one provided by the distribution, possibly point it towards a git repo where I have some of my own patches. I want automatic (recursive) dependency downloading, based on semver. I want to be able to enable features on libraries, not just the features the distribution provides (i.e. ./configure --enable-foo etc). All of this simply by having a simple config file which lists by dependencies, which I can update at any time without changing my distribution. This is what rust/cargo provides.

In my 30 years of software development it has been a constant that the distribution does not provide the version/fix/etc I need, so I have to work around it. The distribution package tooling is utterly useless for software development so very few software developers use it.

I get that the task for distributions is so much harder because of it. How about working upstream with cargo/rust? It's a very warm and welcoming community. Surely there something we can fix together. The result would be amazing.

Packaging Rust for Fedora

Posted Nov 2, 2022 17:22 UTC (Wed) by Wol (subscriber, #4433) [Link]

That pretty much sums up why I run gentoo ...

I was running the latest most up-to-date SUSE, I needed the latest, most up-to-date lilypond, and never the twain shall meet ...

Cheers,
Wol