> 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.
This is not about personal trust - personally, I don't have any problems trusting our packagers.
It is about the reproducible chain that we usually have: you can `spectool -gf` the original sources and compare checksums etc.
> 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.
I'm curious t see what happens when we have src-git on Fedora infrastructure, which we should have. Will our src-git carry ("distribute") unhobbled sources?
> 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
Yes, for example.
> wouldn’t want to update it for every rebase, and a comment with a %{version}
> macro might not be very helpful either.
"%%" so that rpmlint does not complain. Yes, why not? I'm not suggesting something that could be construed as "distributing via link"; otherwise defining an %origsource and bconding build switches/hobble-related patches would be perfect, but maybe too close to "encouraging".
> 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?
I know how to find the URL etc. (and so far don't know, but may have to in the future). I just think we can make it easier and more transparent (see above), and besides the technical aspect this also communicates "we hear you and do what we can" much better.
_______________________________________________
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
