Hi Santiago and all-- On Sun 2016-09-11 21:30:22 +0200, Santiago Vila wrote: > Well, maybe the problem has always been there. > > Maybe official autobuilders have a lot of entropy and we have never > found the problem there, but IMHO we should not take that for granted > in the general case.
I would hope that the autobuilders never actually *need* entropy to build packages. we want package builds to be reproducible, and entropy isn't necessary for that :) > But I really don't know. A quick search on gnupg and /dev/random > led me to the "haveged" package you mention. > > This is the kind of "entropy helper" package I believed it "had" to exist, > but I have never used any of them really. > > Would be possible to have haveged as a build-dependency of this > package so that it works automatically and avoids the problem in a > generic way for every kind of autobuilder trying to build the package? I've used haveged with gnupg before. It certainly removes the kernel's sense of lacking entropy, but i have had no time to verify that the bits mixed into the random pool by haveged is in any way a robust entropy source. I'm also not sure that haveged is available (or well-motivated) on all architectures, since what little logic i've understood about how haveged works sounded processor-specific to me. > Maybe we should ask dkg and the other people maintaining gnupg about > what it's usually done in cases like this (package needing a lot of > entropy in its build system). An even easier approach might be to do the following within the build: * ln -sf /dev/urandom /dev/random why would we need the blocking kernel RNG in the buildd anyway? Lastly, one other option for gnupg at least is to patch upstream to use --debug-quick-random in the build-time test. do any of these options sound more appealing than the others? --dkg
signature.asc
Description: PGP signature