You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Dale Worley <dw...@pingtel.com> on 2005/08/19 15:29:36 UTC
Neon and /dev/random
My apologies if this has been discussed before, but it seems to me that for
Subversion's use, Neon should be built to use /dev/urandom by default.
/dev/random is necessary if one wants cryptographic-quality random bits, but
as far as I know, Subversion's security does not depend on the
unpredictability of transaction IDs.
On the other hand, a peculiarity of /dev/random is that it extracts its
random information from hardware input events on the computer, but it does
not include disk accesses and network packets, because they are not due to
external physical systems, and might be manipulatable by other
processes/systems on the network. On a workstation, /dev/random gets all
the information it needs from the keyboard and mouse, but Neon runs on a
server, which does not get keyboard and mouse events.
The result is that it's hardly surprising that accessing /dev/random blocks
on some people's servers, and there's no reason not to use /dev/urandom.
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Neon and /dev/random
Posted by kf...@collab.net.
Dale, you've already received on-topic replies. I'm writing to make a
meta-comment:
Please don't follow up to an existing thread to start a new subject.
See http://subversion.tigris.org/mailing-list-guidelines.html#fresh-post
for a detailed explanation of why.
Thanks,
-Karl
"Dale Worley" <dw...@pingtel.com> writes:
> My apologies if this has been discussed before, but it seems to me that for
> Subversion's use, Neon should be built to use /dev/urandom by default.
> /dev/random is necessary if one wants cryptographic-quality random bits, but
> as far as I know, Subversion's security does not depend on the
> unpredictability of transaction IDs.
>
> On the other hand, a peculiarity of /dev/random is that it extracts its
> random information from hardware input events on the computer, but it does
> not include disk accesses and network packets, because they are not due to
> external physical systems, and might be manipulatable by other
> processes/systems on the network. On a workstation, /dev/random gets all
> the information it needs from the keyboard and mouse, but Neon runs on a
> server, which does not get keyboard and mouse events.
>
> The result is that it's hardly surprising that accessing /dev/random blocks
> on some people's servers, and there's no reason not to use /dev/urandom.
>
> Dale
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Neon and /dev/random
Posted by Max Bowsher <ma...@ukf.net>.
Dale Worley wrote:
> My apologies if this has been discussed before, but it seems to me that
> for
> Subversion's use, Neon should be built to use /dev/urandom by default.
We can't really place any reliance on that, though, because more and more,
neon is being built as an independent library, for use by more than just
subversion. If there is a pressing need to stop subversion's use of neon
depleting /dev/random, then neon's API needs to have a way for subversion to
tell it that crypto-strength random numbers are not required.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Neon and /dev/random
Posted by Branko Čibej <br...@xbc.nu>.
Dale Worley wrote:
>My apologies if this has been discussed before, but it seems to me that for
>Subversion's use, Neon should be built to use /dev/urandom by default.
>
>
APR, not Neon.
Anyway, whether or not /dev/urandom should be the default, and on which
systems (not all systems have the blocking /dev/random problem), is a
question for the APR project, not for Subversion.
We use APR as our portability layer, therefore we shouldn't be in the
business of deciding how APR should behave on a particular platform.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Neon and /dev/random
Posted by James FitzGibbon <jf...@primustel.ca>.
Wouldn't using /dev/urandom mean that you would no longer get
cryptographic-quality random bits for accessing https:// repositories? Or
does that setting come from the compiled openssl that neon was built
against?
-----Original Message-----
From: Dale Worley [mailto:dworley@pingtel.com]
Sent: Friday, August 19, 2005 11:30 AM
To: dev@subversion.tigris.org
Subject: Neon and /dev/random
My apologies if this has been discussed before, but it seems to me that for
Subversion's use, Neon should be built to use /dev/urandom by default.
/dev/random is necessary if one wants cryptographic-quality random bits, but
as far as I know, Subversion's security does not depend on the
unpredictability of transaction IDs.
On the other hand, a peculiarity of /dev/random is that it extracts its
random information from hardware input events on the computer, but it does
not include disk accesses and network packets, because they are not due to
external physical systems, and might be manipulatable by other
processes/systems on the network. On a workstation, /dev/random gets all
the information it needs from the keyboard and mouse, but Neon runs on a
server, which does not get keyboard and mouse events.
The result is that it's hardly surprising that accessing /dev/random blocks
on some people's servers, and there's no reason not to use /dev/urandom.
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.12/77 - Release Date: 8/18/2005
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.12/77 - Release Date: 8/18/2005
--
----------------------------------------------------------------------------
This electronic message contains information from Primus Telecommunications
Canada Inc. ("PRIMUS") , which may be legally privileged and confidential.
The information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient, be aware that any
disclosure, copying, distribution or use of the contents of this information
is prohibited. If you have received this electronic message in error, please
notify us by telephone or e-mail (to the number or address above)
immediately. Any views, opinions or advice expressed in this electronic
message are not necessarily the views, opinions or advice of PRIMUS.
It is the responsibility of the recipient to ensure that
any attachments are virus free and PRIMUS bears no responsibility
for any loss or damage arising in any way from the use
thereof.The term "PRIMUS" includes its affiliates.
----------------------------------------------------------------------------
Pour la version en français de ce message, veuillez voir
http://www.primustel.ca/fr/legal/cs.htm
----------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org