Re: randomdev entropy gathering is really weak
http://www.counterpane.com/pseudorandom_number.html Cryptlib is described here: http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ Thanks! Asynchonous reseeding _improves_ the situation; the attacker cannot force it to any degree of accuracy, and if he has the odds stacked heavily against him that each 256-bits of output will have an associated reseed, it makes his job pretty damn difficult. What I meant with that point is that the user may get, say an extra few hundred bits out of it with no new entropy before the scheduled reseed task kicks in. How does he know which bits are which? His analysis task just got a whole lot more difficult. 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: Netscape
Adam wrote: On Sun, 23 Jul 2000, Trevor Johnson wrote: Are the fixed in Netscape 4.74 bugs not critical for release? Who knows? I don't know of any changelog for Netscape. The release notes are at http://home.netscape.com/eng/mozilla/4.7/relnotes/unix-4.74.html#whatnew . The only change that looks like it applies to us is a new feature to delete all your e-mail when exiting the program. I haven't tried it, but it seems to me that making an alias like alias netscape='/usr/local/bin/netscape rm -rf ~/nsmail/*' or putting something similar in your .logout would achieve the same thing. If you are talking about Expunging, I believe to netscape that means it actually goes through and deletes the emails that you have deleted... (uhh..) When I used to use netscape for my email, netscape wouldn't release hard disk space when you delete emails until you empty trash *and* run expunge. Expunding does NOT do something like rm -rf ~/nsmail/*' but it compacts all of your local e-mail folders by _completly_ deleting already "notched" messages. Look on your ~/nsmail/ directory; you have there some files like inbox, sent, trash, etc. and you also have inbox.snm, sent.snm, trash.snm, etc. The *.snm files is a pointers' files; when you delete some locally saved message from inbox (for example) you actually only delet the pointer to this message from inbox.snm file not the message itself. If you don't want some day catch out that you don't have free space on your hard drive you need to do "Compact Folders" that deletes all such unpointered messages. In the last 4.74 version of Netscape Communicator you can do this automatically when you exit the program. Why deleting from trash doesn't do it, I don't know, but netscape got to be too buggy for me to use for an email client about a year ago. The trash folder designed for undeleting locally saved and amiss deleted e-mail messages, it's just a backup folder not something else. By the way, if you do "Empty Trash on Local Mail" it automatically will do "Compact Folders" after it (in 4.73 version there was a bug, the "Compact Folders" didn't work). So when you "delete" some message from inbox (for example) it will just copy the message into the trash folder and delete the pointer to him from inbox.snm file. If you don't want the copy in a trash folder you can press and hold the [Shift] key when you delete any 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
On Sun, Jul 23, 2000 at 03:06:34PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Stefan `Sec` Zehl writes: With the current approach it has a 256bits key. This is, in my eyes, not good. Although yarrow is nice, It's suited for any kind of key generation. The first law of crypto clearly states: "Know what you're doing". There is no way around that law. We cannot load down FreeBSD with impossibly heavy computations to cater for any and all conceiveable application of random numbers. But FreeBSD should provide a way to get truely random numbers when it asks for them. /dev/random was invented so the applications don't have to bother with entropy-gathering. I agree that yarrow is good, but we need some way to get really random numbers. Maybe call it /dev/rrandom. The way Kris describes it, it won't really use cpu time until it is read. CU, Sec -- I even remember having a private exchange of messages with you about other possible approaches to that problem. :-) Hopefully, these approaches involved slowly crushing of tender body parts. -- Liviu Wietse about broken Mailers ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locale issues on -current
On Sat 2000-07-22 (00:10), Doug Barton 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. Viren: Is that in an X session, possibly running gnome? I've had this too. Never have figured what it was about, but it happened only in X, where I use gnome. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure
On Sat, Jul 22, 2000 at 02:49:02PM -0700, Marcel Moolenaar wrote: Did we bump the libc version number when the strtofflags/fflagstostr functions went in? Nope, the added functionality didn't change any of the existing interfaces, so it no longer meets our requirements for a shlib version bump. In the a.out days, we would have done a minor number bump. One of the assumptions in not needing a bump, is ``make world'' uses the right libraries to link the new source with. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DHCP client problem?
On Mon, Jul 24, 2000 at 01:58:47PM +0900, Seigo Tanimura wrote: Did you see this log? On Thu, 20 Jul 2000 02:53:11 -0700 (PDT), "David E. O'Brien" [EMAIL PROTECTED] said: I'll take a look at this on Monday. Thanks! for the bug reports -- just what I wanted to hear before I thought about a MFC for this. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pcvt works
Strange but true, i cvsupped a tree yesterday (and another on another machine today) and on both machines a pcvt-configured kernel now works again and does not panic any longer (same config files hint files). hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Recent make world breakages
Not to exacerbate a sore subject, but... From what I'm seeing go by, the intention is that a current make world is supposed to work from -stable. OK, what about make release? The reason I am asking, is that I'm actually running current on a laptop, and for various reasons, its far easier to be able to load it from a cdrom. My build machine is a 4.0 release box, its the only one I have that's muscular enough to do the build. Since I've been tracking -current (the last couple of weeks or so, but I've been on this list for a year or so) I have been able to build world, but building the boot crunch dies compiling /bin/sh (there are intermediate files created by yacc and such that are built in the current directory, not where the source is.) Should this work? Is it germane that I don't build in /usr/whatever, but over in /home/current, etc? Should this work? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure
-On [2723 07:15], John Polstra ([EMAIL PROTECTED]) wrote: 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. Think we could come up with a make cleanworld like target which does just that? 't Would be pretty helpful IMHO. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Truth is always exciting. Speak it, then. Life is boring without it... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
patch for ds1 soundcard
I found on my computer that a ds1 builtin soundcard of type 10 (found in the file) will not init correctly unless the same 400ms wait is applied to it that is applied to type 8 cards. I have included a patch to make this happen. The patch was created against a -STABLE from today, but should not be too hard to get into -CURRENT as it only modifies one line of code. = | Kenneth Culver | FreeBSD: The best NT upgrade| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = Index: sys/dev/sound/pci/ds1.c === RCS file: /home/ncvs/src/sys/dev/sound/pci/ds1.c,v retrieving revision 1.8.2.1 diff -r1.8.2.1 ds1.c 295c295 if (sc-type == 8) --- if (sc-type == 8 || sc-type == 10)
Re: Locale issues on -current
"Neil" == Neil Blakey-Milner [EMAIL PROTECTED] writes: Neil On Sat 2000-07-22 (00:10), Doug Barton 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. Neil Viren: Is that in an X session, possibly running gnome? Neil I've had this too. Never have figured what it was about, but it Neil happened only in X, where I use gnome. Yes, it is gnome. And, as Doug suggested, it stops when you unset LC_CTYPE. I don't think it is actually doing anything other than irritating me. :-) Neil Neil Thanks Viren -- Viren R. Shah, [EMAIL PROTECTED], http://www.rstcorp.com/~vshah/ `Beware the Jabberwock, my son! The jaws that bite, the claws that catch! Beware the Jubjub bird, and shun the frumious Bandersnatch!' -- Lewis Carroll (Jabberwocky) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure
-On [2723 07:15], John Polstra ([EMAIL PROTECTED]) wrote: 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. Think we could come up with a make cleanworld like target which does just that? 't Would be pretty helpful IMHO. That would be pretty much like a fresh install from a snapshot. Or a backup/restore cycle. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FW: Recent make world breakages
Blasted Outhouse mailer. Grumble Lets try again. -Original Message- From: Gray, David W. Sent: Monday, July 24, 2000 11:15 AM To: 'FreeBSD Current list' Subject: Recent make world breakages Not to exacerbate a sore subject, but... From what I'm seeing go by, the intention is that a current make world is supposed to work from -stable. OK, what about make release? The reason I am asking, is that I'm actually running current on a laptop, and for various reasons, its far easier to be able to load it from a cdrom. My build machine is a 4.0 release box, its the only one I have that's muscular enough to do the build. Since I've been tracking -current (the last couple of weeks or so, but I've been on this list for a year or so) I have been able to build world, but building the boot crunch dies compiling /bin/sh (there are intermediate files created by yacc and such that are built in the current directory, not where the source is.) Should this work? Is it germane that I don't build in /usr/whatever, but over in /home/current, etc? Should this work? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locale issues on -current
According to Neil Blakey-Milner: I've had this too. Never have figured what it was about, but it happened only in X, where I use gnome. /me has the very same problem, running Gnome as well. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 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, 24 Jul 2000, Jeroen C. van Gelderen wrote: 1. The overhead will probably be insignificant. One doesn't use such vast amounts of random numbers. True, but the effect on slow CPUs for a single read may be signfificant. We'll have to see. 2. At least the generator gate can be optimized out if it turns out to be a problem. Yes. 3. We could use a cipher with better key agility (CAST) to make each operation less computationally intensive. Yes. ITYM Pg = k 2^(-k/3) though - you want a maximum k bits of output, not 1. Pg is the number of blocks IIRC. Pg is the number of (n=64)-bit blocks between generator gates, but min(2^n,2^(k/3)Pg) is the maximum number of output bits you'll get before the thing shuts up and waits for a reseed. So Pg 1 means we'll take a generator gate after every output block, but will still output our 2^(k/3)Pg = k bits (i.e. 4 blocks worth) In practice we'd probably have to just special-case this since the required Pg is approximately 10^-24 :-) 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: MS CHAP v2 in -current?
On Sat, Jul 22, 2000 at 08:29:23AM -0400, Nathan Binkert wrote: 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. Out of interest, is there any code relationship, beyond the ijppp ancestor, between mpd-netgraph and ppp? I switched to mpd-netgraph recently when I was having problems getting pptp to work against a recent-ish NT server, and it's sort of working (keeps dropping out: I'll mail some traces to Archie soon.) It does do the authentication thing, though. -- Andrew 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: [...] Asynchonous reseeding _improves_ the situation; the attacker cannot force it to any degree of accuracy, and if he has the odds stacked heavily against him that each 256-bits of output will have an associated reseed, it makes his job pretty damn difficult. This is not correct for a variety of reasons. But that's all fairly theoretical and ... not relevant for the discussion at hand. What I meant with that point is that the user may get, say an extra few hundred bits out of it with no new entropy before the scheduled reseed task kicks in. How does he know which bits are which? His analysis task just got a whole lot more difficult. Again, not entirely correct but not relevant either... Kris is simply right in that the /dev/random semantics change and that more bits can be output by Yarrow than there is entropy gathered. *In theory* the complexity of an attack on our Yarrow has an upper bound of 2^256 and *in theory* this is less than the complexity of an attack on our current /dev/random. This is a hard fact, no way around that. However, the big question here is not about theory but about *practicality*. Is Yarrow less secure than /dev/random in practice? How does our /dev/random hold up under attack? How does Yarrow compare? I think we need to evaluate these practical questions instead of deep theoretical issues as Yarrow is all about practicality. At a more fundamental level we will need to answer the question: "Do we need to preserve the current /dev/random semantics or can we decide to change 'em? [1]". And how will this affect our applications *in practice*. So let's concentrate this discussion on the practical issues and explain why you think backing /dev/random with Yarrow and changing the semantics is justifyable or even a good thing. Cheers, Jeroen [1] And, should we decide not to change /dev/random semantics, can we still back /dev/random with a modified Yarrow? -- 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
