Bug#902981: [Non-DoD Source] Re: Font-Awesome 5 no build system DFSG compatibility
> -----Original Message-----
> From: Ian Jackson [mailto:ijackson@chiark.greenend.org.uk]
> Sent: Monday, July 23, 2018 3:42 PM
> To: Simon McVittie <smcv@debian.org>
> Cc: Alexis Murzeau <amubtdx@gmail.com>; debian-legal@lists.debian.org; 902981@bugs.debian.org; Daniel Baumann
> <daniel.baumann@progress-linux.org>
> Subject: [Non-DoD Source] Re: Font-Awesome 5 no build system DFSG compatibility
>
> Simon McVittie writes ("Re: Font-Awesome 5 no build system DFSG compatibility"):
> > I think this is a technical issue, but not a DFSG violation; and I
> > think it would be appropriate to track it as a bug, but not a
> > release-critical bug.
>
> I have a different analysis, at least, as far as I currently understand the situation.
>
> What is going on here is that upstream are keeping some of the actual source code (and yes, I think the Makefiles count - I agree with the
> GPL's definition of source in this context) secret (perhaps unintentionally). We need to obtain it. If we can't, then perhaps we can
> produce an equivalent build sequence to replace the missing parts.
>
> IMO for files which are built automatically by upstream, they should be built automatically in Debian too.
>
> > The same situation exists in any package where some hard-to-modify,
> > non-executable data file (perhaps an icon) is accompanied by its
> > easier-to-modify source form (perhaps in GIMP format or as a SVG) but
> > a manual export step is required to transform the source form into the
> > modifiable form.
>
> This is quite different. In those cases there is no other build system. When there is no other build system, then upstream are doing the
> same manual thing that we are expecting ourselves, our users, and our downstreams to do.
>
> Thanks,
> Ian.
>
> --
> Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
I agree with Ian on this; build systems can have extra code in them that we may need (e.g., a build system that generates new files for a given computer that are then compiled into the final executable). They aren't optional, not in Free software.
My personal rule of thumb is that if a human being generated the file, then we need that file. Anything that is generated from human generated files (e.g., the icon that was generated from the GIMP file, or the executable from the original source files), doesn't need to be included.
>From a security point of view, I'd prefer **not** to have any of the generated binaries as I can then look at all the sources (code, icon files, build system files, etc.) and choose if I'm going to run the final output or not. A convenience binary that claims to be the output of a compilation step may or may not be, and it may be difficult to prove one way or the other (if the creator is caught, they may claim that they compiled using 'better' flags than the build system supplies).
Moreover, where do we draw the line? I've written code generators before that generate VAST amounts of highly optimized code (think on the order of a million lines of C code in one file). I could create a project where I open source the generated code, but keep the code generator to myself. At that point, there is no simple method of checking the file; I might have hand-edited a few of the generated functions to do something 'extra'. If you had the code generator in hand, you could check it, then compare its output against the file I supply to see if there are any differences. The important thing here is that one human being is approximately equal to another human being in terms of level of effort required to generate or check material; if someone else had access to my code generator, it would take them approximately as long to check it as it took me to write it, so my ability to hide anything nefarious is dramatically limited[1].
So, I vote for requiring the build files **and anything else created by a human** before accepting it as open source.
Thanks,
Cem Karan
[1] Yes, you can do some really, really clever things to obfuscate what you're doing; witness The International Obfuscated C Code Contest (https://www.ioccc.org/), or The Underhanded C Contest (http://www.underhanded-c.org/). However, you can't do the equivalent of a DOS attack on all people that are checking your code; I believe that the time to check human generated code versus create it is O(1) (although the constant that is hidden in there may be high). A computer can generate infinite amounts of code in relation to the amount of input. At that point, no human checker (or even team of checkers) can verify the output.
Reply to: