RE: randomdev entropy gathering is really weak

[David Schwartz]

> > /dev/random should block if the system does not contain as much
> real entropy
> > as the reader desires. Otherwise, the PRNG implementation will be the
> > weakest link for people who have deliberately selected higher levels of
> > protection from cryptographic attack.

> I don't want to rehash this thread from the beginning. Please go
> back, read the Yarrow paper, and recognise that Yarrow is not an
> entropy-counter, it is a cryptographically secure PRNG. The "count
> random bits and block" model does not apply.

Then the current implementation cannot provide the usual semantics for
/dev/random, while it can provide the semantics for /dev/urandom. As I
understand it, /dev/random is supposed to provide true randomness suitable
for generating keys of unlimited length, whereas /dev/urandom is supposed to
provide cryptographically-strong randomness for general applications.

If people want /dev/random to seed 1024-bit keys, /dev/random must be
stronger than a 1024-bit key.

DS



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

World broken

[Warner Losh]

makeworld from -stable is broken.  Needless to say this is completely
and totally unacceptible.  Would the people involved with the mtree
and settofflags changes please get together and fix this right.

cc -O -pipe -DMD5 -DSHA1 -DRMD160   -I/usr/obj/home/imp/FreeBSD/src/i386/usr/include  
-o mtree compare.o crc.o create.o excludes.o misc.o mtree.o spec.o verify.o  -lmd
misc.o: In function `flags_to_string':
misc.o(.text+0x89): undefined reference to `fflagstostr'
spec.o: In function `set':
spec.o(.text+0x5f5): undefined reference to `strtofflags'
*** Error code 1

I'm kludging mtree so that make buildworld isn't broken.  Don't remove
the kludge until such time as the underlying problems have been
corrected.

FLAME ON

Can't people test the changes they make?  I mean this one bit me in
less than a minute for a buildworld.  Less than a minute.

GRUMP.  I'm not amused.

FLAME OFF

I got here checking an UPDATING entry someone sent me saying that one
needed to do a makeinstall in libc before this would succeed

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: buildworld failure

[John Polstra]

In article <[EMAIL PROTECTED]>,
Doug White  <[EMAIL PROTECTED]> wrote:
> 
> Incidentally, whoever broke this should be shot and strung -- I thought
> that upgrading from the latest -STABLE to -CURRENT was a supported
> operation?
> 
> Copying files from snapshots to bootstrap yourself is just plain
> unacceptable.

In general -current has been a cesspool for the past year, and things
haven't been so great in -stable either.  We shouldn't even _need_ an
UPDATING file because there shouldn't have to be any special updating
procedures.  We got by without them just fine the first few years I
was involved with the project.  An upgrade was make world and build a
kernel -- nothing more.

Breaking make world used to be considered a major embarrassment.  Now
it's practically a daily occurrance.

Some developers just aren't being careful enough.  The biggest problem
is they don't restore their systems to a 100% pristine state before
they test.  Their own make world runs falsely succeed, because they
already had the key header file, library, or utility installed from
earlier testing and they didn't take care to revert it before trying a
make world.  Doing it right takes some thought and some care.  I would
like to see more of that and less impatience around here.

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

KDE2 hangs in 5.0-CURRENT but not in 4.1RC ...

[The Hermit Hacker]

I've been spending the past few days trying to get KDE2 from anoncvs to
work on my 5.0-CURRENT machine, totally unsuccessfully.  I can get it to
compile and then run 'startx', but it appears to hang on the ksmserver
process ...

Will Andrews, who is working on the KDE2 ports, has the same thing running
on his 4.1RC system, so I'm starting to wonder if the "bug" is in FreeBSD
vs KDE2 ...

>From what I've been able to determine, the 'hang' is in ksmserver, which
is the last thing that 'startkde' runs.  After it hangs, I've done a
'gcore' of the process, with the results showing the following:

Script started on Sun Jul 23 01:19:11 2000
> gdb `which ksmserver` core.12615 
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...

