summaryrefslogtreecommitdiff
path: root/cross/nios2-gcc/buildlink3.mk
diff options
context:
space:
mode:
authornia <nia@pkgsrc.org>2020-06-23 17:38:49 +0000
committernia <nia@pkgsrc.org>2020-06-23 17:38:49 +0000
commit94d4b620e9ff7b13b5f5f197eaa8e5caaf032e27 (patch)
tree5fe4b93e1e64c4e02ecb38921cca3abf8a346f2b /cross/nios2-gcc/buildlink3.mk
parent1bdf64fe7f4f49dd39eef589c532411a84addff7 (diff)
downloadpkgsrc-94d4b620e9ff7b13b5f5f197eaa8e5caaf032e27.tar.gz
firefox: Avoid reading from /dev/random on NetBSD
Motivation: This becomes a problem when a user is on a system without HWRNG or a preexisting seed file (to increase the estimated entropy to 256 bits), where Firefox will hang forever on startup waiting for a user to write to /dev/random. Since this was reported on port-arm@, I decided to investigate this, and believe this is the only place Firefox might end up reading from /dev/random. Risk: Probably not much. For actual Transport Layer Security purposes, Network Security Services reads directly from /dev/urandom. On systems where Firefox is used, we can probably reasonably assume that enough entropy has been generated from user input, on-board sensors, and network devices to provide a state that is fairly difficult to predict, even if the NetBSD kernel assigns no value to it (since in embedded environments where the device's operator may be absent, such events can be manipulated to theoretically produce a predictable state - although I don't think this theoretical attack is necessarily something we should be concerned with on low-end desktop systems). Other kernels do assign value to these inputs, so have much lower criteria for unblocking. Bump PKGREVISION
Diffstat (limited to 'cross/nios2-gcc/buildlink3.mk')
0 files changed, 0 insertions, 0 deletions