4 ms·

I dislike some of the framing of the article. In particular: > Valentini further inquired to the project maintainers, how were these new binaries "actually pro

I dislike some of the framing of the article. In particular: > Valentini further inquired to the project maintainers, how were these new binaries "actually produced," and if it would be possible for him to recreate the binaries, as opposed to consuming precompiled versions. David Tolnay, who is the primary Serde maintainer, responded with potential workarounds at the time. The article links to the response [1] as well, which is very good. However, the response doesn't provide workarounds. It provides clear instructions: >> how is the x86_64-unknown-linux-gnu binary actually produced? Would it be possible for us to re-create the binary ourselves so we can actually ship it? > By https://github.com/serde-rs/serde/blob/v1.0.177/precompiled/build.sh https://github.com/serde-rs/serde/blob/v1.0.177/precompiled/.... Yes. When the article states that the library author only provided "potential workarounds", it sounded really shady to me, and I believe this is mischaracterizing the real response. [1] https://github.com/serde-rs/serde/issues/2538#issuecomment-1654783988 https://github.com/serde-rs/serde/issues/2538#issuecomment-1...

monocasa 3y ago
The issue is that build.sh doesn't create reproducible binaries. You can run that, but there's no guarantee you'll build the same binary that ships, so you can't automate proof that there hasn't been a supply chain attack.
- earthnail 3y ago
  That's fair. Thanks for explaining.
- fnordpiglet 3y ago
  But I would assume you would build it in your own hermetic build system and use those artifacts as the reproducible artifacts, since you don’t trust the precompiled distribution. Instead you would start your chain of trust with your build.
  - monocasa 3y ago
    The whole problem is that binaries are in the regular source distribution unfortunately with no way to turn off their usage.
    - fnordpiglet 3y ago
      Yes thanks as I read the issue and the code I realized the advice was to patch downstream. I know a lot of folks who build hermetic and reproducible builds for large amounts of open source code often have to patch downstream, but its fairly rare to see that requirement from such a basic crate/library. Hopefully this resolved at some point, it seems like a pretty aggressive stance to take that puts people who have a hard job (rigorous chain of trust in builds is hard work and done for very good reasons!!) in a harder spot.
the_gipsy 3y ago
> x86_64-unknown-linux-gnu binary Do they provide binaries for other architectures? Aren't new macbooks and some cheap VPSs using ARM now? This all sounds like a huge mistake, see python/node deps with C bindings.
- monocasa 3y ago
  The other archs just build the library like used to be the old behavior.
  - qhwudbebd 3y ago
    ...with the ironic consequence that linux amd64 w/ glibc is the only platform triple that's broken rather than - as so often - the other way around!

monocasa 3y ago

The issue is that build.sh doesn't create reproducible binaries. You can run that, but there's no guarantee you'll build the same binary that ships, so you can't automate proof that there hasn't been a supply chain attack.

earthnail 3y ago
That's fair. Thanks for explaining.
fnordpiglet 3y ago
But I would assume you would build it in your own hermetic build system and use those artifacts as the reproducible artifacts, since you don’t trust the precompiled distribution. Instead you would start your chain of trust with your build.
- monocasa 3y ago
  The whole problem is that binaries are in the regular source distribution unfortunately with no way to turn off their usage.
  - fnordpiglet 3y ago
    Yes thanks as I read the issue and the code I realized the advice was to patch downstream. I know a lot of folks who build hermetic and reproducible builds for large amounts of open source code often have to patch downstream, but its fairly rare to see that requirement from such a basic crate/library. Hopefully this resolved at some point, it seems like a pretty aggressive stance to take that puts people who have a hard job (rigorous chain of trust in builds is hard work and done for very good reasons!!) in a harder spot.

the_gipsy 3y ago

> x86_64-unknown-linux-gnu binary Do they provide binaries for other architectures? Aren't new macbooks and some cheap VPSs using ARM now? This all sounds like a huge mistake, see python/node deps with C bindings.

monocasa 3y ago
The other archs just build the library like used to be the old behavior.
- qhwudbebd 3y ago
  ...with the ironic consequence that linux amd64 w/ glibc is the only platform triple that's broken rather than - as so often - the other way around!