delphij's Chaos

有个疑似 OCD 患者最近抽风升级了一下 MySQL 数据库，然后发现 blog 里面全都变成了乱码。

那乱码的模式一看就是把 utf8 直接扔进了 latin1 的数据库，一看 SHOW CREATE TABLE mt_entry 发现果然如此。

略有些慌神，看了 MySQL 文档发现用 ALTER TABLE 的 CONVERT TO 硬来有点不太行好，遂想到可以试试看 mysqldump，于是做了：

当作 latin1（不然会再按 utf8 编码一次）：

mysqldump mt_delphij --default-character-set=latin1 -r utf8.dump

把里面的 CHARSET=latin1 替换为 CHARSET=utf8：

sed -e s,CHARSET=latin1,CHARSET=utf8,g < utf8.dump > utf8.dump.edited

删掉其中的 SET NAMES latin1。

然后重新导入：

mysql -uroot -p --default-character-set=utf8 mt_delphij
mysql> SET names utf8;
mysql> SOURCE utf8.dump.edited;

还好没用到 zfs rollback。

razor 同学对于 Xcode ghost 的事情的评价是：这也太不注意卫生了。个人深以为然。

技术细节、影响等等，已经有很多大牛写过很好的文章来介绍。但是我想问的是，这事完了吗？在我看来远远没有，根据有关厂商的介绍，想要装上这个下了马的 Xcode，首先得从 App Store 以外的渠道去下载，其次还得允许运行来自 'Anywhere' 的应用程序，或者开发人员习惯于绕过系统的数字签名检查。

我看到的至少有这么两个问题：1. 开发人员常态化地使用并忽略未经签名的工具（非常不重视卫生，我认为这个事情基本上和一个厨师在上班时间去上厕所，回来工作之前不洗手是一样的性质）。2. 具有这种态度的开发人员同时拥有发布权限（管理者玩忽职守）。

我认为基本上这次出现问题的 iOS 应用开发者都应该进行特别标记，并改进其发布流程之后才允许继续发布新的应用程序。自然，每一个直接导致问题的开发者都是负有责任的，但允许这样问题出现，并在事后用公关稿文过饰非的企业及其管理者更有责任。这种攻击已经持续了数月，到底有多少不同的版本受到影响？也许只有 Apple 能够提供相关数据了。

当然，对于手机应用安全厂商来说，也许这是一次难得的商机，因为 iOS 设备用户和 Apple 之间的信任被这种攻击直接打破了。事实上，国内某前越狱团队已经制作了一款采用企业证书的扫描程序（我并不怀疑该团队提供这样的程序是出于好意，但出于谨慎，个人建议不要使用，因为我们并不知道该团队手中是否拥有更多提权漏洞，或者后续版本是否会做一些其他事情）。

对于最终用户而言，我认为现在应该做的是立即删除非必要的全部应用程序，特别是那些存疑或已经知道出现过问题，而在其公关稿中淡化问题，而没有提出对前面两个问题解决方案的开发者开发的软件，并在确认手机中没有问题应用之后重新设置全部密码。

今天的一个偶然的发现。FreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525。clang 3.8 2015/07/20 的版本同样有此问题。

之前， FreeBSD 上 strndup(3) 的实现是这样的：

char *
strndup(const char *str, size_t n)
{
	size_t len;
	char *copy;

	len = strnlen(str, n);
	if ((copy = malloc(len + 1)) == NULL)
		return (NULL);
	memcpy(copy, str, len);
	copy[len] = '\0';
	return (copy);
}

而 OpenBSD 上的实现，则是这样的：

char *
strndup(const char *str, size_t maxlen)
{
	char *copy;
	size_t len;

	len = strnlen(str, maxlen);
	copy = malloc(len + 1);
	if (copy != NULL) {
		(void)memcpy(copy, str, len);
		copy[len] = '\0';
	}

	return copy;
}

今天搞了一个 大新闻。如果你用BIND并且今天之前没打过补丁的话，请读到这里为止，立即去补吧。

我觉得还是得提高知识水平。做 freebsd-update 补丁的时候，赫然发现修改的文件中有一个不认识的：

world|base|/usr/bin/slogin|f|0|0|0555|0|3d4103fa290ca0dcd32fc1f9775e860a4bbf4af7e2be80e835217cd560cb100e|

当时就慌了！我明明没改啥库啊？ldd看一下：