warning: exec file is newer than core file.
Core was generated by `ksmserver'.
Reading symbols from /usr/local/lib/libkdecore.so.3...done.
Reading symbols from /usr/local/lib/libkde-qt-addon.so.3...done.
Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
Reading symbols from /usr/local/lib/libDCOP.so.1...done.
Reading symbols from /usr/local/lib/libqt.so...done.
Reading symbols from /usr/local/lib/libpng.so.4...done.
Reading symbols from /usr/lib/libz.so.2...done.
Reading symbols from /usr/local/lib/libjpeg.so.9...done.
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /usr/lib/libstdc++.so.3...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x289659c4 in select () from /usr/lib/libc.so.4
(gdb) bt
#0  0x289659c4 in select () from /usr/lib/libc.so.4
#1  0x2881a1b5 in _XWaitForReadable () from /usr/X11R6/lib/libX11.so.6
#2  0x2881ab59 in _XRead () from /usr/X11R6/lib/libX11.so.6
#3  0x2881b69c in _XReply () from /usr/X11R6/lib/libX11.so.6
#4  0x28807520 in XInternAtom () from /usr/X11R6/lib/libX11.so.6
#5  0x28872b62 in _XimFilterPropertyNotify () from /usr/X11R6/lib/libX11.so.6
#6  0x288391f5 in XFilterEvent () from /usr/X11R6/lib/libX11.so.6
#7  0x282e1c28 in QApplication::x11ProcessEvent () from /usr/local/lib/libqt.so
#8  0x282e16cf in QApplication::processNextEvent ()
   from /usr/local/lib/libqt.so
#9  0x2837fa0b in QApplication::enter_loop () from /usr/local/lib/libqt.so
#10 0x282e165b in QApplication::exec () from /usr/local/lib/libqt.so
#11 0x80546f1 in main (argc=2, argv=0xbfbffa90) at main.cpp:80
(gdb) quit
> exit
exit

Script done on Sun Jul 23 01:19:30 2000

I'm at a loss as to where to look from here ... but if the same code
appears to be working fine under 4.1RC and not 5.0-CURRENT, suspecting a
bug in KDE2 appears to be the wrong path to be searching ...

Thoughts?  Comments?  Suggestions on where further to look?

Thanks ...



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: buildworld failure

[Doug White]

On Sun, 23 Jul 2000, Bruce Evans wrote:

> > Do I have to do something special before I can do a 'make buildworld', or
> > is ~current currently broken ?
> 
> Bootstrapping from 4.0 and previous versions to 4.1 and -current is broken,
> because mtree depends on new library features but must be built before the
> new libraries.  You have to somehow bootstrap the new libraries.  Maybe
> copy them from a current snapshot.

Incidentally, whoever broke this should be shot and strung -- I thought
that upgrading from the latest -STABLE to -CURRENT was a supported
operation?

Copying files from snapshots to bootstrap yourself is just plain
unacceptable.

Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED] |  www.FreeBSD.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SBLive (value)

[Thomas R. Stromberg]

Frank Mayhar wrote:
> 
> Kent Hauser wrote:
> > I've again been trying to get my sound support working.
> > The problem I have is the machine panic's (RAM parity error)
> > whenever I (for instance) play an mp3.
> 
> This is a known problem with the SBLive and machines with ECC memory.  So
> far no sign of a fix for it.
> 
> Jordan, if you read this, please email me the address to send the memory
> stick.  I'll contribute it to the cause.  (I'll need a receipt, though. ;-)
> --
> Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
> Exit Consulting http://store.exit.com/
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

I get the panic myself without ECC memory. I posted a crash dump myself
a few weeks ago. This also affects -STABLE I believe.

Would be neat to fix for 4.1, but probably a little late.

The GNATS entry is at:
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19022

/ Thomas


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Kris Kennaway]

On Sat, 22 Jul 2000, Jeroen C. van Gelderen wrote:

> I agree that you need long RSA keys ... but the real 
> discussion isn't really about key length but rather about 
> the overall complexity of attacking the key:

Okay, using RSA keys wasn't the best example to pick, but Yarrow also
seems easy to misuse in other cases: for example if you want to generate
multiple 256-bit symmetric keys (or other random data) at the same time,
each additional key after the first won't contain any additional entropy,
so if you break the state of the PRNG at the time the first one was
generated you get the others for free (until the thing reseeds).

This design tradeoff is discussed in section 4.1 of the paper.

> That said, there is nothing to prevent the system admin 
> from tweaking the Yarrow security parameters so that 
> Yarrow will only spit out as many bits or pseudo-randomness 
> as it gathers bits of entropy.[4]

Well, I don't see a way to tune this without modifying the Yarrow design,
since the entropy pool is intentionally decoupled from the output
mechanism, and it seems like it would add additional (unnecessary)
overhead anyway to use it in that fashion.

Indications are we can probably get quite a lot of usable entropy from a
standard system (on the order of many kilobytes per second - but I need to
read more of the literature about processing of entropy samples) - in this
case I think maintaining a third pool which is directly tapped by
/dev/random, and leaving Yarrow sitting behind /dev/urandom is the way to
go.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Jeroen C. van Gelderen]

Kris Kennaway wrote:
> 
> On Sat, 22 Jul 2000, Jeroen C. van Gelderen wrote:
> 
> > You don't care in practice, 256 bits are unguessable.
> 
> Actually, I do..that's the entire point of using long keys.

I agree that you need long RSA keys ... but the real 
discussion isn't really about key length but rather about 
the overall complexity of attacking the key:

The complexity of factoring a 1024-bit RSA keys is on the
order of 2^71 operations. For a 3214-bit key it is roughly 
equivalent to 2^101 complexity. (See [1][2] for gloriously 
arcane details.)

Now, assuming that you generate a 3214-bit RSA key from a 
256-bit entropy pool, the complexity of factoring it (2^101) 
is much lower than the complexity of guessing the entropy
pool from which it was generated (2^256); Actually, factoring 
is the most efficient attack up to the point where you are 
using something like a 13841-bit RSA key[3].

So, for practical key purposes Yarrow-256 is in excess of 
complexity requirements. (I can't say anything about other 
uses than crypto but seeing as the promise of /dev/random 
is cryptographically secure random numbers this should not 
pose a problem.)

That said, there is nothing to prevent the system admin 
from tweaking the Yarrow security parameters so that 
Yarrow will only spit out as many bits or pseudo-randomness 
as it gathers bits of entropy.[4]

Check out http://www.cryptosavvy.com/table.htm and preferrably
the full paper at http://www.cryptosavvy.com/cryptosizes.pdf
if you remain unconvinced :-)

Cheers,
Jeroen

[1] Numbers from http://www.cryptosavvy.com/table.htm .

[2] Yes, this sortof means that using >= 128-bit keys is 
overkill for most applications that use assymmetric
algorithms for key-negotiation :-)

[3] http://www.cryptosavvy.com/suggestions.htm

[4] And if you really would like to restore the old semantics
of /dev/[u]random, you could code it into Yarrow. Just 
make /dev/random block based on the entropy estimation 
that Yarrow keeps anyway.

-- 
Jeroen C. van Gelderen  o  _ _ _
[EMAIL PROTECTED]  _o /\_   _ \\o  (_)\__/o  (_)
  _< \_   _>(_) (_)/<_\_| \   _|/' \/
 (_)>(_) (_)(_)   (_)(_)'  _\o_


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: missing idea.h ... ?

[Alex Zepeda]

On Fri, 21 Jul 2000, The Hermit Hacker wrote:

> If it helps any, I setup an anoncvs mirror for most of the stuff ... not
> sure if it helps any, since you are working off of snapshots, but its
> updated every 4hrs from the central repository, and the CVSROOT for it was
> announced on kde-devel ...

What really needs to be done is fixing up of the kconsole grantpty code,
the socket credentials code in kdesu(d) as well as some of the system info
gathering for kcontrol as well as ksysguard.  But that's just if you're
looking for some code to hack on :)

- alex



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: buildworld failure

[Norbert Irmer]

Marcel Moolenaar wrote:
> 
> Bruce Evans wrote:
> >
> > Bootstrapping from 4.0 and previous versions to 4.1 and -current is broken,
> > because mtree depends on new library features but must be built before the
> > new libraries.  You have to somehow bootstrap the new libraries.  Maybe
> > copy them from a current snapshot.
> 
> Grrr...
> 
> Is there a clean way to fix this, other than reverting the -L
> incompatibility?
> Did we bump the libc version number when the strtofflags/fflagstostr
> functions went in?
> 

Thanks for the information.

I could solve this dilemma by adding the source file 'strtofflags.c' from the
new 'libc' sources temporarily to the sources of 'mtree'.
Then I could do a 'buildworld'. Afterwards I replaced the old libc with the
new libc, removed 'strtofflags.c' from the sources of 'mtree' again, 
and rebuild it.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Kris Kennaway]

On Sat, 22 Jul 2000, Jeroen C. van Gelderen wrote:

> You don't care in practice, 256 bits are unguessable.

Actually, I do..that's the entire point of using long keys.

> If you do care, you load a different random module :-)

The core of my complaint is that even though our old PRNG did crappy
entropy handling, we used to have such a method, which is now gone. I'd
like to see yarrow hang off /dev/urandom and have /dev/random tap directly
into the entropy pool (perhaps a third pool separate from Yarrow's
fast/slow) so I can generate my large keys safely.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Perl libraries install in wrong place...

[Eric Jacoboni]

> "Mike" == Mike Meyer <[EMAIL PROTECTED]> writes:

Mike> Basically, some (all?) ports that install perl libraries want to
Mike> install them in /usr/local, without paying proper heed to
Mike> PREFIX. Things wind up in /usr/local, and I then get complaints about
Mike> missing files for them when I deinstall the port. Further,
Mike> ${LOCALBASE}/lib/perl5 has no actual files in it - just
Mike> directories.

Yes, same for me... It seems there is a mess with Perl ports since the
5.6.0 upgrade. For my own, i've decided to make all modules by hand,
waiting for the fix.

-- 
-
Éric Jacoboni   « No sport, cigars! »  (W. Churchill)
-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Kris Kennaway]

On Sat, 22 Jul 2000, Mark Murray wrote:

> > So what it if I want/need 257 bits? :-)
> 
> Read them. You'll get them. If you want higher quality randomness than
> Yarrow gives, read more than once. Do other stuff; play. Don't get stuck
> in the "I have exhausted the randomness pool" loop; Yarrow does not play
> that game.

I think you're missing the point. The only way I can get a random number
with more than n bits of entropy out of Yarrow-n is if I sample either
side of a reseed operation, which in general comes down to timing
guesswork and having to make assumptions about the PRNG implementation.

If you want to generate a cryptographic key of length n bits then you
really want >n bits of entropy in the random source you're deriving it
from, otherwise your key is actually much weaker than advertised because
it's easier for the attacker to attack the state of the PRNG that derived
it than to attack the key itself.

> >From the Yarrow paper:
> ``Yarrow's outputs are cryptographically derived. Systems that use Yarrow's
> outputs are no more secure than the generation mechanism used.''
> 
> We currently have Yarrow-256(Blowfish); wanna make it Yarrow-1024? I could
> make it so.

Well, if we did that then how about generating 2048-bit keys? :-)

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: buildworld failure

[Marcel Moolenaar]

Bruce Evans wrote:
> 
> Bootstrapping from 4.0 and previous versions to 4.1 and -current is broken,
> because mtree depends on new library features but must be built before the
> new libraries.  You have to somehow bootstrap the new libraries.  Maybe
> copy them from a current snapshot.

Grrr...

Is there a clean way to fix this, other than reverting the -L
incompatibility?
Did we bump the libc version number when the strtofflags/fflagstostr
functions went in?

-- 
Marcel Moolenaar
  mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
  tel:  (408) 447-4222


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Perl libraries install in wrong place...

[Mike Meyer]

Maybe this belongs in ports, but it looks like the problem is actually
somewhere inside the Perl build, which I think means it belongs here.

Basically, some (all?) ports that install perl libraries want to
install them in /usr/local, without paying proper heed to
PREFIX. Things wind up in /usr/local, and I then get complaints about
missing files for them when I deinstall the port. Further,
${LOCALBASE}/lib/perl5 has no actual files in it - just
directories.

ImageMagick is one such port. A make install generates the following
output fragment:

Manifying blib/man3/Image::Magick.3
Installing /usr/local/lib/perl5/site_perl/5.6.0/mach/auto/Image/Magick/Magick.so
Installing /usr/local/lib/perl5/site_perl/5.6.0/mach/auto/Image/Magick/Magick.bs
Files found in blib/arch: installing files in blib/lib into architecture dependent 
library tree
Installing /usr/local/lib/perl5/site_perl/5.6.0/mach/auto/Image/Magick/autosplit.ix
Installing /usr/local/lib/perl5/site_perl/5.6.0/mach/Image/Magick.pm
Installing /usr/local/lib/perl5/5.6.0/man/man3/Image::Magick.3
Writing /usr/local/lib/perl5/site_perl/5.6.0/mach/auto/Image/Magick/.packlist

Even though LOCALBASE is set to /usr/opt in /etc/make.conf.

Only the Perl portion of the port does this, and Perl has magic that I
don't understand for doing such libraries. Since I don't find the
string /local/ in the Perl stuff, this makes me think it may be in the
Perl configuration, not the port.

Any help from someone who understands the perl package system would be
greatly appreciated.

Thanx,

Re: randomdev entropy gathering is really weak

[Mark Murray]

> /dev/random should block if the system does not contain as much real entropy
> as the reader desires. Otherwise, the PRNG implementation will be the
> weakest link for people who have deliberately selected higher levels of
> protection from cryptographic attack.

I don't want to rehash this thread from the beginning. Please go
back, read the Yarrow paper, and recognise that Yarrow is not an
entropy-counter, it is a cryptographically secure PRNG. The "count
random bits and block" model does not apply.

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 message

Re: Journaling Filesystem ?

[James FitzGibbon]

* Thomas T. Veldhouse ([EMAIL PROTECTED]) [000721 16:01]:

> Hello.  I was wondering if there is any work on a Journaling filesystem to
> possible replace, or as an alternative to UFS.  I have been following
> ReiserFS for Linux quite closely, and I have had the chance to experiment
> with it.  It seems to be coming along nicely and the performance is great.
> Are there plans for something along this line for FreeBSD?  Is there a
> project underway?

At the Usenix 2000 Conference, a paper comparing Softupdates to a
Journalling Filesystem was presented.  The author said that the tests were
performed on a FreeBSD box.  AFAIK, the code is not yet available, but one
of the other attendees mentioned that it would be 'some time in the near
future'.

The journally system allowed for the journal to exist as a file on the
filesystem in question, or on a separate partition (which would be mounted
synchronously to provide a level of protection from crashes).  That having
been said, the performance of the filesystem was not significantly different
from softupdates.

You can get at the paper if you're a Usenix member.  The authors included
Margo Selzer and Kirk McKusick, but the talk was given by another of the
authors whose name I can't recall at the moment.

-- 
j.

James FitzGibbon   [EMAIL PROTECTED]
Targetnet.com Inc.  Voice/Fax +1 416 306-0466/0452


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: randomdev entropy gathering is really weak

[David Schwartz]

> From the Yarrow paper:
> ``Yarrow's outputs are cryptographically derived. Systems that
> use Yarrow's
> outputs are no more secure than the generation mechanism used.''
>
> We currently have Yarrow-256(Blowfish); wanna make it Yarrow-1024? I could
> make it so.
>
> M
> --
> Mark Murray

It doesn't matter if it's Yarrow-256, Yarrow-1024, or Yarrow-10.
/dev/random should block if the system does not contain as much real entropy
as the reader desires. Otherwise, the PRNG implementation will be the
weakest link for people who have deliberately selected higher levels of
protection from cryptographic attack.

DS



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: buildworld failure

[Bruce Evans]

On Sat, 22 Jul 2000, Norbert Irmer wrote:

> I cvsup'ed the lastest sources of ~current, but got the
> following after only a few seconds
> 
> cd /usr/src/usr.sbin/mtree; make _EXTRADEPEND
> ...
> cc -O -pipe -DMD5 -DSHA1 -DRMD160   -I/usr/obj/usr/src/i386/usr/include  -o mtree 
>compare.o crc.o
> create.o excludes.o misc.o mtree.o spec.o verify.o  -lmd
> misc.o: In function `flags_to_string':
> misc.o(.text+0x89): undefined reference to `fflagstostr'
> spec.o: In function `set':
> spec.o(.text+0x5f5): undefined reference to `strtofflags'
> *** Error code 1
> 
> Do I have to do something special before I can do a 'make buildworld', or
> is ~current currently broken ?

Bootstrapping from 4.0 and previous versions to 4.1 and -current is broken,
because mtree depends on new library features but must be built before the
new libraries.  You have to somehow bootstrap the new libraries.  Maybe
copy them from a current snapshot.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Rodney W. Grimes]

> On Fri, 21 Jul 2000, Mark Murray wrote:
> 
> > Section 2.1, last paragraph:
> > "If a system is shut down, and restarted, it is desirable to store some
> > high-entropy data (such as the key) in non-volatile memory. This allows
> > the PRNG to be restarted in an unguessable state at the next restart. We
> > call this data the reseed file."
> 
> I'm all for storing a sample at shutdown and using it to help seed the
> PRNG at startup, but it shouldn't be the only seed used (for example, the
> case where the system has never been shut down (cleanly) before and so has
> no pre-existing seed file is a BIG corner case to consider since thats how
> the system is at the time it first generates SSH keys after a fresh
> install).
> 
> It might be only an academic vulnerability, but if someone can read your
> HD during the time the system is shut down then I'd prefer them not to
> know the precise state when the system next starts up again. Yes, if they
> can read they can probably also write, but it seems like a mistake when
> there's nothing really gained by saving the complete state, as opposed to
> an extract.

And for folks like us who do mass installs via dd if=/dev/da1 of=/dev/da2,
where da1 is a mastered image created via ``make installworld DESTDIR=/mnt'',
the corner case is very large.  I have been bitten by an event where the
master disk was booted once before replication, and thus all systems
had _IDENTICAL_ /etc/ssh contents.  Not a very good idea !!

We have amended the manufacturing process now, so that part of the
disk replication is the nuking and regeneration of /etc/ssh.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

buildworld failure

[Norbert Irmer]

I cvsup'ed the lastest sources of ~current, but got the
following after only a few seconds

cd /usr/src/usr.sbin/mtree; make _EXTRADEPEND
echo mtree: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/lib/libmd.a 
>> .depend
cc -O -pipe -DMD5 -DSHA1 -DRMD160   -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.sbin/mtree/compare.c
cc -O -pipe -DMD5 -DSHA1 -DRMD160   -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.sbin/mtree/../../usr.bin/cksum/crc.c
cc -O -pipe -DMD5 -DSHA1 -DRMD160   -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.sbin/mtree/create.c
cc -O -pipe -DMD5 -DSHA1 -DRMD160   -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.sbin/mtree/excludes.c
cc -O -pipe -DMD5 -DSHA1 -DRMD160   -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.sbin/mtree/misc.c
/usr/src/usr.sbin/mtree/misc.c: In function `flags_to_string':
/usr/src/usr.sbin/mtree/misc.c:120: warning: assignment makes pointer from integer 
without a cast
cc -O -pipe -DMD5 -DSHA1 -DRMD160   -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.sbin/mtree/mtree.c
cc -O -pipe -DMD5 -DSHA1 -DRMD160   -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.sbin/mtree/spec.c
cc -O -pipe -DMD5 -DSHA1 -DRMD160   -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.sbin/mtree/verify.c
cc -O -pipe -DMD5 -DSHA1 -DRMD160   -I/usr/obj/usr/src/i386/usr/include  -o mtree 
compare.o crc.o
create.o excludes.o misc.o mtree.o spec.o verify.o  -lmd
misc.o: In function `flags_to_string':
misc.o(.text+0x89): undefined reference to `fflagstostr'
spec.o: In function `set':
spec.o(.text+0x5f5): undefined reference to `strtofflags'
*** Error code 1

