[Reproducible-builds] Minimising work needed for this build-path issue

[Ximin Luo]

Ximin Luo:
> Daniel Kahn Gillmor:
>> On Thu 2016-10-27 11:18:00 -0400, Ximin Luo wrote:
>>> So, I can implement option B fairly easily, but there is one ugly fact
>>> about the syntax that we should think about. The way that GCC does it,
>>> it means you can't strip a prefix that itself contains the "="
>>> character.
>>>
>>> Now this is not going to matter in all the cases that *we* want to use
>>> it for. Doing a `sudo find / -name "*=*"` on my system gets me one
>>> result: "songs/releases/2012 - Grimes - Visions/06 Vowels = space and
>>> time.mp3".
>>>
>>> However, we're defining a *standard* here and if it takes off, it will
>>> last for quite some time and have quite wide reach. It means that if
>>> someone wants to have a folder structure like e.g.
>>>
>>> C:\Documents and Settings\Betrand Russell\Proofs of 1+1 = 2\Automated Proofs\Source Code\
>>>
>>> or perhaps in the future:
>>>
>>> /srv/net/distributed-hash-table/address/VaIWP8YIWDChR2O76yiufXBsbw5g2skB/kp9VP+qVLvydovdGw==/projects/gcc-6/
>>
>> note that your "convenient" use of base64 here is problematic for other
>> reasons, because of the "/" character -- some "uniform" paths will be more
>> layers deep than others.  This isn't directly relevant to our specific
>> problem, but just an observation that stuffing b64 encodings into the
>> filesystem might already be problematic.
>>
> 
> Yeah I noticed that right after I sent it. There is a "urlencoded" form of base64 which avoids that problem though, it replaces +/ with -_.
> 
>> I guess quoted-printable encodings are even more likely to have problems
>> with "=" though:
>>
>>     0 dkg at alice:~$ qprint -e <<<"abcdé"
>>     abcd=C3=A9
>>     0 dkg at alice:~$ 
>>
>>> these people won't be able to use this standard. Do we care about
>>> these sorts of things? Even if not, we should explicitly say "Paths
>>> containing '=' are not supported" - there is no sense in trying to
>>> brush this fact "underneath the carpet".
>>
>> I agree that it is actively good to explicitly state this constraint.
>>
>> The constraint already exists (for debug-prefix-map).
>>
> 
> Well, one option is to change GCC to strip at the last '=' instead of the first '='. 
> 
> The "no =" constraint then moves to newprefix instead of oldprefix. I can think of much fewer places where this would be an issue, I don't know of any software that contains a "=" in its name, and even then usually they'd have a "preferred" ASCII alternative that they could use.
> 
> Anyway, I will make this change in a separate patch and see if GCC agree with it.
> 

Updated patches here:

https://gist.github.com/infinity0/72aba22411a2e8baaae4649329f96643

Everyone please feel free to comment / review before I soon send them off to GCC.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git