Re: fun with smtpd, (two bugs)
Jason McIntyre wrote, On 05/15/14 13:54: the man page sates that: Both auth and auth-optional accept an optional table as a parameter. When provided, credentials are looked up in this table. but reading the new smtpd.conf(5) gives the impression that authtable is mandatory. I haven't checked the code but the following passes a check with smtpd -n listen on iwn0 tls auth listen on em0 tls auth-optional so it seems to be a valid syntax. it's why i added the word optional to the description. the syntax [table] is really ugly, and is hard to understand. we could do it, but i don;t want to. sometimes it's better to sacrifice being a million percent correct for clarity. The syntax may be ugly, but the vagueness for a novice such as myself is confusing. I wasted an hour with this exact issue the other day. I was looking for the problem in all the wrong places. I thought my certs were bad, my pki declaration was wrong, my email client was misconfigured. Finally, I decided to try around my table name. Voilà! The documentation is inconsistent and that's what threw me off. In smtpd.conf(5) on OpenBSD 5.5 for example, the listen on directive has the option auth authtable where the angle brackets are implied. But the accept | reject directive has the option for [!] domain domains [alias aliases] where the angle brackets are explicit. It should be exclusively one way or the other. If [table] is too ugly, then suffix all table place holders with table. So for example, the accept | reject directive I mentioned above would become for [!] domain domaintable [alias aliastable]. Then make a note that all place holders/variables must be encloded by angle brackets. Personally, I don't like that solution. I think being explicit with the syntax is the correct solution. It doesn't matter if it is ugly; it's the syntax that smtpd uses so it should be documented as such.
Re: fun with smtpd, (two bugs)
Jason McIntyre wrote, On 06/07/14 00:51: On Sat, Jun 07, 2014 at 12:22:35AM -0700, Clint Pachl wrote: Jason McIntyre wrote, On 05/15/14 13:54: the man page sates that: Both auth and auth-optional accept an optional table as a parameter. When provided, credentials are looked up in this table. but reading the new smtpd.conf(5) gives the impression that authtable is mandatory. I haven't checked the code but the following passes a check with smtpd -n listen on iwn0 tls auth listen on em0 tls auth-optional so it seems to be a valid syntax. it's why i added the word optional to the description. the syntax [table] is really ugly, and is hard to understand. we could do it, but i don;t want to. sometimes it's better to sacrifice being a million percent correct for clarity. The syntax may be ugly, but the vagueness for a novice such as myself is confusing. I wasted an hour with this exact issue the other day. I was looking for the problem in all the wrong places. I thought my certs were bad, my pki declaration was wrong, my email client was misconfigured. Finally, I decided to try around my table name. Voil?! but that is not down to my not wrapping authtable in [], right? The documentation is inconsistent and that's what threw me off. In smtpd.conf(5) on OpenBSD 5.5 for example, the listen on directive has the option auth authtable where the angle brackets are implied. But the accept | reject directive has the option for [!] domain domains [alias aliases] where the angle brackets are explicit. i don;t know how it looked in 5.5., but it is explicit now. It should be exclusively one way or the other. If [table] is too ugly, then suffix all table place holders with table. So for example, the accept | reject directive I mentioned above would become for [!] domain domaintable [alias aliastable]. Then make a note that all place holders/variables must be encloded by angle brackets. Personally, I don't like that solution. I think being explicit with the syntax is the correct solution. It doesn't matter if it is ugly; it's the syntax that smtpd uses so it should be documented as such. ok, here's what's there now: [auth | auth-optional authtable] ... Both auth and auth-optional accept an optional table as a parameter. i really don;t see the problem. still, i will add [] just now, ok? jmc You're right, I apologize. I just consulted the current smtpd.conf(5) via openbsd.org and the man page looks much improved since OBSD 5.5 release. Thanks Jason.
Re: pkg_delete recursive uninstall option
Luis Useche wrote: I implemented this option for the pkg_delete that remove all the 'non-used' dependencies of all packages you are deleting. It first check that the package is not a dependency of another installed package and it was not installed manually. I usually remove the diff between manually installed pkgs and all top-level pkgs, then repeat until there is no more diff. But this always seemed so ad-hoc. This feature Useche submitted would make my life slightly easier and keep my system cleaner while being less error prone.
Re: Allegations regarding OpenBSD IPSEC
Salvador Fandiqo wrote: On 12/23/2010 06:39 AM, Marsh Ray wrote: On 12/22/2010 03:49 PM, Clint Pachl wrote: Salvador Fandiqo wrote: Could a random seed be patched into the kernel image at installation time? Admittedly this is not entropy, this is a just secret key and anyone with access to the machine would be able to read it, How is it different than any other installation file then? because it is accessible *before* any filesystem is mounted, from second 0 of the boot process. This reminds me of something. The last time I installed FreeBSD about 5 years ago, it asked me to pound on the keyboard for like 60 seconds during installation (or at first boot, can't remember) in order to build up some randomness. I wonder what kind of entropy that provided?
Re: Allegations regarding OpenBSD IPSEC
Salvador Fandiqo wrote: On 12/22/2010 01:46 AM, Theo de Raadt wrote: 2010/12/21 Theo de Raadtdera...@cvs.openbsd.org: HANG ON. Go look at the function random_seed() in /usr/src/etc/rc Then look at when it is called. so, the current state of the PRNG will be preserved during reboots. That statement is false. Good. No. You misread the code. That gives some information about system entropy, which will be good at all times, except for the very first boot of an installation. See : rnd.c: randomwrite() - add_entropy_words(); That part is true. But what you said earlier is false. However, arc4_stir will still be called once after every reboot. During its first call, the value of nanotime() will be placed at the beginning of buf, which is then beeing used to init the rc4 context. What else do you think we should use? Where do we invent entropy from when the kernel has only been running for 0.01 of a second? Could a random seed be patched into the kernel image at installation time? Admittedly this is not entropy, this is a just secret key and anyone with access to the machine would be able to read it, but from the outside, specially considered that machines are not rebooted so often (and when they are, it is usually for updating them), it would look like real random data. Now that it's amateur suggestion hour (no offense Salva), I'm going to take a shot. Would it be possible to use what randomness the system does have to seed some reader that pseudo-randomly reads arbitrary bits from the loaded kernel image in RAM? This may differ per system, but doesn't uninitialized RAM start in an unknown state? If so, could that be added to the entropy pool if it is determined to be random (i.e. not initialized to zeros)?
