Re: randomdev entropy gathering is really weak
The situation is _worse_; the entropy is minimal, and is _very_ attackable. What's wrong about timers for enthropy (I mean high resolution ones)? Really we need only few bytes of enthropy and can use them to seed RNG for the first time if no true randomness available. To be joking: MD5 of kernel module can help too :-) getnanotime() is already extensively used; we just need to force the RNG to reseed once at the beginning. As soon as I'm happy that the code is panic-free, I'll commit it. 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
The problem is that the randomdev stuff should be a delete option, ie. it should be built as part of the kernel unless EXPLICITLY excluded, not the wrong way around as it is at the moment. I agree. Any objections? 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
ssh-keygen should just block until it gets enough - this is not acceptable behaviour if /dev/urandom is returning unseeded data. OpenSSL uses /dev/urandom at the moment - I just read a comment in md_rand.c that using /dev/random may block, which I didn't think was true. On the other hand, doing a dd if=/dev/random of=/dev/null gives me infinite "randomness" at 10MB/sec - have the semantics of /dev/random changed? Yes; remember that what we have here is Yarrow algorithm; which is an algorithm for cryptographically secure PRNG - one whose internal state is unguessable, or if compromised folr some reason is self-recovering. "Infinite" randomness is possible with this algorithm. 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
On Mon, 17 Jul 2000, Mark Murray wrote: On the other hand, doing a dd if=/dev/random of=/dev/null gives me infinite "randomness" at 10MB/sec - have the semantics of /dev/random changed? Yes; remember that what we have here is Yarrow algorithm; which is an algorithm for cryptographically secure PRNG - one whose internal state is unguessable, or if compromised folr some reason is self-recovering. "Infinite" randomness is possible with this algorithm. On the other hand, didn't you say that at system boot the RNG is essentially unseeded, so this is actually a liability because processes cannot be sure they're getting real randomness. 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
On Mon, 17 Jul 2000, Mark Murray wrote: On the other hand, doing a dd if=/dev/random of=/dev/null gives me infinite "randomness" at 10MB/sec - have the semantics of /dev/random changed? Yes; remember that what we have here is Yarrow algorithm; which is an algorithm for cryptographically secure PRNG - one whose internal state is unguessable, or if compromised folr some reason is self-recovering. "Infinite" randomness is possible with this algorithm. On the other hand, didn't you say that at system boot the RNG is essentially unseeded, so this is actually a liability because processes cannot be sure they're getting real randomness. Until you type or move the mouse. I'm putting the rest of the harvesting calls in today. 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
In message [EMAIL PROTECTED], Mark Murray writes: getnanotime() is already extensively used; I looked at that use, but as far as I can tell, it is only used as a flag at this time, the bits returned by getnanotime() does not end up in the entropy pool ? Not true; struct entropy contains nanotime and the harvested entropy; _both_ are hashed in the reseed operation. I'm not dissatisfied about that btw, the output from getnanotime() is not very random at all, unless you dive into the timecounter code to find out what the parameters are. I agree that it is not (very) random; however cclock jitter and keystroke timing can help thwart the bad guys... 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
In message [EMAIL PROTECTED], Mark Murray writes: getnanotime() is already extensively used; I looked at that use, but as far as I can tell, it is only used as a flag at this time, the bits returned by getnanotime() does not end up in the entropy pool ? I'm not dissatisfied about that btw, the output from getnanotime() is not very random at all, unless you dive into the timecounter code to find out what the parameters are. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
In message [EMAIL PROTECTED], Mark Murray writes: getnanotime() is already extensively used; I looked at that use, but as far as I can tell, it is only used as a flag at this time, the bits returned by getnanotime() does not end up in the entropy pool ? Not true; struct entropy contains nanotime and the harvested entropy; _both_ are hashed in the reseed operation. I'm not dissatisfied about that btw, the output from getnanotime() is not very random at all, unless you dive into the timecounter code to find out what the parameters are. I agree that it is not (very) random; however cclock jitter and keystroke timing can help thwart the bad guys... But do please keep in mind that many of my FreeBSD platforms have neither keyboard or mouse. And for the ones that do, they tend not to get used until long after the system boots. It's essential that the randomness harvesting also be driven off of other events, such as network interface or storage system interrupts for these environments. In fact, it would be rather interesting to have a configuration flag which always forces something like an fsck on a file system in order to provide some entropy to the random device. Or some other user-exposed way of providing entropy. I might have some data on disk, or some network operations which can be performed to help seed the entropy pool. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
In message [EMAIL PROTECTED], "Louis A. Mamakos" writ es: In fact, it would be rather interesting to have a configuration flag which always forces something like an fsck on a file system in order to provide some entropy to the random device. Or some other user-exposed way of providing entropy. I might have some data on disk, or some network operations which can be performed to help seed the entropy pool. What we really need is this: fetch -o http://entropy.freebsd.org/ /dev/random with a bunch of volounteers providing random bits to people in need. I have thought about adding a entropy server to my array of weird servers in my lab. Something like a Geiger counter and a smokedetector could do wonders. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]): I have thought about adding a entropy server to my array of weird servers in my lab. Something like a Geiger counter and a smokedetector could do wonders. HA! Cool! Do that please! I mean, seriously. And an option to sysinstall, where you can enable this as you can with ntpdate :) Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
In message [EMAIL PROTECTED], Alexander Langer writ es: Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]): I have thought about adding a entropy server to my array of weird servers in my lab. Something like a Geiger counter and a smokedetector could do wonders. HA! Cool! Do that please! I mean, seriously. And an option to sysinstall, where you can enable this as you can with ntpdate :) DuH! NTP is the perfect way to gather entropy at bootup! Predicting the clock's offset from reality and the two way path to the server of choice is impossible, plus if people enable authentication later on the packets will be choke full of high-quality entropy. We need an enterprising soul to add an option (default on) to ntpdate to write the received packets in toto to /dev/random if it exists. If somebody does this, I will spear-head the effort of getting it into the ntpv4 sources (Hmm, don't I have a commit bit there already ? Can't remember...) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]): We need an enterprising soul to add an option (default on) to ntpdate to write the received packets in toto to /dev/random if it exists. If noone else wants to do it, I could take a look at it. Little time, though. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
On 17-Jul-00 Poul-Henning Kamp wrote: NTP is the perfect way to gather entropy at bootup! Only if in reach of an NTP server ? -- Steve O'Hara-Smith [EMAIL PROTECTED] http://sohara.webhop.net/ A Better Way To Focus The Sun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
In message [EMAIL PROTECTED], "Steve O'Hara-Smith" writes : On 17-Jul-00 Poul-Henning Kamp wrote: NTP is the perfect way to gather entropy at bootup! Only if in reach of an NTP server ? Obviously :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MFS complains that no vop_getwritemount operation(?)
On Sun, 16 Jul 2000 01:11:16 +0900, Makoto MATSUSHITA wrote: Jul 16 00:48:32 martini /kernel: mfs_badop[vop_getwritemount] Jul 16 00:48:32 martini /kernel: mfs_badop[vop_getwritemount] = 45 I'm using MFS as /tmp filesystem, and this message shows up if I access to /tmp directory such as create a file/directory. Following patch seems to shut up my kernel, but I dunno it is the right fix for this problem (I've got a hint from ../ufs/ufs_vnops.c). Have you sent your patch to Kirk McKusick [EMAIL PROTECTED]? Does anyone can reproduce mfs_badop[vop_getwritemount] warnings ? Yes, I got them until I switched to a malloc(9)-backed md(4) device. They seemed harmless. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mfs_badop...
On Sun, 16 Jul 2000 18:41:08 MST, Matthew Jacob wrote: any reason that we should be seeing these now: mfs_badop[vop_getwritemount] mfs_badop[vop_getwritemount] = 45 I suspect that these relate to the import of ffs snapshots. I've mailed Kirk, and someone else has posted a tentative patch to this list. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MFS complains that no vop_getwritemount operation(?)
sheldonh Have you sent your patch to Kirk McKusick [EMAIL PROTECTED]? No, not yet. It seems that this change is incoroprated with FFS snapshots feature, but I cannot decide it's true or not; other filesystem are modified also (see commitlogs), but mfs is not changed... Anyway, I'll try to email later. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
I agree that it is not (very) random; however cclock jitter and keystroke timing can help thwart the bad guys... But do please keep in mind that many of my FreeBSD platforms have neither keyboard or mouse. And for the ones that do, they tend not to get used until long after the system boots. It's essential that the randomness harvesting also be driven off of other events, such as network interface or storage system interrupts for these environments. Agreed. I have already committed a "persistent" entropy cache that reseeds the random device on reboot. In fact, it would be rather interesting to have a configuration flag which always forces something like an fsck on a file system in order to provide some entropy to the random device. Or some other user-exposed way of providing entropy. I might have some data on disk, or some network operations which can be performed to help seed the entropy pool. I'm (er, phk is) looking at hooking namei() in some way. I'm also going to hook the networking stack. 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
What we really need is this: fetch -o http://entropy.freebsd.org/ /dev/random For this to work, you'll need to encrypt the traffic. fetch -o https://entropy.freebsd.org/ /dev/random ^ If the world knows what they are, your bits aren't random enough. 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 wrote: I agree that it is not (very) random; however cclock jitter and keystroke timing can help thwart the bad guys... But do please keep in mind that many of my FreeBSD platforms have neither keyboard or mouse. And for the ones that do, they tend not to get used until long after the system boots. It's essential that the randomness harvesting also be driven off of other events, such as network interface or storage system interrupts for these environments. Agreed. I have already committed a "persistent" entropy cache that reseeds the random device on reboot. You may also want to extend /etc/crontab to periodically save entropy. This would help if something unexpected like halt(8) or panic(9) happened. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
On Mon, 17 Jul 2000, Steve O'Hara-Smith wrote: On 17-Jul-00 Poul-Henning Kamp wrote: NTP is the perfect way to gather entropy at bootup! Only if in reach of an NTP server ? If you can't reach a NTP server, you are not connected to the internet. In that case you don't need to worry so much about security... Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
On 17-Jul-00 Leif Neland wrote: If you can't reach a NTP server, you are not connected to the internet. In that case you don't need to worry so much about security... Not clear. I might not be connected at boot time but could well become connected later. -- Steve O'Hara-Smith [EMAIL PROTECTED] http://sohara.webhop.net/ A Better Way To Focus The Sun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
world breakage in -current (also breaks release)
cd /usr/src; make -f Makefile.inc1 hierarchy cd /usr/src/etc;make distrib-dirs mtree -deLU -f /usr/src/etc/mtree/BSD.root.dist -p / mtree: illegal option -- L usage: mtree [-cdeinrUux] [-f spec] [-K key] [-k key] [-p path] [-s seed] [-X excludes] *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New mtree needed for installation
I did a "make buildworld" then "make installworld", and: -- Making hierarchy -- cd /usr/src; make -f Makefile.inc1 hierarchy cd /usr/src/etc;make distrib-dirs mtree -deLU -f /usr/src/etc/mtree/BSD.root.dist -p / mtree: illegal option -- L usage: mtree [-cdeinrUux] [-f spec] [-K key] [-k key] [-p path] [-s seed] [-X excludes] *** Error code 1 Of course, installing the new mtree first solves this, but it may be worth a note in UPDATING (or better, use the newly built mtree or do not require the use of the new -L option). Sam -- Samuel Tardieu -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ftpd 550 reply
Does anyone else than me have trouble with ftpd reporting "550 not a plain file" instead of "550 no such file or directory" when the requested file does not exist? DES -- Dag-Erling Smorgrav - [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
Maxim Sobolev wrote: [Charset koi8-r unsupported, filtering to ASCII...] Mark Murray wrote: Agreed. I have already committed a "persistent" entropy cache that reseeds the random device on reboot. You may also want to extend /etc/crontab to periodically save entropy. This would help if something unexpected like halt(8) or panic(9) happened. I thought about a reseed daemon periodically saving entropy to, say, /var/log/entropy. But, a crontab entry would work just as well. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
On Mon, 17 Jul 2000, Steve O'Hara-Smith wrote: On 17-Jul-00 Leif Neland wrote: If you can't reach a NTP server, you are not connected to the internet. In that case you don't need to worry so much about security... Not clear. I might not be connected at boot time but could well become connected later. [Why do so few people manage the RFC compliant space in their .sig? i.e. "-- "] But by then you've already booted and other events have generated some entropy for the random device. You no longer need seeding. Brandon D. Valentine -- bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world breakage in -current (also breaks release)
"Jordan" == Jordan K Hubbard [EMAIL PROTECTED] writes: Jordan cd /usr/src; make -f Makefile.inc1 hierarchy Jordan cd /usr/src/etc;make distrib-dirs Jordan mtree -deLU -f /usr/src/etc/mtree/BSD.root.dist -p / Jordan mtree: illegal option -- L Yep, same for me... I succeed in installing mtree _before_ making installworld. -- - É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
Thus spake Leif Neland ([EMAIL PROTECTED]): If you can't reach a NTP server, you are not connected to the internet. In that case you don't need to worry so much about security... That is wrong :) Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New mtree needed for installation
On Mon, Jul 17, 2000 at 05:39:12PM +0200, Samuel Tardieu wrote: I did a "make buildworld" then "make installworld", and: -- Making hierarchy -- cd /usr/src; make -f Makefile.inc1 hierarchy cd /usr/src/etc;make distrib-dirs mtree -deLU -f /usr/src/etc/mtree/BSD.root.dist -p / mtree: illegal option -- L usage: mtree [-cdeinrUux] [-f spec] [-K key] [-k key] [-p path] [-s seed] [-X excludes] *** Error code 1 Of course, installing the new mtree first solves this, but it may be worth a note in UPDATING (or better, use the newly built mtree or do not require the use of the new -L option). It is a known problem, and Marcel Moolenaar [EMAIL PROTECTED] has posted a patch to -committers for a review. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftpd 550 reply
On Mon, Jul 17, 2000 at 06:18:39PM +0200, Dag-Erling Smorgrav wrote: Does anyone else than me have trouble with ftpd reporting "550 not a plain file" instead of "550 no such file or directory" when the requested file does not exist? This is on 4.1-RC (built from today's sources which equivalent to -CURRENT): Script started on Mon Jul 17 20:01:30 2000 Connected to localhost. 220 perl.sunbay.crimea.ua FTP server (Version 6.00LS) ready. Name (localhost:ru): 331 Password required for ru. Password: 230 User ru logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp get foo local: foo remote: foo 550 foo: No such file or directory. ftp by 221 Goodbye. Script done on Mon Jul 17 20:01:38 2000 -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fetch(1) bug?
Hi, I found a weird problem with your new fetch(1). Please try fetching the following file with both fetch and wget for comparison: http://www.hiei.kit.ac.jp/~hitomi/mutt/mutt/manual_ja-1.2i-0.tar.gz 1) Fetching the file with wget knu@archon[2]% uname -a ~ FreeBSD archon.local.idaemons.org 5.0-CURRENT FreeBSD 5.0-CURRENT #36: Sun Jul 16 21:17:50 JST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ARCHON i386 knu@archon[2]% wget http://www.hiei.kit.ac.jp/~hitomi/mutt/manual_ja-1.2i-0.tar.gz --02:01:36-- http://www.hiei.kit.ac.jp:80/%7Ehitomi/mutt/manual_ja-1.2i-0.tar.gz = `manual_ja-1.2i-0.tar.gz.1' Connecting to www.hiei.kit.ac.jp:80... connected! HTTP request sent, awaiting response... 200 OK Length: 262,692 [application/x-gzip] 0K - .. .. .. .. .. [ 19%] 50K - .. .. .. .. .. [ 38%] 100K - .. .. .. .. .. [ 58%] 150K - .. .. .. .. .. [ 77%] 200K - .. .. .. .. .. [ 97%] 250K - .. [100%] 02:01:44 (33.20 KB/s) - `manual_ja-1.2i-0.tar.gz.1' saved [262692/262692] knu@archon[2]% ls -l manual_ja-1.2i-0.tar.gz ~ -rw-r--r-- 1 knu knu - 262692 Jul 6 09:06 manual_ja-1.2i-0.tar.gz knu@archon[2]% md5 manual_ja-1.2i-0.tar.gz~ MD5 (manual_ja-1.2i-0.tar.gz) = 809121b8baa58906fba7422de9c2b236 knu@archon[2]% tar ztf manual_ja-1.2i-0.tar.gz~ manual_ja.sgml manual_ja.tex manual_ja.txt manual_ja.html Seems fine. 2) Fetching the file with fetch knu@archon[2]% fetch -vv http://www.hiei.kit.ac.jp/~hitomi/mutt/manual_ja-1.2i-0.tar.gz looking up www.hiei.kit.ac.jp connecting to www.hiei.kit.ac.jp:80 requesting http://www.hiei.kit.ac.jp:80/~hitomi/mutt/manual_ja-1.2i-0.tar.gz looking up www.hiei.kit.ac.jp connecting to www.hiei.kit.ac.jp:80 requesting http://www.hiei.kit.ac.jp:80/~hitomi/mutt/manual_ja-1.2i-0.tar.gz Receiving manual_ja-1.2i-0.tar.gz: 262697 bytes 262697 bytes transferred in 7.7 seconds (33.16 kBps) knu@archon[2]% md5 manual_ja-1.2i-0.tar.gz~ MD5 (manual_ja-1.2i-0.tar.gz) = 3b078418a5fdcc765d8bea0fed3ee6dd knu@archon[2]% ls -l manual_ja-1.2i-0.tar.gz ~ -rw-r--r-- 1 knu knu - 262697 Jul 6 09:06 manual_ja-1.2i-0.tar.gz knu@archon[2]% tar ztf manual_ja-1.2i-0.tar.gz~ manual_ja.sgml manual_ja.tex manual_ja.txt manual_ja.html gzip: stdin: decompression OK, trailing garbage ignored tar: child returned status 2 Hmm, fetch(1) seems receiving extra 5 bytes of garbage. Have you got a clue? -- / /__ __ / ) ) ) ) / Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc driver and underruns (was: Strangeness with 4.0-S)
... As far as I can tell the fxp driver doesn't even use the tx_fifo in the 825xxx chips :-) The 82557-9 have a 2KB internal buffer for transmits. They don't start transmitting until a programmed threshold is reached - this is to insure that PCI bus latency doesn't result in the transmitter getting stalled. The fxp driver starts out with this threshold set at 512 bytes, but will increase it (512 bytes at a time) when a DMA underrun occurs. Of course once the threshold reached 1536, then an entire 1500 byte packet is DMA'd into the buffer before the transmit begins. Can you point me to the part of if_fxp.c that does this, as alls I can find about any form of fifo in the code are these references: Guardian# grep -i fifo *fxp* if_fxp.c: cbp-rx_fifo_limit =8; /* rx fifo threshold (32 bytes) */ if_fxp.c: cbp-tx_fifo_limit =0; /* tx fifo threshold (0 bytes) */ if_fxpreg.h:volatile u_int rx_fifo_limit:4, if_fxpreg.h:tx_fifo_limit:3, No place do I find anything that does any adjustments to these values :-(. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
nic cards
One thing that I just noticed on the python mailing list is a portable way of retrieving an ip addy. Why not start using eth0 (unfortunately as they do in Linuxland) eth1 ... For nic cards instead of fxp0 for an intel, etc... The fxp0 way is too hardware and implementation dependant. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nic cards
On Monday, July 17, 2000, Tony Johnson wrote: One thing that I just noticed on the python mailing list is a portable way of retrieving an ip addy. Why not start using eth0 (unfortunately as they do in Linuxland) eth1 ... For nic cards instead of fxp0 for an intel, etc... The fxp0 way is too hardware and implementation dependant. ``eth0'' is no more portable than ``fxp0''. Just because Linux does it doesn't mean it's standard or portable. -- |Chris Costello [EMAIL PROTECTED] |MIPS: Meaningless Indicator of Processor Speed. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rc.shutdown hook is not a solution (was Re: randomdev entropy gathering is really weak)
On Mon, Jul 17, 2000 at 07:02:50PM +0200, Alexander Langer wrote: Thus spake Leif Neland ([EMAIL PROTECTED]): If you can't reach a NTP server, you are not connected to the internet. In that case you don't need to worry so much about security... That is wrong :) The reason is not security only, the reason is buggy RNG. Imagine diskless keyboard-less and mouse-less slide-show machine with no rc.shutdown hooks since it comes with power up and goes down with power down. This machine will always start with same picture because RNG have not enough enthropy. In worst case we should relay only on processor registers always present, i.e. timers and so on. rc.shutdown hook not solve problem completely. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
You may also want to extend /etc/crontab to periodically save entropy. This would help if something unexpected like halt(8) or panic(9) happened. That is an idea I can use! :-) 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: nic cards
One thing that I just noticed on the python mailing list is a portable way of retrieving an ip addy. Why not start using eth0 (unfortunately as they do in Linuxland) eth1 ... For nic cards instead of fxp0 for an intel, etc... The fxp0 way is too hardware and implementation dependant. 'ethX' is also too 'specific'. Use 'ifconfig -l' to get a list of network interfaces, at which point you don't care what they're called... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fetch(1) bug?
Sorry, I seem to have supplied a wrong URL. Here's the correct one. http://www.hiei.kit.ac.jp/~hitomi/mutt/manual_ja-1.2i-0.tar.gz -- / /__ __ / ) ) ) ) / Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MS CHAP v2 in -current?
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. :) ==ml To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.shutdown hook is not a solution (was Re: randomdev entropy gathering is really weak)
The reason is not security only, the reason is buggy RNG. Imagine diskless keyboard-less and mouse-less slide-show machine with no rc.shutdown hooks since it comes with power up and goes down with power down. This machine will always start with same picture because RNG have not enough enthropy. In worst case we should relay only on processor registers always present, i.e. timers and so on. rc.shutdown hook not solve problem completely. Actually, it is only a faulty reseed mechanism. For the purposes of your argument above, the time-of-day would be an acceptable reseed to random(9). For cryptographic randomness, more noise is needed. 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
On Mon, 17 Jul 2000 19:33:40 +0200, Mark Murray wrote: That is an idea I can use! :-) See the recently fixed and documented crontab(5) @reboot, in fact. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
On Mon, Jul 17, 2000 at 05:08:35PM +0200, Leif Neland wrote: On Mon, 17 Jul 2000, Steve O'Hara-Smith wrote: On 17-Jul-00 Poul-Henning Kamp wrote: NTP is the perfect way to gather entropy at bootup! Only if in reach of an NTP server ? If you can't reach a NTP server, you are not connected to the internet. In that case you don't need to worry so much about security... Flawed logic. That's cryptography. It's about information protection. And you of course know that about 80% of computer crimes are commited by local cow orkers in a LAN environment behind a twenty five firewalls, proxies and the like. -- Alex Kapranoff, 2:50/383.20@fidonet, Voice: +7(0832)791845. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
On Mon, 17 Jul 2000, Mark Murray wrote: What we really need is this: fetch -o http://entropy.freebsd.org/ /dev/random For this to work, you'll need to encrypt the traffic. fetch -o https://entropy.freebsd.org/ /dev/random ^ If the world knows what they are, your bits aren't random enough. Plus you need to authenticate (and obviously trust) your entropy server and the data stream to make sure they're not actually someone else feeding you zeros. 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: ftpd 550 reply
Ruslan Ermilov [EMAIL PROTECTED] writes: On Mon, Jul 17, 2000 at 06:18:39PM +0200, Dag-Erling Smorgrav wrote: Does anyone else than me have trouble with ftpd reporting "550 not a plain file" instead of "550 no such file or directory" when the requested file does not exist? This is on 4.1-RC (built from today's sources which equivalent to -CURRENT): [doesn't have the bug] --- ftp.ofug.org:21 220 flood.ping.uio.no FTP server (Version 6.00) ready. USER ftp 331 Guest login ok, send your email address as password. PASS [EMAIL PROTECTED] 230- 230- * * 230- * Welcome to flood.ping.uio.no!* 230- * * 230- * All transfers are logged. If you are not comfortable * 230- * with that, please find another server. * 230- * * 230- * Please report any problems or irregularities to * 230- * [EMAIL PROTECTED] * 230- * * 230- 230 Guest login ok, access restrictions apply. TYPE I 200 Type set to I. CWD /pub/FreeBSD/ports/distfiles 250 CWD command successful. SIZE shorten.tar.gz 550 shorten.tar.gz: not a plain file. fetch: File unavailable (e.g., file not found, no access) --- ftp.freebsd.org:21 220 sourcerer.freesoftware.com FTP server (Version DG-3.1.42 Thu Jul 6 14:10:01 PDT 2000) ready. USER ftp 331 Guest login ok, send your email address as password. PASS [EMAIL PROTECTED] 230-Welcome to ftp.freesoftware.com - home FTP site for Walnut Creek CDROM. 230-There are currently 744 users out of 5000 possible. 230- 230-Most of the files in this area are also available on CDROM. You can send 230-email to [EMAIL PROTECTED] for more information or to order, or visit our Web 230-site at http://www.wccdrom.com. For tech support about our products, please 230-email [EMAIL PROTECTED] You may also call our toll-free number: 230-1-800-786-9907 or +1-925-674-0783. Please keep in mind that we only offer 230-technical support for our CDROM products and not for the files on our 230-FTP server. 230- 230-This server is a Xeon/550 with 4GB of memory 400GB of RAID 5 storage. 230-The operating system is FreeBSD. Should you wish to get your own copy of 230-FreeBSD, see the pub/FreeBSD directory or visit http://www.freebsd.org 230-for more information. FreeBSD on CDROM can be ordered using the WEB at 230-http://www.wccdrom.com/titles/freebsd/freebsd.phtml or by sending email 230-to [EMAIL PROTECTED] 230- 230-Gigabit colocation services provided by Lightning Internet. For more 230-information, please visit http://www.lightning.net. 230- 230-Please send mail to [EMAIL PROTECTED] if you experience any 230-problems. Please also let us know if there is something we don't have that 230-you think we should! 230- 230 Guest login ok, access restrictions apply. TYPE I 200 Type set to I. CWD /pub/FreeBSD/ports/distfiles 250 CWD command successful. SIZE shorten.tar.gz 550 shorten.tar.gz: not a plain file. fetch: File unavailable (e.g., file not found, no access) --- ftp.kiarchive.ru:21 220 kiarchive.relcom.ru FTP server (Version 6.00) ready. USER ftp 331 Guest login ok, send your email address as password. PASS [EMAIL PROTECTED] 230 Guest login ok, access restrictions apply. TYPE I 200 Type set to I. CWD /pub/misc/hardware/soundcard/gus 250 CWD command successful. SIZE timidity-0.2i.tar.gz 550 timidity-0.2i.tar.gz: not a plain file. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No /boot/loader
No response to this on -stable. The actual error message is: Disk error 0x1 (lba=0x7004c) No /boot/loader Also, on a whim I decided to try running /boot/loader. I got a message saying that there was a syntax error on line 4, that it was missing either a close paren or a close curly brace. It went by fast, and I couldn't reproduce it. A quick examination of the sources by my boot code inexpert eyes didn't reveal anything that looked relevant on any line 4's. Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? -- Forwarded message -- Date: Fri, 14 Jul 2000 20:30:48 -0700 (PDT) From: Doug Barton [EMAIL PROTECTED] Subject: Re: CFT: boot patch for 4.x I'm having a problem that isn't related to your patch, but that I'm hoping you or someone can shed some light on. I installed 4-Stable from the 7/6 snapshot onto some shiny new machines, and when I reboot them I get an error: See above. then the boot: prompt comes up a couple of times, it finds the kerrnel and boots anyway. I found this odd because there clearly IS a /boot/loader, and I haven't changed anything in /boot at all. I did a make world today and installed a custom kernel, no joy. I'm also getting the dreaded top: nlist failed error. I have the following for adapters: ahc0: Adaptec aic7896/97 Ultra2 SCSI adapter port 0x2000-0x20ff mem 0xf410-0xf4100fff irq 19 at d evice 12.0 on pci0 ahc0: aic7896/97 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: Adaptec aic7896/97 Ultra2 SCSI adapter port 0x2400-0x24ff mem 0xf4101000-0xf4101fff irq 19 at d evice 12.1 on pci0 ahc1: aic7896/97 Wide Channel B, SCSI Id=7, 16/255 SCBs and this for disks: da0 at ahc0 bus 0 target 0 lun 0 da0: QUANTUM ATLAS_V__9_SCA 0200 Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 8755MB (17930694 512 byte sectors: 255H 63S/T 1116C) da1 at ahc0 bus 0 target 1 lun 0 da1: QUANTUM ATLAS_V__9_SCA 0200 Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 8755MB (17930694 512 byte sectors: 255H 63S/T 1116C) I did the install with dangerously dedicated disks, which I know John is not a big fan of, but on the IBM SCSI drives I have in the other machines I have no problems of this sort whatsoever. I suppose I could try the install again with a real partition table, I just hate to waste all that config time. :-/ Any help appreciated. Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
Note that there should be no need to cron the job. You only need to save one set of bits to be used as a seed for the next startup. And one set of bits SHOULD be as good as any other. I suggest you (at boot time): 1: open seed file for read unlink seed file use seed file + available entropy to seed algorithm close the seed file 2: open for seed file for write write X bytes for next time close file Note that even if you do cron step 2, I recommend highly you mix in whatever entropy you can gather at boot time into the initial seeding. This will ensure any reuse of the seed file (such as if you crash between steps 1 and 2) will result in different bit sequences. Regards, Kurt At 10:14 PM 7/17/00 +0200, Sheldon Hearn wrote: On Mon, 17 Jul 2000 19:33:40 +0200, Mark Murray wrote: That is an idea I can use! :-) See the recently fixed and documented crontab(5) @reboot, in fact. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
However much I love the idea of people coding in more randomness, I'd get a better fuzzy feeling if somebody with some cred in the crypto world was sitting in on this discussion and commenting on the ideas. Things like 'going out on the network and fetching some random bits via http' are so utterly bogus (open to attack, presume networks are there) that they kinda suggest this hasn't been well thought out. Likewise embedding a dependency on keyboard/mouse movements. IIRC There have been articles making it plain that week initial random settings propagate out like topsy: you can't add trustable randomness by taking skewed input sources. People like Bruce Schneier, Steve Bellovin, they are not unapproachable. Could somebody mail them for comments on whats considered acceptable sources of random bits? Please? -George -- George Michaelson | DSTC Pty Ltd Email: [EMAIL PROTECTED]| University of Qld 4072 Phone: +61 7 3365 4310| Australia Fax: +61 7 3365 4311| http://www.dstc.edu.au To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cer/b7b/pfc - pem
Apropos pseudorandom, ssh etc; I hope this is not too off-topic, or can somebody point in the right direction: I have a Verisign personal certificate (Look me up at Verisign, as Leif Neland) This works nicely in Windows (Outlook Express), but I'd like to try using the same key with openssl to generate crypted (to myself) or signed messages. I can export the key as a .cer, .p7b or .pfx, but openssl seems to want it in .pem format. Am I totally confused, or is it possible to convert one of the above to .pem? Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cer/b7b/pfc - pem
"Leif Neland" [EMAIL PROTECTED] writes: Apropos pseudorandom, ssh etc; I hope this is not too off-topic, or can somebody point in the right direction: I have a Verisign personal certificate (Look me up at Verisign, as Leif Neland) This works nicely in Windows (Outlook Express), but I'd like to try using the same key with openssl to generate crypted (to myself) or signed messages. I can export the key as a .cer, .p7b or .pfx, but openssl seems to want it in .pem format. What does the p7b file look like? And the .cer file, and the .pfx file? Are any of them ascii, with a "BEGIN PKCS7" or "BEGIN CERTIFICATE" line? Am I totally confused, or is it possible to convert one of the above to .pem? from crl2pkcs7's man page, in the notes section: The output file is a PKCS#7 signed data structure containing no signers and just certificates and an optional CRL. This utility can be used to send certificates and CAs to Netscape as part of the certificate enrollment process. This involves sending the DER encoded output as MIME type application/x-x509-user-cert. The PEM encoded form with the header and footer lines removed can be used to install user certificates and CAs in MSIE using the Xenroll control. Leif 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 wrote: On Mon, 17 Jul 2000, Mark Murray wrote: On the other hand, doing a dd if=/dev/random of=/dev/null gives me infinite "randomness" at 10MB/sec - have the semantics of /dev/random changed? Yes; remember that what we have here is Yarrow algorithm; which is an algorithm for cryptographically secure PRNG - one whose internal state is unguessable, or if compromised folr some reason is self-recovering. "Infinite" randomness is possible with this algorithm. On the other hand, didn't you say that at system boot the RNG is essentially unseeded, so this is actually a liability because processes cannot be sure they're getting real randomness. /dev/random should block until it has seeded. If it does not it's a bug. /dev/random should *never* spit out non-random bytes. 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
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], "Louis A. Mamakos" writ es: In fact, it would be rather interesting to have a configuration flag which always forces something like an fsck on a file system in order to provide some entropy to the random device. Or some other user-exposed way of providing entropy. I might have some data on disk, or some network operations which can be performed to help seed the entropy pool. What we really need is this: fetch -o http://entropy.freebsd.org/ /dev/random with a bunch of volounteers providing random bits to people in need. I have thought about adding a entropy server to my array of weird servers in my lab. Something like a Geiger counter and a smokedetector could do wonders. Right, and an attacker laughingly sniffing those bits. I think you forgot a ';-p' 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
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Alexander Langer writ es: Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]): I have thought about adding a entropy server to my array of weird servers in my lab. Something like a Geiger counter and a smokedetector could do wonders. HA! Cool! Do that please! I mean, seriously. And an option to sysinstall, where you can enable this as you can with ntpdate :) DuH! NTP is the perfect way to gather entropy at bootup! Predicting the clock's offset from reality and the two way path to the server of choice is impossible, plus if people enable authentication later on the packets will be choke full of high-quality entropy. Please quantify 'impossible'. We need an enterprising soul to add an option (default on) to ntpdate to write the received packets in toto to /dev/random if it exists. I think we first need to figure out the security implications. 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
In message [EMAIL PROTECTED], Alexander Langer writ es: Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]): I have thought about adding a entropy server to my array of weird servers in my lab. Something like a Geiger counter and a smokedetector could do wonders. HA! Cool! Do that please! I mean, seriously. And an option to sysinstall, where you can enable this as you can with ntpdate :) DuH! NTP is the perfect way to gather entropy at bootup! Predicting the clock's offset from reality and the two way path to the server of choice is impossible, plus if people enable authentication later on the packets will be choke full of high-quality entropy. We need an enterprising soul to add an option (default on) to ntpdate to write the received packets in toto to /dev/random if it exists. If somebody does this, I will spear-head the effort of getting it into the ntpv4 sources (Hmm, don't I have a commit bit there already ? Can't remember...) Actually, you could really use this in ntpd(8), rather than just ntpdate. You could crank in the offset and delay samples for each packet received from an NTP peer; this will have the effect of adding into the entropy pool the "noise" in the latency of the path between you and each of your NTP peers. This varies over time with each sample, and in fact, NTP goes to considerable effort in it's sample filtering to exclude the noisy samples. We need to get that date before it's discarded and contribute it to the entropy cause. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cer/b7b/pfc - pem
On Tue, 18 Jul 2000 02:14:23 +0200, "Leif Neland" [EMAIL PROTECTED] said: I can export the key as a .cer, .p7b or .pfx, but openssl seems to want it in .pem format. Of course, you haven't really told us what the format of these things is, so it's difficult to say. The ``standard'' export format is something called PKCS#12. You can use `openssl pkcs12' with various options to extract the key and certificate from this sort of format. It will prompt you for the password you specified when exporting. If you export in any other format, it is highly unlikely to contain your private key, which is required to make use of the certificate. Those other formats are normally used when you want to distribute your public key to someone or as a part of something other than a mail message. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Recent -CURRENT locks up keyboard
I've just built a new world on one of my test boxes. The good news is that the Macronix Ethernet card that I have in it works fine (this is the one with the MX98715AEC-C chip with the small hash table). The bad news is that the keyboard is non-functional. This is a GENERIC kernel with nothing changed. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: randomdev entropy gathering is really weak
Predicting the clock's offset from reality and the two way path to the server of choice is impossible, plus if people enable authentication later on the packets will be choke full of high-quality entropy. Please quantify 'impossible'. Impossible as in cannot be done. The offset between, for example, the processor clock and the NIC clock is unpredictable. DS 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 wrote: Predicting the clock's offset from reality and the two way path to the server of choice is impossible, plus if people enable authentication later on the packets will be choke full of high-quality entropy. Please quantify 'impossible'. Impossible as in cannot be done. The offset between, for example, the processor clock and the NIC clock is unpredictable. The EXACT offset is unpredictable. Unfortunately that's not what matters because an attacker can still guess. What does matter is the set of likely/possible offsets. That set may be small or may be large or may be biased. Can you tell me how large it *typically* is on your computer? My clock usually is within a few seconds from my NTP server. I guess -assuming microsecond resolution- that allows for a couple of million possibilities but no more. I can definately extract one or two bits of entropy from this, but can I do ten, twenty or even 30? [1] Can you generate a 1024-bit RSA key after processing 10 NTP packets? I don't think so. How many *do* you need? You need to quantify all this to make a good entropy estimate. Just implementing this functionality because 'predicting the clock's offset [...] is impossible' is pretty pointless. Cheers, Jeroen [1] And then, what's the effect of an attacker sniffing your LAN? What information would he have to make his guess more accurate? -- 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: fetch(1) bug?
At 17 Jul 2000 23:38:23 +0200, DES wrote: I've spent most of the night fixing this and am about to commit the last changes, so you should be able to cvsup and build working libfetch and fetch in an hour or two. Thanks! I could confirm that your changes fixed the problem, and am happy to see them MFC'd before 4.1-RELEASE. :) -- / /__ __ / ) ) ) ) / Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP, mtree defaults returns back to original
In message [EMAIL PROTECTED] "Andrey A. Chernov" writes: : 2716: : mtree now NOT follows symlinks by default, old behaviour restored to be : compatible with rest of *BSD camp. New -L option added to follow : symlinks. This require manual mtree rebuilding before 'make world' Is this still needed? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
In message [EMAIL PROTECTED], "Jeroen C. van Gelderen" writes : Predicting the clock's offset from reality and the two way path to the server of choice is impossible, plus if people enable authentication later on the packets will be choke full of high-quality entropy. Please quantify 'impossible'. People have tried for 30+ years to predict what a quartz xtal will do next. Nobody expects any chance of success. Add to this the need to predict the difference between one or more NTP servers and your local qartz xtal and I think we can safely say "impossible". I think we first need to figure out the security implications. I think the security implications of having no entropy are much worse than having entropy which a truly superhuman *maybe* could guess *some* of the bits in, are far worse. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
