| Thread Previous • Date Previous • Date Next • Thread Next |
Jonathan Lange wrote:
On Sat, Mar 13, 2010 at 10:24 AM, Jeroen Vermeulen <jtv@xxxxxxxxxxxxx> wrote:I've just been discussing something with wgrant that has been bothering both of us....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.
Things just got sillier. I'm a bit delirious from an affliction that feels like being beaten up from all sides while having your head boiled and your extremities frozen, so forgive me if this is lunatic ravings:
Why do we have verification for the slave build ids in the first place? Wouldn't it be enough to re-generate the slave build id, and see if it comes up identical to what the slave quotes?
Again I chatted briefly with wgrant and he points out that we may not always have a BuildQueue handy to re-generate the id from. But, he continues, in that case we want to treat that as an invalid slave build id anyway.
So as things stand, I would suggest re-implementing this as follows:* Replace (this use of) BuildFarmJob.getName with a cookie generator, implemented in a single place. It hashes a bunch of BuildQueue/Job/... properties including date_created (which should give a nice dollop of entropy). * We refer to this as the slave build cookie. It's a better name since there's no particular need for it to be unique AIUI; we want to minimize overlap but there's no identifying function as such. * To verify a cookie passed to us by the slave, we re-generate it from the database and see that it comes up identical.
Jeroen
| Thread Previous • Date Previous • Date Next • Thread Next |