Do I have to do something special before I can do a 'make buildworld', or
is ~current currently broken ?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[Bruce Evans]

On Sat, 22 Jul 2000, John Baldwin wrote:

> Bruce Evans wrote:
> > The dangerously dedicated case has one slice covering the whole disk.  We
> > unclip the slice info from the magic 5 sectors to the size of the whole
> > disk (as reported by the driver) to handle this.  Reading the slice info
> > using DIOCGSLICEINFO shows the full size, but no changes are made to the
> > mbr.  This is in the kernel.  I'm not sure exactly what libdisk does, but
> > it is constrained by what the kernel will accept.
> > 
> > Bruce

Please don't quote signatures or other irrelevant points.

> Ok, so we normally do clip slice information, except in the case of a
> dangerously dedicated slice.  Which works fine so long as no one ever

There is nothing to clip, since the dangerously dedicated slice is the
whole disk.

> creates a 5 block slice in the 4th entry, as we will expand that
  sector
> slice to cover all of the disk.  It also means that kernel, like the loader,

Normal 5-sector slices are very unlikely to be misinterpreted as
dangerously dedicated ones.  A 5000-sector slice is (or should be) only
interpreted as dangerously dedicated if:
1. all bytes in the partition table have certain values, in particular:
2. the slice type is 0xA5 ("FreeBSD").
3. the starting sector is 0 absolute.  This is is strictly invalid for
   normal slices.
