<div dir="ltr"><div class="gmail_quote"><div>(Agreed on all counts)</div><div><br></div><div dir="ltr">On Wed, 20 Jul 2016 at 13:08 Josh Triplett <<a href="mailto:josh@joshtriplett.org">josh@joshtriplett.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jul 19, 2016 at 11:32:17PM +0000, Angus Lees wrote:<br>
> On Mon, 18 Jul 2016 at 15:31 Josh Triplett <<a href="mailto:josh@joshtriplett.org" target="_blank">josh@joshtriplett.org</a>> wrote:<br>
> > On Sun, Jul 17, 2016 at 08:57:40PM -0700, Josh Triplett wrote:<br>
> > > I can understand wanting to support local distro patches. We should be<br>
> > very careful doing so, as it seems questionable to patch a crate while<br>
> > keeping the same version number; that breaks some of Cargo's assumptions<br>
> > about reproducibility. I'd rather have a separate crate and a replace<br>
> > stanza. However, if we absolutely had to, directory registries seem to<br>
> > support that.<br>
> ><br>
><br>
> Remember the *primary* reason we are bothering to do any of this is to be<br>
> able to support a hypothetical security fix to an existing Rust library<br>
> package 5 years from now.  We *must* be able to rebuild with patches.<br>
<br>
I absolutely agree.  I'm just arguing that if we patch version 1.2.3 of<br>
some crate, the patched version shouldn't use version number 1.2.3; it<br>
should use, for instance, version 1.2.3+debian1 or similar, to make it<br>
possible to identify what crate the package built with.  (Cargo and<br>
the Semantic Versioning standard allow that.)  Anything that declares a<br>
dependency on ^1.2, ^1.2.3, ~1.2.3, 1.2.*, or >1.2.3 will still allow<br>
that.  (And we have to rebuild binary crates to pull in the new library<br>
anyway, whether we change the version number or not.)<br>
<br>
Having a distinct version number when we patch a crate will make it<br>
feasible to tell when a build actually picks up that patched crate, such<br>
as in the cargo output in the build log for a bin crate.<br></blockquote><div><br></div><div>Oh, I hadn't thought about propagating the Debian source version into the library - interesting...  That means we'll appear "different" from cargo's pov even for unmodified crates (1.2.3-4 instead of 1.2.3), but I imagine if that triggers an issue with an over-strict dependency, then it was an issue we wanted to fix anyway...</div><div><br></div><div>Debian has elsewhere solved the "what build statically linked what" issue with Built-Using headers in the binary package, fwiw.  We should make sure we properly add these, so the standard tools do the right thing.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> .. or we just patch the Debian version of librust-libgit2-sys-dev's <a href="http://build.rs" rel="noreferrer" target="_blank">build.rs</a><br>
> to always use the system version.<br>
<br>
While that's always an option, I'd like to avoid having to repeatedly<br>
patch each new upstream version of a library if at all possible.  (If we<br>
can get the patch upstream, great, but I'm not wildly hopeful there.)<br>
That said, see below; I think this is a much less widespread problem<br>
than I'd first thought.<br></blockquote><div><br></div><div>Applying patches and later re-patching onto a new upstream is what the Debian toolchain is reasonably good at, for what it's worth.  It's what just about every package does, after all.</div><div><br></div><div>Obviously we can explore this further as we gain experience.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Realistically, we probably want to strip<br>
> the vendored C sources out of most of the *-sys crates when packaging,<br>
> since Build-Deps can guarantee the system library is present, and actually<br>
> removing the files means we can avoid auditing them for licenses, etc.<br>
<br>
> Many of the other *-sys crates I looked at earlier used pkg-config if<br>
> available, so using the system library versions Just Worked.<br>
<br>
I took a quick look at a large selection of -sys crates, and as far as I<br>
can tell, only two (libgit2-sys and one of the readline crates) shipped<br>
their own copy of the upstream source as part of the .crate, and only<br>
libgit2-sys required an environment variable to find and use a system<br>
version by default.<br>
<br>
Given that, I think we could reasonably ask libgit2 to support a<br>
standard environment variable (like CARGO_USE_SYSTEM_DEPS), set that one<br>
variable unconditionally, and ask any new crates to support that.  I<br>
think upstream would probably take such a patch.<br>
<br>
I also don't think, for trivial cases like those where the source is<br>
unlikely to have license problems, that it's worth the trouble of<br>
patching out the bundled source, compared to the benefit of using an<br>
unmodified .orig.tar.gz from the .crate file.  But on the other hand, it<br>
also wouldn't be that bad for just those two crates.<br></blockquote><div><br></div><div>I'm glad to hear that vendoring the upstream source is less common than I thought.</div><div><div>Again, we probably want to choose to repack on a case-by-case basis - I imagine the upstream size and licensing complexity might vary wildly.</div><br class="inbox-inbox-Apple-interchange-newline"></div><div>Last time I checked there also weren't any signed checksums that we could use to verify <a href="http://crates.io">crates.io</a> downloads (other than the implicit HTTPS signature).  It would be nice if we could preserve a bit-for-bit identical upstream however.</div><div><br></div><div> - Gus</div></div></div>