安装软件 apt-get install mpg321 vorbis-tools 使用如下命令转换 mpg321 tweet.mp3 -w raw && oggenc raw -o tweet.ogg && rm -rf raw 示例: root@hkvps:/home/res# mpg321 tweet.mp3 -w raw && oggenc raw -o tweet.ogg && rm -rf raw High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2, and 3. Version 0.3.2-1 (2012/03/25). Written and copyrights by Joe Drew, now maintained by Nanakos Chrysostomos and others. Uses code from various people. See 'README' for more! THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! Playing MPEG stream from tweet.mp3 ... MPEG 1.0 layer III, 192 kbit/s, 44100 Hz joint-stereo [4:45] Decoding of tweet.mp3 finished. Opening with wav module: WAV file reader Encoding "raw" to "tweet.ogg" at quality 3.00 [ 99.7%] [ 0m00s remaining] | Done encoding file "tweet.ogg" File length: 4m 45.0s Elapsed time: 0m 16.3s Rate: 17.5056 Average bitrate: 112.1 kb/s root@hkvps:/home/res# ll

驾校交钱已经一年了，一直没时间考试，上次报考的科目一由于临时加班没去成，这次重新交钱补考。 昨儿晚把驾校发的书翻了一遍，然后就是在手机上用车轮考驾照不停的练习。 今儿中午11点多到考场，换了准考证就等待安排考试。 分配了个电脑有点挫，第一次登录显示考试时间不对，重新更新信息。 第二次指纹录入一直不能验证通过，重新更新指纹验证。 第三次摄像头无法采集视频信息，重置考试系统。 第四次，一切正常开始答题…… 13分钟答完，等过了15分钟交卷，得分98。 考试要点：细心别急、细心别急、细心别急！

注册StartSSL 打开https://www.startssl.com/，点击Sign-up开始注册 参考上图填写注册信息，然后Continue，会有如下提示，系统会发送验证码到你的注册邮箱 检查注册邮箱，将收到的验证码填写提交，然后会出现如下提示，等待审核。 审核通过后，会收到如下提示邮件，点击其中连接，然后输入邮箱中的验证码完成注册 安装证书 接下来创建私匙 安装证书 安装成功后会有如下提示 验证域名 接下来验证域名，点击Validations Wizard 填写域名 选择验证邮件地址 按照提示输入邮箱接收到的验证码完成验证。 创建证书 选择Certificates Wizard，证书目标选择Web Server SSL/TLS Certificate 接下来新建私匙 点击Skip跳过系统建立步骤，我们自己在VPS上建立CSR文件，参考下图通过openssl命令建立CSR文件 注意，为了便于后期安装配置方便，建议密码置空 完成后，cat出建立好的ciuxsss.csr内容，粘贴提交 接下来添加域名 接下来将文本框中的内容保存为一个**.crt**文件 配置Nginx 贴出我的配置文件，大家参考一下 server { listen 80; location /{ return 301 https://$host$request_uri; } } server { listen 443; #listen 80; #listen [::]:80; server_name ciux.org; index index.html index.htm index.php default.html default.htm default.php; root /home/ciux/compiled; ssl on; ssl_certificate /home/bk/ssl/ciuxsss.crt; ssl_certificate_key /home/bk/ssl/ciuxsss.key; ssl_session_timeout 5m; ssl_protocols SSLv2 SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP; ssl_prefer_server_ciphers on; …… 其中第一个Server是将所有80端口的http访问301重定向到443端口的https访问。 ...

首先澄清此文中的免费不是真的免费，而是新注册或转移域名到Gandi，都可以获得标准版SSL证书一年的免费使用。 符合以上条件的话，可以进行下面操作了！ 在Gandi上购买SSL证书，选择标准版，在结算的时候系统会自动判断是否免单，正常情况下会0元结单，完成后接着配置SSL证书。 首先提交CSR，这里需要自己生产CSR。 在此以3c.lc域名为例，在Ubuntu中操作。 openssl req -nodes -newkey rsa:2048 -sha1 -keyout 3clc.key -out 3clc.csr 然后根据提示填写以下内容： Country Name (2 letter code) [AU]: #国家代码，中国为CN State or Province Name (full name) [Some-State]: #省份 Locality Name (eg, city) []: #城市 Organization Name (eg, company) [Internet Widgits Pty Ltd]: #组织名 Organizational Unit Name (eg, section) []: #部门名 Common Name (e.g. server FQDN or YOUR name) []:3c.lc #注意，这里需要填写你的域名。 Email Address []:[email protected] #邮箱 Please enter the following ’extra’ attributes ...