4. the ending C/H/S is 255/255/255.  5-sector slices starting at
   absolute 0 can't reach that far.

> has to special case when it sees a dangeriously dedicated slice, which is
> rather evil, IMO.

It's no more evil than the boot signature.  The garbage in the partition
table is treated as a signature.  It is more authoritative because it is
larger and more magic.

The loader really shouldn't know about the dangerously dedicated case.
Its detection of the dangerously dedicated case is buggy.  It only checks
the conditions (2) and (3) above (and that the slice size is 5).

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Jeroen C. van Gelderen]

Kris Kennaway wrote:
> 
> On Fri, 21 Jul 2000, Mark Murray wrote:
> 
> > Section 2.1, last paragraph:
> > "If a system is shut down, and restarted, it is desirable to store some
> > high-entropy data (such as the key) in non-volatile memory. This allows
> > the PRNG to be restarted in an unguessable state at the next restart. We
> > call this data the reseed file."
> 
> I'm all for storing a sample at shutdown and using it to help seed the
> PRNG at startup, but it shouldn't be the only seed used (for example, the
> case where the system has never been shut down (cleanly) before and so has
> no pre-existing seed file is a BIG corner case to consider since thats how
> the system is at the time it first generates SSH keys after a fresh
> install).
> 
> It might be only an academic vulnerability, but if someone can read your
> HD during the time the system is shut down then I'd prefer them not to
> know the precise state when the system next starts up again. Yes, if they
> can read they can probably also write, but it seems like a mistake when
> there's nothing really gained by saving the complete state, as opposed to
> an extract.

