[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)
From:       Clemens Lang <cllang () redhat ! com>
Date:       2022-09-28 11:41:47
Message-ID: 3CB7E688-9119-4492-85AF-CEC9136E68BD () redhat ! com
[Download RAW message or body]

Hi,

Michael J Gruber <mjg@fedoraproject.org> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[prev in list] [next in list] [prev in thread] [next in thread]