Hi,
Michael J Gruber <mjg@xxxxxxxxxxxxxxxxx> wrote:
Understanding is helped greatly by communication, though. Legal answers
such as "We can not" do not further this understanding, and "We can not
and we can not tell you why" is not much better, but these are the typical
answer we get, not even with a "sorry, but we can't". Obviously, these
legal questions are difficult to explain, but it can't be true that each
such case is under a "gag order”.
A lawyer at a previous employer told me that explanations of such decisions
can be used against you in court. Presumably, this also applies here.
The other big issue are our hobbled sources: We cannot store some original
sources in the look-aside cache, obviously. But packages such as openssl
do not even specify a hash nor an url for the un-hobbled sources. This
makes it unncessarily difficult to verify that our openssl package has
indeed been built against against the hobbled version of the original
sources - for a package like openssl this really is a trust issue (and
might even violate our packaging guidelines, but I'm not a lawyer…).
As one of the people that has previously generated one of the hobbled
tarballs you consider a potential trust issue: The hobbled tarball is the
upstream tarball for the particular release we ship after we extract it, run
./hobble-openssl (which you’ll find in the package) and repack it.
Feel free to replicate this process and compare the output to check that we
haven’t smuggled anything else into it.
Note that we’re discussing moving openssl to a src-git approach, so it
should eventually become much easier to see the relation between upstream
code and our downstream copy.
As a side effect, it makes it unnecesarily difficult to rebuild the
package locally (though it does not effectively inhibit it either, of
course; it is not an "effective measure" for that cause). I do understand
that providing a functional link can be construed to be “redistribution”,
but in the context of a spec file, a comment really is a reference to the
"source of the source", without which we cannot even claim to distribute
the hobbled version legally (and without which we have no trust chain).
Are you suggesting we add a comment that contains the URL to the upstream
tarball? I don’t think we’d have a problem with that. However, we probably
wouldn’t want to update it for every rebase, and a comment with a %{version}
macro might not be very helpful either.
I also don’t agree that not including the URL to the upstream tarball makes
a local rebuild unnecessarily difficult. If you replace the Source in the
specfile with the upstream tarball URL and remove ec_curve.c and octets.c,
the package should build just fine. How would you prefer we simplified this?
--
Clemens
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
