delphij's Chaos

OpenSSH 8.2 中新增了 FIDO/U2F 支持。 它支持两种密钥对类型： ecdsa-sk 和 ed25519-sk。需要注意的是并非所有的 FIDO Security Key 都实现了 ed25519-sk 的硬件支持：例如，截至2022年，Titan Security Key 就不支持 ed25519-sk。

使用 FIDO key 的 SSH key 在使用上和之前的 SSH key 类似， 主要的区别在于在登录时系统会确认用户是否在机器旁边（通常是碰一下 FIDO key）， 这可以显著地改善安全性：与之前的 SSH key 不同的是， 即使机器上的 U2F/FIDO SSH key 私钥文件被攻击者获得， 在没有硬件 FIDO key 的情况下也无法使用这个私钥。 对于对方同时能获得私钥文件和物理访问的情况， 参见 xkcd/538，就不要跟扳手过不去了。

我觉得这事必须得记一笔。

去年9月的时候，我和张师傅在 eBay 上团购了两台 Juniper NFX250-S2。 昨天周师傅问我当时付了多少钱，于是我就打开了浏览器准备去 eBay 查一下交易记录。

诶？右上角那是啥？使用 Gmail 账户登录？这比他们自己那个 2FA 实现好多了啊，我于是想都没想就点了一下。

上个月初带娃去佛罗里达那边休假，在机场租了辆车。这次的租车公司相当先进，完全不需要去排队或是在租车公司的触摸屏上再次确认， 直接在手机应用中确认之后，系统就直接给出了车的位置、型号（Ford Mustang），直接过去开门上车就可以出发了。

开始导航，一会谷歌地图显示去目的地基韦斯特 (Key West) 岛发生了大堵车。

「这题我会」，我想，顺手掏出了另一部手机上的苹果地图导航，发现果然也是出现了堵车。

此地是自古华山一条路，如果桥上发生事故，堵车实属正常。正想着，谷歌地图通知我说您稍微绕一下可以节省四个小时。 「太及时了！」看到堵车地点位于罗纳德里根收费公路附近，我毫不犹豫地跟随指示朝西开去。

走着走着，车的胎压报警突然亮了起来，配合了一段文字：「胎压传感器故障（Tire pressure sensor fault） 」。 这一路上估计车速会比较快，我不敢怠慢，赶快找了附近的一家加油站下车检查。 先是目测，发现轮胎没有显著的变扁，用手使劲按压也没发现什么问题， 于是到气泵处拿气泵带的压力表测了一下，发现胎压完全正常。

由于使用的 port 的编译选项与官方的往往不一致（例如我非常讨厌 gnutls、avahi 这两个包，此外有时我希望使用一个和官方不太一样的 OpenLDAP 版本， 或者采用不同的编译选项等等），我之前一直是 portmaster(8) 的用户。 portmaster 是 Doug Barton 早年用 shell 脚本写的一个 portupgrade(1) 的替代品，和后者相比，它不需要使用数据库，并且充分利用了 shell 的任务管理功能实现了尽可能利用 CPU 的计算能力，我个人也从这个脚本中学到了不少 shell 脚本的技巧。

不过，使用 portmaster 需要在每一台机器上都有一份 ports tree，并且由于直接操作的是本地的生产环境， 因此对于比较基础的库，如 gettext 之类，或是在升级操作系统时， 由于升级时间较久导致出现问题的可能性相对要大一些。 另一方面，使用 port 来管理第三方软件意味着需要把联编过程中的所有依赖软件包全都都装到生产环境中， 有时这是非常不经济的，例如大部分时候运行环境并不需要完整的跨平台 LLVM，等等，而使用 port 安装的话， 每一个系统中都需要整体重新联编一遍。

我之前已经用过很长时间的 poudriere 了。 这是一款现代化的联编系统，它充分利用了 FreeBSD 的一系列特性，包括 ZFS 快照/克隆、 tmpfs、 jail 等等，支持交叉编译。除此之外它还支持使用 ccache 来减少重复编译，等等。 不过，线上的机器出于习惯^H^H懒惰导致的惯性一直还是在沿用之前采用 portmaster 来进行更新。

最近一段时间 Twitter 上开始流行了一个字谜游戏 Wordle， 与此同时也出现了许多与之类似的游戏比如 拼音猜成语 等等。 基本上，这类游戏要求玩家根据一些有限的信息（目前的这些实现通常是会告诉他们是否有字母猜对了，或是字母存在但位置不对等等） 来推测可能的结论。

之前 提到我换了一家ISP。这家ISP目前尚未提供IPv6服务，因此想要用IPv6的话就需要自己动手。 此前也有一些其他朋友问过我关于为什么一定要有 IPv6，毕竟 狼来了 的故事已经讲了这么多年， 而且 十几年前 IPv4 的中央地址池其实就已经用完了，只是在工业界抱残守缺^H^H^H^H食古不化^H^H^H^H我也不知道该管这种行为叫什么， 总之苟延残喘了十几年依然没有把服务迁移到 IPv6 上去，所以目前用 IPv6 往往也只是满足一下一些技术宅的恶趣味， 例如看 kame.net 那只能动的海龟之类。

当然，我自己用 IPv6 有一些更加现实的动力，比如我的一些服务是只在 IPv6 上提供的，这样做可以把那些做的不好的客户端直接排除在外， 有点类似于在当年我把网站的 TLSv1.2 和更早版本的 TLS/SSL 支持全都砍掉一样。

话说回来，由于新的 ISP 出于一些我不理解的原因死活不愿意支持 ping （唯一可能的解释是，这样做会导致扫描起来容易不少，毕竟扫描 IPv4 地址段比扫描 IPv6 地址段要容易太多了， 但安全不能建立在别人不知道的基础上，anyway，打电话、开票之后未能解决该问题），而大河的隧道服务又要求必须可以 ping 到终点，于是陷入了死循环。

上回书 说到我在12月初的时候急诊做了胆囊切除。 这里更新一下后续的情况（主要是保险理赔）。

作为一个资深的bug吸铁石，我总是会不自觉地触发各种系统的边界条件，这一次也不例外： 我之前参加的雇主组织的由安泰(Aetna)负责运营的医疗保险在2021年底到期， 取而代之的是由伟彭医疗(Anthem)运营的医疗保险， 而这次急诊及手术发生在靠近年底的时候，这想必会让保险的理赔复杂化，果不其然，还没到2021年12月31日的23:59， 安泰的手机应用程序已经显示我不能直接用手机应用来查看理赔账单了， 而伟彭医疗的应用程序则认为自己不是我目前的保险应用程序。

我去年和今年参加的保险都是高自负额(High Deductible)的医疗保险。 这类保险通常会要求患者自行支付比较高的自负额之后才开始由保险支付部分直至全部的医疗费用， 由于患者需要自行支付一个比较高的金额之后保险才开始付钱，因此从保险的角度， 这类患者相比只支付一个较低的挂号费(copay)或共同承担额(coinsurance)的患者泡病号的风险更低一些， 因此总体成本，即患者自行支付的保险费加上看病时的患者自行支付的花费， 通常会低于其他保险。

我家由于一些其他的原因，在2021年度的自负额很早以前就已经花满了，因此看病时的主要考虑便变成了优先去网内(in-network， 即与保险公司有合约关系的)医疗服务提供者。我在2021年的保险通常情况下只承认网内的医疗花费， 对于网外产生的费用原则上不予支付，但急诊是其中为数不多的例外情况，在发生急诊时，所有花费原则上都会视为网内花费予以理赔。