Rust Users Push Back as Popular 'Serde' Project Ships Precompiled Binaries

"Serde, a popular Rust (de)serialization project, has decided to ship its serde_derive macro as a precompiled binary," reports Bleeping Computer.

"The move has generated a fair amount of push back among developers who worry about its future legal and technical implications, along with a potential for supply chain attacks, should the maintainer account publishing these binaries be compromised." According to the Rust package registry, crates.io, serde has been downloaded over 196 million times over its lifetime, whereas the serde_derive macro has scored more than 171 million downloads, attesting to the project's widespread circulation... The Serde ecosystem consists of data structures that know how to serialize and deserialize themselves along with data formats that know how to serialize and deserialize other things," states the project's website. Whereas, "derive" is one of its macros...

Some Rust developers request that precompiled binaries be kept optional and separate from the original "serde_derive" crate, while others have likened the move to the controversial code change to the Moq .NET project that sparked backlash. "Please consider moving the precompiled serde_derive version to a different crate and default serde_derive to building from source so that users that want the benefit of precompiled binary can opt-in to use it," requested one user. "Or vice-versa. Or any other solution that allows building from source without having to patch serde_derive... Having a binary shipped as part of the crate, while I understand the build time speed benefits, is for security reasons not a viable solution for some library users."

Users pointed out how the change could impact entities that are "legally not allowed to redistribute pre-compiled binaries, by their own licenses," specifically mentioning government-regulated environments.
The official response from Serde's maintainer: "The precompiled implementation is the only supported way to use the macros that are published in serde_derive. If there is implementation work needed in some build tools to accommodate it, someone should feel free to do that work (as I have done for Buck and Bazel, which are tools I use and contribute significantly to) or publish your own fork of the source code under a different name.

"Separately, regarding the commentary above about security, the best path forward would be for one of the people who cares about this to invest in a Cargo or crates.io RFC around first-class precompiled macros so that there is an approach that would suit your preferences; serde_derive would adopt that when available."

I don't see much of a difference

[innocent_white_lamb]

I don't see much of a difference in terms of security and reproducibility either way. In theory, sure, but in practice this is one of those things that's automatically pulled into your own project from this guy's repo so what you get right now is what's there today, not what was there yesterday, and it might be different again tomorrow.

So if you want a secure and reproducible development environment, DON'T DO THAT.

My tools and libraries reside on my own computer. They get updated or changed when and if an

Re:

[codebase7]

I don't see much of a difference in terms of security and reproducibility either way. In theory, sure, but in practice this is one of those things that's automatically pulled into your own project from this guy's repo so what you get right now is what's there today, not what was there yesterday, and it might be different again tomorrow.

But I thought Rust was a secure programming language that would just automagicly make my lazily written code safe. /s

There isn't a difference. At best you have the source to code that might be safe to use. (Assuming you don't have a trusting trust compiler / OS / Hardware / etc. ...) At worse it's the same result only the code has already been compiled. Using either without vetting is asking for trouble. Using either by constantly pulling it off of someone else's computer is the definition of negligence

Re:I don't see much of a difference

[ShanghaiBill]

There is no absolute security. Ultimately, you have to trust someone[1]. You just have to choose wisely.

By fetching pre-compiled binaries, you're mostly trusting people you have to trust anyway, because they write and distribute the source.

[1] Reflections on Trusting Trust [cmu.edu] by Ken Thompson.

Re:

[codebase7]

There is no absolute security. Ultimately, you have to trust someone[1]. You just have to choose wisely. By fetching pre-compiled binaries, you're mostly trusting people you have to trust anyway, because they write and distribute the source.

I wasn't saying there was absolute trust. I was agreeing with the GP that if the rust users are worried about trust, then they shouldn't be constantly redownloading and blindly executing some random binary or source code from the Internet.

There's a huge difference between downloading code from someone else once, vetting it, and storing it for later use if it validates good enough for your needs. Vs. redownloading and executing code from someone else, without any vetting, every time it's needed. Neither p

Diverse double-compiling not so easy for Rust

[tepples]

[1] Reflections on Trusting Trust by Ken Thompson.

It's funny you should mention that paper, as one of the better known countermeasures isn't quite as applicable to Rust or other single-implementation languages. Diverse double-compiling [arxiv.org], a construction described in David A. Wheeler's dissertation, depends on having multiple independent implementations of a language with which to build a particular compiler for that language. This works well for C++ or any other language with a fairly stable specification. However, because Rust is an unstable language, third

Re:I don't see much of a difference

[Uecker]

But you are not only trusting them not to be evil, you also trusting them to have perfect security on their systems all the time. The last part is difficult to achieve in general, so such trust is generally not well placed.

This is why it is important to distribute in source and have reproducible builds.

Some people say supply-chain security is more critical than memory safety, and apparently the Rust folks learn this the hard way.

Re:I don't see much of a difference

[Bu11etmagnet]

> By fetching pre-compiled binaries, you're mostly trusting people you have to trust anyway, because they write and distribute the source.

However, it's virtually impossible to audit binaries, as opposed to sources.

Re:

[TechyImmigrant]

There is no absolute security. Ultimately, you have to trust someone[1]. You just have to choose wisely

Trust in Rust you must. Compile time slow it will be.

Re:I don't see much of a difference

[Tailhook]

I don't see much of a difference in terms of security and reproducibility either way.

Others do, which is why they have policies in place for this sort of thing. Specifically, this drama began when the build.rs behavior of serde was noticed [github.com] by a Fedora package maintainer:

This is problematic for us, since we cannot, under no circumstances (with only very few exceptions, for firmware or the like), redistribute precompiled binaries.

Re:

[DRJlaw]

Others do, which is why they have policies in place for this sort of thing.

That's an others problem, not the maintainer's problem. Declaring that you have a policy does not mean that the projects that you draw from are required to comply with it.

Re:

[Tailhook]

not the maintainer's problem

Which maintainer do you have in mind? The downstream package maintainer or the maintainer of the upstream fork? The latter is where this is headed.

Re:

[DRJlaw]

or the maintainer of the upstream fork? The latter is where this is headed.

Good luck with that.

How is this different from protobufs?

[LindleyF]

Just curious. Description sounds similar.

Re: How is this different from protobufs?

[doragasu]

Protobufs make you define the structure using protobuf syntax. This automatically derives serialization/deserialization code of Rust data structs, no additional syntax needed.

Re: How is this different from protobufs?

[LindleyF]

Ah, so more like Java Serializable (though presumably less shitty).

Re:

[phantomfive]

Automatic serialization libraries always have security faults. They aren't worth using.