Well, academic or not (not when you run financial transactioning
systems on FreeBSD) you can edit rc.shutdown to not write out a
seed file. You don't have to use it but it's good that it's there.

Cheers,
Jeroen
-- 
Jeroen C. van Gelderen  o  _ _ _
[EMAIL PROTECTED]  _o /\_   _ \\o  (_)\__/o  (_)
  _< \_   _>(_) (_)/<_\_| \   _|/' \/
 (_)>(_) (_)(_)   (_)(_)'  _\o_


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Jeroen C. van Gelderen]

Kris Kennaway wrote:
> 
> On Sat, 22 Jul 2000, Mark Murray wrote:
> 
> > Lots of references: Schneier's "Applied Cryptography" talks about
> > using Good Hashes for crypto and Good Crypto for hashes. Schneier's
> > site at www.counterpane.com will give you plenty.
> 
> I havent been able to get my hands on Applied Cryptography, but I don't
> recall seeing anything like this on the website. I'll check again.
> 
> > The differnce with the old system and Yarrow is yarrow's self-recovery
> > property; Yarrow screens its internal state from the ouside world
> > very heavily, and provides enough perturbation of it from its
> > copious :-) entropy harvesting to keep the state safe from compromise.
> 
> Yeah, I know all this and agree that Yarrow makes a better /dev/urandom,
> but it doesn't change the fact that Yarrow-256 is only good for 256 bits
> of entropy between reseeding operations. You can pull all you want out of
> it but will never get more than 256 bits until it reseeds.

