Re: Missing LIST_PREV() ?
Hans Petter Selasky writes: Hi, Why should LISTs only be forward traversable? The following piece of code make lists backward traversable: No objection to the concept. But... /sys/sys/queue.h: +#define LIST_PREV(head,elm,field) \ + (((elm) == LIST_FIRST(head)) ? ((__typeof(elm))0) : \ + ((__typeof(elm))(((uint8_t *)((elm)-field.le_prev)) - \ + ((uint8_t *)LIST_NEXT((__typeof(elm))0,field) Please don't use typeof; it is a GCCism. Do you really mean NULL? M -- Mark R V Murray - Cert APS(Open) Dip Phys(Open) BSc Open(Open) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ProPolice: best way to fill canary
Sam Leffler writes: I asked a certain person to add the obsd sysctl long ago but it never happened. That would be me. And it wouldn't be the first time a ball got dropped. I'll get to it. :-] M -- Mark R V Murray What is the most interesting question you have asked? What, if any, was the answer? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
Thomas David Rivers writes: If I'm remembering correctly - the historical way to do this is to alias the rm command to something that else that checks the arguments and complains appropriately (and then executes /bin/rm.) Typically with just a shell alias. That keeps you from accidently doing something. Yeah. $ alias rm=rm -i and you get the annoying confirm all deletes behaviour. Just thinking that putting extra smarts into a utility isn't the typical UNIXy way to do this. Let each tool do the one thing it does really well.. 'rm' removes; let it remove. Right. There are SO many special cases here that rm cannot possibly catch them all: # cd / ; rm -rf foo/ * ^ This space is a typo. I think, in the old UNIX Review magazine (what - almost 15+ years ago now?) There was a couple of examples of this. Many others as well. Windows' job is to prevent you from shooting yourself in the foot. With UNIX, the idea is to make damn sure that there is a hole in your foot with the greatest possible efficiency. (Paraphrased) I've typed rm -rf * in the wrong place. ONCE. I learned Unix-fu from that experience. Now, if I type rm anything, I wake up. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to build lint libraries, e.g. llib-lc.ln?
Alexander Mueller writes: when writing C applications I'd like to check them using lint. Unfortunately FreeBSD comes with only llib-lposix.ln and llib-lstdc.ln in /usr/libdata/lint. Is there an easy, i.e. automated, way to create lint libraries (e.g. llib-lc.ln) for all the libs in /usr/src/lib? yes. In current use WANT_LINT= yes in /etc/make.conf. This won't work in STABLE; I haven't MFCed it. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-hackers Digest, Vol 42, Issue 6
YACINE GHANJAOUI writes: Anyone help me how to untar a file with this extention file.tar.bz2 ? Thanks, This is really questions@ material, but... $ tar -y M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Paul Robinson writes: In short, you can put all the effort you want in, but -core and many with a commit bit will resent you for it, because you're just a user. 4. In private I've already apologised for that particualr comment as I realise now it was very Daily Mail of me to make it (for those of you without access to the Daily Mail, congratualations), and it's only fair as it spilled out onto the public lists, that I apologise here too. Mark also apologised for swearing at me. I consider hands to have been shaken over this. :-). And for those of you who normally shout Submit a patch - well, I'm thinking about it. :-) I've been thinking of your objection to the submit a patch reply, and I offer this as a proto-thought on how it can be applied to non-coders: As FreeBSD is a volunteer project, I suspect part of the problem is getting said volunteers to do things that they would otherwise not do. Submit a patch can be easily(?) extendted to cover a much wider area of volunteer-organised work than simply code. Under specifically _patches_, there are code, documentation and web page patches, but there is also a need for organizational skills. The PR database frequently gets blitzed by keen folks who get lots of PRs closed, follwed by burnout. We are doing rather well with our release-engineering team (Go Scott L!), and our currently active admin@ crowd are doing a great job, but we could still use skills, and these are not necessarily of the coding kind. SO - instead of submit a patch perhaps if we were to go submit something tangible and useful? This can be anything that will forward the progress of FreeBSD. It could be something lofty like paying the salary of a developer who will then work primarily on projects useful to yourself. It could be commissioned work for a particular project you would like to see done. It could be a financial or equipment donation. It could be a donation of your time in a way that would be useful (please help here by finding something that needs doing and offering to do it, rather than expecting us geeks to find it for you!). It could be _anything_ that forwards the aims of the project and that you can do, and it preferably needs to be something that can be done autonomously (or as autonomously as possible). You will not get paid, you may not get thanked, but you will have the satisfaction of actually getting something done, and if you like FreeBSD as much as I do, that is an end in itself! M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SVBUG what happened tonight (12-04-2003)
Hi Could you please discuss spam issues on a spam list. Your mail has nothing to do with FreeBSD. I'm sorry about your car accident, but that is also not hackers@ material. It is, however OK for [EMAIL PROTECTED] Thanks! M [EMAIL PROTECTED] writes: Announcement for 2003-12-04 Topic: What happened to me tonight. The reflections of a night can at times be beyond one's control. To make it short, I got in a car accident tonight. I am okay, nothing wrong; just a shaken realization. As the CHP officer said, your still alive. And I am glad of that. My vehicle is totaled and replacement will not be easy. At least not as easy as when I worked in the tech sector. My decision has been and always will be to stay in computers. However, it's a pity that my life decisions are not as good a my technical. (some might argue otherwise). To surmise I'm a bit melancholy, but what's important to you is this: Jon Syrstad of Ampex has confirmed that my findings that using a white list is the key to avoiding spam. He estimates that within a month his job of reviewing the daily SPAM from 8 times a day for legitamite email to once. Jon uses a full set of tools and is personally charged by the CEO to reduce SPAM. He has both commercial and open source tools. None have been or will every be as effective as a white list, consisting of family, friends, business associates and people you really want to talk to. So, as a local company selling cell phone service likes to say, get off 'their' clock, permission to speak freely. Thank You Jessem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Size-independent byte order swapping functions.
David Schultz writes: I'm not sure if dedicated epanic() is the best way to implement out-of-rang e errors prevention - the more handy solution should cause compile error. See CTASSERT. There is an extremely limited number of sizes that are possible here, even with weird/theoretical architectures like 256-bit machines. Doesn't it make sense just to presume that out-of-range is impossible, and recode for default if (sizeof(x) == 1) return x; (ignore syntax) ? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: User asks: can we decouple device vendor IDs from drivers?
M. Warner Losh writes: The problem with decoupling things entirely from the drivers is that many drivers will say if I have this revision of that card, do this workaround. or if I'm this or newer, I have this feature both of which are broken by the kernel forcing the driver to service a given hunk of hardware. Hmm. Careful design may sort this out, methinks. If the file (which sounds analagous to /boot/device.hints to me) turned devid's into generic griver requrements (DEVID(0x04589045) == driver(foo) revision(bar) flags(baz, qux)) would that not be usable? (/me wonders if he has the time to do this - he's certainly interested) The other down side is that when you bork the alias file on solaris, you are so hozed. ... like most of the files in /boot/... However, it would make the dynamic loading of drivers easier. I really like to concept of configuring things with vi(1), instead of with gcc :-) M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no subject
maya Haddad writes: would you help me in writing network LKM under linux kernel 2.4, small examol e would be good. You sent this to a FreeBSD list, you need to find a Linux list instead. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: building sshd
Adil Katchi writes: I'm trying to build sshd from src/crypto/openssh and I'm having problems. I've only modified auth2.c. I've followed the FREEBSD-upgrade instructions. So, this is what I've done: 1. autoconf // to generate the configure file 2. autoheader // got a bunch of warnings but no errors 3. ./configure --with-pam --with-s-key// PAM was configured, but S/Key wasn't.. dunno why yet 4. make sshd // below are the errors I got after a bunch of warnings No. That is NOT how its built. Look at src/secure/*/*ssh*/Makefile M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: replacing sendmail with qmail
Alin-Adrian Anton writes: Hi guys, As sendmail showed to be so vulnerable in the past, and even in the recent past, I was wondering to propose removing it from the default install on freebsd. Currently, sendmail comes with the system sources, and runs as root. I think this is bad, and it could be replaced with qmail, for example. Or, something else, if you think something else is more secure. Please let me know if this is possible, or why if not, and to whom shall I address this idea (I wonder why it didn't happen yet). Please look for this topic in the archives. It has been discussed VERY many times. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forged subscriptions and the troll.
Pawel Jakub Dawidek writes: On Sun, Jun 01, 2003 at 04:46:10PM +0100, Mark Murray wrote: + We are currently being attacked by an individual who is attempting + to mass-subscribe our lists to other mailing lists. +=20 + PLEASE DO NOT RESPOND TO ANY OF THIS MAIL! I am taking care of it. +=20 + Thank you for your co-operation. :-) Maybe is time to disallow posting for non-members on selected lists? As I said, I'm taking care of things. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Forged subscriptions and the troll.
Hi We are currently being attacked by an individual who is attempting to mass-subscribe our lists to other mailing lists. PLEASE DO NOT RESPOND TO ANY OF THIS MAIL! I am taking care of it. Thank you for your co-operation. :-) M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The Trolls identity (was: Re: matthew dillon)
Rahul Siddharthan writes: (I assume I'm replying to the real PHK here) [EMAIL PROTECTED] wrote: We know that the lamer behind the Troll is Bill Huey aka billh. Is there any evidence for it? If so, you should share it and if not, you shouldn't make such accusations. He admitted to it. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant ?
Roman Neuhauser wrote: No, that's not the reason. I just don't like getting cc's. That's easily fixed: I recommend /usr/ports/mail/procmail. You can't expect people on a mailing list to tailor their MUA configuration to suit your choices. It's up to you to set up your own MUA and filters to cater to your own pickiness. Amen! Can we get back on topic now, please? :-) M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can dhclient rely on /dev/random?
Policy Question: is a fast, high-quality /dev/random a gauranteed feature starting with 5.0? yes. More like Yes, effectively. It is a module, and its conceivable under the right (Wrong?) circumstances that this module is not loaded. This would not be the default case, and it breaks Much(tm) if you don't include it. The kernel-building individual would have had to have made a decision to not include the RNG, and as such is assumed to know what she is doing. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Linux compatibility and /dev/null
What gives? ls -l /dev/null says: crw-rw-rw- 1 root wheel2, 2 Oct 9 12:45 /dev/null As it should. That's groovy. But what about /compat/linux/dev/null? -rw-r--r-- 1 root wheel 0 Oct 2 17:59 /compat/linux/dev/null Huh??! A _file_??! It should be a device! Hmm??? Doing chmod 666 /compat/linux/dev/null fixes the problem. Temporarily only. A better workaround is rm /compat/linux/dev/null; mknod /compat/linux/dev/null c 2 2 root:wheel. With your solution, that file may fill up with unwanted junk. This looks like a bug in the linux-base port. I'll file a PR. Indeed. Good move. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
Do you mean recompile SSL using urandom instead of random ?
Yes.
Would it be the exact same effect if I simply changed my /dev/random to
major/minor 2,4 instead of 2,3 ?
Yes. That would work.
It seems like that would be much easier...
Indeed!
M
Ok, I am not sure how I can do that though - I cannot successfully run
`rndcontrol -s X` inside a jail.
On the other hand, I already have:
rand_irqs=9 10 11 13 14
In my rc.conf on the underlying host machine, and have done several
boots
with that in place. So presumably I should be seeded just fine, but if
I am
not, I cannot change that in the jail because it seems I cannot set that
(I
assume it is a sysctl issue).
Willing to try whatever you can think of next :)
Hokay. Can you grovel around inside OpenSSL (src/crypto/openssl/...) and
find where the random device is read? If it is /dev/random, then change
that to /dev/urandom.
See how that works.
M
I can't seed it by banging on the keyboard - it is a headless server
in
a
rack thousands of miles from me :)
Perhaps there is another way to do it ?
Yes.
You need to find sources of entropy in interrupts. Look at a
dmesg, and note which IRQ's your network device(s) and mass
storage controller(s) (both SCSI and ATA). Use any other
irq's that aren't too busy and may be somewhat random.
Staring at a 'systat 2 -vmstat' screen (right hand side)
may give some clues.
Then use rndcontrol(8) to set up the seeding. There is a knob
in rc.conf to make this setting survive the next reboot.
M
Date: Thu, 03 Oct 2002 21:54:30 +0100
Sorry, here is the rest:
Here is the output of the `dd` command using urandom:
dd if=/dev/urandom of=/dev/stdout bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
a0 69 1a 7c 8f 32 e5 21 ae 7a 33 14 68 0b 8e a6
|.i.|.2.!.z3.h...|
... etc. Looking good.
$ ls -l /dev/*rand*
crw-r--r-- 1 root wheel2, 3 Sep 3 21:46 /dev/random
crw-r--r-- 1 root wheel2, 4 Sep 3 21:46 /dev/urandom
Also good.
So then, as root I ran: `chmod 0666 /dev/stdout` and then I
ran
your
`dd`
command and got:
$ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump
-C
0+0 records in
0+0 records out
0 bytes transferred in 0.36 secs (0 bytes/sec)
Can you try a few of these while furiously abusing your keyboard?
I'm trying to see if /dev/random can be persuaded to give _any_
aoutput at all.
Maybe do it on a vty instead of in X.
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
_
Chat with friends online, try MSN Messenger:
http://messenger.msn.com
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
_
Send and receive Hotmail on your mobile device: http://mobile.msn.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
_
Send and receive Hotmail on your mobile device: http://mobile.msn.com
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
Ok, I did this, and got the exact same results - first it says that PRNG is not seeded, and then I chmod 0666 /dev/urandom and then it tells me host key verification failed. I hope you mean /dev/random? M So, just in case I also did the opposite - I left random alone and set urandom to 2,3 so it behaves like random ... and this was interesting, when I did this, it told me PRNG not seeded no matter what I set the permissions to - so at no point did I progress to host key verification failed. Hope this helps - I hate to think that the single most used userland application does not function inside of jail (which is the case, it seems, at least in 4.6.2) Do you mean recompile SSL using urandom instead of random ? Yes. Would it be the exact same effect if I simply changed my /dev/random to major/minor 2,4 instead of 2,3 ? Yes. That would work. It seems like that would be much easier... Indeed! M Ok, I am not sure how I can do that though - I cannot successfully run `rndcontrol -s X` inside a jail. On the other hand, I already have: rand_irqs=9 10 11 13 14 In my rc.conf on the underlying host machine, and have done several boots with that in place. So presumably I should be seeded just fine, but if I am not, I cannot change that in the jail because it seems I cannot set that (I assume it is a sysctl issue). Willing to try whatever you can think of next :) Hokay. Can you grovel around inside OpenSSL (src/crypto/openssl/...) and find where the random device is read? If it is /dev/random, then change that to /dev/urandom. See how that works. M I can't seed it by banging on the keyboard - it is a headless server in a rack thousands of miles from me :) Perhaps there is another way to do it ? Yes. You need to find sources of entropy in interrupts. Look at a dmesg, and note which IRQ's your network device(s) and mass storage controller(s) (both SCSI and ATA). Use any other irq's that aren't too busy and may be somewhat random. Staring at a 'systat 2 -vmstat' screen (right hand side) may give some clues. Then use rndcontrol(8) to set up the seeding. There is a knob in rc.conf to make this setting survive the next reboot. M Date: Thu, 03 Oct 2002 21:54:30 +0100 Sorry, here is the rest: Here is the output of the `dd` command using urandom: dd if=/dev/urandom of=/dev/stdout bs=512 count=1 | hexdump -C 1+0 records in 1+0 records out a0 69 1a 7c 8f 32 e5 21 ae 7a 33 14 68 0b 8e a6 |.i.|.2.!.z3.h...| ... etc. Looking good. $ ls -l /dev/*rand* crw-r--r-- 1 root wheel2, 3 Sep 3 21:46 /dev/random crw-r--r-- 1 root wheel2, 4 Sep 3 21:46 /dev/urandom Also good. So then, as root I ran: `chmod 0666 /dev/stdout` and then I ran your `dd` command and got: $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C 0+0 records in 0+0 records out 0 bytes transferred in 0.36 secs (0 bytes/sec) Can you try a few of these while furiously abusing your keyboard? I'm trying to see if /dev/random can be persuaded to give _any_ aoutput at all. Maybe do it on a vty instead of in X. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- o Mark Murray \_ O.\_Warning: this .sig
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
-- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
Ok, I am not sure how I can do that though - I cannot successfully run `rndcontrol -s X` inside a jail. On the other hand, I already have: rand_irqs=9 10 11 13 14 In my rc.conf on the underlying host machine, and have done several boots with that in place. So presumably I should be seeded just fine, but if I am not, I cannot change that in the jail because it seems I cannot set that (I assume it is a sysctl issue). Willing to try whatever you can think of next :) Hokay. Can you grovel around inside OpenSSL (src/crypto/openssl/...) and find where the random device is read? If it is /dev/random, then change that to /dev/urandom. See how that works. M I can't seed it by banging on the keyboard - it is a headless server in a rack thousands of miles from me :) Perhaps there is another way to do it ? Yes. You need to find sources of entropy in interrupts. Look at a dmesg, and note which IRQ's your network device(s) and mass storage controller(s) (both SCSI and ATA). Use any other irq's that aren't too busy and may be somewhat random. Staring at a 'systat 2 -vmstat' screen (right hand side) may give some clues. Then use rndcontrol(8) to set up the seeding. There is a knob in rc.conf to make this setting survive the next reboot. M Date: Thu, 03 Oct 2002 21:54:30 +0100 Sorry, here is the rest: Here is the output of the `dd` command using urandom: dd if=/dev/urandom of=/dev/stdout bs=512 count=1 | hexdump -C 1+0 records in 1+0 records out a0 69 1a 7c 8f 32 e5 21 ae 7a 33 14 68 0b 8e a6 |.i.|.2.!.z3.h...| ... etc. Looking good. $ ls -l /dev/*rand* crw-r--r-- 1 root wheel2, 3 Sep 3 21:46 /dev/random crw-r--r-- 1 root wheel2, 4 Sep 3 21:46 /dev/urandom Also good. So then, as root I ran: `chmod 0666 /dev/stdout` and then I ran your `dd` command and got: $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C 0+0 records in 0+0 records out 0 bytes transferred in 0.36 secs (0 bytes/sec) Can you try a few of these while furiously abusing your keyboard? I'm trying to see if /dev/random can be persuaded to give _any_ aoutput at all. Maybe do it on a vty instead of in X. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
I have found that if you create a jail in FreeBSD 4.6.2, and then log into that jail ... if you are root you can scp and ssh just fine. However if you are not root and you attempt to ssh or scp, you get this error: PRNG is not seeded Hmmm. A few details - first, I created my jail by simply using the dump command to dump my / filesystem, and then restoring that inside the jail. Not elegant, but it works - so the jail in question has a full /dev and everything. Second, I used the exact same method in 4.6.1 and did not have problems. I saw a usenet post that recommended solving the problem with this: chmod a+r /dev/*rand* You seem to be on the right track in assuming it is a /dev/[u]random problem. Can you confirm this by (as a pleb user) dumping some random output? $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C (and same for /dev/urandom). Please also give a ls -l /dev/*random. however I tried that, and now when I try to ssh or scp from a non root user inside the jail, I get: Host key verification failed Does anyone know why this happens, why it didn't happen prior to 4.6.2, and how I can fix it ? The random device has not changed, but the OpenSSL code has. Maybe OpenSSL's internal PRNG is doing something naughty. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
Hi You only sent me a third of what I asked for :-) M Ok, here you are - as a normal user (non root) inside the jail, I have run: $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C dd: /dev/stdout: Permission denied $ ls -asl /dev/stdout 0 crw--- 1 root wheel 22, 1 Sep 3 21:46 /dev/stdout All of this was _after_ I ran the `chmod a+r /dev/*rand*` command. So then, as root I ran: `chmod 0666 /dev/stdout` and then I ran your `dd` command and got: $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C 0+0 records in 0+0 records out 0 bytes transferred in 0.36 secs (0 bytes/sec) I hope this is useful, and thank you for your help. I have found that if you create a jail in FreeBSD 4.6.2, and then log into that jail ... if you are root you can scp and ssh just fine. However if you are not root and you attempt to ssh or scp, you get this error: PRNG is not seeded Hmmm. A few details - first, I created my jail by simply using the dump command to dump my / filesystem, and then restoring that inside the jail. Not elegant, but it works - so the jail in question has a full /dev and everything. Second, I used the exact same method in 4.6.1 and did not have problems. I saw a usenet post that recommended solving the problem with this: chmod a+r /dev/*rand* You seem to be on the right track in assuming it is a /dev/[u]random problem. Can you confirm this by (as a pleb user) dumping some random output? $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C (and same for /dev/urandom). Please also give a ls -l /dev/*random. however I tried that, and now when I try to ssh or scp from a non root user inside the jail, I get: Host key verification failed Does anyone know why this happens, why it didn't happen prior to 4.6.2, and how I can fix it ? The random device has not changed, but the OpenSSL code has. Maybe OpenSSL's internal PRNG is doing something naughty. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
Sorry, here is the rest: Here is the output of the `dd` command using urandom: dd if=/dev/urandom of=/dev/stdout bs=512 count=1 | hexdump -C 1+0 records in 1+0 records out a0 69 1a 7c 8f 32 e5 21 ae 7a 33 14 68 0b 8e a6 |.i.|.2.!.z3.h...| ... etc. Looking good. $ ls -l /dev/*rand* crw-r--r-- 1 root wheel2, 3 Sep 3 21:46 /dev/random crw-r--r-- 1 root wheel2, 4 Sep 3 21:46 /dev/urandom Also good. So then, as root I ran: `chmod 0666 /dev/stdout` and then I ran your `dd` command and got: $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C 0+0 records in 0+0 records out 0 bytes transferred in 0.36 secs (0 bytes/sec) Can you try a few of these while furiously abusing your keyboard? I'm trying to see if /dev/random can be persuaded to give _any_ aoutput at all. Maybe do it on a vty instead of in X. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
I can't seed it by banging on the keyboard - it is a headless server in a
rack thousands of miles from me :)
Perhaps there is another way to do it ?
Yes.
You need to find sources of entropy in interrupts. Look at a
dmesg, and note which IRQ's your network device(s) and mass
storage controller(s) (both SCSI and ATA). Use any other
irq's that aren't too busy and may be somewhat random.
Staring at a 'systat 2 -vmstat' screen (right hand side)
may give some clues.
Then use rndcontrol(8) to set up the seeding. There is a knob
in rc.conf to make this setting survive the next reboot.
M
Date: Thu, 03 Oct 2002 21:54:30 +0100
Sorry, here is the rest:
Here is the output of the `dd` command using urandom:
dd if=/dev/urandom of=/dev/stdout bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
a0 69 1a 7c 8f 32 e5 21 ae 7a 33 14 68 0b 8e a6
|.i.|.2.!.z3.h...|
... etc. Looking good.
$ ls -l /dev/*rand*
crw-r--r-- 1 root wheel2, 3 Sep 3 21:46 /dev/random
crw-r--r-- 1 root wheel2, 4 Sep 3 21:46 /dev/urandom
Also good.
So then, as root I ran: `chmod 0666 /dev/stdout` and then I ran your
`dd`
command and got:
$ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C
0+0 records in
0+0 records out
0 bytes transferred in 0.36 secs (0 bytes/sec)
Can you try a few of these while furiously abusing your keyboard?
I'm trying to see if /dev/random can be persuaded to give _any_
aoutput at all.
Maybe do it on a vty instead of in X.
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
_
Chat with friends online, try MSN Messenger: http://messenger.msn.com
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: /dev/null sources
I'd wish to implement something like /dev/null or /dev/zero driver taking the original source code as a base, but I can't find the sources themselves, can you help? On STABLE (4.x and below) it is in src/sys/i386/i386/mem.c and it is a bit messy. (Look for Rathole) On Current (5.0+) it is in src/sys/dev/null/ and is much cleaner. :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PC/104 for factor cpu boards running FreeBSD?
Does anyone on this forum have any experience using these sorts of cards with FreeBSD and could you impart some of your general knowledge to me? I think the forum would be interested as well. Mike Smith was doing this as least as long ago as 1999 with a 486/PC104 at Walnut Creek. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: __STDC__ removal?
I'd support this. Makes maintaining the code a lot cleaner. M NetBSD is nuking almost all __STDC__ usages because it's always defined. Do we want to do the same? The exception I've seen is for assembler files where old style C is needed to avoid conflicts. mrouted/cfparse.y:#ifdef __STDC__ mrouted/cfparse.y:#ifdef __STDC__ mrouted/cfparse.y:#ifdef __STDC__ mrouted/defs.h:#ifdef __STDC__ mrouted/defs.h:#if defined(__STDC__) || defined(__GNUC__) mrouted/main.c:#ifdef __STDC__ mrouted/main.c:#ifdef __STDC__ mrouted/mapper.c:#ifdef __STDC__ mrouted/mapper.c:#ifdef __STDC__ mrouted/mrinfo.c:#ifdef __STDC__ mrouted/mrinfo.c:#ifdef __STDC__ mrouted/mtrace.c:#ifdef __STDC__ mrouted/mtrace.c:#ifdef __STDC__ mrouted/mtrace.c:#ifdef __STDC__ mrouted/mtrace.h:#if defined(__STDC__) || defined(__GNUC__) mtree/create.c:#if __STDC__ mtree/create.c:#if __STDC__ mtree/create.c:#if __STDC__ pppd/main.c:#if __STDC__ pppd/main.c:#if __STDC__ pppd/options.c:#if __STDC__ pppd/pppd.h:#if __STDC__ route6d/route6d.c:#ifdef __STDC__ route6d/route6d.c:#ifdef __STDC__ route6d/route6d.c:#ifdef __STDC__ route6d/route6d.c:#ifdef __STDC__ route6d/route6d.c:#ifdef __STDC__ route6d/route6d.c:#ifdef __STDC__ route6d/route6d.c:#ifdef __STDC__ rtsold/rtsold.c:#if __STDC__ zic/zdump.c:#ifdef __STDC__ zic/zdump.c:#endif /* defined __STDC__ */ zic/zdump.c:#ifndef __STDC__ zic/zdump.c:#endif /* !defined __STDC__ */ ee/ee.c:#if defined(__STDC__) || defined(__cplusplus) ee/ee.c:#ifndef __STDC__ ee/ee.c:#endif /* __STDC__ */ ee/new_curse.c:#if defined(__STDC__) ee/new_curse.c:#if __STDC__ || defined(__cplusplus) ee/new_curse.c:#endif /* __STDC__ */ ee/new_curse.c:#ifndef __STDC__ ee/new_curse.c:#endif /* __STDC__ */ ee/new_curse.c:#ifndef __STDC__ ee/new_curse.c:#else /* __STDC__ */ ee/new_curse.c:#endif /* __STDC__ */ ee/new_curse.c:#ifndef __STDC__ ee/new_curse.c:#ifndef __STDC__ ee/new_curse.c:#else /* __STDC__ */ ee/new_curse.c:#endif /* __STDC__ */ ee/new_curse.c:#ifdef __STDC__ ee/new_curse.c:#endif /* __STDC__ */ ee/new_curse.h:#if __STDC__ || defined(__cplusplus) find/getdate.y:#if defined (__STDC__) || defined (USG) find/getdate.y:#if defined (__STDC__) lex/NEWS: - Changed to only use '\a' for __STDC__ compilers. lex/NEWS: and free() for gcc, which defines __STDC__ but (often) doesn't lex/NEWS: - Generated scanner uses prototypes and const for __STDC__. lex/flex.skl:#if __STDC__ lex/flex.skl:#endif /* __STDC__ */ lex/flex.skl:#if __STDC__ lex/flexdef.h:#ifndef __STDC__ lex/flexdef.h:#define __STDC__ 1 lex/flexdef.h:#if __STDC__ lex/initscan.c:#if __STDC__ lex/initscan.c:#endif /* __STDC__ */ lex/initscan.c:#if __STDC__ lex/misc.c:#if __STDC__ lex/misc.c:#if __STDC__ rpcgen/rpc_hout.c: f_print(fout, \n#if defined(__STDC__) || defined(__cplusplus)\n); rpcgen/rpc_main.c: f_print(fout, \n#if defined(__STDC__) || defined(__cplusplus)\n); telnet/externs.h:# ifdef__STDC__ telnet/externs.h:# if defined(__STDC__) telnet/ring.h:#if defined(__STDC__) || defined(LINT_ARGS) yacc/skeleton.c:#if defined(__cplusplus) || __STDC__, yacc/skeleton.c:#if defined(__cplusplus) || __STDC__, yacc/skeleton.c:#if defined(__cplusplus) || __STDC__, -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: improved unifdef(1)
The unifdef in the system is not suited to heavyweight tasks like (say) xterm's main.c or wu-ftpd for a number of reasons: * it has a very low limit on the number of command-line arguments that it can cope with (100) -- I've sumbitted PR#37454 about this. * it doesn't have the slightest clue about #elif * it doesn't attempt to handle #if I am in violent agreement :-). Because I needed an unifdef with a bit more oomph and couldn't find a better one, I have done my own tune-up job on the BSD one, starting from the NetBSD sources (which seemed to have a mostly-superset of the changes made by the other BSDs). It's available from http://dotat.at/prog/misc/unifdef.c. The detailed change list is below. Note that only a very limited subset of #if expressions are understood, involving just defined(), !, , ||, and brackets. If anyone is interested I'd appreciate some testing, and it would be nice to get it committed eventually. Ooooh! :-) Yes please! I'll look at this. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
Again, look at current. The RNG is _really_ fast. I know. I know. I wish we could use it. Unfortunately this is for an appliance type application and I just don't feel comfortably shipping -CURRENT as product. I'm only just now making the effort to get up to speed on -CURRENT so that we can be ready to use it later this year. Also - have you looked at STABLE's /dev/urandom? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
We did make some enhancements that serve our needs, but may not be best for everyone. We actually need entropy in quantity since we could be doing a lot of crypto operations back to back and it can easily become our worst bottleneck. Have you looked at the Yarrow algorithm? To this end, we have an entropy buffer in kernel memory that pulls large blocks of entropy from the RNG if it's going to read from it at all. The device puts out several orders of magnitude more entropy than the original drivers captured, and we needed as much as we could grab. Ideally we would not mix the entropy into the entropy pool and just use the high quality entropy from the buffer, but we decided to minimize divergence from the original sources and not switch to 100% hardware entropy. In CURRENT, I have implemented Yarrow to achieve just this purpose. The drawback to our approach is that it can spend a lot of time in the kernel. To tune this behavior we added a few sysctl's. The start/stop script after the diff's tweaks a few of these settings after boot up. Again, look at current. The RNG is _really_ fast. I cc'd Kaj Groner, who actually did the work for us. He's not on this list, so don't drop his address. I was more involved at the higher levels of what we needed to get done when we rebased our appliance from OpenBSD to FreeBSD last Summer. :-) You may be pleasantly surprised :-) M (Thanks for the sources!) -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
But, back to the topic. We have taken the OpenBSD driver for the RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to FreeBSD-4.4. We made some enhancements to get more of the available random data bandwidth. We want to clean them up a little and submit them as a PR, but have not had time to. If you're interested I can send you the patches and you can give them a try. Hi. Please send me what you have. Thanks! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should pam_ssh and xdm work?
I've uncommented the entries for pam_ssh in /etc/pam.conf, and am trying to log in via xdm on my local machine. I can type in my SSH passphrase into the password box, and it authenticates me, and runs my .xsession. So far, no problems. But it's not setting up the ssh-agent properly. Yes this is a known bug. We need to fix it. Two copies of ssh-agent appear to be run, and the environment variables SSH_AUTH_SOCK and SSH_AGENT_PID are not passed. They are not available in any xterms, and they do not appear in the environment while .xsession is being executed. Combinations of using sufficient and required for pam_ssh and pam_unix do not seem to affect things. Nor should they :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: random + large IRQ's + SMP
What I need to know is when this was fixed (assuming it was). I tried to look through i386/i386/mem.c, per the messages to find the fix, but somewhere between when that message was posted and now random (and a few other things) were ripped out of there and scattered across several machine independant files. This has not been fixed. I could look at it (I am the author of that) and look for a solution. It may take a bit of time. with unsubscribe freebsd-hackers in the body of the message -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pam_wheel
This piece obviously has at least two errors. First, if PAM_OPT_AUTH_AS_SELF is true, then value of user is undefined. It should probably log pwd-pw_name instead. Second, check for root must of course be reversed and become if (!pwd-pw_uid). Fixed locally. Commit coming soon. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: blow fish
I think Mark Murray is still sitting on the patch I did for this very thing. Check the -hackers mail archives. It was about 2-3 Months ago, so it may not even patch cleanly anymore against -CURRENT. I committed this today! Apologies for the delay. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/kerberos5/usr.bin Makefile src/kerberos5/usr.bin/k5su Makefile
Will we always have this dichotomy between kblah/k5blah utilities? It is fairly annoying. Anecdotally, there don't seem to be many new Kerberos IV installations, Kerberos V's utilities can get/list/trash version 4 5 tickets. When all the K5 utils reliably double-up as K4 ones, I'll fix this. (I think we are really close, BTW). M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/kerberos5/usr.bin Makefile src/kerberos5/usr.bin/k5su Makefile
"Jacques A. Vidrine" [EMAIL PROTECTED] writes: Will we always have this dichotomy between kblah/k5blah utilities? It is fairly annoying. Anecdotally, there don't seem to be many new Kerberos IV installations, Kerberos V's utilities can get/list/trash version 4 5 tickets. Yes. My current plan of things to happen (in -current and after 4.3) is to ditch the v4 programs basically and install the v5 ones under the canonical names (with v4-compatibility if compiled in). And to always build and install the krb5 programs/libraries, but ifdef'ing the support in other programs. How does that sounds? Wonderful! If you need repo-copying done, I'm your man! -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch of licence Jiha...
Hi Could you people please take this flamewar off our lists? Thanks! M --part1_f8.65bd20b.278a2f74_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 1/7/2001 11:27:46 AM Pacific Standard Time, [EMAIL PROTECTED] writes: [ The dict command is your friend ] 1. Exempt from subjection to the will of others; not under restraint, control, or compulsion; able to follow one's own impulses, desires, or inclinations; determining one's own course of action; not dependent; at liberty. 2. Not under an arbitrary or despotic government; subject only to fixed laws regularly and fairly administered, and defended by them from encroachments upon natural or acquired rights; enjoying political liberty. What do you think the average person would interpret "free software" as ? Software that's not opressed, or software that has no cost ? Give me a break. We already have a term for software that just costs no money: "freeware". This is _NOT_ free software. Shareware is not free software. GPLed , BSDed, X11ed, public domain, APSLed (ad infinitum) code is free software, the kind that is not often written for Windows. I would agree with this statement fully in the case of BSD and X11. The other cases do not fulfill the definition of "free." GPL is not free, although it approaches it. GPL, APSL, etc. are subject to the will of th e authors. You're idioticly redefining the term "free" to be software with source code and restrictions, rather than no source code and no restrictions. You can't define the language. Free doesn't have a damned thing to do with your value judgements on what's useful, what's "no-value", whether or not it includes source, and whether or not it travels under the restrictions of your "free" licence. You're saying that the only "free" software is open-source software, and that's a pretty damned closed minded point of view. I'v e I'm afraid you are the victim of a "pretty damned closed minded point of view." "Free" binaries are under the restraint, control, and compulsion of the author. the user is unable to determine the course of action. If I cannot freely change the function of a program, it is not "free". If I must perform other actions as a result of my modifications, it is not "free." I am being compelled to perform. This is not "free." Oh, but other "free" (open source) software has no restraints, controls, o r compulsions right ? Then what's the point of having the licence ? If I may repeat what you just said again: If I must perform other actions as a result of my modifications, it is not "free." I am being compelled to perform. This is not "free." a.. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. b.. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Those sure seem to be compulsions. They are small and simple, but they ar e compulsions. So even BSD licenced software is not truly "free software" b y your foolish definitions. X11 and this permission notice appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation X11 has the same restrictions. Although including the licence in future copies is no big thing, it's still a restriction, and by your own words: "If I must perform other actions as a result of my modifications, it is not 'free'". Now lets hear you rephrase your words to try to become less ambigous about the definition of "free" and how it interacts with the restrictions of the BSD and/or X11 licences. Maybe you can tell us how they are "more free". That's always fun, to listen to people rant about levels of "freeness". I dunno who has it, but here's a cool little program called MultiRes... it's like QuickRes, but it's for Windows 2000, and supports refresh rates and shit. Oh, and Stox and Feldman need to, like, sit on a tack or something... --part1_f8.65bd20b.278a2f74_boundary Content-Type: application/octet-stream; name="multires.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="multires.exe" TVpQAAIEAA8A//8AALgAQAAa AAEAALoQAA4ftAnNIbgBTM0hkJBUaGlzIHByb2dyYW0gbXVzdCBiZSBydW4gdW5k ZXIgV2luMzINCiQ3
Re: encrypt h/w for FreeBSD? re-post
Just my quarterly check to see whether there's support coming up for hardware assisted IPsec, SSL, whatever? I have a card that does this, and I'm slowly working towards making it work. In addition to SSL on web servers, we'd recently have found some need like to run TLS for SMTP and postfix. The mail volumes will benefit from hardware crypto. I really prefer to stay with Free, vs. Open. Quite. :-) Please don't ask anything more than your "quarterly query"; that way I won't have to lie to you. :-) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
Any ideas on how to do this? Any suggestions on the process?
Simple lock (like flock(3)) in the perl script. Lock some ${FILE},
and if you can't get the lock, die. The file should contain the PID
of the process that holds the lock, so that a cleanerd can kill
stuck processes, or so that the lock can be blown away if needed.
Works like a charm.
M
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
unlock the file The cleaner you mentioned: run it every 15 minutes, compare the date/time on the lockfile, if more than 15 minutes old, grab the PID, and kill the job, remove the lock. Correct. Actually, you can make it a lot better: If the lockfile exists, then kill -0 the PID to see if it is still live. If not, blow away the lockfile. If still alive and older than N minutes, blow away the PID and break the lock. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
Okay, can you be specific about what you mean by "There was a time that we were very lax". If there was a change of server identity, then we did not necessarily announce what the new identity was in a way that people could trust. These days, a member of the Security Officer team sends out an announcement (cryptograhically signed of course) letting folks know what identity (fingerprint) to expect. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
Which original keys are you talking about? SSH public server keys. (Sometimes called "server identities"). Are you saying that the original SSH Public Keys for the servers were always sent in the clear, without PGP signature or anything? David was saying that, but he's wrong. There was a time that we were very lax about confirming the server public keys. The last round of changes have all been confirmed by digital signature by well-known server administrators. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD's random.c dicey on the Alpha
Anyone want to have a look at this? It's from the GNU awk maintainer. Without knowing which random.c it was, it's hard to judge :-) Also not knowing what the intended use is, it's hard to recommend something. I'd guess src/lib/libc/stdlib/random.c I'll bury it in my TODO. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: patches for 4.x devrandom so that bind works
Yes, it is this simple :-). Can you get it ready for 4.2? I'd like to see us be able to run bind9 in the next release. Sure. I'll see if I can do it in the next couple of hours. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: patches for 4.x devrandom so that bind works
Hi
I have something similar to this, and it goes slightly further.
Yes, it is this simple :-).
M
I was playing with bind9 and got the typical:
On FreeBSD systems, the server logs error messages like "fcntl(8,
F_SETFL, 4): Inappropriate ioctl for device". This is due to
a bug in the FreeSBD /dev/random device. The bug has been
reported to the FreeBSD maintainers. Versions of OpenBSD prior
to 2.8 have a similar problem.
I took a look at what OpenBSD did and it looks like they just
no-op'd out the ioctl:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/rnd.c?r1=1.40r2=1.41
I have a patch that seems to shut bind up, but I'm not 100% sure
this is the right fix, as it looks like it just fakes the nonblocking
access to the random devices.
Here's my patch (I can probably generate this for alpha):
Index: mem.c
===
RCS file: /home/ncvs/src/sys/i386/i386/mem.c,v
retrieving revision 1.79.2.4
diff -u -u -r1.79.2.4 mem.c
--- mem.c 2000/08/04 22:31:07 1.79.2.4
+++ mem.c 2000/11/13 23:53:43
@@ -57,6 +57,7 @@
#include sys/proc.h
#include sys/random.h
#include sys/signalvar.h
+#include sys/filio.h
#include sys/uio.h
#include machine/frame.h
@@ -465,8 +466,20 @@
* selecting and inspecting which interrupts are used in the muck
* gathering business.
*/
- if (cmd != MEM_SETIRQ cmd != MEM_CLEARIRQ cmd != MEM_RETURNIRQ)
+ switch (cmd) {
+ case FIOASYNC:
+ /* rnd has no async flag in softc so this is really a no-op. */
+ /* FALLTHROUGH */
+ case FIONBIO:
+ /* Handled in the upper FS layer. */
+ return (0);
+ case MEM_SETIRQ:
+ case MEM_CLEARIRQ:
+ case MEM_RETURNIRQ:
+ break;
+ default:
return (ENOTTY);
+ }
/*
* Even inspecting the state is privileged, since it gives a hint
Did I miss part of the OpenBSD delta? This looks too easy. :(
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Blowfish passwords
It patches cleanly against -STABLE and -CURRENT, and only touches libcrypt. Take a look at it, feedback/patches are welcome, and if you like it, maybe someone can integrate it into -CURRENT. (I don't know whose dept. this would be -- Mark Murray perhaps? ) http://www.frenchfries.net/paul/freebsd/blowfish.passwd.patch.gz Cool! Thank you! :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: perlcc in current - xs_init and boot_DynaLoader
If i do a perlcc test.pl i get the folllowing , in CURRENT ? Must i define something beforehand, or is it broken ? I'll take a look... Looks like perl brokenness. The missing boot_DynaLoader is in DynaLoader.a, but there is no way of linking it in. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: perlcc in current - xs_init and boot_DynaLoader
If i do a perlcc test.pl i get the folllowing , in CURRENT ? Must i define something beforehand, or is it broken ? I'll take a look... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A few device questions
At Thu, 24 Aug 2000 01:48:32 EDT, Louis Gerbarg wrote: I have been working with the OpenBSD /dev/random driver, and have ported it to Darwin. While I was at I wanted to also port it to FreeBSD, because it is more functional then current one, but I have a few questions: You should talk to Mark Murray [EMAIL PROTECTED] who has done alot of work with the current implementation of our random device. I am currently rewriting FreeBSD's /dev/random device to use Schneier's Yarrow algorithm. Some of it is in current, and a lot more is uncommitted. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: weird error messages from __COPYRIGHT macro
I'm not trying to protect the way I do it, since I don't use the macro myself. I just want to make sure that, if the NetBSD behaviour (handling embedded newlines properly) is correct, that we provide a compatible interface. Am I missing something here? Maybe I am. Did your _exact_ sample program fail on NetBSD in the same way that it failed on FreeBSD? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: weird error messages from __COPYRIGHT macro
(I just checked - it worked!) Now we just need someone with a NetBSD box handy to let us know whether double-escaping the newlines works alright there. I have a feeling it won't, which probably means we need to see if we can fix our implementation of __IDSTRING(). Bah. Only three things use __COPYRIGHT; ftp(d?), routed and make. None of them use \n's like you do. I've sent private mail to Peter, who introduced this implementation of __IDSTRING in rev 1.26 of cdefs.h. Compatibility measure? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: weird error messages from __COPYRIGHT macro
And please don't whine about me about string concatenation -- it's legal
in ANSI C. :-)
__COPYRIGHT is defined as
#define __COPYRIGHT(s) __IDSTRING(copyright,s)
and __IDSTRING is
#define __IDSTRING(name,string) __asm__(".ident\t\"" string "\"")
By the time the string makes it to the assembler, the \n's have been
turned into (real) NL's so the assembler line looks like
.ident "@(#) Copyright (c) 1983, 1988, 1993
The Regents of the University of California. All rights reserved.
"
...and it does not like the multi-line string. You may need to
double-escape the \n's (like \\n) to get them into the .ident
line symbolically.
(I just checked - it worked!)
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: desire for ftp.internat.freebsd.org mirror
Why not just use cvsup? It is already installed and running on internat and the firewall is already configured to allow it through. CVSUP only covers that which is already in CVS. The FTP stuff is what this chap is looking for. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: desire for ftp.internat.freebsd.org mirror
Mark Murray would know :-) I think there's a lot of stale cruft on ftp.internat.freebsd.org which doesn't need to be mirrored - Mark could probably tell us all which bits are suitable for mirroring (this should be documented somewhere for posterity) Mostly packages and distfiles. covering_in_asbestos mirroring of all that stuff should be migrated to rsync(1), since this implicitly defines (in terms of standard archive'/distribution handling) a structured "package" like layout, so we would have several collections (freebsd-ftp/ freebsd-www/ freebsd-crypto-US/ freebsd-crypto-nonUS/ and so on...) thus, it would be easier to set up a mirror, the paths would be more standard, the updates would be better in sync (since rsync really does a good job in not just only checking if a file has a new datestamp) and the world would be a bit better ;-) /covering_in_asbestos I could do this. What arre the setup concerns? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Crypto in the kernel: where how?
...a sys/crypt/ directory should hold their DES code. :-) ^ Shouldn't this be crypto ? That is what I see if I look on internat in the /usr/local/etc/cvsup/sup directory. So it should, and in the patch that I have, it is :-). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Crypto in the kernel: where how?
What is the plan (if any) for including crypto stuff in the kernel? As time goes on this will be more and more needed, eg. for IPSec and other VPN applications. The KAME/IPv6 guys have already brought this up; the agreement was that... It would be nice if we had a /usr/src/sys/crypt directory, plus whatever export-controlled firewalling silliness is necessary. ...a sys/crypt/ directory should hold their DES code. :-) Proposal.. (to get things started) - Add /usr/src/sys/crypt directory The CTM things aleady know about this dir. My ulterior motive is to checkin netgrapph/ng_mppc.c which adds MPPE/MPPC support for PPTP. However it's useless without an [A]RC4 implementation. I'd like DES, arc4 and MD5/SHA for Yarrow. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Release build
Does anybody know why ( i know that the directory /R/stage/trees/krb/ does not exist , but the directory /R/stage/trees/krb4/ do exist ) ?? For some reason, your src/release/* area is not getting updated. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP sequence numbers
I'd expect Yarrow to be (perhaps quite a bit) slower than our existing PRNG - it's a more conservative design and uses primitives like SHA-1 (for yarrow-160). I don't know how much of an impact this would be for network performance. I will doing Yarrow-1.0A, once the IPSec stuff is around. I expect to be able to tweak it so that this his is not too heavy, and customisable. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I wonder... There was a contrib/sys (where softupdates went), and that got moved to sys/contrib. Perhaps something similar could be invented for src/crypto? We'd need to make the distibution machinery understand that, but I don't see too much a problem there. I have no strong feelings about src/crypto/sys or src/sys/crypto. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
FYI, There are crypto-related files in the following locations. I'll take a detailed look into both repositories... Thanks! It makes the most sense to keep this exactly as it it, except for the files in src/sys/netinet6/ which should move to src/sys/crypto/ if they have crypto in them. Please do not import this until we (JDP!) gets the distribution channels crypto-happy. This is not difficult. itojun src/sys/netinet6/esp_output.c src/sys/netinet6/esp_input.c src/sys/netinet6/esp_core.c src/sys/crypto/cast128/cast128.c src/sys/crypto/cast128/cast128.h src/sys/crypto/cast128/cast128_cbc.c src/sys/crypto/cast128/cast128_subkey.h src/sys/crypto/blowfish/bf_cbc.c src/sys/crypto/blowfish/bf_cbc_m.c src/sys/crypto/blowfish/bf_enc.c src/sys/crypto/blowfish/bf_locl.h src/sys/crypto/blowfish/bf_pi.h src/sys/crypto/blowfish/bf_skey.c src/sys/crypto/blowfish/blowfish.h src/sys/crypto/des/des_3cbc.c src/sys/crypto/des/des.h src/sys/crypto/des/des_cbc.c src/sys/crypto/des/des_ecb.c src/sys/crypto/des/des_locl.h src/sys/crypto/des/des_setkey.c src/sys/crypto/des/podd.h src/sys/crypto/des/sk.h src/sys/crypto/des/spr.h -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days (at least outside the USA). The DoD, DoJ, DoE, DoC and watever other Do's you guys have are all passing the buck very fast nowadays. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
KAME team really needs your suggestions on how to integrate crypto part. In case of NetBSD/KAME integration, we did like this: - place IPsec core part and AH part into cvs.netbsd.org (in US) - place ESP part and crypto algorithms (DES, Blowfish and whatever in cvs.fi.netbsd.org (in finland) We need some tricky symbolic link, or makefile/config hack for this separated repository (NetBSD has makefile and config hack). FreeBSD has the src/crypto directory for this purpose. It works in exactly the same way as src/contrib, but contains code that may get Americans into trouble if they export it, so I maintain a copy in South Africa (on internat.freebsd.org). I'll be very happy to work with you on this one. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I wonder... There was a contrib/sys (where softupdates went), and that got moved to sys/contrib. Perhaps something similar could be invented for src/crypto? We'd need to make the distibution machinery understand that, but I don't see too much a problem there. I have no strong feelings about src/crypto/sys or src/sys/crypto. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
FYI, There are crypto-related files in the following locations. I'll take a detailed look into both repositories... Thanks! It makes the most sense to keep this exactly as it it, except for the files in src/sys/netinet6/ which should move to src/sys/crypto/ if they have crypto in them. Please do not import this until we (JDP!) gets the distribution channels crypto-happy. This is not difficult. itojun src/sys/netinet6/esp_output.c src/sys/netinet6/esp_input.c src/sys/netinet6/esp_core.c src/sys/crypto/cast128/cast128.c src/sys/crypto/cast128/cast128.h src/sys/crypto/cast128/cast128_cbc.c src/sys/crypto/cast128/cast128_subkey.h src/sys/crypto/blowfish/bf_cbc.c src/sys/crypto/blowfish/bf_cbc_m.c src/sys/crypto/blowfish/bf_enc.c src/sys/crypto/blowfish/bf_locl.h src/sys/crypto/blowfish/bf_pi.h src/sys/crypto/blowfish/bf_skey.c src/sys/crypto/blowfish/blowfish.h src/sys/crypto/des/des_3cbc.c src/sys/crypto/des/des.h src/sys/crypto/des/des_cbc.c src/sys/crypto/des/des_ecb.c src/sys/crypto/des/des_locl.h src/sys/crypto/des/des_setkey.c src/sys/crypto/des/podd.h src/sys/crypto/des/sk.h src/sys/crypto/des/spr.h -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days (at least outside the USA). The DoD, DoJ, DoE, DoC and watever other Do's you guys have are all passing the buck very fast nowadays. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Looking for good QA tests...
Therefore, I'm asking people to put their minds to work, and talk about valid tests that we could run to catch things that might slip through the cracks. I'm hoping that some of the long-timers can point out areas that have been missed before, and others to point out areas where they have seen local problems. As you are a networking outfit, I would imagine that you would be interested in two things: 1) Does the core OS still work, and 2) Does the networking still work? 1) Is usually well checkable with a "make world", and 2) could (I imagine) be well tested with a make world with NFS mounted disks, possibly using another FreeBSD box as a router for extra stress. Is this what you are looking for? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Looking for good QA tests...
Therefore, I'm asking people to put their minds to work, and talk about valid tests that we could run to catch things that might slip through the cracks. I'm hoping that some of the long-timers can point out areas that have been missed before, and others to point out areas where they have seen local problems. As you are a networking outfit, I would imagine that you would be interested in two things: 1) Does the core OS still work, and 2) Does the networking still work? 1) Is usually well checkable with a make world, and 2) could (I imagine) be well tested with a make world with NFS mounted disks, possibly using another FreeBSD box as a router for extra stress. Is this what you are looking for? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Looking for good QA tests...
Mmmm... No. _I_ (read: Not Cisco as a whole) am looking for tests that will help locate bugs pre-release copies of the OS so that there is still time for others to debug the code before Jordan cuts the release. Its more of a lets help the project by coordinating testing thing A regression test to make sure that the OS is not broken before you inflict it on your colleagues/engineers? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Looking for good QA tests...
Still too small a scope. How about A regression test to make sure that the OS is not broken before Jordan inflicts it on the world ? Athough it does not actively hunt down bugs, a NFS mounted, FreeBSD-routed build should stress enough of the system to disprove many serious problems. Inflicting it on standard idiots to check for install problems is a human-engineering aproach you could also take? Impossible to automate, though. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mandatory locking?
Now I suppose you're going to come and say that this is bad programming, and advisory locking would do the job if the software is written right. Correct. You could also use the same argument to say that memory protection isn't necessary, because a correctly written program doesn't overwrite other processes address space. It's the same thing: file protection belongs in the kernel. Well, I'd say advisory lock does the job if the software is written right, and if the software is not written right, mandatory locking won't help. Folk are all skirting around a very convenient (and necessary) loophole; in cases where there _is_ mandatory locking, there is always some meta-user which is allowed to violate this. In process-space, this is the kernel. In file-space, this should be root. Processes that require mandatory locking must revoke superuser before attempting locks. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: from number to power of two
Does anyone know an inexpensive algorithm (O(1)) to go from an number to the next (lower or higher) power of two. 1 - 1 2,3 - 2 4,5,6,7 - 4 8,9,10,11,12,13,14,15 - 8 etc. So %1101 should become either %1 or %1000. Shift a bit until it becomes greater than (or less than) the number in question. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
So are there any _objections_ to having the kernel match promiscuous "enabled" messages with "disabled" counterparts? I strongly _request_ such a log message. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
So are there any _objections_ to having the kernel match promiscuous enabled messages with disabled counterparts? I strongly _request_ such a log message. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Kerberos 5 integration.
Who were the parties that were heading up the Kerberos 5 integration? I have questions. Me. I will be bringiong in Heimdal (when it interoperates with MIT-K5). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kerberos 5 integration.
What do you think about moving all the current '#ifdef KERBEROS' to
'#ifdef KERBEROS4' and starting to integrate the '#ifdef KERBEROS5' bits
in ftp, telnet, rsh, rlogin etc? I don't see a reason to rip out the krb4
stuff and delay on the krb5 userland integration. Since the userland
stuff doesn't involve actual crypto code I think we're pretty safe no?
I have a better idea; PAM-ify everything (that can be pammed). The rest
of the stuff, I intend to do as you say.
I'd also be interested in hearing reasons for or against putting the krb4
specific stuff (kinit, klist whatever) in /usr/krb4, and the krb5 bits in
/usr/krb5. This would simplify the task of leaving krb4 in the tree.
Hmm. Methinks I might name the version-specific stuff k[45]${FOO}
for FOO in init, list, destroy, etc. Telnetd and FTPD should be
PAMmable, likewise the r.*d's. The userland ftp and telnets can
have both (Isuspect), and the r-utils also.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Kerberos 5 integration.
Who were the parties that were heading up the Kerberos 5 integration? I have questions. Me. I will be bringiong in Heimdal (when it interoperates with MIT-K5). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Kerberos 5 integration.
What do you think about moving all the current '#ifdef KERBEROS' to
'#ifdef KERBEROS4' and starting to integrate the '#ifdef KERBEROS5' bits
in ftp, telnet, rsh, rlogin etc? I don't see a reason to rip out the krb4
stuff and delay on the krb5 userland integration. Since the userland
stuff doesn't involve actual crypto code I think we're pretty safe no?
I have a better idea; PAM-ify everything (that can be pammed). The rest
of the stuff, I intend to do as you say.
I'd also be interested in hearing reasons for or against putting the krb4
specific stuff (kinit, klist whatever) in /usr/krb4, and the krb5 bits in
/usr/krb5. This would simplify the task of leaving krb4 in the tree.
Hmm. Methinks I might name the version-specific stuff k[45]${FOO}
for FOO in init, list, destroy, etc. Telnetd and FTPD should be
PAMmable, likewise the r.*d's. The userland ftp and telnets can
have both (Isuspect), and the r-utils also.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Kerberos 5 integration.
What is holding back the work in the userland stuff then? Time? No; the lack thereof ;-) The current rush of things crypto has piqued my interest, so I am hammering away quite hard these days. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Kerberos 5 integration.
The current rush of things crypto has piqued my interest, so I am hammering away quite hard these days. Well, would it be useful for me to commit the KERBEROS - KERBEROS4 changes? Er, no; please submit them to me as patches. :-) Thanks! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: SRA+IDEA Telnet
Couldn't you work the code so it obtains all its' encryption functions from an external library, such as the system's libdes? That would let you export the code, since it doesn't provide any encryption functions itself, and international people could use the international DES library (for other encryption algorithms, pick a freely available implmenetation such as the one from openssl). This makes the most sense. Thrash it out as a port, and if that works, we can bring it into both repositories. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SRA+IDEA Telnet
Couldn't you work the code so it obtains all its' encryption functions from an external library, such as the system's libdes? That would let you export the code, since it doesn't provide any encryption functions itself, and international people could use the international DES library (for other encryption algorithms, pick a freely available implmenetation such as the one from openssl). This makes the most sense. Thrash it out as a port, and if that works, we can bring it into both repositories. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Review please] (was: Re: cvs commit: src/gnu/usr.bin/man/manpath manpath.config)
DES, Mark, -hackers! How about the following patch. It adds an OPTIONAL_MANPATH directive, which is equivalent to the MANDATORY_MANPATH, except an absence of the directory is not considered an error. Cool! Do it, I say! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: SRA+IDEA Telnet
Why not just wait and bring the openssl library in? Er - I do't think that will happen. Not for a while. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
This is a clear security vs functionality issue and I need to get a good feel for which cause is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? I am pro. It takes a root compromise to use it anyway, and its usefulness for DHCP and rarpd is too compelling. Perhaps the comments in the GENERIC file could be updated. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: file(1) Magdir candidate: wintendo
So I propose a new file wintendo, for all gaming file formats used on the MS Windows platform. Wintendo is a bad name for anything official. Try to find MS's official name for the format(s). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 22:17:20 +0200, Mark Murray wrote: Wintendo is a bad name for anything official. Try to find MS's official name for the format(s). You're hoping for a standard name for file formats of games used on Microsoft platformat? There are two words in that question that one doesn't usually fine together in a sentence that doesn't contain the word bastardize. :-) You could start with WinEXE. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
Sue Blake wrote: Nobody seems to be confident about the answer to my post to -questions. Below is the only public answer. It is typical of many private answers I received from otherwise knowledgeable people willing to make a partial educated guess but not willing to expose their ignorance publicly. They're all keen to know whatever I can find out :-) The usual use of the term "sandbox" means "restricted environment". A chroot(3) can be used to build this, and jail(3) is a stronger version, although this is not a usual use for the term. The term is popular in Java where it it implies that the (possibly hostile) applet _cannot_ do anything dangerous, because the environment it runs in has no API that allows this (like the applet cannot open arb files). The term "sandbox" in inetd.conf refers to a "su - safe_user; chroot safe_dir; app" environment (I think) so that app cannot do any damage even if compromised. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandbox??
Sue Blake wrote: Nobody seems to be confident about the answer to my post to -questions. Below is the only public answer. It is typical of many private answers I received from otherwise knowledgeable people willing to make a partial educated guess but not willing to expose their ignorance publicly. They're all keen to know whatever I can find out :-) The usual use of the term sandbox means restricted environment. A chroot(3) can be used to build this, and jail(3) is a stronger version, although this is not a usual use for the term. The term is popular in Java where it it implies that the (possibly hostile) applet _cannot_ do anything dangerous, because the environment it runs in has no API that allows this (like the applet cannot open arb files). The term sandbox in inetd.conf refers to a su - safe_user; chroot safe_dir; app environment (I think) so that app cannot do any damage even if compromised. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: rndcontrol and SMP
What is needed to make this support a more sensible number of IRQs? Mainly changing the ioctl and its clients (rndcontrol only?) to supply more bits. I am currently rewriting /dev/random (and rndcontrol). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Base Kerberos 5 support?
I would love to see krb 5 made part of the standard distribution. BEST has been using it for several years now with no problems and I believe that it is a whole lot easier to administrate then krb 4. I have Heimdal commit-ready (this has been the case for a year). I am waiting for it to be more compatible with MITK5. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
Quoth "Keith Stevenson": (Mark Murray: jump in here if I get this wrong) The way I understand it, a PAM module (pam_unix?) would need to be able to look at the password hash and figure out which of the crypt functions to call. Ideally, the PAM configuration would be able to specify which crypt functions are valid for the system. I'm sure this could be done. I'm not sure that it is PAM's job. I'll look at it. That said, one of the very attractive features of specifying the crypt function in the login class is the ability to assign different crypt algorithms on a user by user basis. ...or group... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rndcontrol and SMP
When you say rewriting, do you mean syncing with the version of the code in Linux (1.04, instead of our 0.95) or actually rewriting? If the latter, I'm curious as to what your aims are. I want to implement Bruce Schneier's Yarrow. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rndcontrol and SMP
What is needed to make this support a more sensible number of IRQs? Mainly changing the ioctl and its clients (rndcontrol only?) to supply more bits. I am currently rewriting /dev/random (and rndcontrol). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Base Kerberos 5 support?
I would love to see krb 5 made part of the standard distribution. BEST has been using it for several years now with no problems and I believe that it is a whole lot easier to administrate then krb 4. I have Heimdal commit-ready (this has been the case for a year). I am waiting for it to be more compatible with MITK5. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD
Quoth Keith Stevenson: (Mark Murray: jump in here if I get this wrong) The way I understand it, a PAM module (pam_unix?) would need to be able to look at the password hash and figure out which of the crypt functions to call. Ideally, the PAM configuration would be able to specify which crypt functions are valid for the system. I'm sure this could be done. I'm not sure that it is PAM's job. I'll look at it. That said, one of the very attractive features of specifying the crypt function in the login class is the ability to assign different crypt algorithms on a user by user basis. ...or group... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: rndcontrol and SMP
When you say rewriting, do you mean syncing with the version of the code in Linux (1.04, instead of our 0.95) or actually rewriting? If the latter, I'm curious as to what your aims are. I want to implement Bruce Schneier's Yarrow. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 22:34:09 +0200, Mark Murray wrote: As long as the documentation is _clear_ that this is not a front-line security tool, but rather a thing to marginally augment logs with user-supplied info, then I'll buy it. This is why I put forward a motion to move pidentd out of security and into net / sysutils last year. The suggestion wasn't well received, but I still think it'd help. I'd also like for the DESCR file for the port to say: This service offers remote users some identity to report back to the local admin when complaining about abuse / break-ins originating from the local host. This issue is way to religious. As long as folk don't do anything blatantly stupid, and as long as the caveats are well documented, it is probably a good idea to just let this one stand, and lean on it gently :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
