I’ve updated my binpatch page to include binpatches for OpenBSD 4.3 (i386 and amd64 only, right now).
I will continue for a while to create binpatches for both 4.2 and 4.3 until it becomes too much work.
At some point soon, I’ll start supporting sparc64 4.3 binpatches.
The OpenBSD team released an OpenBSD 4.2 Errata entry for OpenSSH: 011_openssh2.
It is a SECURITY fix. The description is:
Avoid possible hijacking of X11-forwarded connections with sshd(8) by refusing to listen on a port unless all address families bind successfully.
I’ve made binpatches for i386, amd64 and sparc64.
The OpenBSD team released Errata entries 009_ppp and 010_openssh for OpenBSD 4.2.
Both are SECURITY fixes.
For 009_ppp, the description is:
Buffer overflow in ppp command prompt parsing.
For 010_openssh, the description is:
sshd(8) would execute ~/.ssh/rc even when a sshd_config(5) ForceCommand directive was in effect, allowing users with write access to this file to execute arbitrary commands. This behaviour was documented, but was an unsafe default and an extra hassle for administrators.
I’ve made binpatches for i386, amd64 and sparc64.
It appears that some people have difficulty unsubscribing from mailing lists on my server. Perhaps this is because of the anti-spam measures I have on my server.
Fighting spam takes a ridiculous amount of my time. I employ several methods of preventing the delivery of spam to this list and to the mailboxes on my server. Among these are blacklisting and greylisting.
With blacklisting, I use several methods to obtain lists of known spammers and tarpit those hosts. (See OpenBSD’s
spamd(8) for more info) If you have having problems sending emails to this list, the list manager (to un/subscribe) or me, perhaps your server landed on a blacklist.
With greylisting, if my server hasn’t recently “talked” to your server, your server gets a temporary failure message. If your server retries in 30 minutes (the standard), your message will be accepted. Many large email providers use broken methods to deliver mail. They use a pool of SMTP servers that rotate on retries. Since greylisting uses the IP address of the sending server (along with the sender email address and the recipient email address) to determine when a message should be delayed or delivered and these pools use different IP addresses for each host, it is theoretically possible that the message NEVER gets delivered if the pool doesn’t retry with the same IP address within the timeout period. For large known providers, I make an effort to whitelist their pools, but not all providers make that information easily accessible. Usually the downside to greylisting is that your message takes ~30 minutes to be delivered. It sucks when I place an online food order and don’t get the confirmation email for ~30 minutes (and their system ate the order and we assumed it was on the way).
If you are trying to contact me and my server is simply not receiving your messages, leave a comment to a post on my site. Comments are moderated and I’m a clever guy and should be able to figure out that you don’t actually mean for that comment to be made public. But if you’re concerned that I may not understand, put in the comment that you tried to email me and it didn’t work, please don’t publish this comment, …
The OpenBSD team released an Errata entry 008_ip6rthdr for OpenBSD 4.2.
Quote from the henning@’s commit message:
MFC (mcbride) Correctly check that we have a complete rthdr before trying to do m_copydata() on it.
I’ve made binpatches for i386, amd64 and sparc64.