思考

我今天话放这儿。

回国的时候和 康神 及端木吃饭的时候聊起过这个话题，这里整理出来。

实现安全有三种主要的手法：基于隐蔽的安全（或者，基于假象的安全）、基于默认配置的安全和基于设计的安全。

基于假象的安全很容易理解，也很容易实现。举一个简单的例子，在一片西瓜地前面戳一块牌子，说这块西瓜地里有一个西瓜里面注射了剧毒。

可以想象，由于信息的不对称（不知道是哪个西瓜有毒，或者根本就没有西瓜有毒），试图偷西瓜的人就会有所忌惮—-如果偷走的西瓜含有剧毒，那么这个西瓜是没办法吃的。然而，这样做有至少三个很致命的弱点：首先，为了实现最大化的利益，很可能瓜地的主人并不真的注射剧毒（或者反过来说，把偷瓜的人毒死并不是他的目的，他的目的是尽可能地保护瓜不被偷）；其次，即使瓜地的主人真的只给一个西瓜注射了剧毒，那么如果有人偷了那个西瓜并且死掉，那么知道这件事的人就可以冲过来直接把所有的西瓜偷走；最后，一个以牙还牙的小偷，很可能会在牌子上留下这么一段话：现在有两个了……

简单地说，基于假象或隐蔽的安全，建立在"别人不知道其机制"的基础上。这样的做法有时能够在一定程度上延缓攻击，但并不能使攻击的成功率降低。将弱点隐蔽这种方法成本比较低，例如，把门钥匙放在门框上、将知名服务端口如ssh（tcp/22）转到不知名端口如tcp/12580上、port knocking技术，以及国内银行常用的Active X插件等等。然而，假象终归是假象，这些方法都不能真正改善系统的安全性。这类做法，充其量只能作为没有其他更好的办法时候的一种临时 workaround，而不能带来长久的安全。

第二种做法，也就是基于默认配置的安全，是一类非常常见的策略。这种做法通常与其他安全机制合并使用。简单地说，采用这种策略的系统，在其出厂的时候是没有暴露在外的弱点的，例如它可能只开启了非常少量，甚至完全不开启任何服务，随后，管理员可以根据需要进行配置来开放一些需要的服务。

和蛇头GG讨论了一个关于卖票的问题，简单地说是票很有限，需求量很大，如何能够尽可能高效地让票以尽可能公平的方式卖出去。

我设计了一个分布式的结构来解决这个问题，当然这个原型可以进一步改进，此处按下不表。记录一下我对这个结构公平性的描述的一个比喻：

刘纪鹏老师一篇很有意思的 文章，对这个问题有兴趣的同学建议读一读。

很久没有shared chaos了，今天来一道小学数学题。

有一个水池，进水的速度恒定，提前接了一定时间的水；水池有若干出水口均在底部，假设所有出水口的出水速度一样（换言之，每多开一个出水口，速度即相应线性提高—-本人注）。同时打开3个出水口，水池水位在80秒后会下降到0；同时打开4个出水口，水池水位在50秒后会下降到0；问：如果同时打开8个出水口，水位需要多长时间下降到0？

今年 1 月 27 日发表的 《GCC运行环境豁免条款 (英文版)》 再次狠狠地打了苹果的耳光。

原先的豁免条款如下：

// As a special exception, you may use this file as part of a free software
// library without restriction. Specifically, if other files instantiate
// templates or use macros or inline functions from this file, or you compile
// this file and link it with other files to produce an executable, this
// file does not by itself cause the resulting executable to be covered by
// the GNU General Public License. This exception does not however
// invalidate any other reasons why the executable file might be covered by
// the GNU General Public License.

忘记在哪里看到的了，应该是小时候看过的某本书。先不要管故事的合理性，我只是想说明一个很简单的道理。

说从前有一个国王，他有两个儿子，这两个儿子总是互相攀比，搞的国王头疼不已。

有一天，国王想出了一个主意。他把两个儿子带到沙漠边上，给了他们一个人一匹马。他对两个儿子说，你们两个穿过这片沙漠，但是今天不要比谁的马快，我要比的是你们谁的马后走出沙漠，后走出沙漠的人就可以得到王位。

两个儿子在沙漠里互相抱怨着父王的这个馊主意。突然，哥哥灵机一动，对弟弟说了几句话。

接着，两个人骑马飞奔而去。

故事讲完了，你知道哥哥的主意是什么吗？

之前和 A core 聊过这个问题。整理一下发出来。

这个话说的可能比较绝对，有人说，缺少信任的社会是可悲的—-而我想说的是，现今，被过度滥用的信任则是可怕的。通过各式各样的社交网站，如 Facebook、LinkedIn、开心网、天际网等等（我想有人会提到 豆瓣，但是我个人认为豆瓣算是一个比较另类的社交网站，因为上面的人很少使用真名），很多人之间的联系被轻易地挖掘和利用。

来自李笑来老师的blog(原来在新东方上过他的GRE课)的《如何找到属于自己的兴趣》。

我这次不铁口直断了，估计明年见了，如果这周能够RC2的话，最终RELEASE估计要到明年的1月5日左右。

这次FreeBSD 7.1在软件工程角度是相当失败的案例，我想我们应该从里面总结一些教训出来。

首先，我们的目标是什么？

我想，用户对于一个发行版本的期待是：一个经过了大量测试的、阶段性的稳定版本。而开发人员对于发行版本的期待则是尽可能地将可用的功能交付给用户。作为OS，我认为这应该包括自动化的回归测试、性能改进、更新的驱动程序、文档的修订，以及更新的第三方软件等等。

FreeBSD目前的开发模式，是将分别开发的三大模块，即内核与基本系统(src/)、文档(doc/)、第三方软件(ports/)的人在一定的时候聚集在一起，通过代码冻结的方法来使他们从增加新功能转移到集中去修bug，最后发布一个版本。这个模式在过去运转的相当好，以至于我们没有发现其中存在的问题。

这次FreeBSD 7.1暴露出来了这个模式存在的很多问题。例如，由于安全小组发现了很多安全漏洞，而另一方面，安全小组的人手不够，限制了修正这些问题的速度。我本人撰写的一个安全公告等了一个月才在今天最终公之于众，而另一方面，安全小组对于发行版本拥有一票否决的绝对权力，导致6.4和7.1的发布都一再推迟。

而作为非常快节奏的开发的 ports/ 维护者，则对不断的推迟感到相当不满。FreeBSD目前只维护 ports/ 的 -HEAD，也就是说，在正式发行 -RELEASE 之前，ports/ 不能进行大量的、破坏性的修改。例如，我本人维护的 OpenLDAP 现在就必须等待 -RELEASE 之后才可以进行升级。不断地推迟新的发行版本，会导致 ports/ 的开发继续延迟。