You don't care in practice, 256 bits are unguessable.
If you do care, you load a different random module :-)

Cheers,
Jeroen
-- 
Jeroen C. van Gelderen  o  _ _ _
[EMAIL PROTECTED]  _o /\_   _ \\o  (_)\__/o  (_)
  _< \_   _>(_) (_)/<_\_| \   _|/' \/
 (_)>(_) (_)(_)   (_)(_)'  _\o_


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[John Baldwin]

Bruce Evans wrote:
> On Fri, 21 Jul 2000, John Baldwin wrote:
> 
> > Bruce Evans wrote:
> > > On Thu, 20 Jul 2000, John Baldwin wrote:
> > > > ...
> > > > unused even though it is, in fact, used.  The fact that it works at all is
> > > > due to brokenness on our part (we don't check that partitions in a disklabel
> > > > fit in the parent slice) and also results in several hacks in various portions
> > > > of the code where we have to check for such bogusness and work around it.
> > > 
> > > No, that's wrong too :-) .  We a lot of checking that partitions in a
> > > disklabel fit in the parent slice.  We clip partitions that don't fit in
> > > various ways for backwards compatibility.
> 
> > Erm, maybe we clip partitions which aren't dangerously dedicated, but
> > I've created test dangerously dedicated disks, and we certainly do not
> > bother to actually change any of the slice information when we do so.
> > disklabel(8) does for truly dedicated, but libdisk doesn't for dangerously
> > dedicated.
> 
> The dangerously dedicated case has one slice covering the whole disk.  We
> unclip the slice info from the magic 5 sectors to the size of the whole
> disk (as reported by the driver) to handle this.  Reading the slice info
> using DIOCGSLICEINFO shows the full size, but no changes are made to the
> mbr.  This is in the kernel.  I'm not sure exactly what libdisk does, but
> it is constrained by what the kernel will accept.
> 
> Bruce

Ok, so we normally do clip slice information, except in the case of a
dangerously dedicated slice.  Which works fine so long as no one ever
creates a 5 block slice in the 4th entry, as we will expand that
slice to cover all of the disk.  It also means that kernel, like the loader,
has to special case when it sees a dangeriously dedicated slice, which is
rather evil, IMO.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: MS CHAP v2 in -current?

[Nathan Binkert]

The patch does work for client side.  I have verified that I can connect
to a windows server using chap v2, but I forgot to do something for
server.  Shouldn't take me long.  If you need the server part before
Brian gets back, let me know.

  Nathan

> Oops, it doesn't work yet, and I'm off on holidays tomorrow, so it's 
> not a good idea for me to commit I'm afraid.
> 
> I've put the patch at http://www.Awfulhak.org/mschap2.patch for those 
> interested



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Mark Murray]

> On Sat, 22 Jul 2000, Mark Murray wrote:
> 
> > Because of Yarrow's cryptographic protection of its internal state, its
> > frequent reseeds and its clever geneation mechanism, this paradigm is
> > less important - the output is 256-bit safe (Blowfish safe) for any size
> > of output[*]. When you read 1000 bits, I am not selling you 1000 bits
> > each guaranteed random, I am selling you 1000 bits that are predictable
> > within the constraints of needing to crack 256-bit Blowfish.
> 
> So what it if I want/need 257 bits? :-)

Read them. You'll get them. If you want higher quality randomness than
Yarrow gives, read more than once. Do other stuff; play. Don't get stuck
in the "I have exhausted the randomness pool" loop; Yarrow does not play
that game.

