虽然小鲁的专长不是大型网站开发或资安渗透测试，
但是毕竟还是对资讯有一点兴趣，在大三以后接触了不少阿宅小知识，
对于今次的所谓“电子投票”(吗?) 的许多争议，潜在水里看了看
觉得应该可以对该系统本身的设计、程式架构、安全性的众多问题提出一些意见。
首先是看个影片。写程式的阿宅总会想套用老梗“ hello world ”在初见的新玩意儿上。
我们可不可以请投票系统 hello world 一下呢？ (注: 该漏洞在投票前就已修正)
http://vimeo.com/96702478
就如影片当中所显示的，只要投票者有心，并且他能在短时间内想办法用 VPN
内网的装置 (例如投票的平板) 快速输入大约 170 characteres 的魔法咒语，
就可让远端服务器执行任何你想要的指令。（例如 rm -Rf . 之类的）
这里只是为了展示概念而简单地 touch hello-world 一下，不需多做解释；
总之在影片左上角可以看到 git repository 内容可以成功地被我们投票者修改。
不过 real world attackers 想要做的当然远远不止这些，
所有该 process uid 可以做的事情咱们都能做到... 这就要看人们的想像力了。
至于为什么这个系统会有这样的问题呢？鄙人认为有数个因素，在此列出几小点。
1. 撰写整个网站没有善加利用已经存在的 Web development frameworks
想要使用 MVC ，但是对 PHP 不是太熟悉的话，就不应该徒手去刻。
自己刻的话，各种安全性议题的 edge case 要考虑全面是很辛苦的。
2. 系统设计看起来有许多逻辑上的问题、怪异之处
举例来说“身份认证”不应该是随便想一套算法，套个 MD5 就可以 work 的，
应直接找现有的方案来套用。数学系及资讯系都有人对资讯安全、密码技术相当了解，
遇到问题时向他们咨询也是需要的。
举例来说，像是影片中的攻击，之所以成立，
应该是因为有一个像这样的奇怪的判断条件可以被 bypass with arbitrary code：
f( some_constant || user_input_key1 ) === user_input_key2
其中 f 是一个 cryptographically insecure one-way function
这里只是很简单地描述而已，实际状况比较复杂，可以直接参照 code 。
使用者输入的这个 key1 值会一层层逐渐传递到投票系统的深处，最终被 git commit
如果使用者可以改 key1 的话，就会因为其他部分的疏忽，导致任意代码执行的漏洞。
但是，为什么使用者改了 key1 以后这个判断条件还能成立？
这是因为 some_constant 不是未知的数值，
任何人只要计算 f() 马上就可以推知 key2 了，这样子检查 key2 就没有任何意义。
3. 这个系统的开发可能没有得到足够多人的协助、咨询、review
如果有足够多的 reviewer 的话，应该就不会允许那么多 bad practice 四散各地，
该份程式码有非常多潜在问题，不只是上面影片中提到的 exec() 问题而已。
允许 bad practice 是很不好的，今天程式跑起来没有问题，但是隔几个月后，
陆陆续续修改各个元件了，还能保证以后不会引爆出别的更严厉的漏洞吗？
4. 这样子的系统其实根本不算是合理的“电子投票”
现在我们看到的只是一个有电子设备辅助的投票流程，
而且这个“电子辅助”好像没有带给我们更多的方便。
如果只是想要咬文嚼字地片面解释说这玩意儿就是“电子投票”当然也是可以...
但是一个正常运作的“电子投票”需要有一些良好的 "provable" properties
- 某些人想要作弊？数学定理告诉我们他做不到。
- 想要验自己的票？可以。你可以确认自己的票是否正确地被计入。
- 想要验他人的票？多给一些条件以后，这当然也有办法做到。
如果一个系统运行的正确性，有很多部分可以被“验证”的话，就更能被大家接受。
而不是完全黑箱，把所有奢求的正确性都压在一个名为“相信选举主办方”的篮子里。
这样子的“正确性”是脆弱而难以被长时间考验的。
其实最理想的情况下，应当是使用者直接安装软件，在手机/电脑上直接参与投票，
请计中(orz)协助线上身份认证，或者善用 NFC 学生证悠游卡来帮忙投票的过程。
一个好的 protocol 可以让使用者无法在他的终端作弊，而主办方也没有办法作弊。
当然了，这是一个浩大的工程，要请更多专家来帮忙才行，并不是短时间可以做到的。
5. 开放原始码的程度其实不够完整，普通人难以直接参与其中
只有 GitHub 上这一部分的 php 程式码，
对于普通的 programmer 来说，还是难以帮忙“开发”、“测试”的。
应加上如何部署一台服务器的说明、资料该如何生成、数据库应该要有怎样的结构等。
降低协助测试的门槛，才会有更多志愿者来帮忙开发。
辛苦的核心开发人员也就不用焦头烂耳修 bug 写新 features 了。
如果这个系统以后还想要被使用，必定是要经过“砍掉重练”等级的大幅度更动。
不过任何的新制度也都是如此，刚开始会冲突、有异议，
必须仔细接纳不同的意见，经逐步地修正、成熟化，最终才能被广泛地接受。
如果还有许多争议、不同的声音时，就表示有一些根本上的问题，
所以人们才没有被说服，所以该制度、系统就还需要修正。
不过无论如何，我们都还是由衷地感谢许多台前台后参与、帮忙的人，
因为有你们默默地无偿付出，我们才能够享受到各式各样的福利。谢谢你们！