声明: 本文来自霍炬的微信公共帐号“歪理邪说”，用微信添加 wxieshuo 公众号，即可订阅。 先跟读者道个歉，最近一段时间有点忙，好久没更新。而写文章这事，一旦有一段时间不写就会越来越写不下去。很长一段时间我甚至不敢打开公众帐号后台，一怕被催稿，二怕看到惨烈的退订数字以至于更不敢写…非常感谢各位还没退订的读者，我未来一定争取保持一个合理的更新频率。 最近XcodeGhost导致的严重安全问题，相信大家已经从各个渠道知道了。简单概括一下，有人在中国网盘和论坛上传播了一个修改过的Xcode，这个版本的Xcode会在编译出来的App上面加一些可以被远程控制的代码，并且发送数据到某个服务器上。这是iOS出现以来，未越狱系统遭遇的最大安全威胁，在此之前苹果的Sandbox模式几乎没遇到过挑战，iPhone用户甚至大量iOS开发者都认为系统固若金汤，不可能遇到问题。 在XcodeGhost开始被媒体报道的时，很多人大大低估了它的风险。我在乌云报道这个问题的当天，在朋友圈上建议大家先把中招的app都删掉，并且立刻修改iCloud密码，开两步验证。甚至遭到了不少人反对，还有好几位iOS开发者告诉我这件事没什么大问题，因为iOS有Sandbox，不会造成什么伤害。当时网易也发了一个关于云音乐被感染的说明，也是类似不痛不痒的口气。这些说法当然都是大错特错的，会有这种想法，是因为只会站在程序员角度看问题，如果对安全问题稍微有一点敏感性，就会立刻意识到这是极严重的威胁，稍微发挥一些想象力就会被吓着。 所谓安全威胁，大部分都是在获取到非常有限资源的情况下，利用社会工程学（俗称：骗）来达到目的。比如，你觉得让别人看到你的通讯录有什么问题吗？很多人会认为虽然不舒服，但不会有什么威胁。实际上，骗子会从通讯录里面挑出来你父母的电话，打电话去骗他们。所以，这和iOS有没有sandbox，能不能保护系统安全没关系，只要我获得了一个机会，能控制你信任的app上弹出对话框，我就可以利用这个对话框来骗你输入系统的重要密码。程序员应该想象力再丰富一点，不要把目光局限于“系统给了我什么权限”，而是要扩展到“如果我被完全信任了，我能进行什么样的欺骗”。 我不打算在这里讲太多直接的安全问题，毕竟已经很多人分析过了，在好几篇非常不完善，极大低估这次事件威胁的分析文章之后，腾讯给出了一篇相当详细的分析，比较符合我的观点，也把问题的严重性说的非常清楚。在腾讯的分析里面，说可以利用OpenUrl来操作用户拨打电话，同样又有iOS开发者说“OpenUrl不能控制iPhone打电话”。事实上，OpenUrl可以弹出一个带有固定电话号码的弹窗，上面有“拨打”和“取消”两个按钮，这确实不算直接拨打了电话，但如果给一千万个用户在某个特定环境下弹出一个这样的窗口，其中有多大比例的人会去点“拨打”呢？如果程序员不去提高想象力，总把安全问题和功能局限在系统文档提供的“能做什么”这个范围内，软件的安全性实在让人难以信任。 具体的安全问题有更专业的人去普及，本文不多说，在这里我更想谈谈关于信任的问题。在这次事件中，也有一些人想起了Ken Thompson大神（Unix系统/C语言的前身B语言/Go语言的直接贡献者，称作Unix之父也不过分）在1984年的一次演讲，在那次演讲中中，Ken讲了他在70年代在贝尔实验室捉弄同事的一次恶作剧，在那段时间里面，实验室里面所有的Unix系统，Ken都可以随便以最高权限登录，而同事反复检查用户，权限，甚至是当时使用的Unix代码，都没查不到后门，百思不得其解。14年之后，Ken在这次演讲里面才公开，后门其实隐藏在他写的编译器中，当用编译器编译Unix系统的时候，后门就被放在了编译出来的系统里面，但Unix本身的代码是干净的，所以同事无论如何也查不到问题。Ken的演讲所提到的核心问题并不是如何入侵一个操作系统，而是信任。其标题“Reflections on Trusting Trust” （我翻译为"深入思考我们信任的可信"，以下简称RoTT）开宗名义，明确强调这一点。 在80年代曾经有很多人用这样的办法给开发工具加各种外壳和后门，但当时联网条件并不好，很难产生大规模影响。很多案例是发生在相对封闭的企业内网和教育网中，Ken捉弄同事的原始案例也可以看作是企业内网上的传播。可以说，RoTT能产生的影响一直被人们低估，因为在现实世界想要具备适合它的条件，实在是太难了。历史上，虽然有很多底层代码Bug导致的安全事件（比如之前的OpenSSL心脏出血漏洞，可以参考我的另外一篇文章，点阅读原文可见），但直接通过这种在基础工具上制造的后门，从而衍生的大规模安全事件，从来没有真正发生过。这种手法一般是用在有限范围的网络上，比如在早年的教育网上或者企业网络里面，那时候在内网上传递一个被下了毒的软件，很容易传播开。 在互联网上，如果要重现Ken的案例，首先需要找到一个可信的源头感染，这本身就已经是极其困难的事了。用这次的事件做例子的话，在正常情况下，用户是通过Mac App Store来下载Xcode的，在下载安装的过程中，OS X本身会替用户进行加密签名校验，保证下载的东西确实是苹果原始分发的软件，这样才能被安装到用户的机器上。如果想把在Xcode中嵌入一个后门，你得先找到Apple服务器的漏洞，才能有机会把自己改过的包上传上去，而且还要弄到苹果的私钥去进行签名，才能装到用户计算机上。但如果同时具备了这两个条件，已经是荣华富贵唾手可得，有的是更可靠，获利更大的做法，谁又肯去舍近求远感染一个Xcode呢？ 所以，只有在相对封闭的网络环境下，才有可能玩这个把戏。80年代，网络远远没有今天发达，人们更多的下载和网络活动是分布在各大机构自己的网络里面的，比如大型企业的内部网络，相对于互联网，这些内部网络网络速度会快的多，人们通常更倾向于从内部网络获得软件。这就给了入侵者（通常是商业间谍）通过替换内容软件来侵入公司内部的机会。但内网又造成了另外一个问题，在封闭网络下，入侵者获得的数据也没这么容易拿走，必须还要回到内网才有机会拿到之前的战果。这些特性造成了这种做法始终在小范围内有效，在公众网络上性价比不高。 这次XcodeGhost事件会给很多人启发，中国目前的网络环境类似于80年代的企业内网，但规模又比当年的内网大的多，而且不像那么难以进入。 于是，一些80年代流行但没造成大规模影响的办法，有机会可以在中国环境下重新应用了，并且造成巨大影响。以前的创业是Copy to China，现在同样可以复制30年前的安全问题。 Ken的演讲最后指出，你没办法信任那些不是自己写的代码。80年代达到这个目标尚且有可能，那时候的软件规模还很小。而今天，任何工作都需要建立在大量的现成软件基础之上，换句话说，你必须去信任其他人，才有可能制作出产品。如今的可信任环境就变得更加重要。 但在中国，因为GFW和相关政策的存在，要获得一个可信环境变得非常困难。在这个环境里面，大量国外网站不能访问或者难于访问，非常多怕麻烦的人会使用国内替代品，这次的事件之所以影响巨大，就是因为通过苹果官方渠道升级Xcode速度太慢，少则10多个小时，多则几十个小时，其间还有可能中断和重新下载。从国内随便下载一个Xcode用当然是错的，但在这样的环境下也不是完全不能理解，考虑一下互联网的下载速度只有50K，企业内网速度能高达10M的时候，谁会不从内网下载呢？ 用一个现实世界的例子做个比喻吧，前面说了骗子拿到你父母的电话之后，会打电话去骗他们，比如跟你父母说你出了车祸，急需用钱。要让这个骗术成功，一个前提条件是要阻止你父母去找你验证真假，所以骗子同时会用各种办法来骚扰你的电话，迫使你不堪其扰关机或者始终占线。这样你父母和你的联系就断开了，他们没法找你验证了，此时骗子的话就更容易被相信。在这次事件里面，GFW让人们无法访问国外的可信网站，或者访问速度极慢，它起的作用就如同迫使你占线或者关机，从而让人们只能从不可信的地方获取软件。 GFW让中国本来开放的互联网环境，变成了一个巨大的企业内网，或者叫做中国局域网。除了速度和难以访问的影响，各种各样的DNS投毒，电信运营商干扰也是严重问题，你拿回来的DNS结果往往也未必是可信的，而运营商试图在HTTP请求中插入广告的行为，又经常会导致正常的应用表现不正常，而这些乱七八糟的毛病还经常变化，今天你可以这样对付，下周可能就需要换一个办法。要维持一个可信的软件环境，需要付出巨大的精力，能愿意付出这个代价的人越来越少。 在这个环境中，我们能信任的什么呢？网络链接不可信，运营商不可信，DNS不可信，大企业不可信。最后这一点更荒唐，如果是在正常的网络环境下，你很难相信苹果或者Google会坑害自己的用户，因为这和他们的利益直接相关，他们总是要尽量保护自己的用户。但在中国，如果你敢信任百度，基本意味着你生活各方面都会出问题，用百度查个搬家公司，骗死你没商量，用百度查个快递电话，骗死你也没商量，用百度查个医院，你猜会怎么样？那是真要骗死你没商量，这里的骗死都不再是比喻了。你要信任百度的软件，更好玩了，它莫名其妙就给你把百度出的所有软件都装在你机器上了，人们管这个不请自来的大礼叫做百度全家桶。如此致力于坑害自己用户的大公司，在中国之外还真是罕见。 在中国的网络环境下，这次事件产生的危害本身也更加危险。事件发生时，我告诉朋友们立刻删除所有被感染的软件，直至问题被修复。有人说，黑客自己的网站已经关闭了，没什么危险。这么说当然是错的，因为遍布中国各处的DNS投毒和劫持，创造一个一样域名的网站再简单不过了。比如到游客聚集的区域，带一个路由器，创建一个没有密码的WIFI热点，等着人们连上来，在这个热点上劫持XcodeGhost使用的域名，就可以利用已经中毒的app来骗iCloud密码了。这些都是非常容易实现的办法，千万不要低估安全问题能造成的后果，尤其是在中国特殊的网络环境下。 目前中国的网络环境和食品安全有诸多共同之处，你没法信任路边的小饭馆，但同时你也没法信任昂贵的大饭馆。你没法信任菜市场买的肉，但超市买的肉也并不那么可靠。在一切的背后是土壤和水的全面污染，可能一家好的饭馆未必打算毒害自己的顾客，但他们也很难保证自己原材料的供货商可靠，要保证使用的所有材料可靠，这是一家饭馆不可能具备的能力。比如，奶粉的三聚氰胺事件之前，一家有追求的饭馆大概会觉得，我不用来路不明的奶粉，我用大品牌的三鹿，伊利，这算是对顾客负责了吧？可惜，这些大品牌一样出问题。这绝非饭馆所希望的，他们也是受害者，就像是这次事件中的网易云音乐，他们确实没打算坑自己的用户，不过网易、腾讯这样的大公司一样中招了。 相对封闭的iOS尚且如此（单一开发工具，单一软件分发渠道，独家封闭系统iOS，独家硬件iPhone）尚且能出这么大问题，想想Android会怎么样？Android官方网站几年前就被封了无法访问，大部分开发者都是从国内渠道下载的开发工具。App的安全可靠吗？国内无数家忙着改Android皮肤就称自己是“操作系统”厂商，他们能保证自己的定制Android版本是安全吗？他们有真正的操作系统厂商级别的能力吗？进一步，他们能保证自己使用的开发工具安全吗？每家手机厂商都恨不得做自己的Android app下载渠道，他们能保证这些渠道上分发的app安全吗？甚至，他们能保证自己的下载市场安全吗？请大家继续联想吧。有朋友跟我说，你想多了，Android哪需要这么麻烦啊，本来国内环境就是木马遍地了。真实情况恐怕只能用惨烈来形容。顺便说一声，传说Google要把Play Store进入中国，提供一个受审查的版本，很多人说这是Google妥协了，我看这根本不是妥协了，是中国内部的Android环境太糟糕，已经威胁全球生态了，Google不得不自己出手解决这个问题。所以，一旦Google Play真的进了中国，请大家记得立刻把Play Store做为自己唯一的Android软件下载渠道，哪怕它不好用，不中国国情，甚至显得有点傻里傻气…千万记得，安全比方便更重要。 在这些前提下，重新认真考虑Ken的演讲提到的观点就显得更加重要，深入思考我们信任的可信。到底什么是可信的呢？开发工具可信吗？操作系统可信吗？你觉得下载来之后验证一下md5或者sha512总应该可信了，但你用来计算sha的工具是哪下载来的？你又如何知道这个工具本身是可信呢？在一个封闭的，难以和真正源头沟通的环境下，根本没办法谈所谓的信任。 在中国目前的环境下，难以直接套用成熟的软件开发和管理流程，除非保证团队所有人都必须翻墙，必须用Google查资料，必须不信任国内网站。你的团队中有一个习惯用百度查资料，顺着国内论坛的链接从百度网盘或者迅雷下载工具的人，就不知道会惹出来多大麻烦。这次事件充分证明了这一点，我起初认为腾讯应该不会有问题，因为我知道腾讯内部有极好的网络环境，但最终不幸的是微信也中招了。我们的恶劣环境已经改变了工程师的习惯，甚至改变了教育，就算是在腾讯内部这么好的网络环境下，仍然有人会去百度查资料，用百度网盘下载开发工具。就像很多留学生到了美国仍然用百度搜索一样，环境的改变并不能直接逆转已经完成的用户习惯。 比较讽刺的是，在中国特色的现实世界反而又制约了出现大规模安全灾难的可能性。比如，中国有相当严重的网络监控、审查和实名制、以及互联网公司必须保存（而且要向有关部门开放）的各种用户数据，并且互联网和世界半隔绝，在出现这种问题的时候，要抓到始作俑者又相对简单。现实世界中，只要在论坛发个贴，去你家查水表就是分分钟的事情。这大概算是“不幸+不幸“互相抵消之后产生了一点点微小的幸运吧。 很多年前，我说招聘工程师有几个原则，比如，必须使用Google而不是百度，必须翻墙而不是用国内替代品，必须优先使用国外的工具。经常有人认为这种要求过于苛刻，甚至认为是装逼。这次事件告诉了我们，这些良好的习惯确实是工程师的第一道防线，融入世界主流，可以让你少遭遇很多中国特色的麻烦。虽然保持这些良好的习惯需要付出不小的代价，但事实证明这些代价是值得的。 这样的网络环境，是我们这一代工程师的耻辱，但我们如此愤怒于此 ，又如此无能为力，这是这个时代最令人悲哀的事情。 我们对此有多么无能为力呢？我写这篇文章的时候就在想，大家应该赶快传播它，因为我觉得它很快会被删掉。这就是无能为力的具体表现。 顺便说一句，1996年，受Ken的案例启发，我写过一篇科幻小说，大意是一种病毒把编译器做为感染的源头，最终感染了操作系统。在这个操作系统上，它会判断用户指令对它是否会造成伤害，如果是有害的指令，就假装执行一下，实际并不真执行，从而可以躲过杀毒软件和人工清除。这同样是信任问题，在这个环境下，没有任何可信的东西，这种病毒将会在操作系统中永存，并且把自己附着于任何在这台计算机上制造的软件中。在一个计算机一开机就无线联网的时代，病毒可以借此高速传播，最后人类已经找不到一台干净的计算机可以去编写真正干净的操作系统了。（90年代还没有无线网络，那时候甚至连有线网络都没普及，Sun还在号称网络就是计算机，那时候一台随时联网的计算机简直太奢侈了，但如今看来…世界确实已经发展到了这样，想找一台不联网的计算机倒是不容易了）。 不知道这种幻想中的病毒什么时候会真正出现…其实，前几年工信部推行绿坝的时候，我当时就觉得那简直是创造这种病毒的一个非常好的机会，还好最终绿坝计划被放弃了。中国网络和政策环境的特殊性，将来真的有可能制造出适合这种病毒生存的环境，就像这次因为GFW的正面和潜在影响，让70年代Ken设想的RoTT在2015年大规模流行，40多年的时间跨度…著名科幻作家韩松说过：“中国的现实变得比科幻还要科幻”。深以为然。