Tails

#2 Updated by intrigeri 2018-03-13 20:04:51

bertagaz wrote:
> Since Feature #14680 and the installation of the Tails pythonlib in the ISO, it’s not possible to reproduce the ISO anymore.

I suspect you mean something else than Feature #14680.

It would be nice to have some kind of blame-free post-mortem to understand why this problem was not identified early enough in this dev cycle, as in: best case, before the faulty branch was merged; or worst case, before the 3.6 ISO was built. Quite possibly it’s not clear who is responsible to notice such problems and ensure they’re addressed. I would first like to hear bertagaz’ take on it because I guess he’s the one who has followed the closest what happened in the 48 hours before the release, after this problem has been diagnosed by our CI. I’ll try to start a discussion about this on a more suitable place.

#3 Updated by bertagaz 2018-03-13 23:07:11

intrigeri wrote:
> I suspect you mean something else than Feature #14680.

right, sorry, I meant Bug #15370 probably, or Feature #11753 (if testing how python apps behave was part of this ticket).

> It would be nice to have some kind of blame-free post-mortem to understand why this problem was not identified early enough in this dev cycle, as in: best case, before the faulty branch was merged; or worst case, before the 3.6 ISO was built. Quite possibly it’s not clear who is responsible to notice such problems and ensure they’re addressed. I would first like to hear bertagaz’ take on it because I guess he’s the one who has followed the closest what happened in the 48 hours before the release, after this problem has been diagnosed by our CI. I’ll try to start a discussion about this on a more suitable place.

I clearly missed this when I reviewed Bug #15370, and it was part of the job. This issue was raised late in the release cycle, and I merged it while having also other hotter branches to review in a timely manner, so I did not pay enough attention to check if the change broke reproducibility. I fixed other issues brought by it though, but did not think reproducibility would be that hit.

#4 Updated by lamby 2018-03-14 17:06:50

Could you update the ticket with a diffoscope HTML URI? The linked one 404s and I can’t seem to find the now-relevant job/build. :)

#7 Updated by segfault 2018-03-14 19:47:52

segfault wrote:
> Should be fixed by d55d2c0a08d5f5eacf654d7486dfe7a8adc0c695 in branch bug/15400-python-lib-breaks-reproducibility in my repo

I had to fix a path, the commit is now ccdcf81352617406099ea9a5b00511ae68a41bb7.

#8 Updated by intrigeri 2018-03-16 07:58:41

>> It would be nice to have some kind of blame-free post-mortem […]

> I clearly missed this when I reviewed Bug #15370, and it was part of the job. This issue was raised late in the release cycle, and I merged it while having also other hotter branches to review in a timely manner, so I did not pay enough attention to check if the change broke reproducibility. I fixed other issues brought by it though, but did not think reproducibility would be that hit.

Thanks for explaining! I think I’ve understood the root cause and I hope commit:6dbd9f55bbcc7d69a013976fb0e7000b43c2efff will avoid such issues in the future :) Case closed then.

#11 Updated by intrigeri 2018-03-16 13:20:21

segfault, in the future please fork bugfix branches off stable. I’ll rebase it this time.

#13 Updated by segfault 2018-03-16 15:03:07

intrigeri wrote:
> segfault, in the future please fork bugfix branches off stable.
Ok, didn’t know this, but will try to keep it in mind.

#15 Updated by intrigeri 2018-03-16 15:15:29

>> segfault, in the future please fork bugfix branches off stable.
> Ok, didn’t know this

Then I suggest you read https://tails.boum.org/contribute/git/ one of these days :)

#20 Updated by segfault 2018-03-16 17:44:00

intrigeri wrote:
> Thanks!
>
> * Code review:
> wrt. commit:a867dfd898275d60c935c739a676e6ddb99e2847 I don’t really get it: why not drop the quotes instead? You’re not quoting the same variable a few lines above so it has to be safe for unquoted usage anyway.

You are right. I thought the quotes in strip_nondeterminism_wrapper() in the following line were the cause:

strip-nondeterminism "${@}"

But indeed in a quick test (I didn’t run the build yet) it seems to work if I just remove the quotes in 00-install-tailslib. I don’t understand why, but I’m used to not understanding why bash does weird things.

> I’m not super happy with the fact the implementation will break if the glob ever matches more than one file. Something based on ls or find and loops over the matches would be more robust.

It should not break. I already tested this before, but I see that I should have noted it in the commit message: Both realpath and strip-nondeterminism can take multiple filenames, and then do its work on all of them. So if the glob matches multiple files, they will simply all be stripped.

> segfault, if you agree with the above please give yourself a follow-up ticket for 3.7 or later. But I’m not going to block on this for our 3.6.1 security release.

I just pushed b3429630495744cb9d88471c6389d340db399df2, if you find the time to review it in time for 3.6.1, you could cherry-pick on your branch. Else I can create a follow-up ticket for 3.7.