> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Reply via email to