It’s not necessary to have direct access to the server in order to perform a timing attack - as far as I know, it’s (at least theoretically) possible to do the same kind of attack via an ordinary connection. An attacker would have to measure a lot of tries in order to average out latency, but if there is a meaningful difference between comparisons some information can still be gained about the hash. That’s why that stack exchange post says “access to the salt means access to the password”. But as that post also says, better be safe than sorry and take care of those kinds of attacks anyway
In any case, this is orthogonal to the point I was trying to make: Because of the new compilations for each different machine, I’m not sure certain guarantees you could make in pseudo code (I.e. No hotwiring) are still valid in Julia (e.g. Maybe the compiler “optimizes” the comparison and inserts the hotwired early escape?). Maybe it’s not a problem as long as the routine itself always compiles to the same machine code, but as the compiler is somewhat in flux at the moment, I don’t think that’s a guarantee we get.
That being said, if it’s just about calling bcrypt and comparing the hashes, is there any reason not to call into trusted and often used implementations other than having it in pure Julia? Don’t get me wrong, having reliable bcrypt in pure Julia would be really awesome, but I’m not sure it’s achievable for all possible compilation targets, at least right now.