3 ms·

I've seen Rust crates where the code was generated from a Python script and some other data and neither of those things are in the crate, which is potentially a

by pabs3 4y ago

I've seen Rust crates where the code was generated from a Python script and some other data and neither of those things are in the crate, which is potentially a license violation for copyleft crates. Or crates where the tests were in VCS but not in the crate. Or there were prebuilt files in the crate. I think always going with the VCS is a better option.

newpavlov 4y ago
>code was generated from a Python script and some other data and neither of those things are in the crate Yes, it's (IMO unfortunately) possible to have non-reproducible code generation during compile time. The most prominent example is code generation based on DB schema. But such cases are quite rare and "going with the VCS" does not help here in any way. If you mean that Rust code gets generated by a Python script and then gets uploaded to crates.io without the "origin" scrips, then I don't see any problems here. >Or crates where the tests were in VCS but not in the crate Tests are not used in building the final application, so they are irrelevant for reproducibility. >prebuilt files in the crate While I think it's a bad practice (though I haven't seen such crates myself), it does not hinder build reproducibility.
- pabs3 4y ago
  > "going with the VCS" does not help here in any way. It does, because then you can run the build process yourself from the real source files and check if it is reproducible. > If you mean that Rust code gets generated by a Python script and then gets uploaded to crates.io without the "origin" scrips, then I don't see any problems here. Right. The problem is there is no source in the crate, just generated Rust code, so you can't know if the build process to create that Rust code is reproducible or not. > While I think it's a bad practice (though I haven't seen such crates myself), it does not hinder build reproducibility. The problem is that these are prebuilt files and so your build process is just copying them not building them, so you can't know if the build of them is reproducible.
  - newpavlov 4y ago
    I think your definition of "reproducible" is somewhat different from the one usually used. Reproducibility means that by running build process you always get the same binary, nothing more, nothing less. Having a bunch of generated Rust code or blobs in a published crate makes it harder to review (which is why I consider it a bad practice), but such crate is still completely reproducible.
    - pabs3 4y ago
      The crate might be reproducible, but the build process used to create the crate is not reproducible. Every build process should be reproducible, even the ones that are used to create the crates themselves.
      - simiones 4y ago
        There is no build system that can guarantee that though - Go's certainly doesn't, with its use of go:generate tags that can easily do system-dependent things at build time and ability to link C lib blobs.
bombolo 4y ago
You can put binary files on git as well… if the developer is clueless there is no fix. It would be good to flag bad packages but it's impossible.
- pabs3 4y ago
  Yes, you have to audit the VCS for non-source files as well as verifying reproducibility.

by pabs3 4y ago

newpavlov 4y ago

>code was generated from a Python script and some other data and neither of those things are in the crate Yes, it's (IMO unfortunately) possible to have non-reproducible code generation during compile time. The most prominent example is code generation based on DB schema. But such cases are quite rare and "going with the VCS" does not help here in any way. If you mean that Rust code gets generated by a Python script and then gets uploaded to crates.io without the "origin" scrips, then I don't see any problems here. >Or crates where the tests were in VCS but not in the crate Tests are not used in building the final application, so they are irrelevant for reproducibility. >prebuilt files in the crate While I think it's a bad practice (though I haven't seen such crates myself), it does not hinder build reproducibility.

pabs3 4y ago
> "going with the VCS" does not help here in any way. It does, because then you can run the build process yourself from the real source files and check if it is reproducible. > If you mean that Rust code gets generated by a Python script and then gets uploaded to crates.io without the "origin" scrips, then I don't see any problems here. Right. The problem is there is no source in the crate, just generated Rust code, so you can't know if the build process to create that Rust code is reproducible or not. > While I think it's a bad practice (though I haven't seen such crates myself), it does not hinder build reproducibility. The problem is that these are prebuilt files and so your build process is just copying them not building them, so you can't know if the build of them is reproducible.
- newpavlov 4y ago
  I think your definition of "reproducible" is somewhat different from the one usually used. Reproducibility means that by running build process you always get the same binary, nothing more, nothing less. Having a bunch of generated Rust code or blobs in a published crate makes it harder to review (which is why I consider it a bad practice), but such crate is still completely reproducible.
  - pabs3 4y ago
    The crate might be reproducible, but the build process used to create the crate is not reproducible. Every build process should be reproducible, even the ones that are used to create the crates themselves.
    - simiones 4y ago
      There is no build system that can guarantee that though - Go's certainly doesn't, with its use of go:generate tags that can easily do system-dependent things at build time and ability to link C lib blobs.

bombolo 4y ago

You can put binary files on git as well… if the developer is clueless there is no fix. It would be good to flag bad packages but it's impossible.

pabs3 4y ago
Yes, you have to audit the VCS for non-source files as well as verifying reproducibility.