OpenBSD 5.7 highlights
tedunangst.com
tedunangst.com
[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.
1 http://www.tedunangst.com/flak/post/the-wiki-box-is-out-of-c...
"Check me out with CVS!"
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.
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.
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.
Does this mean we might finally get IPv6 and DHCP support enabled by default? Currently dhcpd does not support IPv6
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.
More here... https://github.com/libressl-portable/portable/issues/36
https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-05
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?".
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.
[1] https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00