Re: Security concerns with minified javascript code
On Tue, Aug 25, 2015 at 07:08:06PM +0100, Ian Jackson wrote:
> Not regenerating configure doesn't pose any significant risk that
> we're shipping a configure script that we can't regenerate (or, at
> least, regenerate an equivalent or better one). I've not heard of
> people (for example) using private autoconf macros not included in
> their build tree.
Even though this has been disputed by Jakub Wilk already, let me give
another example: The configure script included with src:blt cannot be
regenerated anymore. Bug #772590 contains my attempts to fix that. From
my pov src:blt FTBFS.
This is also not the first time where a configure was buggy and
regenerating it would have solved the problem, but regenerating is no
longer possible.
The worst example I ever saw is nothing less than Perl's Configure. In
bug #762638, we agreed that Perl's Configure shell script, which is
generated by metaconfig, is considered preferred form for modification
and thus does not need source code included. But the irony goes on. When
I sent a patch against Configure, it was rejected, because what I wanted
should be done in metaconfig[1], i.e. Perl upstream implicitly
acknowledged that it is not preferred form for modification. The Debian
Perl maintainers have been very helpful in trying to address this
situation, but without more help from upstream, they cannot fix it.
What all of this shows however is that not regenerating configure
scripts during build has a significant risk of causing severe
maintenance problems down the road. When this reaches the point where
the generated scripts is called source, sanity is lost.
Please, let's always build from source. Let's not just apply this to
JavaScript libraries. The only way to provide the freedom to build from
source is to regularly do it.
Helmut
[1] https://rt.perl.org/Public/Bug/Display.html?id=124326#txn-1351869
Reply to: