| Thread Previous • Date Previous • Date Next • Thread Next |
Jonathan Lange wrote:
We can't be sure, but we think the cross-check may have started out as an extra protection against compromised slaves trying to confuse the buildd master....If we ever decide that we need seriously unpredictable ids...Then again, maybe we don't need a cookie at all and that would be even easier. Any comments? Jeers? Cheers? Beers..?The plan sounds good to me. It seems that you are missing key information on what the actual threats and security requirements are. I don't want to block what seems to be a useful simplifying change, but were I you I'd consult James Troup, LaMont Jones or do some threat analysis.
The story just got better. I had a bug (bug 539499) in our specialization of the slave build id generation (the very kind of code I want to get rid of).
There was a test that produced a translations build-farm job with matching Job and BuildQueue; generated a slave build id for it; and ran the slave build id through the verifier of its matching behavior class. The code that generated the slave build id mistakenly used the Job.id instead of the BuildQueue.id. The test passed by sheer accident, because the two ids happened to be the same in that case.
So right now I'm highly motivated to kill that code. Or perhaps a goat. Jeroen
| Thread Previous • Date Previous • Date Next • Thread Next |
