[Pkg-xfce-devel] Bug#654468: Bug#645191: update on waf binary data

[Yves-Alexis Perez]

On sam., 2012-03-17 at 02:45 +0100, Carsten Hey wrote:
> waf scripts are not cleanly divided into python and data, but instead
> the python part contains also two two byte sequences (found using brute
> force whilst building the waf script).  My original plan was to ship two
> scripts debian/waf-unpack and debian/waf-repack to provide an easy way
> to edit the waf sources and document this in README.source. Due to the
> above mentioned mix of header information and python source code this
> can not be done in a clean way, so there so there is nothing to review
> for ftpmaster.

I don't completely understand this. What are those two bytes sequences
you bruteforced? Afaict you don't call waf in your snippets (and I
specifically asked you about that).
> 
> http://bugs.debian.org/660193 (search for the string waf) contains
> snippets, based on what Tolimar pointed to in his mail, you just need to
> paste into the midori package and some additional notes.  The remaining
> part is IMHO to document this in README.source.  One thing I forgot to
> mention in my mail to #660193 is that the reason to remove the blob from
> the used waf script is to ensure that the unpacked waf source is used.

Well, in midori diff, I repack and ensure the new one and the old ones
are the same to be sure I don't do anything bad. Now indeed it could be
split in two parts, one run by maintainer, which would then hack in the
waf sources themeselves, and one at build time, which would pick the
extracted sources and make a new waf script.
> 
> If requested I could provide a less hackish script to extract the
> tarball embedded in a waf script.  It is finished, but it is probably
> useless because there is no reliable way to put a new tarball into a waf
> script without using ugly hacks or being waf itself.

I don't understand that either.
> 
> * Yves-Alexis Perez [2012-03-15 21:26 +0100]:
> > To be honest, I didn't even wanted to spend any time on this, as I
> > consider the decision bad.
> 
> If a security update would require any changes in the packages build
> system, using waf the way upstream intended it to be used would cause
> the security team a lot of work and reviewing even simple changes
> related to the build system would be a mess to review by the release
> team during freeze.  Some .jar files also contain their source, should
> we in your opinion start to just ship them instead of rebuilding them?
> (this was of course a rhetorical question)

I'm a security team member so I'm well aware of that. I'm not defending
waf, I *don't* like it, and I already told upstreams about that. Now
it's their choice. And changing the way waf is used at built time is not
supported and might fail in bad ways too, so it's not really helpful to
do things *against* what advised by waf upstream.

And I still consider the decision bad because the source *is* there and
is tunable, even though it's not the easiest way in the world. But
upstream(s) made a choice here, we can disagree (and I do) but at the
end of the day, unless you want to fork, there's not much you can do.

Now, I really think I'm losing my time and yours on those aspects, so
lets keep it on the technical side, because I do find this helpful (and
I'm puzzled about the few questions I asked).

Regards,
-- 
Yves-Alexis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-xfce-devel/attachments/20120317/91733cff/attachment.pgp>