| 3) It is not built by default (except as a kernel module), so you
|either need to add the "options RANDOMDEV" like to your kernel
|config, or load it at boot time in /dev/loader.conf
Can we make this a standard thing? I can't imagine why anyone wouldn't
want /dev/random in
On Sun, 25 Jun 2000, Warner Losh wrote:
Some days is OK, imho. Much more than that and I'd begin to worry.
Much more than a week or two and I'd worry a lot. I'll go put a note
in updating right now.
That's okay with me too. People should just not upgrade their work
machines for the
On Mon, 26 Jun 2000, Mark Murray wrote:
That's okay with me too. People should just not upgrade their work
machines for the next few days until entropy is fixed.
Upgrading is fine; just don't build certificates/credentials.
Or use ssh
Kris
--
In God we Trust -- all others must submit
On Sun, 25 Jun 2000, Soren Schmidt wrote:
It seems Mark Murray wrote:
Without knowing what you typed (and where), I can't help.
Well, I thought that was obvious :)
Not really; folks do the darndest things. :-)
Just added options RANDOMDEV as pr your instructions and made
On Sun, Jun 25, 2000 at 12:55:47PM -0700, Kris Kennaway wrote:
I must say I'm not all that comfortable with this series of commits - I
was expecting this to stay in Mark's tree until it at least tries to do
everything the old driver did. Weakening system security like this for an
On Sun, Jun 25, 2000 at 10:17:27PM +0200, Mark Murray wrote:
2) With the SMP "Destabilization" of the tree coming, I took the
opportunity because
a) Merging differences was going to get harder; and
b) folk were already warned off the use off CURRENT for
production purposes.
On Sun, Jun 25, 2000 at 12:35:12PM +0200, Mark Murray wrote:
3) It is not built by default (except as a kernel module), so you
either need to add the "options RANDOMDEV" like to your kernel
config, or load it at boot time in /dev/loader.conf
Can't things be made to autoload random.ko as
On Sun, Jun 25, 2000 at 12:55:47PM -0700, Kris Kennaway wrote:
I don't know which applications depend on /dev/random providing entropy
and which gather their own.
SSH and SSL should not be used: PGP should be okay.
FWIW, a quick look indicates:
MIT Kerberos V gathers its own
On Sun, Jun 25, 2000 at 12:35:12PM +0200, Mark Murray wrote:
3) It is not built by default (except as a kernel module), so you
either need to add the "options RANDOMDEV" like to your kernel
config, or load it at boot time in /dev/loader.conf
Can't things be made to autoload
]
To: "Kris Kennaway" [EMAIL PROTECTED]
Cc: "Mark Murray" [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, June 26, 2000 3:25 PM
Subject: Re: HEADS UP! New (incomplete) /dev/random device!
On Sun, Jun 25, 2000 at 12:55:47PM -0700, Kris Kennaway wrote:
On Mon, Jun 26, 2000 at 04:09:26PM +0200, Leif Neland wrote:
How much does this "unrandomness" matter?
That's why I said `depending on the application'.
It probably doesn't matter too much for a Kerberos session key that will
be used for the duration of an ftp session.
It definately matters
Mark Murray wrote:
On Sun, 25 Jun 2000, Warner Losh wrote:
Some days is OK, imho. Much more than that and I'd begin to worry.
Much more than a week or two and I'd worry a lot. I'll go put a note
in updating right now.
That's okay with me too. People should just not upgrade
On Sun, Jun 25, 2000 at 12:35:12PM +0200, Mark Murray wrote:
1) It is not yet cryptographically secure, so those of you using
CURRENT for "live" projects, please be careful!
I guess it follows that it is not a good idea to generate keys or
certificates on -CURRENT for a while (until entropy
I guess it follows that it is not a good idea to generate keys or
certificates on -CURRENT for a while (until entropy comes back to town)?
Correct if they rely on /dev/random for entropy.
I don't know which applications depend on /dev/random providing entropy
and which gather their own.
It seems Mark Murray wrote:
Hola Mondo!
The New /dev/random device is in but there are come caveats.
1) It is not yet cryptographically secure, so those of you using
CURRENT for "live" projects, please be careful!
2) If you do not have the randomdev module loaded, ssh will
fail
Hi
Without knowing what you typed (and where), I can't help.
M
Uhm, what about this:
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions
-ansi -g -nostdinc -I- -I. -I../..
It seems Mark Murray wrote:
Hi
Without knowing what you typed (and where), I can't help.
Well, I thought that was obvious :)
Just added options RANDOMDEV as pr your instructions and made
a new kernel with config -r and make depend then make
cc -c -O -pipe -Wall -Wredundant-decls
Without knowing what you typed (and where), I can't help.
Well, I thought that was obvious :)
Not really; folks do the darndest things. :-)
Just added options RANDOMDEV as pr your instructions and made
a new kernel with config -r and make depend then make
Do you have a full crypto
It seems Mark Murray wrote:
Without knowing what you typed (and where), I can't help.
Well, I thought that was obvious :)
Not really; folks do the darndest things. :-)
Just added options RANDOMDEV as pr your instructions and made
a new kernel with config -r and make depend then
Do you have a full crypto distribution (kernel also)?
Nope, just figured that out myself :)
Aren't we supposed to be able to build without crypto ??
I'm not sure about that rule anymore; AFAIK, it is not possible.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To
It seems Mark Murray wrote:
Do you have a full crypto distribution (kernel also)?
Nope, just figured that out myself :)
Aren't we supposed to be able to build without crypto ??
I'm not sure about that rule anymore; AFAIK, it is not possible.
Hmm, we also have another rule, and that
I'm not sure about that rule anymore; AFAIK, it is not possible.
Hmm, we also have another rule, and that is to test before commit,
the following patch is needed to make a current kernel with
your resent commits compile :)
Fooey. :-(
This is what you get from too-heavy testing in
It seems Mark Murray wrote:
I'm not sure about that rule anymore; AFAIK, it is not possible.
Hmm, we also have another rule, and that is to test before commit,
the following patch is needed to make a current kernel with
your resent commits compile :)
Fooey. :-(
This is what you
He he :) remember the patch to i386/i386/mem.c as that is also
broken, the default statement is best used _inside_ a switch :)
Yeah - I got that :-).
That makes my kernel compile, but ssh doesn't work anymore,
What are the symptoms?
which might be due to world being broken due to your
It seems Mark Murray wrote:
He he :) remember the patch to i386/i386/mem.c as that is also
broken, the default statement is best used _inside_ a switch :)
Yeah - I got that :-).
And the one to yarrow.c ??
That makes my kernel compile, but ssh doesn't work anymore,
What are the
On Sun, 25 Jun 2000, Mark Murray wrote:
I don't know which applications depend on /dev/random providing entropy
and which gather their own.
Right.
SSH and SSL should not be used: PGP should be okay.
I must say I'm not all that comfortable with this series of commits - I
was expecting
On Sun, 25 Jun 2000, Soren Schmidt wrote:
It complains about libcrypto libssl not containing RSA, but it
might be because make world is broken due to perl...
This happens when a test RSA operation fails - but OpenSSH doesn't try to
check why it fails and assumes it was because no RSA code
In message [EMAIL PROTECTED] Kris
Kennaway writes:
: I must say I'm not all that comfortable with this series of commits - I
: was expecting this to stay in Mark's tree until it at least tries to do
: everything the old driver did. Weakening system security like this for an
: indeterminate
And the one to yarrow.c ??
Done!
What are the symptoms?
It complains about libcrypto libssl not containing RSA, but it
might be because make world is broken due to perl...
That means the /dev/random driver is not loaded.
/../../contrib/perl5/configpm line 20.
Use of uninitialized
I must say I'm not all that comfortable with this series of commits - I
was expecting this to stay in Mark's tree until it at least tries to do
everything the old driver did. Weakening system security like this for an
indeterminate period really bothers me.
1) I whined for reviews for long
It complains about libcrypto libssl not containing RSA, but it
might be because make world is broken due to perl...
This happens when a test RSA operation fails - but OpenSSH doesn't try to
check why it fails and assumes it was because no RSA code even
exists. It's probably more likely
Yes. Me too. Mark, how long is this period going to be?
Some days. Certainly a lot shorter that the SMP destabilization.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the
On Sun, 25 Jun 2000, Mark Murray wrote:
I must say I'm not all that comfortable with this series of commits - I
was expecting this to stay in Mark's tree until it at least tries to do
everything the old driver did. Weakening system security like this for an
indeterminate period really
In message [EMAIL PROTECTED] Mark Murray writes:
: Yes. Me too. Mark, how long is this period going to be?
:
: Some days. Certainly a lot shorter that the SMP destabilization.
Some days is OK, imho. Much more than that and I'd begin to worry.
Much more than a week or two and I'd
On Sun, 25 Jun 2000, Warner Losh wrote:
Some days is OK, imho. Much more than that and I'd begin to worry.
Much more than a week or two and I'd worry a lot. I'll go put a note
in updating right now.
That's okay with me too. People should just not upgrade their work
machines for the next
Kris Kennaway wrote:
On Sun, 25 Jun 2000, Warner Losh wrote:
Some days is OK, imho. Much more than that and I'd begin to worry.
Much more than a week or two and I'd worry a lot. I'll go put a note
in updating right now.
That's okay with me too. People should just not upgrade their
36 matches
Mail list logo