/usr/bin/slogin:
	libprivatessh.so.5 => /usr/lib/libprivatessh.so.5 (0x800849000)
	libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800ada000)
	libcrypto.so.7 => /lib/libcrypto.so.7 (0x800ce3000)
	libc.so.7 => /lib/libc.so.7 (0x8010da000)
	libprivateldns.so.5 => /usr/lib/libprivateldns.so.5 (0x801482000)
	libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016de000)
	libz.so.6 => /lib/libz.so.6 (0x8018fe000)

还用了 Kerberos，等等，ssh？man slogin出来一个SSH的manpage，一个字没提slogin的事情。

ls -li一看才恍然大悟：

4574 -r-xr-xr-x  2 root  wheel  179000 Jul 19 00:19 /usr/bin/slogin
4574 -r-xr-xr-x  2 root  wheel  179000 Jul 19 00:19 /usr/bin/ssh

原来是马甲......

phk 老大如此 吐槽：

One week until the leap-second. If you haven't tested your IT-system already, it is too late now. Good luck if you're in California or Japan.

背景

关于时间，A core 几年前写过一个 时间是什么？ 的系列： 序言 续一 续二 续三。

为了兼顾天文观测获得的时间 UT1 （更符合普通人的需要）和由铯-133原子震荡获得的时间 TAI （更稳定），将两者综合一下就获得了协调世界时 UTC。UTC 和 UT1 之间的差距永远保持在 1 秒以内。UTC 中的一秒和 TAI 相同，但 UTC 和 UT1 保持最多一秒的差距，这是通过 IERS 在 UTC 事件中人为插入或减少闰秒这样的人为调整来实现的。从1972年这套系统投入运营到今天为止，总共插入了35个闰秒（2015年6月30日还将再插入一个闰秒）。

闰秒只在每年的6月30日和12月31日的UTC时间 23:59:59 之后插入，表示为当天的 23:59:60。

作为十几年的 tcsh 拥趸，我最近改信了 zsh。

基于 Robby Russell 的 Oh My ZSH 搞了一套自己的 Oh My ZSH，可以用 ZSH_THEME="delphij" 来启用我的配置，其外观、行为大致与我之前的 csh 配置相同。

经过PGP签名的tag版本可以在 这里 找到（请自行使用安全的方法获得我的PGP公钥）。