>From the Yarrow paper:
``Yarrow's outputs are cryptographically derived. Systems that use Yarrow's
outputs are no more secure than the generation mechanism used.''

We currently have Yarrow-256(Blowfish); wanna make it Yarrow-1024? I could
make it so.

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 message

Re: MS CHAP v2 in -current?

[Brian Somers]

> > Ping...
> > 
> > Does anyone know if ms chap v2 will be integrated into -current any
> > time soon?  I need it for pptpclient.
> > 
> > If anyone has any patches they'd like public testing on, I'll volunteer.  :)
> 
> I have some code submitted by Nathan Blinkert - I'll apply them later 
> today.

Oops, it doesn't work yet, and I'm off on holidays tomorrow, so it's 
not a good idea for me to commit I'm afraid.

I've put the patch at http://www.Awfulhak.org/mschap2.patch for those 
interested

> > ==ml

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[Bruce Evans]

On Fri, 21 Jul 2000, John Baldwin wrote:

> Bruce Evans wrote:
> > On Thu, 20 Jul 2000, John Baldwin wrote:
> > > ...
> > > unused even though it is, in fact, used.  The fact that it works at all is
> > > due to brokenness on our part (we don't check that partitions in a disklabel
> > > fit in the parent slice) and also results in several hacks in various portions
> > > of the code where we have to check for such bogusness and work around it.
> > 
> > No, that's wrong too :-) .  We a lot of checking that partitions in a
> > disklabel fit in the parent slice.  We clip partitions that don't fit in
> > various ways for backwards compatibility.

> Erm, maybe we clip partitions which aren't dangerously dedicated, but
> I've created test dangerously dedicated disks, and we certainly do not
> bother to actually change any of the slice information when we do so.
> disklabel(8) does for truly dedicated, but libdisk doesn't for dangerously
> dedicated.

The dangerously dedicated case has one slice covering the whole disk.  We
unclip the slice info from the magic 5 sectors to the size of the whole
disk (as reported by the driver) to handle this.  Reading the slice info
using DIOCGSLICEINFO shows the full size, but no changes are made to the
mbr.  This is in the kernel.  I'm not sure exactly what libdisk does, but
it is constrained by what the kernel will accept.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: DHCP client problem?

[Tatsumi Hosokawa]

At Fri, 21 Jul 2000 17:22:15 -0700 (PDT),
Nick Sayer <[EMAIL PROTECTED]> wrote:
> 
> Something changed very recently in the dhcp client stuff that seems
> to have broke my -current machine's ability to be a dhcp client.
> 
> The symptom is that I see
> 
> ifconfig: netmask 255.255.255.224: bad value
> 
> come out of the script invocation, and the ip address does not get
> set.

My -current machine (cvsupped only a few hours ago) has the same
problem.

> If I echo out the parameters and type in THE EXACT SAME command line
> myself, it works just fine. I suspect some sort of bizarre
> quoting conspiracy. :-)

Maybe here?
(in
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/isc-dhcp/client/scripts/freebsd.diff?r1=1.11&r2=1.12)

-  if [ x$old_ip_address = x ] || [ x$old_ip_address != x$new_ip_address ] || \
- [ x$reason = xBOUND ] || [ x$reason = xREBOOT ]; then
-ifconfig $interface inet $new_ip_address $new_netmask_arg \
-   $new_broadcast_arg $medium
+  if [ "x$old_ip_address" = "x" ] || [ "x$old_ip_address" != "x$new_ip_address" ] || \
+ [ "x$reason" = "xBOUND" ] || [ "x$reason" = "xREBOOT" ]; then
+ifconfig "$interface" inet "$new_ip_address" "$new_netmask_arg" \
+   "$new_broadcast_arg" "$medium"

---
Tatsumi Hosokawa
[EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: MS CHAP v2 in -current?

[Brian Somers]

> Ping...
> 
> Does anyone know if ms chap v2 will be integrated into -current any
> time soon?  I need it for pptpclient.
> 
> If anyone has any patches they'd like public testing on, I'll volunteer.  :)

I have some code submitted by Nathan Blinkert - I'll apply them later 
today.

> ==ml

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Kris Kennaway]

On Sat, 22 Jul 2000, Mark Murray wrote:

> Because of Yarrow's cryptographic protection of its internal state, its
> frequent reseeds and its clever geneation mechanism, this paradigm is
> less important - the output is 256-bit safe (Blowfish safe) for any size
> of output[*]. When you read 1000 bits, I am not selling you 1000 bits
> each guaranteed random, I am selling you 1000 bits that are predictable
> within the constraints of needing to crack 256-bit Blowfish.

So what it if I want/need 257 bits? :-)

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Mark Murray]

> > The differnce with the old system and Yarrow is yarrow's self-recovery
> > property; Yarrow screens its internal state from the ouside world
> > very heavily, and provides enough perturbation of it from its
> > copious :-) entropy harvesting to keep the state safe from compromise.
> 
> Yeah, I know all this and agree that Yarrow makes a better /dev/urandom,
> but it doesn't change the fact that Yarrow-256 is only good for 256 bits
> of entropy between reseeding operations. You can pull all you want out of
> it but will never get more than 256 bits until it reseeds.

Aaah! I understand your question better; this is the "conservation of
entropy" argument which Yarrow "breaks".

