delphij's Chaos
选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
最近帮公司的一个客户做了一个数据库迁移,客户声称数据是 utf-8 的,然而在使用过程中出现了许多乱码,检查发现数据并非 utf-8,而是 utf-8 编码之后的 big5,而排序方式更是混乱不堪的默认的utf8-swedian-ci。
MySQL的国际化支持很差。MySQL从 4.1 版本开始大刀阔斧地进行了不兼容的改动,简单地说,这些改动让相当多的操作默认以UTF-8进行,然而这会给旧的应用程序带来很多问题。许多文献推荐使用 SET CHARACTER SET 作为 workaround,尽管这能够解决一些问题,但这种做法本质上会导致 MySQL 进行额外的转换,因此并不是十分理想。
正确的方法是把所有的东西都转换成 UTF-8。一个比较常见的错误是使用SET NAMES UTF8并直接从原始的 Big5 表中导出。这种情况下,文字会被以UTF-8编码的big5方式保存。比较简单的做法是将其直接导入数据表,并以 latin-1 导出:
mysqldump -u 用户名 -p密码 –skip-extended-insert –default-character-set=latin1 –databases 数据库名 > big5.sql
接着,使用 piconv (随 Perl 提供)来转换编码。我个人认为这个工具比 uconv 和 iconv 都要好。
piconv -f big5 -t utf8 < big5.sql > utf8.sql
接下来要把 utf8.sql 中的 latin1 等不正确的编码改为 utf8(通常,简单地sed即可)
最后重新导入。前面 skip-extended-insert 可以让发生错误时显示较具体的行号,这对于较大的数据库而言会比较方便。
声明:此 HOWTO 文档以现状方式提供,不提供任何担保。此文档为个人作弊条,本人会对部分疑问进行解释,但同样不提供任何保证。
此篇按下述授权发表:
/*-
* Copyright (c) 2009 Xin LI delphij@FreeBSD.org
终于,是吧,直接写入BIOS的终极木马诞生了。十几年前的CIH病毒等等现在看来都是小儿科。
这种东西迟早会出现,这个我并不觉得奇怪,但是这次CORE实现的这个攻击是一个通用性很强的攻击,换言之,它能够适应多种不同品牌的 BIOS;实际上我认为这种攻击很可能也适用于网卡、RAID卡、显卡上面的可刷写ROM。例如,如果在 VBE 中写上这么一个玩意呢?现在看来 ACPICA 真是一个有前瞻性的玩意,也许 Intel 早就意识到了这种问题可能会发生?
不管怎么说,我想这是一次很好的机会来让用户知道:永远不要获得不应该获得的权限,如果你是小白,就不要用管理员身份登录!这件事真的很危险。
Read more...之前在水木社区发过,这里也发一下。
我们目前正在寻找有意参加这次活动的在校学生。Google Summer of Code 是由Google公司赞助的供在校学生参与开源项目的暑期活动。目前,FreeBSD已经被选为符合资格的 mentoring organization,这是 FreeBSD 第 5 年参与 GSoC。
重要的日期:
Google将为获得资助的学生提供每人 $4,500 的资助,分3次支付;同时,对于每个项目,Google还会为对应的开源项目提供 $500 的资助。
关于 FreeBSD 本次 SoC 活动的 网站。
Read more...FreeBSD 今天发布了 2009 年第 6 号安全公告 FreeBSD-SA-09:06.ktimer。这个安全公告适用于 7.0-RELEASE 以上到修正日期之前的所有 FreeBSD 版本。
由于这个安全公告修正的是一个零时差 (0-day,也就是发现者直接对问题进行了全面披露,而不是等待供应商修正之后再发布漏洞细节) 披露的漏洞,因此,适当地评估其风险并采取措施就非常重要。安全公告中提到,这是一个"Local privilege escalation"(本地特权提升问题),这种问题属于一类非常常见的(特别是 Linux 内核)、严重的安全漏洞,具体来说,通过一定的方法,登录在系统上的用户可以提升其权限,并实施进一步的攻击。
关于这类漏洞的一个常见的误解是,“本地"漏洞通常是没什么大碍的。然而,那种无关大碍的一类"本地"漏洞,指的是只能在本地控制台触发的问题。例如,如果手中有一张包含了某些工具的Windows PE光盘,用它启动系统便可以得到本地的管理员权限—-这是一个安全问题,但是并不严重,因为事实上如果别人能够接触本地系统,那么他就可以做任何事情。
而 FreeBSD-SA-09:06 指出的问题则不是这类问题。在其上下文中,“本地"是指能够登入系统的任何用户,以及能够以本地用户身份运行的服务进程。对于 Web 服务器而言,这是一个非常严重的安全威胁—-例如,如果在设计时因为疏忽而没有考虑上传文件是否有可能由于某种条件被执行,那么,之前这可能只是一个简单的 DoS 问题(例如,用户可以上传一个不停 fork() 的程序,将 www 用户的进程配额耗尽而导致新的服务请求无法被及时响应),而有了这个漏洞,这些问题便成了远程特权提升问题,其危害也就非常严重了。
Read more...今天路过Castro的时候看到了El Camino Real上那家Washing Mutual上面原先大字的WASHINGTON MUTUAL换成了CHASE的logo,隐约还能看到WAMU大字留下的痕迹。这家百年老店就这样一点一点地消失了。
Read more...出来混迟早要还的。
PST 01:59:59AM之后,系统立即将时间改成了PDT 03:00:00AM。时间就这样在不知不觉中少了一个小时。
Read more...许多新的笔记本计算机系统配备了基于指纹的身份识别系统。与通常人们的认知不同,这类系统的安全性往往仅仅与使用口令相当,甚至要比基于口令的身份认证系统来的更差;这类系统的价值在于,它们简化了用户的身份验证过程,而不是其改善了系统的安全性。
指纹识别,以及目前采用的其他生物特征识别技术,其共同特点是需要使用某种加密存储来保存特征数据 以及 用户用于验证身份的信息,这类信息可能是口令,也可能是私钥等等。
不可避免地,由于生物特征只能以基于概率的方法来进行验证(例如,指纹验证通常是取几十个数据点,如果符合的比例超过一个阈值则认为匹配),而不是通过采样得到数据直接来进行计算(话说回来,即使是这样也有问题,因为那样的话,便没有办法任意修改这些数据来获得与更换密钥同样的效果),因此,这些加密存储也就不得不要求验证系统本身持有解密的密钥。换言之,如果负责身份验证的芯片存在后门或漏洞的话,是否持有带生物特征的信任状,并不会改变能否拿到机密数据这个结果。又比如,身份认证芯片本身如果完成的是取解密密钥,而不是解密这样的操作(从减少成本的角度说,很有理由这样做),那么一旦软件系统存在的漏洞所导致的风险就大大提高;而由硬件直接完成解密操作的问题则是,硬件事实上没有办法验证软件是否仍然在一个"理性"的状态运行,或者说,硬件并没有办法来验证访问它的软件是不是它期待的那一份。
不过,从积极的方面看,基于生物特征识别技术的身份验证方案尽管并不能消除系统中的任何薄弱环节(如果不是增加薄弱环节的话),但是对于缺乏安全知识的用户还是有一些积极意义的,例如:
由于不需要每次都输入很长的口令,这些用户会更乐意接受不容易被穷举的、复杂的长口令。当然,任何理性的远程验证系统都应该有适当的密码重试锁定策略,这种做法只是减少或消除了偶然猜中密码的可能性。
减少了使用长口令的用户登录的时间。
看起來很"酷"。
不过很遗憾,这个列表并不包含直接地改善系统的安全性。
Read more...最近在看 Berkeley DB,发现一套 FreeBSD 上没有的宏, CIRCLEQ_*。
看了一下,这组宏是来自 4.4BSD 的,因此 FreeBSD 曾经有过这个宏;后来, phk 在 2000 年 12 月 29 日从 FreeBSD 里面把它拿掉了(SVN revision 70469),当时的说明如下:
CIRCLEQs are a disgrace to everything Knuth taught us in Volume 1 Chapter 2.
Retire them before anybody starts to use them again.
Use TAILQ instead, it provides the same functionality.
这个说的并不是很明确。查了一下,果然当时引起过争议(反对的意见主要是认为这会导致无法从 NetBSD 和 OpenBSD 移植代码,而另一方面,这被认为是 4.4BSD API 的一部分)。
Kirk McKusick(queue.h的作者)随后表示 支持 这一变动。具体的原因是 CIRCLEQ 的所有的功能,都可以用 TAILQ 以更高效的方式实现(因为 TAILQ 产生的 比较 操作更少)。
Read more...刘纪鹏老师一篇很有意思的 文章,对这个问题有兴趣的同学建议读一读。
Read more...Maho今天正式commit了 OpenJDK 的port,表面上看这是一小步,但在我看来这却是一项历史性的进步,因为终于可以不再受到之前那个 click-through 许可证的限制了(也就是说,可以几乎没有任何限制地随光盘,或者通过网站提供可用的jdk源代码和二进制版本了)。
与此同时,继续期待 Apache Harmony 的 FreeBSD port,有没有人有兴趣搞一下?
Read more...