安装方法(假定当前shell是zsh或sh或bash）：

$ ZSH=~/.oh-my-zsh
$ git clone --depth=1 --branch=delphij-20150522 https://github.com/delphij/oh-my-zsh.git $ZSH
$ cd $ZSH
$ git tag --verify delphij-20150522
# 以上复制一份tag过的 Oh My ZSH 并验证其签名。
# 如果有之前的.zshrc请自行备份。
$ cp $ZSH/templates/zshrc.zsh-template ~/.zshrc
$ sed -i '' -e "/^export ZSH=/ c\\
export ZSH=$ZSH
" ~/.zshrc
$ sed -i '' -e "/export PATH=/ c\\
export PATH=\"$PATH\"
" ~/.zshrc
# 以上使用模板覆盖.zshrc并复制已有的PATH配置。
chsh -s `which zsh`
# 将shell改为zsh

需要注意的是，由于 zsh 并非系统自带的 shell，因此保留一个非 zsh 的 root 账户会是个好主意。

许久不碰反垃圾邮件的事情了，一来前段时间垃圾邮件确实也没有那么多，加上spamassassin确实相当有效，二来也是因为犯懒。

不过，最近几天垃圾邮件明显比平时多了许多，所以决定坐下来仔细处理一下。

OpenBSD 的 spamd 是一个反垃圾邮件陷阱软件，它的主要功能是灰名单（SMTP协议要求客户端在一段时间之内重试投递），但又有一个个人很喜欢的特性：以极慢的速度回应发送垃圾邮件的服务器（默认配置为1秒一个字符，最高可以到10秒一个字符）。对发送垃圾邮件的人来说，这样做会显著地降低他们发出垃圾邮件的能力。

结构上，spamd 会修改服务器上的防火墙的转发规则中的地址，简而言之，是维持一份动态的白名单（由通过了灰名单测试的IP形成），所有不符合白名单的IP都转到 spamd 处理。如果符合白名单，则直接正常转到MTA去处理。

简单记一笔配置。

由于我的机器内存够用，所以将 spamd 配置为最大拖住1024个连接。灰名单最短等待期设置为 1 分钟，灰名单过期时间设置为 4 小时；白名单过期时间设置为 36 天。

选择的黑名单是uatraps和nixspam，各自用本地白名单做补。此外，本地另设一黑名单。

启动spamd服务并更新pf规则。接下来用：

grep 'Passed CLEAN {AcceptedInbound}' maillog* | \
cut -f3 -d[ | cut -f1 -d] | grep -v : | sort | uniq -c | \
sort -n | awk '{ if ($1 > 20) print $2; }' | sort -n | \
xargs spamdb -a

来将过去几天的 Amavisd 认为没问题的地址加入本地白名单。

最后可以用 spamdb -Ta 来添加一些陷阱地址。陷阱地址是那种故意流出，但绝不应该收到邮件的地址。

我有一心得和大家分享一下，话说三个人一起坐一电梯上，其中一个一直跳一直跳，一个蹲在角上一直祈祷，一个满地打滚手脚抽搐，最后都到了十二楼，若干年以后有人问为什么您能到楼上啊？第一个人说，我坚持不懈的努力，和大自然对抗，力竭也不放弃，最终达到了这个巅峰，第二个人说，我真诚而且坚持，我坚持自己的信仰从未忘记初心，第三个人说，我反直觉反传统反对一切，于是创造了完全不可思议的结果。我看很多商业书籍就这感觉，你们几位不聊聊电梯这事到底几个意思？

今天 John-Mark Gurney 修正了一个影响过去4个月左右的 FreeBSD -CURRENT 的随机数发生器问题，具体受影响的版本是 r273872（引入问题）到 r278907 （修正）。

由于问题只影响 -CURRENT，因此我们不会就此发表安全公告。

问题的影响：在对随机数发生器 （/dev/random）进行重构的过程中，原先为内核 arc4random(9) API 进行初始化(seeding)的部分没有正确地在新的随机数处理器上线(randomdev_init_reader)时进行配置，导致内核一直使用 dummy RNG 来生成 arc4random(9) 的种子。由于 dummy RNG 的输出范围有限（大约 2^30），导致 arc4random(9) 的输出容易预测。

由于 arc4random(9) 同时也用来在用户态代码中产生随机数种子，因此这个问题也连带影响了用户态的随机数生成(由于 arc4random(9) 在内核中被广泛使用，因此或多或少地减弱了这个问题的实际影响，但我们建议用户不要因此而产生侥幸心理)。

我们建议使用这些版本的 FreeBSD -CURRENT 的用户 立即 升级到最新的 -CURRENT，同时销毁并重新生成在这段时间内生成的全部私钥。

翻了个船，记一笔。题目如题。

对口相声选段：Node.js Is Bad Ass Rock Star Tech。视频：

p1: And in conclusion we have found Apache to be an excellent server for our web applications. Any questions?

p2: Yes, I have a question. Why didn't you use node.js? node.js is an event driven, non-blocking IO server that can be used to build high-performance web applications.

p1: That is an excellent question. We evaluated several alternative web servers and concluded, that while options like node.js are very interesting, Apache meets our needs and has a solid track record.

p2: But it doesn't have performance. Everybody knows that Apache applications are slow because they use blocking IO and have context switches.

p1: That's a commonly held belief that threaded web servers are somehow less performant or as scalable than event based servers. In fact, if you measure carefully, you will find that both models have similar performance characteristics.

p2: Threads don't scale. Simple as that.

将近三年前搬家的时候买了一台三星 WF350ANW/XAA 洗衣机，结果上周发现门合不上了。上网找到了 这个视频，发现更换并不麻烦，打电话给三星，对方说已经过保，于是决定自己动手修理一下。

首先是断开电源和水源。

拆解比较简单：首先用尖嘴钳从洗衣机下部胶皮中将弹簧拽出（这是一个细金属丝＋弹簧构成的圈，用来箍住橡胶皮隔水圈），然后小心将橡胶隔水圈拆开。接下来把门锁的螺丝拧掉，然后把它取出（有连接线）。

首先将外面的塑料外壳卸下（有两个比较重要的塑料卡隼）。接下来将连接的线断开。

拆下来以后，发现最下面的螺丝所在的位置的塑料裂开了，同时在这个地方发生了比较严重的开裂。

由于是受力的地方，而采用的材料是较为廉价的塑料，因此可以预见这个部件在未来还是会发生问题。

安装过程基本是拆解过程反过来，其中比较费力的部分是将金属圈装回的部分，基本上要把圈上到3/5左右，剩下的部分用 iFixIt 套件中的 Spudger 在两侧同时用力来装上。