Re: Will 5.2 ship with WITH_LIBMAP? (was Re: KSE howto?)
On Friday, Sep 26, 2003, at 13:29 US/Eastern, Terry Lambert wrote: Which begs the question... is 5.2 going to ship with WITH_LIBMAP enabled by default? http://www.google.com/search?q=libmap+default+WITH_LIBMAPie=UTF- 8oe=UTF-8 http://people.freebsd.org/~bmah/relnotes/CURRENT/relnotes-i386.txt rtld(1) now includes ``libmap'' functionality by default; the WITH_LIBMAP compile knob is unnecessary and has been retired. More information can be found in libmap.conf(5). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
DP2: ar / sysinstall fdisk trouble / GEOM?
Hi, In order to debug a minor problem with the ar-driver, I installed DP2 on an Abit KR7A-RAID with HighPoint ATA-RAID controller. The machine contains two identical 40GB IBM drives as masters on each of the two HighPoint IDE channels. The issue I ran into was that the partition editor in sysinstall does not work correctly. While it correctly displays the existing disk partitioning scheme, it insists on reporting an incorrect drive geometry of 0/255/63. Trying to delete slices does not work and causes sysinstall to go unresponsive. Manually overriding geometry to the correct value of 7476/255/63 (as determined by FreeBSD 4.6) did not help. I could not find a way to make the partition editor work right. In the end I worked around the problem by using a 4.6 disk to do the partitioning. Labeling and the rest of the installation process were done with DP2 and worked like a charm. (GEOM and RCng kick ass!) Once installed and booted into DP2, I checked /stand/sysinstall again, with the exact same results. Executing /sbin/fdisk however does report the correct geometry which leads me to believe that the problem is sysinstall-specific. Attached are dmesg, fdisk output. The machine is available for remote root login over SSH. Any suggestions? -J - [sysinstall partition editor] - Disk name: ar0FDISK Partition Editor DISK Geometry: 0 cyls/255 heads/63 sectors = 0 sectors (0MB) Offset Size(ST)End Name PType Desc Subtype Flags 0 63 62- 12 unused0 63 120101877 120101939ar0s1 8freebsd 165 120101940 1259 120103198- 12 unused0 The following commands are supported (in upper or lower case): A = Use Entire Disk G = set Drive Geometry C = Create Slice F = `DD' mode D = Delete Slice Z = Toggle Size UnitsS = Set Bootable | = Wizard m. T = Change Type U = Undo All Changes W = Write Changes Use F1 or ? to get more help, arrow keys to select. - [ fdisk output ] - # fdisk *** Working on device /dev/ar0 *** parameters extracted from in-core disklabel are: cylinders=7476 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=7476 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 120101877 (58643 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED # - [ dmesg (verbose) ] - Dec 12 12:39:49 syslogd: kernel boot file is /boot/kernel/kernel Dec 12 12:39:49 kernel: Copyright (c) 1992-2002 The FreeBSD Project. Dec 12 12:39:49 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Dec 12 12:39:49 kernel: The Regents of the University of California. All rights reserved. Dec 12 12:39:49 kernel: FreeBSD 5.0-DP2 #1: Sat Nov 16 13:38:33 GMT 2002 Dec 12 12:39:49 kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Dec 12 12:39:49 kernel: Preloaded elf kernel /boot/kernel/kernel at 0xc0679000. Dec 12 12:39:49 kernel: Preloaded elf module /boot/kernel/acpi.ko at 0xc06790b4. Dec 12 12:39:49 kernel: Calibrating clock(s) ... TSC clock: 1534133428 Hz, i8254 clock: 1193301 Hz Dec 12 12:39:49 kernel: CLK_USE_I8254_CALIBRATION not specified - using default frequency Dec 12 12:39:49 kernel: Timecounter i8254 frequency 1193182 Hz Dec 12 12:39:49 kernel: CLK_USE_TSC_CALIBRATION not specified - using old calibration method Dec 12 12:39:49 kernel: Timecounter TSC frequency 1533986470 Hz Dec 12 12:39:49 kernel: CPU: AMD Athlon(tm) XP 1800+ (1533.99-MHz 686-class CPU) Dec 12 12:39:49 kernel: Origin = AuthenticAMD Id = 0x662 Stepping = 2 Dec 12 12:39:49 kernel: Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE, MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE Dec 12 12:39:49 kernel: AMD Features=0xc048MP,AMIE,DSP,3DNow! Dec 12 12:39:49 kernel: Data TLB: 32 entries, fully associative Dec 12 12:39:49 kernel: Instruction TLB: 16 entries, fully associative Dec 12 12:39:49 kernel: L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative Dec 12 12:39:49 kernel: L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative Dec 12 12:39:49 kernel: L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative Dec 12 12:39:49 kernel: real memory = 536805376 (511 MB) Dec 12 12:39:49 kernel: Physical memory chunk(s): Dec 12
Re: expat2 in the base system?
On Friday, Oct 4, 2002, at 06:26 US/Eastern, Giorgos Keramidas wrote: On 2002-10-03 22:22, Mike Barcroft [EMAIL PROTECTED] wrote: Ernst de Haan [EMAIL PROTECTED] writes: If most file formats would be XML-based (yes I know XML should not replace all file formats, but it comes a great way) then these formats would be leveraged by the fact that there are a lot of XML tools available, like XML editors and XML transformation processors (XSLT). It's easy to convert from one XML format to the other, making the generation of DocBook or XHTML documents a /lot/ easier. I've always wondered what a Makefile would look like in XML. You'd be surprised. There is already such a thing. The j2ee (Java Beans, Enteprise Edition) already have something that works this way. It's called ant, if my memory from my early 2001 work with j2ee, doesn't fail me. Almost. It's indeed called Ant but has been developed under the umbrella of the Apache Jakarta project. -J -- Jeroen C. van Gelderen - [EMAIL PROTECTED] - +1 242 357 5115 When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong. -- R. Buckminster Fuller To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: an IPv4-mapped IPv6 address off by default
Umemoto-san,
May I ask what motivated this change?
-J
On Thursday, Jul 25, 2002, at 11:51 US/Eastern, Hajimu UMEMOTO wrote:
Hi,
I've just committed to change an IPv4-mapped IPv6 address off by
default.
The existing applications may be affected this change. The
applications which depend on an IPv4-mapped IPv6 address will become
listen only an IPv6 socket.
Apache2 is known having this problem. You may need to specify the
Listen directive explicitly in your httpd.conf like as follows:
Listen 0.0.0.0:80
Listen [::]:80
If you still want to use an IPv4-mapped IPv6 address, please specify
ipv6_ipv4mapping=YES
in your /etc/rc.conf.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
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
Not committing WARNS settings...
On Tuesday, February 5, 2002, at 01:04 , Kris Kennaway wrote: On Tue, Feb 05, 2002 at 07:20:46AM -0800, David O'Brien wrote: On Mon, Feb 04, 2002 at 07:06:54PM -0800, Kris Kennaway wrote: If you use the argument that one shouldn't set WARNS because a new compiler will cause the tree to break, then there's no point having it at all since that condition will always be true. The difference is _impending_. EPARSE. David is about to switch to GCC 3.0 and I guess he does not like moving targets. I would expect that for the GCC 4.0 upgrade a similar freeze request will go out. And that seems fair enough since it does not prevent anyone from applying the actual code fixes. We want to make this import stuff as easy on David as we can, no? It is a job from hell already. Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Freedom is essentially a condition of inequality, not equality. It recognizes as a fact of nature the structural differences inherent in man - in temperament, character, and capacity - and it respects those differences. We are not alike and no law can make us so. -- Frank Chodorov To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ssh reports no RSA support in libssl and libcrypto.
Peter Jeremy wrote: Having built and installed -current from last Friday, I find that ssh* is now reporting no RSA support in libssl and libcrypto. See ssl(8) and will only talk SSH2. I couldn't find anything relevant in ssl(8). I haven't specified WITH_RSA=NO anywhere and checking through the build logs, there's no sign of -DNO_RSA. libcrypto.a contains an RSA_generate_key() which doesn't look like a stub. Does anyone have any ideas? I seem to remember that I once got a misleading message just like that. It turned out that /dev/random was not available or not working properly. Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] A government that robs Peter to pay Paul can always depend upon the support of Paul. -- George Bernard Shaw To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: yarrow /dev/random
Mark Murray wrote: [...] Again, I'm not so sure; Yarrow goes to great trouble to protect its internal state; by blocking, I have this very nasty suspicion that this carefully guarded state is being disclosed. The moment you block, you are confiding in the fact that you have no updating entropy, and as a result /dev/urandom gan be attacked to get the internal state. You would normally assume that an attacker knows when you are not adding in entropy. In Yarrow, the assumption is that the internal state is (sufficiently) protected by both a hash and the blockcipher so blocking will not affect Yarrow's security properties AFAICS. Yes, /dev/urandom can be attacked at the point of blocking but given robust primitives the complexity is still 2^(sizeof(hash)) which is exactly the complexity Yarrow claims to provide. This is completely independent of any knowledge of reseed timings (or lack thereof). 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: yarrow /dev/random
Mark Murray wrote: [...] Crypto construct-wise I don't think you can treat BF-CBC of a 256 bit plaintext with a 256 bit key as a virtual 256 bit block cipher operation. I suspect the result will be weaker than 256 bits because of the internal structure of BF-CBC. I'm not sure I understand this? 256-bit Davies-Meyer is considered secure if a blockcipher with a 256-bit block is being used. Encrypting 256 bits in CBC mode is not the same as a blockcipher with a 256-bit block. For one, it will not obfuscate certain plaintext patterns. Consider what happens if the first 64 bits of two plaintext blocks are equal... Using the current construct allows for a variety of attacks on the compression function of the constructed hash. If you want 256 bit hash (and it is desirable for AES) you could use what Jeroen suggested: abrest Davies-Meyer, and a 128 bit block cipher. Or we could wait for the AES hash mode. That is doable; But we don't have any 128-bit block blockciphers in the kernel? at the moment I only have SHA1, MD5, DES and Blowfish available in FreeBSD's kernel crypto API; I'd need a lot more evidence before I feen I can pull in any more :-) You could argue that AES belongs in the kernel as soon as it is selected. You could then go ahead and import Serpent now (as the most conservative possible choice of AES) with the comment that it will be replaced with the real AES later. Waiting for the AES hash mode requires a lot of patience. I suspect a 256-bit hash will accompany the next-generation DSA but that will take at least a year or so... In any case, the currently available building blocks are not sufficient and I doubt you will encounter much objections against importing another cipher. Have you actually asked or is it more of a perceived objection? Twofish in abrest Davies-Meyer mode is going to blow away BF-CBC-256 pseudo 256 bit block cipher Davies-Meyer performance wise, because of the key agility. But Twofish is not neccessarily the best choice. Yes, it's being pushed by Bruce Schneier but that's for marketing purposes, not for technical merits. Iff you are going with a 128-bit-block blockcipher you ought to select the most conservative one and that currently isn't Twofish IMO. [...] The quality of the de-skewing function, conservative assumptions about distribution of entropy across samples and conservativeness of the entropy estimates don't help. It's the yarrow output function which blows it. Yeah; that monotonically-increasing counter bothers me slightly. Why? How would it affect security if one assumes the blockcipher is secure? 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
Brian Fundakowski Feldman wrote: On Mon, 24 Jul 2000, Jeroen C. van Gelderen wrote: 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. Even if the attack on a single non-blocking read from Yarrow is only of 2^256 complexity, it is designed to be much more expensive than just cracking a single block cipher. Blowfish has a very large keying step, and Yarrow is designed to exploit having large keying steps and then adding more complexity in its setup in addition. This makes it infeasible to mount attacks on Yarrow, and the security is really not as weak as just cracking 20-round Blowfish-256. Actually, it is. The low key agility doesn't add anything in terms of practical security because it only affects brute force attacks and can be optimized out in a pipelined implementation. Expensive, yes, but can be done. There is some more details on this in the Yarrow paper I think... Anyway, not that is matters, Yarrow was designed to be as secure as the underlying blockcipher and Blowfish is generally considered to be reasonably secure. So, the security still is 2^256 maximum, no way around that. However, none of this makes Yarrow useless for getting many bits of high-quality random data for, e.g., generation of an RSA key. Well, you will need to back that up with arguments if you want to convince the more sceptical (not me). A mere statement will not do it, you need proof or at least arguments :-) The question that Kris posed basically boiled down to: "Does 2^256 complexity equal 2^x (x 256) complexity in practice?" . I can't think of a practical system where it wouldn't be sufficient in practice but that's just me. Well, you seem to agree and MarkM seems to too. Hmm, maybe the complainers should provide proof that they do need more than 2^256 complexity. Makes it easier for us, proponents ;-/ Also, since a 1024 RSA-key only has ~2^77 complexity it isn't a very good example. A more interesting question is, what if you generate a couple of 256-bit symmetric keys in a row. Their total complexity is 2^256 which is less than they could have. Does that matter in practice? Mark already stated that in *practicality*, Yarrow-BF-cbc-256 1.0 (I guess that's the proper name for this :-) According to Bruce S. one would call it Yarrow-256 (implementation details go here) You would definately spell out Blowfish completely. Btw, how exactly is the hash actually constructed in our Yarrow? I wonder how one constructs a 256-bit hash out of Blowfish with a 64-bit block size. A quick explanation would be appreciated. is complex enough and generates good enough ouput. If you /really/ want to make the attack on it much harder, how about this: if you're going to read 1024 bits of entropy from Yarrow on /dev/random, you will request it all at once and block just as the old random(4) used to block; the blocking can occur at 256 bit intervals and sleep until there is a reseed. Waiting to reseed for each read will ensure a much larger amount of "real" entropy than it "maybe" happening at random times. Sounds like a good idea. It looks like it would be reasonably easy to then add an extra entropy counter to the pool from which you subtract the number of bits that are output and to which you add the number of entropy bits that are mixed in. You can then extract bytes until that counter hits 0 and then block until it goes positive again which would ensure that the entropy output trough /dev/random is not re-used for output trough /dev/urandom. This would not affect the security of Yarrow at all but preserve the semantics of /dev/random almost completely. Can you really find anything wrong with doing what I propose *in practice*? No. Although I think you can make it nearly perfect by incorporating the above suggestion. You would then *never* return more bits than you have gathered entropy and you would never use those entropy bits twice. I've already implemented this as well as some other bugfixes, so see the attached diff. Cool. [1] And, should we decide not to change /dev/random semantics, can we still back /dev/random with a modified Yarrow? I think it makes sense :) Me too, especially with your changes (or modification thereof) to preserve current /dev/random semantics. Cheers, Jer
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
Re: randomdev entropy gathering is really weak
David Schwartz wrote: /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. 1. The current /dev/random cannot do it, it's less secure than Yarrow for a variety of reasons. So we have a net improvement anyway. Thanks Mark. 2. Most people do not want to seed 1024-bit keys as outlined in another mail in this thread. If they *understand* the issues involved they will realize that 2^256 complexity is plenty uncrackable for all practical purposes. FreeBSD is about practical purposes IMHO. 3. Yarrow can be modified to just do this, should someone think this is neccessary. Read the paper and think of what happens when you set Pg to 1/(2^(k/3)). (Note that the paper restricts this value to 1 = Pg but that's of no importance here.) ** This is overly conservative for most applications I can think of; Even a multi-million dollar financial transactioning system will be practically secure when Pg is set to 1. 4. Nothing prevents you from adapting Yarrow so that current /dev/random semantics are preserved, making Yarrow even better. It can be done with the current design it's just not very beneficial to do it. 5. Yarrow was designed as a better replacement for most any PRNG by a couple of bright cryptographers. Can you do better than that? 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
Kris Kennaway wrote: On Sun, 23 Jul 2000, Mark Murray wrote: This design tradeoff is discussed in section 4.1 of the paper. Tweakable. Doing a reseed operation with every output is going to be *very* computationally expensive. Tradeoff. What do you want? Lightning fast? Excessive security? Balance it out. Thinking about it further, I dont think Yarrow can even do this (introduce entropy into every output value) without bypassing the block cipher. Why not? And if you reseed with every 256 bits of output then you're vulnerable to an iterative guessing attack because the fast pool won't have much in it. You would block until the pool is filled with entropy. [...] There are two other models which rate "pretty well-designed" in the Yarrow paper: the cryptlib and PGP PRNGs. I don't know what their properties are right now (the cryptlib one is described in the paper on PRNG cryptanalysis). Fortunately you don't need them :-) I'll relent somewhat if a secure entropy distilling algorithm could be found; one which stands up to crypanalysis. Well, a simple scheme which doesn't seem to suffer from any of the vulnerabilities discussed in the schneier papers is to accumulate entropy in a pool, and only return output when the pool is full. i.e. the PRNG would either block or return 0 bytes of data, or a full pool's worth. And you can make Yarrow do just that. Not very practical but you can do it. You effectively set Pg to 1/(2^(k/3)). Will you relent a step or two if I can get the entropy harvesting _rate_ high enough? :-) If we get the entropy pools filling fast enough that the reseed is triggering close to every 256 bits of output then it becomes much less of a concern (but it's still there, because reseeding happens asynchronously with respect to PRNG output). Reseeds do not *have* to happen asynchronously as pointed out above. What is of importance is that you *cannot* forcibly trigger a reseed without there being enough entropy in the pools. There is nothing against having /dev/random block until the pools have accumulated enough entropy. 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
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: randomdev entropy gathering is really weak
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
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: randomdev entropy gathering is really weak
Mark Murray wrote: What about saving the state of the RNG and re-reading it on bootup? That will allow Yarrow to continue right where it left off. :-) That's a bad thing. You don't want someone to be able to examine the exact PRNG state at next boot by looking at your hard disk after the machine has shut down. It is a Yarrow-mandated procedure. Please read the Yarrow paper. Actually, it's not. You don not want to save the exact PRNG state to disk, ever. It's not Yarrow mandated procedure but a big security hole. That said, you do not write out the state of the PRNG, you write out a couple of blocks of output from which the state cannot be derived. That *is* okay and that's what you are doing. And just for completeness: it's not mandatory to do so. I don't know where you read that in the paper. If they can do that, they have either the console (==root) or they have root. Either way, who cares what they know about your machine, they have the whole darn thing :-O. Someone may well compromise your randomness source without you noticing. And read your PGP mail for the coming couple of years because your PGP key was compromised without you noticing. Perfect Trojan horse to write for the FBI, IRS, anyone who doesn't like you. Oops. 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
Dan Moschuk wrote: | | Gotcha - fix coming; I need to stash some randomness at shutdown time, and | | use that to reseed the RNG at reboot time. | | What about saving the state of the RNG and re-reading it on bootup? That | will allow Yarrow to continue right where it left off. :-) | | That's a bad thing. You don't want someone to be able to examine the exact | PRNG state at next boot by looking at your hard disk after the machine has | shut down. I don't see how. If the attacker has physical access to the machine, there are plenty worse things to be done than just reading the state of a PRNG. If the random device is initialized in single user mode, and the file is then unlink()ed, I don't see any problems with that. You generate a new PGP keypair and start using it. Your co-worker reboots your machine afterwards and recovers the PRNG state that happens to be stashed on disk. He can then backtrack and potentially recover the exact same random numbers that you used for your key. 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], "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". See my reply to David Schwartz. What kind of numbers are we talking about? 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. I agree, but to paraphrase: that's policy decision. Just quantify it so that people can be their own judge. 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], "Jeroen C. van Gelderen" writes: 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". See my reply to David Schwartz. What kind of numbers are we talking about? With microsecond timestamps, 64second ntp poll period we are talking about approx 10 bits of randomness in the received packet and about 3 bits of randomness in the clock difference. FreeBSD uses nanosecond timestamping (Actually could do nanoseconds with 32 bitfractions), but that only adds about 4 bits to the clock difference due to the clock frequency end interrupt hardware. Thanks! This is useful. 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. I agree, but to paraphrase: that's policy decision. Just quantify it so that people can be their own judge. No, it is not policy to try to get as many random bits as we can by default. It would be policy to *not* do so for some obscure principle of scientific purity. It's up to the user to decide what security level he needs. Both ought to be possible but having an insecure box ought to be an explicit decision. I think you will agree that there needs to be a decent security level by default. I.e. newly generated SSH host keys are sufficiently secure. 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
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
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: ssh not working after upgrading OS?
John Galt wrote: On Wed, 12 Jul 2000, Mark Murray wrote: You are probably using a -CURRENT with a broken randomness device. For more information you can try and search the mailing list archives. No - he has _no_ randomness device. Isn't there an add-on daemon for that, ESD or somesuch? The OpenSSL docs mention it. Yes and no. That daemon is a 'hack' for systems that lack a randomness device. You don't want to use it when you do have a good /dev/random. FreeBSD has a /dev/random except that it has been broken for a while whilst MarkM brought it up to snuff. The mailing list archives ought to contain all of the details one needs to fix this temporary problem. No need to resort to EGD, just tweak some config. 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: ssh not working after upgrading OS?
Sam Xie wrote: Hi! All, I upgraded my OS to FreeBSD 5.0-CURRENT #20, everything seems fine except ssh. Every time if I try to ssh to another host, the system gives me an error message says, "ssh: no RSA support in libssl and libcrypto. See ssl(8). Disabling protocol version 1 DH_generate_key" What is wrong and how to fix it? Any help will be gratefull! You are probably using a -CURRENT with a broken randomness device. For more information you can try and search the mailing list archives. Try updating to a more recent -CURRENT, that should help. 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: HEADS UP! New (incomplete) /dev/random device!
Mark Murray wrote: On Sun, 25 Jun 2000, Warner Losh wrote: Some days is OK, imho. Much more than that and I'd begin to worry. Much more than a week or two and I'd worry a lot. I'll go put a note in updating right now. That's okay with me too. People should just not upgrade their work machines for the next few days until entropy is fixed. Upgrading is fine; just don't build certificates/credentials. Upgrading is *not* fine. Everything that uses high-quality randomness is broken. This includes SSH, PGP, GnuPG, Apache/SSL random pid generation and what not. No, upgrading is not fine at all. 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: mktemp() patch
Kris Kennaway wrote: On Sat, 10 Jun 2000, Kris Kennaway wrote: Given the other replies in this thread I think I'll just remove the PID stuff altogether and make the temp filename only constructed from alphanumeric character. The price is that there's a chance of collision between two programs who mktemp() and come up with the same random filename, which is a theoretical security risk (at present only something with the same PID can come up with a colliding tempfile name) but the probability is altogether pretty small. I'll do some calculations to estimate the exact level of risk here. Actually, it's not of course a security risk in the new algorithm (this is mktemp() after all), but it's a potential failure mode which can cause applications to fail in ways they otherwise wouldn't (with some very low probability) on a normal system. But, I don't think it's a big enough problem to worry about (numbers still coming :-) It's not a new situation, any application that can write to /tmp can create files that collide with other program's use of mktemp(). 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: mktemp() patch
Kris Kennaway wrote: On Sat, 10 Jun 2000, Jeroen C. van Gelderen wrote: Actually, it's not of course a security risk in the new algorithm (this is mktemp() after all), but it's a potential failure mode which can cause applications to fail in ways they otherwise wouldn't (with some very low probability) on a normal system. But, I don't think it's a big enough problem to worry about (numbers still coming :-) It's not a new situation, any application that can write to /tmp can create files that collide with other program's use of mktemp(). Not under the current mktemp() since the PID is unique (except for wraparounds) mktemp() is not the only function that creates files in /tmp. 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: mktemp() patch
Mark Murray wrote: What is the purpose of this? It looks hugely wasteful to me. If you really need a single random bit, it is not good to waste a block of hard-gained gryptographic randomness; can you not use a pseudo-random bit-generator? arc4random() does not consume entropy except the first time it is called and when explicitly reseeded through arc4random_stir(). Apart from that it's a deterministic function (the arc4 stream cipher), but it's still a reasonably good cryptographic PRNG because arc4 is a cryptographically strong algorithm. But I repeat myself; are you still intending to use cryptographic security for one bit? What does that buy you? An attacker will laugh at the waste of resources that went into a coin-flip :-). Much better is to use something cheaper like time-of-day XOR 1 whatever. Pseudo random numbers are so cheap (or they should be) that you just don't want to try and 'optimize' here. It is much better to be conservative and use a good PRNG until it *proves* to be very problematic. 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: VMware detection code in boot loader
Luoqi Chen wrote: Would anyone object if I add a ficl word to detect whether we're booting from a vmware virtual machine? I find it extremely useful when I'm running FreeBSD as a guest under NT. Because it is a dual cpu box, I can't use a single kernel to boot both directly or inside the virtual machine. With this new word, I can determine which kernel to use in the loader script, saving me the trouble to unload and reload a new kernel each time I reboot. Here's the patch to the boot loader, Index: boot/ficl/ficl.h === RCS file: /home/ncvs/src/sys/boot/ficl/ficl.h,v retrieving revision 1.14 diff -u -r1.14 ficl.h --- boot/ficl/ficl.h2000/06/01 18:10:43 1.14 +++ boot/ficl/ficl.h2000/06/07 18:18:38 @@ -860,6 +860,7 @@ #if defined(__i386__) !defined(TESTMAIN) extern void ficlOutb(FICL_VM *pVM); extern void ficlInb(FICL_VM *pVM); +extern void vmware(FICL_VM *pVM); I'm not sure it is a good idea to name this variable VMWare as that is implementation specific. It may be better to have a var named 'emulation' set to 'none' or 'vmware' or 'bochs' or ... Just my EC 0.02, 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: mktemp() patch
"Andrey A. Chernov" wrote:
On Fri, Jun 09, 2000 at 10:02:44PM +0200, Mark Murray wrote:
But I repeat myself; are you still intending to use cryptographic security
for one bit? What does that buy you? An attacker will laugh at the waste
of resources that went into a coin-flip :-). Much better is to use something
cheaper like time-of-day XOR 1 whatever.
Pseudo random numbers are so cheap (or they should be) that you
just don't want to try and 'optimize' here. It is much better to
be conservative and use a good PRNG until it *proves* to be very
problematic.
Why not just XOR the whole lot into the current ${randomnumber}?
That way, at least the effort of the whole calculation is not wasted
as much.
Good point, there is no need to throw them away indeed.
Why to XOR true random bits from arc4random() with non-random bits from
getpid()? It only weakens. Better way is just remove any getpid() code and
left arc4random() only.
Then you will get collisions which you will have to deal with. I am not
familiar with the code but if we can handle collisions nicely then that
would be the way to go: 64^6 = 2^36 possibilities which is nice...
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: mktemp() patch
Kris Kennaway wrote: On Fri, 9 Jun 2000, Andrey A. Chernov wrote: On Thu, Jun 08, 2000 at 08:47:36PM -0700, Kris Kennaway wrote: filesystems. For example, should we limit all FreeBSD file names to 8.3 single-case in case someone wants to run from an old-style MSDOS partition? Bad example. Not _all_ filenames but temp. ones only which allows to run FreeBSD binary in MSDOS FS with MSDOS files. The point is the same. Files created by FreeBSD binaries during the course of operation don't conform to an 8.3 monocase naming scheme (think of dotfiles for example). I don't believe there's such a thing as a lowest common denominator of file system naming conventions - either a filesystem can support UFS names (perhaps through a translation later) or it's not suitable for running FreeBSD from. There really is no reason to use 72 characters instead of -say- 64. The increase in security is marginal and if the side-effect of using 64 is that it works with more filesystems than that is a Good Thing (TM). We are not alone in this world as -say- Microsoft tends to think. It's probably better to just get rid of the PID and use randomness troughout the name than to use 72 characters. 64^6 vs. 2*(72^3) . 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: VMware detection code in boot loader
Peter Wemm wrote: Christopher Masto wrote: On Fri, Jun 09, 2000 at 01:14:35PM -0400, Jeroen C. van Gelderen wrote: I'm not sure it is a good idea to name this variable VMWare as that is implementation specific. It may be better to have a var named 'emulation' set to 'none' or 'vmware' or 'bochs' or ... Mmm.. or, giving forth the ability to do in/out instructions, so the non-generic code would be entirely in the add-on forth piece. I'm not sure if there are any security implications there.. at boot time the machine is essentially as single-user as it's ever going to be. I prefer 'emulation' being set to 'native', 'vmware' etc. Consider that there is IA64, Alpha, sparc, ppc etc to deal with. Teaching the ficl scripts to do inb/outb would be bad. It would be much better to have a generic mechanism for informing the loader about possible emulation environments, eg you are using the IA64 emulator under an x86 box, or an x86 emulator on an Alpha, or an Alpha SIMOS emulation under x86, or whatever. Rethinking, emulation may not be the best suggestion. People might confuse it with Linux emulation. How about 'hardware' ? or 'platform' or your suggestion here ? 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: Major device numbers and mem device redesign
Mark Murray wrote: I want to commit a new /dev/random RSN, so I'll be needing a major device; what is the procedure for getting one? I know how to steal one, but ISTR that this is not how it is done. Just edit sys/conf/majors and claim the next available number. You don't need one. You can use the same major/minor numbers. You can register multiple cdevsw's per major number with make_dev(); (do NOT use cdevsw_add() for this). How does this work for all the routines? When you register the "new" minor number, can you be specifying new read/write/poll/ioctl/etc routines? I ask, as my RNG is a kld, and I want it to be as separate as possible without getting ridiculous. Have a look at http://jeroen.vangelderen.org/FreeBSD/misc_device . Cheers, Jeroen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Small MAKEDEV bug
David O'Brien wrote: On Sun, May 07, 2000 at 03:27:07PM -0400, Jeroen C. van Gelderen wrote: Or just settle for a more intuitive solution: MAKEDEV acd2 creates /dev/acd2 MAKEDEV 2 acd creates /dev/acd[01] which would allow for "MAKEDEV 64 da" and "MAKEDEV 256 pty" I agree with this syntax and after sending my message to you, was sitting there thinking "MAKEDEV num_of_devs dev_name" would make a really nice clear syntax. If you can get BDE's buy-in and other BSD traditionalists I think this would be great. The good part of this solution is that it's backwards compatible. If the first argument is an integer and the second a device name without a suffix we do the new thing, if not we revert to the traditional behaviour. bde: what do you think? Cheers, Jeroen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Small MAKEDEV bug
Bruce Evans wrote: On Mon, 8 May 2000, David O'Brien wrote: On Sun, May 07, 2000 at 03:27:07PM -0400, Jeroen C. van Gelderen wrote: Or just settle for a more intuitive solution: MAKEDEV acd2 creates /dev/acd2 MAKEDEV 2 acd creates /dev/acd[01] which would allow for "MAKEDEV 64 da" and "MAKEDEV 256 pty" I agree with this syntax and after sending my message to you, was sitting there thinking "MAKEDEV num_of_devs dev_name" would make a really nice clear syntax. If you can get BDE's buy-in and other BSD traditionalists I think this would be great. I don't buy it :-). This syntax is similar to a special case of the syntax of jot(1). It's better to use jot(1) directly, e.g.: MAKEDEV $(jot -w da 2 0)# make 2 acd devices beginning at acd0 From this it follows that MAKEDEV should be modified to create just it's argument: MAKEDEV dev8 creates just dev8, not dev0-dev7. Otherwise MAKEDEV $(jot -w da 6 4) wouldn't work or violate POLA. Agreed? Now it's a question of "the UNIX way" vs. convenience/userfriendlyness :-) Is it acceptable to have all users juggle with jot(1) or can we build in a convenience syntax that covers 95% of all uses? I'd think the latter, otherwise we might as well force our users to use mknod(8) and chmod(1) directly instead of MAKEDEV; After all, MAKEDEV is just a convenient wrapper around those commands. So I'd still propose: MAKEDEV count device_name_without_suffix MAKEDEV device_name_with_suffix ... As a consolation, added such a special syntax can be added in a few lines at the top of MAKEDEV, after which it recursively calls MAKEDEV with the appropriate jot(1)-expanded device list. So it doesn't clobber the code. Thoughts? Cheers, Jeroen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Small MAKEDEV bug
[CC culled, -stable removed] David O'Brien wrote: On Sun, May 07, 2000 at 04:59:46PM +0200, Jeroen Ruigrok van der Werven wrote: Can we settle this once and for all in a slightly sane manner? I committed the change so that MAKEDEV acd1 creates acd1 and not just acd0. This is wrong. ``MAKEDEV acd2'' should either create only /dev/acd2*, or /dev/acd[01]*. It would be nice to fix our inconsistency problem. Looking at the 4.4Lite vendor import to find the BSD way would be a good start. Or just settle for a more intuitive solution: MAKEDEV acd2 creates /dev/acd2 MAKEDEV 2 acd creates /dev/acd[01] which would allow for "MAKEDEV 64 da" and "MAKEDEV 256 pty" -- David([EMAIL PROTECTED]) Jeroen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP changes and breaking kld object module compatibility
Richard Wackerbarth wrote: On Mon, 24 Apr 2000, Matthew Dillon wrote: : However, I consider your SMP changes VERY destablizing; they BREAK : lots of modules :-( Huh? No they don't. They simply require recompiling the modules. If they actually broke the modules I wouldn't be trying to MFC it to -stable. From the USER's perspective, anything that requires me to as much as reload a module/program that I have already installed "breaks" it. The fact that it is only necessary to recompile it in order to fix it only means that it is easy to fix IF I have the source code. I don't think it was ever recommended that you upgrade your kernel without upgrading and rebuilding the modules (better still, world) at the same time. So this wouldn't really have an adverse effect, would it? Cheers, Jeroen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl 5.6.0?
Nick Hibma wrote: Are there actually any good reasons why we _should_ upgrade in the first place? Security fixes, added functionality we require, etc. The perl we have is stable and the problems it has are well known, which is good enough in 99% of the cases. PERL is not just used by the FreeBSD system, it's also used by many applications ran on top of FreeBSD. Those applications are more likely to require an up-to-date version of PERL. We for one need the (overly late) 64-bit support in PERL. You could of course force users to install the latest PERL locally and fiddle with $PATH but this would amount to hacking around a deficiency in FreeBSD. If FreeBSD needs an older version of PERL for it's own use, it should provide something like 'perl_freebsd' or 'system_perl' so that 'perl' can always be up2date. Later Anton Berezin wrote: Historical evidence suggests there will be 5.6.1 *very* soon, and 5.6.2 shortly after that. Let's wait a couple of months before jumping on this vagon... :-) 5.6.0 will almost surely prove to have far too many problems to include it into FreeBSD source tree. Problems in a dot-zero release are a very good argument against importing PERL 5.6.0 now. Of course it would be even better to just import PERL4 again and force everybody to use Python, but that's another religious war ;-/ Cheers, Jeroen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world breakage...
Mark Murray wrote: BTW, we can soon stop worrying about the crypto stuff, right? :) It sure seems so! :-) RSA will be the only problem for USA, Only until 20 September 2000 IIRC. and IDEA will be aproblem in Europe. And the rest of the world. It's patented in Japan and USA too, basically a useless algorithm as there are better free replacements available. (Especially by the time the patent expires.) Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Interesting read: http://www.vcnet.com/bms/ JLF To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: multiple cd devices
Bruce Evans wrote: On Fri, 31 Dec 1999, Chuck Robey wrote: Why are "certain" devices wildly different than all other ones? I've Because the CAM update broke (SCSI) cd devices in rev.1.171 of MAKEDEV. mcd and scd were in the same case statement so they were broken too. The breakage has spread to acd and ccd (although the latter is not a cdrom), but not to matcd or wcd or non-cdrom disks. What about having ./MAKEDEV cd0 cd1 cd4 -da2 da6-da9 create cd0, cd1, cd4, da1, da2, da6, da7, da8, da9 ? This would be a generic solution that still allows for holes. Not possible because of compatibility issues? I'm willing to give it a go. Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Interesting read: http://www.vcnet.com/bms/ JLF To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with the ATA-driver
Nick Hibma wrote: If you end up doing this, can you have the driver print a line letting people know this is intentional? i.e., ad0: DMA disabled: This drive does not properly support DMA mode. ad0: To force DMA for this drive (at your own risk) set flags 0xXX. Let's not go the Linux way and make the boot messages slow down booting. Mentioning it in the manpage should be sufficient I guess. Blacklisting devices sounds like a good idea if tey fail to work correctly in many cases. I agree that the 2nd line should go in the manual pages but keeping the first line could reduce the number of user questions. Also, if you have broken hardware, you probably don't care about boot speed. Soren: thanks for the ATA driver. My Thinkpad 600 now happily runs -CURRENT at UDMA33 mode. Only suspends don't seem to work yet, but that can be pilot error as well... Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Interesting read: http://www.vcnet.com/bms/ JLF To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
"Jordan K. Hubbard" wrote: In other words, it's not a problem specific to KLD's .. but it's still a problem :-) Which raises an important issue - other than walking the sysctl tree regularly looking for changes, how does such an application become aware that the sysctl space has changed? I seem to recall that John Poltstra was working on a notification system (for use with CVSup) that would allow you to subscribe to certain change events... Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Interesting read: http://www.vcnet.com/bms/ JLF To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Mount problems after lockup
/ ufs rw 1 1 ^^ not running soft updates. the others do. /dev/da0s1f /tmpufs rw 2 2 /dev/da0s1g /usrufs rw 2 2 /dev/da0s1e /varufs rw 2 2 /dev/wcd0c /cdrom cd9660 ro,noauto 0 0 /dev/ccd0c /mnt/ccd0 ufs rw 0 2 /dev/wd2s1e /mnt/wd2ufs rw 0 2 /dev/wd3s1e /mnt/wd3ufs rw,sync 0 2 proc/proc procfs rw 0 0 -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Interesting read: http://www.vcnet.com/bms/ JLF To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mount problems after lockup
From: "Jeroen C. van Gelderen" [EMAIL PROTECTED] 14:33 Subject: Re: Mount problems after lockup To: Poul-Henning Kamp [EMAIL PROTECTED] Poul-Henning Kamp wrote: It is really a good idea to read the current mailing list if you run current on your machine. I do. copy MAKEDEV from src/etc/MAKEDEV to /dev, and run it to recreate your disk devices. I did just this. The entries in /dev are supposed to be of type char right? They are. Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Interesting read: http://www.vcnet.com/bms/ JLF To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Should UPDATING tell you to rerun MAKEDEV now?
David Malone wrote: I just had the same problem as someone else on the list where I booted after a make world and new kernel, and then fsck reported the filesystems clean but mount said they were dirty. I booted from the old kernel, installed and ran the new MAKEDEV and the new kernel ran fine. This is on a 386. Being the other person, I basically had the same problem. I had run MAKEDEV but an IDE disk did go bad which caused a crash which caused /dev corruption which caused the problem I posted... Phk just recommended running MAKEDEV to the othe person with this problem. I had to boot a kernel and /dev off a floppy to fix the /dev. Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Interesting read: http://www.vcnet.com/bms/ JLF To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FYI: KAME netinet6 basic part is committed
Yoshinobu Inoue wrote: Hello, FYI, KAME(IPv6, IPsec, and etc update kit for BSDs, http://www.kame.net) netinet6 basic part is committed to freebsd-current. It doesn't yet include several important parts (e.g.no IPsec, no v6 multcast forwarding, no TCP/UDP for IPv6 yet), but now it can assigne IPv6 addr automatically and can reply to IPv6 ping, if the kernel is built with "INET6" kernel config option. Please take care because inpcb structure is changed to be shared between netinet and netinet6. You will need to update include files to build several inpcb aware tools and applications. (fstat, netstat, systat, etc) Thanks! Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Interesting read: http://www.vcnet.com/bms/ JLF To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SPAM
Dmitrij Tejblum wrote: Jonathan M. Bresler wrote: with volunteers, we could moderate the list(s). mail transfer would be slower as we wait for the moderator(s) to approve each piece of email. if we use more than one moderator per list, the time-sequence of email would be lostwe would get some very strange threads...could be enteraining. Have you ever considered only allowing list members to post, or are there difficulties that make this impossible? I suggest following approach: moderate only mail that lack the mailing list name in To: or Cc: headers. It is far from ideal, but I think would work reasonably well. May I humbly suggest that we stop this discussion until spam becomes a real problem on this list? So far this thread has generated more noise than all spam that slipped trough to the list in the past year. Jonathan is doing an awful job, please give him credit for stopping the vast majority of spam messages and let this thread die. Cheers, Jeroen -- Jeroen C. van Gelderen - jer...@vangelderen.org - 0xC33EDFDE To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Cryptfs available outside US
Hi, I seem to remember someone requesting cryptfs. It's available outside the US on my webserver: http://wit395301.student.utwente.nl/~gelderen/fist/. It will go to replay soon. Cheers, Jeroen -- Jeroen C. van Gelderen - gelde...@mediaport.org - 0xC33EDFDE To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Postfix
Blaz Zupan wrote: I hate to roll up old threads, but it seems like nothing has come out of the Postfix vs. sendmail debate on this list. We don't even have a Postfix port. Has anybody created a port or should I go ahead and have a look at it? I would be very pleased to see a Postfix port. Not having to deal with Sendmail would render FreeBSD more usable for non-die-hard users. Cheers, Jeroen -- Jeroen C. van Gelderen - gelde...@mediaport.org - 0xC33EDFDE To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
From: Archie Cobbs arc...@whistle.com Doug Rabson writes: Might it be a good idea to choose a consistent naming scheme for the modules? I'd think so because it would help blind loading at the boot prompt. If you choose names it the following format: type_name saver_warp saver_daemon the modules of one type will sort together in a directory listing. This is a change that will make FreeBSD more user friendly I think. When I first started writing KLD, I had a vague notion that there would be a simple directory structure under /modules, e.g.: /modules pci/ ncr.ko ... isa/ if_ed.ko ... ... I like this idea (subdirectories) better.. it will last longer :-) Witness the explosion of the ports tree. I witnessed. But I don't think we will be heading that way. Even if you have 40 modules in each category, this ought to work (ls saver*). It will work because we prefix every driver with it's type so they sort together. This would have worked for the ports tree as well. Another advantage of the flat model is that it's way easier to browse. IMHO it's a real pain to have descend into subdirectories, only to find out that you want to look in another one. Cheers, Jeroen -- Jeroen C. van Gelderen -- gelde...@mediaport.org -- 0x46D8D3C8 -- [8-D}~= To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
KLD naming
Hi, Might it be a good idea to choose a consistent naming scheme for the modules? I'd think so because it would help blind loading at the boot prompt. If you choose names it the following format: type_name saver_warp saver_daemon the modules of one type will sort together in a directory listing. This is a change that will make FreeBSD more user friendly I think. Cheers, Jeroen To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Annoying messages on startup..
From: Jordan K. Hubbard j...@zippy.cdrom.com I don't like this error much either (especially since it generates tech support questions on USENET and other places from users going Aieee! What does this mean?!) aolme too/aol Question is what to do about the messages. I can think of a few options: 1. move them to verbose mode. There are more drivers that spew this kind of message in verbose mode. 2. handle them trough the quirk mechanism. I was told that this would cause kernel-bloat but that might be remedied by using a more compact format (now 17 bytes per entry) for the quirk table and/or allowing the quirk table to be paged out (if possible?) 3. issue them only when the driver expects it to be a quirk. There are a lot of drives that will cause the openings to run down to a certain number and stay there. Don't issue a warning when the number stays above ??. 4. adjust the number of tagged openings on boot. Simply issue a lot of tagged openings and adjust the number appropriately. This would look very nice: da0 at ahc0 bus 0 target 0 lun 0 da0: CONNER CFP4207S 4.28GB 1524 Fixed Direct Access SCSI-2 device da0: 5.0MB/s transfers (5.0MHz, offset 15), Tagged Queueing Enabled (31 concurrent transactions) da0: 4096MB (8388608 512 byte sectors: 255H 63S/T 522C) or, if you want to do something about the formatting of the boot msgs: da0 at ahc0 bus 0 target 0 lun 0 CONNER CFP4207S 4.28GB 1524 Fixed Direct Access SCSI-2 device 5.0MB/s transfers (5.0MHz, offset 15), Tagged Queueing Enabled (31 concurrent transactions) 4096MB (8388608 512 byte sectors: 255H 63S/T 522C) A combination of these ideas might do. Basically you want to get rid of the warnings when there's nothing wrong with the hardware. DISCLAIMER: I don't know much about CAM so please don't shoot me if this is nonsense... Cheers, Jeroen -- Jeroen C. van Gelderen -- gelde...@mediaport.org -- [8-D}~= To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