Because of Yarrow's cryptographic protection of its internal state, its
frequent reseeds and its clever geneation mechanism, this paradigm is
less important - the output is 256-bit safe (Blowfish safe) for any size
of output[*]. When you read 1000 bits, I am not selling you 1000 bits
each guaranteed random, I am selling you 1000 bits that are predictable
within the constraints of needing to crack 256-bit Blowfish.

[*] Assuming no errors on the part of the implementor (me). :-)

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 message

buildworld error

[Tony Johnson]

When I was doing a make world on my system for 
5.0-current, I was getting this error:
 
===> sys/boot/i386/boot2as  --defsym 
FLAGS=0x80 /usr/src/sys/boot/i386/boot2/boot1.s -o boot1.old -nostdlib 
-static -N -e start -Ttext 0x7c00 -o boot1.out boot1.oobjcopy -S -O binary 
boot1.out boot1dd if=/dev/zero of=boot2.ldr bs=512 count=1 
2>/dev/null*** Error code 1 Stop in 
/usr/src/sys/boot/i386/boot2.*** Error code 1 Stop in 
/usr/src/sys/boot/i386.*** Error code 1 Stop in 
/usr/src/sys/boot.*** Error code 1 Stop in /usr/src/sys.*** 
Error code 1 Stop in /usr/src.*** Error code 
1 Stop in /usr/src.*** Error code 1 Stop in 
/usr/src.su-2.04# 

Re: randomdev entropy gathering is really weak

[Kris Kennaway]

On Sat, 22 Jul 2000, Mark Murray wrote:

> Lots of references: Schneier's "Applied Cryptography" talks about
> using Good Hashes for crypto and Good Crypto for hashes. Schneier's
> site at www.counterpane.com will give you plenty.

I havent been able to get my hands on Applied Cryptography, but I don't
recall seeing anything like this on the website. I'll check again.

> The differnce with the old system and Yarrow is yarrow's self-recovery
> property; Yarrow screens its internal state from the ouside world
> very heavily, and provides enough perturbation of it from its
> copious :-) entropy harvesting to keep the state safe from compromise.

Yeah, I know all this and agree that Yarrow makes a better /dev/urandom,
but it doesn't change the fact that Yarrow-256 is only good for 256 bits
of entropy between reseeding operations. You can pull all you want out of
it but will never get more than 256 bits until it reseeds.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: randomdev entropy gathering is really weak

[Mark Murray]

> After rereading the paper in more detail, Step 7 of the reseed algorithm
> seems not entirely consistent with this: they explicitly refer to writing
> out "the next 2k bits of output from the generator to the seed file"
> (slightly different terminology, but I couldn't find any other references
> to the "seed file")

He doesn't talk about it too much :-(.

> Another important point is that Yarrow-160 is not useful for generating
> keys >160 bits, because of Shannon's theorem and the fact that it uses
> SHA-1. You seem to be using a blowfish-based hash function with 256-bit
> keysize (do you have a reference for using blowfish in that fashion?), but
> the point stands. It seems we would need to use an alternative interface
> which either synchronously reseeds with every output to generate stronger
> random data, or just taps into the (hashed) entropy pools directly.

Lots of references: Schneier's "Applied Cryptography" talks about
using Good Hashes for crypto and Good Crypto for hashes. Schneier's
site at www.counterpane.com will give you plenty.

It is also an extension and improvement on the way OpenBSD do their
bcrypt (passwd) hash.

> This was also a problem with our /dev/urandom (by design), but not with
> /dev/random since that tapped the entropy pool directly. Incidentally, it
> also looks like a problem with OpenBSD's /dev/arandom which is a stream
> cipher (arc4 with 256-bit key) periodically reseeded.

The differnce with the old system and Yarrow is yarrow's self-recovery
property; Yarrow screens its internal state from the ouside world
very heavily, and provides enough perturbation of it from its
copious :-) entropy harvesting to keep the state safe from compromise.

Yarrow also keeps multiple (fast/slow pools + key) states, and the
long, slow interactions between those give much better protection
that the old system which was pretty much a simple PRNG+simple
random perturbations.  (I know MD5 is not "simple", but it is
deterministic, and was only used once).

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 message

Re: randomdev entropy gathering is really weak

[Mark Murray]

> I'm all for storing a sample at shutdown and using it to help seed the
> PRNG at startup, but it shouldn't be the only seed used (for example, the
> case where the system has never been shut down (cleanly) before and so has
> no pre-existing seed file is a BIG corner case to consider since thats how
> the system is at the time it first generates SSH keys after a fresh
> install).

Agreed; we need more entropy sources that are available early enough to
be useful.

> It might be only an academic vulnerability, but if someone can read your
> HD during the time the system is shut down then I'd prefer them not to
> know the precise state when the system next starts up again. Yes, if they
> can read they can probably also write, but it seems like a mistake when
> there's nothing really gained by saving the complete state, as opposed to
> an extract.

Academic argument noted; with more entropy sources, this situation will
improve.

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 message

Re: Locale issues on -current

[Doug Barton]

"Viren R.Shah" wrote:
> 
> I installed a recent snapshot of -current (a week ago) and I keep
> getting the following warnings:
> 
> [vshah@vorpal] /etc> perl
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LC_ALL = (unset),
> LC_CTYPE = "en_US",
> LANG = (unset)
> are supported and installed on your system.

I get the same thing. It's LC_CTYPE that's causing the problem. I was half
thinking that it was something related to gnome, but I haven't worked very
hard to fix it. Unsetting that variable makes the warning go away, whether
that fixes the problem or not.

Doug


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message