-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

For Ruby, regenerating all the generated content would be a huge burden. I can't really imagine the Ruby bootstrap, since you need to have Ruby to build Ruby, I don't think we can identify every piece which is/was generated nor we can collect the original files and at the end, we would end up with totally unsupported build, since this is definitely not the upstream direction.


Vít



Dne 18.12.2015 v 20:13 Stephen Gallagher napsal(a):
> Please keep responses on the devel@ list. CCed to the Council list for
> visibility and discussion of how this fits with our "Freedom" foundation.
>
>
> == Premise ==
> Some upstream distribute tarballs that include code and content that
> has been generated at distribution time. Some (non-exhaustive)
> examples of this include:
>
> * Code produced by gdbus-codegen
> * Code generated by a YACC implementation such as bison or jison.
> * Autotools scripts such as libtool
> * Man-pages that are built from templates such as Docbook.
> * Minified JavaScript or CSS
>
> There are many other examples, but those are readily called to mind.
> This brings up several important questions:
>
> 1) Do we require that the original data used to generate this code is
> included in the SRPM?
>
> 2) Do we require that whatever tools are necessary to generate this
> code is packaged in Fedora (with all the legal and policy requirements
> that this implies)? If we do not, do we require that the code used by
> upstream is free software?
>
> 3) Do we require that building in Fedora always requires regeneration
> of this code from the original data?
>
> == Analysis ==
> Shipping pre-generated content may introduce risk:
>
> * If the pre-generated code produces code that is not human-readable,
> it may be impossible to audit (or verify that it actually matches the
> input files, if available). For example, a compromised upstream might
> be shipping a back-door, possibly without knowing.
>
> * If a bug or security vulnerability is discovered in the generated
> code, will it be reasonable for a Fedora maintainer to patch it?
> Patching the source files vs. patching the generated output can be a
> very significant difference in the level of effort.
>
> * Code that was pre-generated by upstream may have been done with
> build flags that differ from Fedora's own set of hardened and
> optimized flags, resulting in a poorer experience (or less secure
>
>
> Forcing the re-generation of all such code may be infeasible in many
> cases. For example, the call has gone out numerous times in the past
> to mandate that `autoreconf` must be run on all autotools code (to
> enforce compiler flags) and every time it has been defeated because
> many programs won't generate with anything but the version of
> autotools that was used by upstream (which is a separate problem).
>
> FESCo discussed this very briefly in our last meeting, but it was
> decided that we should open this up to community discussion before
> attempting to make a decision. Please add your thoughts to this thread
> and FESCo will revisit it at our next meeting (after the New Year).
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWd+DtAAoJEAzgnueZF7h8VrYP/3ri08MXBkfi2afRyVnTz/zA
YymR0+e5J5YBy+Qs6OncYtMKepWQjOoWdLxtqHKNKr2uPh9pOWYsfVQI5F585xoA
rDC6Laly4LeDuKE9Jxyr/EiInWCHe3To+FvWZ95vQnQZ+pAfyWN9yD8BN0BS7QAi
UGeZFYSGPFblIrQGY/HlzKMd3jYdwTPuuYy9CeBgKhVK7uldOWM91dRgigXeWGup
3xBVulxRjoBxvVDPhjR+6nO2IPoGGNo8N4rCR+vnTlpp/DsWlbC3IP5cLyQwDI8G
IbV4yzM30etM8HFiz5jWFveESeI4lLQGA9WH5EWR9TrzvxXcWz+kuLvE8nRwPwqm
DyqDV2RnLUlgOuRNt686MxXMCtb/Y+8wwnXrVy7ildC8kWQnRtKD/Ypoko7vGaWi
EDrR2j7H8VjaZImPd6yMVUauPBHJZCVzpV4KsikTFi6DYadYe+a7F2GSPTFfLcUJ
MH72HgNmDGyDAmj01Fjpy4sZTWnEdgaz2twXwshD6TwjNnCDfsa//87uE7Yg1oO4
znpoIwlZLTfvkAJ/xRQxiUp15zj7GU+g9jBoge+7fGT3wmS6qaQymfy8afKMMAWY
L5burKZl60H/SVVBk1fg2pXVhIoQhRJCkyYHoVWRakPsxGk8wVLjXgpU+QiXeOqs
w7/Pd5TqZIOJ03MSuw77
=0bIY
-----END PGP SIGNATURE-----