diff options
author | nia <nia@pkgsrc.org> | 2020-06-23 17:38:49 +0000 |
---|---|---|
committer | nia <nia@pkgsrc.org> | 2020-06-23 17:38:49 +0000 |
commit | 94d4b620e9ff7b13b5f5f197eaa8e5caaf032e27 (patch) | |
tree | 5fe4b93e1e64c4e02ecb38921cca3abf8a346f2b /chat/ii | |
parent | 1bdf64fe7f4f49dd39eef589c532411a84addff7 (diff) | |
download | pkgsrc-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 'chat/ii')
0 files changed, 0 insertions, 0 deletions