Regarding: "The etc sets are now gone. All the sample /etc files are now included in the base set. This should make sysmerge must [sic] easier and faster in the future, since there will be many fewer conflicts to resolve. On the other hand, even rc and rc.conf are now overwritten, so it’s not possible to maintain local mods without additional work. This makes sense, though, since /etc/rc is as much a part of the base system as /sbin/init. You don’t want to be running a five year old edition."
I thought (and the manpages always indicated) that the rule was that /etc/rc and /etc/rc.conf were fair game, and that if you wanted to make changes that weren't overwritten by a system upgrade, to put them in /etc/rc.local and /etc/rc.conf.local. I'm unclear why this is considered a problem.
It is, I read flak as often as Ted publishes something new and I never saw that. Couple that with the fact that Ted loves to rant[1][2] about bad UI design, especially on the web, and it becomes obvious that his latest "feature" will be gone tomorrow.
> I thought (and the manpages always indicated) that the rule was that /etc/rc and /etc/rc.conf were fair game, and that if you wanted to make changes that weren't overwritten by a system upgrade, to put them in /etc/rc.local and /etc/rc.conf.local. I'm unclear why this is considered a problem.
For the most part that's true, but /etc/rc.local is run fairly late, so if you have a sufficiently-crazy setup you might have to edit /etc/rc.
For example, before softraid crypto was integrated into the bootloader I modified /etc/rc to prompt for the keyphrase before it tried to mount the disks.
Understood - but, at least you have been forewarned by the man pages, that any changes you've made to /etc/rc are going to have to be carried forward, because after an upgrade, /etc/rc will be wiped and set to the operating system version.
I'm a basic novice when it comes to OpenBSD (But a huge fan), and that, in addition to discovering that you keep all the old versions of every library ever installed when upgrading, where two things that I had been taught - so I presume that the knowledge was universal.
Base libraries are not removed automatically but libraries from packages are (though sometimes they stay in limbo as .libs- package, e.g. if pkg_add is interrupted).
It stopped for me after I closed the window in disgust.
Internet Jackass Day is bad enough on a fundamental level, but when your jackass behaviour gets in the way of people's actual tasks (and there's no way to say 'stop this BS'), you're not being funny.
According to http://www.openbsd.org/57.html "IPv6 router solicitations are now sent by the kernel ("inet6 autoconf"); rtsol(8) and rtsold(8) are no longer necessary and have been removed."
Does this mean we might finally get IPv6 and DHCP support enabled by default? Currently dhcpd does not support IPv6
IPv6 is not enabled by default. It is compiled in the kernel, but interfaces don't get an IPv6 link-local address if you don't explicitely say so. When you enable IPv6, you get a link-local address, send router solicitations and process router advertisements ("IPv6 autoconfiguration"). Router advertisements carry the prefix information, and the gateway address, as well as a DNS resolver. The latter is not always processed. It does not happen on Windows 7, on Linux you need to install rdnssd and I'm fairly sure it's the same case with the various BSDs.
Sometimes, this is not enough to get global IPv6 connectivity. The router advertisement has a flag that can indicate that the host must/can request additional information through DHCPv6. While similar to DHCP, DHCPv6 is quite a different protocol; therefore you need a separate client (or you need to merge it in your DHCP implementation; much like ISC's dhclient does with the -4/-6 command line flag).
So no, OpenBSD ships with IPv6 support as well as DHCP support. it's just that IPv6 is not configured by default, and IPv6 and DHCP have little to do with each other.
It popped up something which took three seconds to scroll in. Then disappeared. Then when I found my place again it popped up another one. Then it went away, and I tried to figure out where I was on the page. And then it happened again and I closed the window.
I really like the support for tls in syslogd. Unfortunately it looks like it is not yet supported server-side. At least in current, syslog.conf(5) doesn't mention anything about specifying a private key.
I don't know too much about it but it's a LibreSSL compatibility feature to stay compatible with OpenSSL. Basically it's a mechanism for client software to fall back to reduced encryption when better options fail. Considering their stance on security I can see why the OpenBSD guys look at this as a bad idea. But on the other hand if they want people to adopt LibreSSL some "compatibility over maximum security" choices have to be made.
A client sends a ClientHello trying to connect with TLS 1.2, MITM does not let that through, the client sends a ClientHello for TLS 1.0 with a signal that means "this is a fallback", the MITM lets that through, the server sees this and does not allow a connection, foiling the attempted downgrade attack.
I know that, that's why I asked: "Why is SCSV a sucky feature?".
OK, my bad, I just checked the RFC[1] and reading it agrees absolutely with what you are saying.
I am probably misunderstanding the thread I linked to in my OP but reading through it (I remembered seeing this a while ago when I read your question) I got the impression that the LibreSSL guys looked at it from the opposite angle.
From my link:
TLS_FALLBACK_SCSV is only useful in the case where a client willingly chooses to do a downgrade and attempts to establish a second connection at a lower protocol after the previous one unexpectedly failed. In short, the client should not do this - client-side fallback is dangerous ("a landmine" to quote agl). TLS_FALLBACK_SCSV only works if both ends support it and it is largely a case of adding a workaround to support/enforce insecure behaviour. Unless you control both ends, you cannot be sure TLS_FALLBACK_SCSV is available and if you do control both ends you can either force TLS 1.2 and/or avoid client-side downgrade.
And the final reply:
Server-side TLS_FALLBACK_SCSV support has reluctantly been added to LibreSSL.
I guess in the end the reluctance is more about it being new and untested and not so much a bad security practice.
Interesting in that "want people to adopt" has never been a stated objective for OpenBSD that I've seen. It's more like "we build what we're interested in, and if it solves a problem for you too, that's great."
[edit - it stops after a while]
Regarding: "The etc sets are now gone. All the sample /etc files are now included in the base set. This should make sysmerge must [sic] easier and faster in the future, since there will be many fewer conflicts to resolve. On the other hand, even rc and rc.conf are now overwritten, so it’s not possible to maintain local mods without additional work. This makes sense, though, since /etc/rc is as much a part of the base system as /sbin/init. You don’t want to be running a five year old edition."
I thought (and the manpages always indicated) that the rule was that /etc/rc and /etc/rc.conf were fair game, and that if you wanted to make changes that weren't overwritten by a system upgrade, to put them in /etc/rc.local and /etc/rc.conf.local. I'm unclear why this is considered a problem.