Bruce Evans (bde@)，那个愿意花时间在你改了三行看似无关紧要代码的时候写上整整两页回信细数为什么这么做不对，之前他们还做过什么以及为什么那么做也不行的老爷子在上周（12月18日）突然去世了。我已经开始想念他了。
RIP。
Google 在十年前提出了一套名为 BeyondCorp 的零信任网络的安全方案。 这套方案想要完整地实现还是有一定门槛的，在这种模型下，企业内网不再作为一个安全边界存在，相反即使在内网进行的访问也必须进行和外网同样的鉴权与访问控制。 最终的改造方向是内网不再是一个特权网络，每个终端上部署的客户端证书主要是作为一项身份信息来使用。
在 BeyondCorp 方案中对用户比较可见的一项便是统一登录认证 SSO 和基于用户身份进行访问控制的反向代理。之前考虑过许多其他方案，包括使用 nginx 自己山寨一套，不过后来听 @yegle 同学的建议， 直接用 Pomerium 来实现了一套鉴权反向代理，这里把大致过程记录一下。
首先是安装。 FreeBSD 没有对应的 port，于是 做了一个。新用户可以直接用 pkg install pomerium 来安装了。
必须配置的一些选项包括 pomerium_enable （显然）。如果使用 Pomerium 来的做 https 服务，那么还需要配置 pomerium_cert_file（指向一个 wildcard 证书）和 pomerium_cert_key_file。除此之外， pomerium_shared_secret 和 pomerium_cookie_secret 应分别设置为两个随机串，不过如果没设置的话系统会自动每次启动时生成新的随机串。需要注意的是，假如需要使用标准的 https 端口 443，如果以系统默认的非特权用户来运行 Pomerium 的话，需要将 net.inet.ip.portrange.reservedhigh 设为小于 443 的值才行。
然后是配置。OAuth 2.0 需要一个回调 URL，Pomerium 中这个可以是 https://authenticate.corp.{example.com}。在 IdP （如 Google、Azure等等）完成身份验证之后，IdP会将用户转回这个URL完成后续的设置。
IdP相关的主要设置是 idp_provider、idp_client_id 和 idp_client_secret，后两项信息要从 IdP 那里获得。如果 IdP 提供了群组功能，可能还需要进行一些额外的设置，例如 G Suite 就要求服务账户必须能够以某种管理员的身份运行。
代理方面，在代理服务器后面受其保护的服务器应 验证 Pomerium 的请求头签名。除此之外，代理的配置其实是很简单的，如果是比较小的系统，用 allowed_users 就足够了。大一些的系统可以用 allowed_domains 和 allowed_groups。另一个潜在的坑是要注意后端服务器不要在做 redirect 时回自己的 URL，如果发生这种情况，需要把后端服务改对或者至少搞一层重写。
许多操作系统会默认系统时钟（主板通过电池驱动的）是UTC，Windows上并不是这样。多系统并存时这会带来一些困扰。
在 64-位 Windows 10 系统中，以管理员身份运行：
reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_QWORD /f
即可让 Windows 也把系统时钟当作 UTC 而不是本地时间了。
加州光照充足，在换了油电混合车并安装了空调以后，我目前每年的用电量大约是每年6000 kWh（此前每年的用电量大约是2400 kWh）。随着加州电价的逐年提高，安装太阳能发电终于不再是一件不经济的事情了。
根据贵厂的 Project Sunroof 估计，我家屋顶每年的可用光照时间大约是 1903 小时，其中有 1357 平方英尺（大约126平方米）的面积可以用来安装太阳能板。经过和数家（马老板的 Tesla 即原 SolarCity、 Costco 合作的 SunRun，以及同事推荐的 SunWork）太阳能板安装公司的询价，最终选择了采用 10 块太阳能板、微型逆变器(microinverter)的方案。其中， SunWork 是一家致力于推广太阳能发电的 501(c)(3) 非盈利机构（他们要求客户在12个月内的电费低于 $100；对于使用了电车的用户，这些用户在购买电车之前的12个月内应满足此条件），因此报价比其他供应商低了 1/3 左右。
Continue reading 安装了太阳能发电系统.
有个疑似 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;
}
Continue reading clang优化器的一个问题.
今天搞了一个 大新闻。如果你用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。
Continue reading 关于闰秒.
作为十几年的 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 来添加一些陷阱地址。陷阱地址是那种故意流出，但绝不应该收到邮件的地址。
我有一心得和大家分享一下，话说三个人一起坐一电梯上，其中一个一直跳一直跳，一个蹲在角上一直祈祷，一个满地打滚手脚抽搐，最后都到了十二楼，若干年以后有人问为什么您能到楼上啊？第一个人说，我坚持不懈的努力，和大自然对抗，力竭也不放弃，最终达到了这个巅峰，第二个人说，我真诚而且坚持，我坚持自己的信仰从未忘记初心，第三个人说，我反直觉反传统反对一切，于是创造了完全不可思议的结果。我看很多商业书籍就这感觉，你们几位不聊聊电梯这事到底几个意思？
Recent Comments