> On Jul 21, 2019, at 5:03 PM, Joerg Sonnenberger wrote:
>
>
> [EXTERNAL EMAIL]
>
> On Sun, Jul 21, 2019 at 08:50:30PM +, paul.kon...@dell.com wrote:
>> /dev/urandom is equivalent to /dev/random if there is adequate entropy,
>> but it will also deliver random numbers not suitable for
On Mon, Jul 22, 2019 at 07:11:34PM +0200, Kamil Rytarowski wrote:
>
> It looks like we need a paravirt random driver for xen that could solve
> the rust / random(6) problem.
Or just run on a CPU that has RDRAND / RDSEED available. Our package
builders are old; I'd chip in a few bucks to replace
> On Jul 22, 2019, at 4:55 PM, Joerg Sonnenberger wrote:
>
>
> [EXTERNAL EMAIL]
>
> On Mon, Jul 22, 2019 at 04:36:41PM +, paul.kon...@dell.com wrote:
>>
>>
>>> On Jul 22, 2019, at 10:52 AM, Joerg Sonnenberger wrote:
>>>
>>>
>>> [EXTERNAL EMAIL]
>>>
>>> On Sun, Jul 21, 2019 at
On Mon, Jul 22, 2019 at 04:36:41PM +, paul.kon...@dell.com wrote:
>
>
> > On Jul 22, 2019, at 10:52 AM, Joerg Sonnenberger wrote:
> >
> >
> > [EXTERNAL EMAIL]
> >
> > On Sun, Jul 21, 2019 at 09:13:48PM +, paul.kon...@dell.com wrote:
> >>
> >>
> >>> On Jul 21, 2019, at 5:03 PM,
Kamil Rytarowski writes:
> On 22.07.2019 13:12, Greg Troxel wrote:
>> Taylor R Campbell writes:
>>
It would also be reasonable to have a sysctl to allow /dev/random to
return bytes anyway, like urandom would, and to turn this on for our xen
builders, as a different workaround.
> On Sun, Jul 21, 2019 at 04:53:08PM +, Taylor R Campbell wrote:
>> It has become popular to redefine the traditional semantics of
>> /dev/random or /dev/urandom so that one or both will block once at
>> boot until the OS thinks the entropy pool may have been seeded, and
>> then never
On Mon, Jul 22, 2019 at 07:56:02PM +0200, Havard Eidnes wrote:
> > So, try forcing scp over IPv4 maybe?
>
> Actually, configuring IPv6 in my case (I didn't have that
> already) works much better:
>
> rust-std-1.32.0-i686-unknown-netbsd.tar.gz
> 72,048,862 100% 184.72kB/s0:06:20 (xfr#3,
> So, try forcing scp over IPv4 maybe?
Actually, configuring IPv6 in my case (I didn't have that
already) works much better:
rust-std-1.32.0-i686-unknown-netbsd.tar.gz
72,048,862 100% 184.72kB/s0:06:20 (xfr#3, to-chk=22/69)
rust-std-1.32.0-powerpc-unknown-netbsd.tar.gz
69,624,858
On 22.07.2019 13:12, Greg Troxel wrote:
> Taylor R Campbell writes:
>
>>> It would also be reasonable to have a sysctl to allow /dev/random to
>>> return bytes anyway, like urandom would, and to turn this on for our xen
>>> builders, as a different workaround. That's easy, and it doesn't break
> On Jul 22, 2019, at 10:52 AM, Joerg Sonnenberger wrote:
>
>
> [EXTERNAL EMAIL]
>
> On Sun, Jul 21, 2019 at 09:13:48PM +, paul.kon...@dell.com wrote:
>>
>>
>>> On Jul 21, 2019, at 5:03 PM, Joerg Sonnenberger wrote:
>>>
>>>
>>> [EXTERNAL EMAIL]
>>>
>>> On Sun, Jul 21, 2019 at
On Sun, Jul 21, 2019 at 09:13:48PM +, paul.kon...@dell.com wrote:
>
>
> > On Jul 21, 2019, at 5:03 PM, Joerg Sonnenberger wrote:
> >
> >
> > [EXTERNAL EMAIL]
> >
> > On Sun, Jul 21, 2019 at 08:50:30PM +, paul.kon...@dell.com wrote:
> >> /dev/urandom is equivalent to /dev/random if
> Is that defense.net your own outgoing protection or is there a route
> messed up? I've used them for inline stuff before.
Not mine, no.
> My traceroute is different to say the least!
But your location is also quite different...
Regards,
- Håvard
On 22/07/2019 15:08, Havard Eidnes wrote:
ftp://golden-delicious.urc.uninett.no/pub/rust/rust-std-1.35.0-i686-unknown-netbsd.tar.gz
Why is it not on ftp.NetBSD.org, with other bootstrap kits?
Because copying the bootstrap kits takes forever...
I'm in the process of copying them over, but
On Mon, Jul 22, 2019 at 10:08 AM Havard Eidnes wrote:
>
> >> >> ftp://golden-delicious.urc.uninett.no/pub/rust/rust-std-1.35.0-i686-unknown-netbsd.tar.gz
> >> >
> >> > Why is it not on ftp.NetBSD.org, with other bootstrap kits?
> >>
> >> Because copying the bootstrap kits takes forever...
> >>
>> >> ftp://golden-delicious.urc.uninett.no/pub/rust/rust-std-1.35.0-i686-unknown-netbsd.tar.gz
>> >
>> > Why is it not on ftp.NetBSD.org, with other bootstrap kits?
>>
>> Because copying the bootstrap kits takes forever...
>> I'm in the process of copying them over, but it's a multi-day
>>
On Mon, Jul 22, 2019 at 9:16 AM Havard Eidnes wrote:
>
> >> ftp://golden-delicious.urc.uninett.no/pub/rust/rust-std-1.35.0-i686-unknown-netbsd.tar.gz
> >
> > Why is it not on ftp.NetBSD.org, with other bootstrap kits?
>
> Because copying the bootstrap kits takes forever...
> I'm in the process of
>> ftp://golden-delicious.urc.uninett.no/pub/rust/rust-std-1.35.0-i686-unknown-netbsd.tar.gz
>
> Why is it not on ftp.NetBSD.org, with other bootstrap kits?
Because copying the bootstrap kits takes forever...
I'm in the process of copying them over, but it's a multi-day
effort.
Regards,
-
Taylor R Campbell writes:
>> It would also be reasonable to have a sysctl to allow /dev/random to
>> return bytes anyway, like urandom would, and to turn this on for our xen
>> builders, as a different workaround. That's easy, and it doesn't break
>> the way things are supposed to be for people
On Sun, Jul 21, 2019 at 06:33:27PM +, co...@sdf.org wrote:
> It currently blocks for literally hours/days. We can't have the OS not
> function due to this purity.
A rust build blocking (due to rustc or the rust libraries doing stupid
things) is very much different from "the OS not function".
> On Jul 21, 2019, at 4:55 PM, Edgar Fuß wrote:
>
>
> [EXTERNAL EMAIL]
>
> TRC> There is no reason in modern cryptography to read more than one byte
> TRC> from /dev/random ever in a single application; once you have done
> TRC> that, or confirmed some other way that the the entropy pool is
> In addition, the notion of "entropy being consumed" is obsolete (if it was e$
Oh, it most certainly was, and is, a valid notion. It may currently
appear that the state of the art in PRNGs is good enough that you can
stream unlimited amounts of key material once you have enough entropy
on hand,
> "Just get a 128GB RAM 32 core machine like me, and then you can use
> netbsd"
Hasn't that been NetBSD's stance since 2011-03-30? (Okay, it's an
exaggeration, but not all that much of an exaggeration.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML
On Sun, Jul 21, 2019 at 08:50:30PM +, paul.kon...@dell.com wrote:
> /dev/urandom is equivalent to /dev/random if there is adequate entropy,
> but it will also deliver random numbers not suitable for cryptography before
> that time.
This is somewhat misleading. The problem is that with an
TRC> There is no reason in modern cryptography to read more than one byte
TRC> from /dev/random ever in a single application; once you have done
TRC> that, or confirmed some other way that the the entropy pool is seeded,
TRC> you should generate keys from /dev/urandom.
DAH> There should be some
> On Jul 21, 2019, at 3:20 PM, Taylor R Campbell
> wrote:
>
>
> [EXTERNAL EMAIL]
>
>> Date: Sun, 21 Jul 2019 20:52:52 +0200
>> From: Manuel Bouyer
>>
>> /dev/randon actually works as documented and if rust wants /dev/urandom
>> behavior it should use /dev/urandom. Also I'd like to get
On Sun, Jul 21, 2019 at 07:20:08PM +, Taylor R Campbell wrote:
> > Date: Sun, 21 Jul 2019 20:52:52 +0200
> > From: Manuel Bouyer
> >
> > /dev/randon actually works as documented and if rust wants /dev/urandom
> > behavior it should use /dev/urandom. Also I'd like to get explained why
> > a
On Sun, Jul 21, 2019 at 06:57:30PM +, m...@netbsd.org wrote:
> On Sun, Jul 21, 2019 at 08:52:52PM +0200, Manuel Bouyer wrote:
> > On Sun, Jul 21, 2019 at 06:43:04PM +, m...@netbsd.org wrote:
> > > On Sun, Jul 21, 2019 at 11:55:23AM -0400, Greg Troxel wrote:
> > > > Another approach,
On Sun, Jul 21, 2019 at 07:20:08PM +, Taylor R Campbell wrote:
> This is _locally_ sensible for a library that may have many users
> beyond a compiler.
No, it can be sensible behavior to allow *optionally* checking. But it
is certainly not sensible default behavior for a library.
Joerg
> Date: Sun, 21 Jul 2019 20:52:52 +0200
> From: Manuel Bouyer
>
> /dev/randon actually works as documented and if rust wants /dev/urandom
> behavior it should use /dev/urandom. Also I'd like to get explained why
> a compiler needs that much random bits.
The difference is that /dev/random may
On Sun, Jul 21, 2019 at 08:52:52PM +0200, Manuel Bouyer wrote:
> On Sun, Jul 21, 2019 at 06:43:04PM +, m...@netbsd.org wrote:
> > On Sun, Jul 21, 2019 at 11:55:23AM -0400, Greg Troxel wrote:
> > > Another approach, harder, is to create a xenrnd(4) pseudodevice and
> > > hypervisor call that
On Sun, Jul 21, 2019 at 06:43:04PM +, m...@netbsd.org wrote:
> On Sun, Jul 21, 2019 at 11:55:23AM -0400, Greg Troxel wrote:
> > Another approach, harder, is to create a xenrnd(4) pseudodevice and
> > hypervisor call that gets bits from the host's /dev/random and injects
> > them as if from a
On Sun, Jul 21, 2019 at 11:55:23AM -0400, Greg Troxel wrote:
> Another approach, harder, is to create a xenrnd(4) pseudodevice and
> hypervisor call that gets bits from the host's /dev/random and injects
> them as if from a hardware rng.
>
>
That requires the ability coordinate "please run this
On Sun, Jul 21, 2019 at 04:53:08PM +, Taylor R Campbell wrote:
> It has become popular to redefine the traditional semantics of
> /dev/random or /dev/urandom so that one or both will block once at
> boot until the OS thinks the entropy pool may have been seeded, and
> then never block
g...@lexort.com (Greg Troxel) writes:
>Another approach, harder, is to create a xenrnd(4) pseudodevice and
>hypervisor call that gets bits from the host's /dev/random and injects
>them as if from a hardware rng.
There is a virtio-rng, implementing that interface would be compatible
with other
> Date: Sun, 21 Jul 2019 11:55:23 -0400
> From: Greg Troxel
>
> I don't think we should change /dev/random. For a very long time, the
> notion is that the bits from /dev/random really are ok for keys, and
> there has been a notion that such bits are precious and you should be
> prepared to
> Date: Sun, 21 Jul 2019 17:28:17 +0200
> From: Martin Husemann
>
> Replacing the /dev/random device node by a symlink to /dev/urandom sounds
> fine. For binaries it is easy to just use the sysctl instead to get high
> quality randomness. Are there any shell script like applications that
>
I don't think we should change /dev/random. For a very long time, the
notion is that the bits from /dev/random really are ok for keys, and
there has been a notion that such bits are precious and you should be
prepared to wait. If you aren't generating a key, you shouldn't read
from /dev/random.
On Sun, Jul 21, 2019 at 02:41:57PM +, co...@sdf.org wrote:
> hi,
>
> since netbsd won't stop using broken setups like xen (which don't
> provide randomness) to build packages, why don't we give up on
> /dev/random entirely?
Replacing the /dev/random device node by a symlink to /dev/urandom
On Sun, 21 Jul 2019 15:05:53 +
co...@sdf.org wrote:
> Rust reads a byte from /dev/random before deciding it's OK to read
> /dev/urandom. We are told this is the correct behaviour and that we
> shouldn't upstream "just use /dev/urandom/sysctl equivalent".
Who says this is correct behaviour?
On 21.07.2019 16:53, Kamil Rytarowski wrote:
> On 21.07.2019 16:41, co...@sdf.org wrote:
>> hi,
>>
>> since netbsd won't stop using broken setups like xen (which don't
>> provide randomness) to build packages, why don't we give up on
>> /dev/random entirely?
>>
>
> /dev/random is not defined in
I'm just pissed off with the current status quo that we tolerate
everything being broken.
AMD CPUs do not provide hardware RNG.
NVMe isn't used as an RNG source because it would slow it down too much.
netbsd/xen never heard about RNG. Or monotonic time. Why are we using
this to build packages?!
On 21.07.2019 16:41, co...@sdf.org wrote:
> hi,
>
> since netbsd won't stop using broken setups like xen (which don't
> provide randomness) to build packages, why don't we give up on
> /dev/random entirely?
>
/dev/random is not defined in POSIX.
> since netbsd won't stop using broken setups like xen (which don't
> provide randomness) to build packages, why don't we give up on
> /dev/random entirely?
As in, remove it from everyone's /dev and kernel, or stop using it for
package builds, or get rid of it from NetBSD/xen's /dev, or what?
I
hi,
since netbsd won't stop using broken setups like xen (which don't
provide randomness) to build packages, why don't we give up on
/dev/random entirely?
44 matches
Mail list logo
