经常看公众号文章的人都知道，一般而言，公众号内是无法放超链接的。这对于一般的文章来说其实不要紧，但是对于我们这种技术类的文章，往往会带有很多链接，而不能插入链接，会导致一篇文章的价值和可信性降低。

备注：

公众号文章可以放超链接的情况有几种：

1. 认证的服务号可以放任意链接
2. 可以链接已经发送的任意公众号文章

针对这种情况，我们之前有过几种解决方案：

1. 将链接 URL 以文字的方式显示在文章中或文章底部。
2. 将链接转换成二维码，可以长按识别跳转。
3. 将文内的链接整理放到一个专门的 HTML 页面，通过“阅读原文”引导读者访问。

其中第 3 种解决方案是我们近几年一直采用的方式。不料，前一段时间，有个读者留言问，链接怎么不能点？而这个读者居然是从 2013 年就关注我们的读者，这让我很吃惊。这说明，一方面我们对读者的提示和帮助还不够；另外一方面，大部分读者还是习惯性的去点击链接（我们文章内的链接有易于识别的样式，一看就像是链接）。

思考之下，结合最近我们正在研究的小程序，我们提出了第 4 种解决方案：用小程序来承载链接。读者点击小程序后，小程序负责将该链接复制到剪贴板中，这样读者只需要打开手机浏览器，就可以手动粘贴该链接进行访问了（有的浏览器会自动询问是否访问剪贴板中的链接）。虽然，还需要打开浏览器一个步骤，但是这样感觉直接多了。

这个功能在我们的公众号和我们专用的小程序“Linux文章”上试验打磨之后，我们决定建立一个公用的小程序，将这个功能开放给大家使用。

使用方法

1、在微信文章编辑器中，点击插入“小程序”，输入“文章助手”查找（使用这个小程序不需要公众号关联）：

就是这个大眼睛，然后下一步：

2、这里输入路径“/pages/a?link=链接地址&title=链接标题”，请使用你的链接和链接标题分别替换路径参数：

当然，展示方式你也可以不使用“文字”，选择图片也是可以的。

插入文字链接后效果如下：

小程序效果

读者在看到你推送的公众号文章后，看到这种熟悉的链接样式，自然而然就知道可以点击了。点击后，会弹出如下小程序界面：

“文章助手”小程序会显示该链接，并自动复制到剪贴板。当你的剪贴板内有较多内容时，不会自动复制，以避免冲掉你的重要内容。这种情况下，可以点击一下链接框，手动复制即可。

然后就可以打开手机上的浏览器来浏览啦。

除此以外，点击小程序左上角的头像，读者还可以看到他查看过的所有链接。

重要提醒

此小程序的使用永久免费，并且我们承诺永远不会主动停止服务，所以不用担心你文章内的链接将来不能使用。

再上面的链接页面内有个预留广告位，我们保留将来投放广告的可能性——但是将来万一（我说万一）真的要投放广告了，我们会给出几种方式，以使你免除被绑架的忧虑：

• 接受公众号或读者的捐赠或付款而享受免投放广告服务
• 之前没有投放过广告的链接页面，我们保证不会出现广告（根据首次出现的时间线判定）

当然，如果你实在不相信我的人品，那么这个原理其实不复杂，你可以自己实现一个这样的小程序。

当我们在基于 Ubuntu/Debian 的系统上使用 apt-clone，包安装会变得更加容易。如果你需要在少量系统上安装相同的软件包时，apt-clone 会适合你。

如果你想在每个系统上手动构建和安装必要的软件包，这是一个耗时的过程。它可以通过多种方式实现，Linux 中有许多程序可用。我们过去曾写过一篇关于 Aptik 的文章。它是能让 Ubuntu 用户备份和恢复系统设置和数据的程序之一。

什么是 apt-clone？

apt-clone 能让你为 Debian/Ubuntu 系统创建所有已安装软件包的备份，这些软件包可以在新安装的系统（或容器）或目录中恢复。

该备份可以在相同操作系统版本和架构的多个系统上还原。

如何安装 apt-clone？

apt-clone 包可以在 Ubuntu/Debian 的官方仓库中找到，所以，使用 apt 包管理器 或 apt-get 包管理器 来安装它。

使用 apt 包管理器安装 apt-clone。

$ sudo apt install apt-clone

使用 apt-get 包管理器安装 apt-clone。

$ sudo apt-get install apt-clone

如何使用 apt-clone 备份已安装的软件包？

成功安装 apt-clone 之后。只需提供一个保存备份文件的位置。我们将在 /backup 目录下保存已安装的软件包备份。

apt-clone 会将已安装的软件包列表保存到 apt-clone-state-Ubuntu18.2daygeek.com.tar.gz 中。

$ sudo apt-clone clone /backup

我们同样可以通过运行 ls 命令来检查。

$ ls -lh /backup/
total 32K
-rw-r--r-- 1 root root 29K Apr 20 19:06 apt-clone-state-Ubuntu18.2daygeek.com.tar.gz

运行以下命令，查看备份文件的详细信息。

$ apt-clone info /backup/apt-clone-state-Ubuntu18.2daygeek.com.tar.gz
Hostname: Ubuntu18.2daygeek.com
Arch: amd64
Distro: bionic
Meta: libunity-scopes-json-def-desktop, ubuntu-desktop
Installed: 1792 pkgs (194 automatic)
Date: Sat Apr 20 19:06:43 2019

根据上面的输出，备份文件中总共有 1792 个包。

如何恢复使用 apt-clone 进行备份的软件包？

你可以使用任何远程复制程序来复制远程服务器上的文件。

$ scp /backup/apt-clone-state-ubunt-18-04.tar.gz Destination-Server:/opt

复制完成后，使用 apt-clone 执行还原。

使用以下命令进行还原。

$ sudo apt-clone restore /opt/apt-clone-state-Ubuntu18.2daygeek.com.tar.gz

请注意，还原将覆盖现有的 /etc/apt/sources.list 并安装/删除包。所以要小心。

如果你要将所有软件包还原到文件夹而不是实际还原，可以使用以下命令。

$ sudo apt-clone restore /opt/apt-clone-state-Ubuntu18.2daygeek.com.tar.gz --destination /opt/oldubuntu

via: https://www.2daygeek.com/apt-clone-backup-installed-packages-and-restore-them-on-fresh-ubuntu-system/

作者：Magesh Maruthamuthu 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

开源社区中很少有法律话题像《贡献者许可协议》一样具有争议性。

开源社区中很少有法律话题像《贡献者许可协议》（CLA）一样具有争议性。除非你算上《Fedora 项目贡献者协议》（我一直被视为非 CLA）的特殊历史案例，或者像 Karl Fogel 一样，将《开发者原创证书》（DCO）归类为一种 CLA。目前红帽公司在其维护的项目中没有使用 CLA。

过去情况并非如此。红帽公司最早的项目遵循我称之为 “入站=出站” （ inbound=outbound ） 的传统做法，其中对项目的贡献仅根据项目的开源许可协议提供，不需要执行外部非自由和开源许可协议。但在 21 世纪初，红帽公司开始尝试使用贡献者协议。Fedora 开始要求贡献者签署基于广泛采用的 Apache ICLA 制定的 CLA，而自由软件基金会衍生的版权转让协议和一对定制的 CLA 分别继承自 Cygnus 和 JBoss 的收购。我们甚至采取了一些措施，在快速增长的红帽公司主导项目中采用 Apache 风格的 CLA。

这种情况已经结束，很大程度上是因为我们红帽公司法律团队成员听到并理解了红帽工程师和更广泛的技术社区提出的担忧和异议。我们继续成为一些人称之为反 CLA 运动的事实上的领导者，特别是我们反对 Project Harmony 以及我们努力让 OpenStack 用 DCO 取代其 CLA。（我们不情愿地签署可容忍的不符合实际需要的上游项目 CLA）

为什么 CLA 存在问题

我们不使用 CLA 的选择反映了我们作为一个真正的开源公司的价值观，它在自由软件运动中有着深厚的根源。多年来，许多开源社区已经解释了为什么 CLA 以及类似的版权分配机制对于开源来说是一个糟糕的政策。

其中一个原因是繁文缛节问题。通常情况下，开源开发的特点是 无障碍 （ frictionless ） 贡献，这可以通过“入站=出站”来实现，而不需要进行进一步的法律仪式或流程。这使得新贡献者相对容易参与项目，允许贡献者社区更有效的增长并推动上游的技术创新。无障碍贡献是开源开发针对专有替代品享有优势的关键部分。但是，CLA 否定了无障碍的贡献。在贡献被接受之前签署不寻常的法律协议会造成官僚主义障碍，从而减缓发展并阻碍参与。尽管采用 CLA 的项目越来越多地使用自动化手段，但这种成本仍然存在。

CLA 还会导致项目参与者之间的法律权力不对称，这也阻碍了项目周边主要贡献者和用户社区的增长。使用 Apache 风格的 CLA，领导项目的公司或组织获得其他贡献者无法获得的特殊权利，而其他贡献者必须承担项目负责人免除的某些法律义务（除了繁文缛节负担）。在 左版 （ copyleft ） 项目中，不对称问题最为严重，即使出站许可协议是宽松的，它也存在。

在评估支持和反对 CLA 的论据时，请记住，今天与过去一样，任何产品中的绝大多数开源代码都源于遵循“入站=出站”实践的项目。相对较少数量的项目使用 CLA 会对所有其他项目造成附带损害，因为它表明，由于某些原因，开源许可协议不足以处理流入项目的贡献。

CLA 的案例

由于 CLA 仍然是少数人的做法，并且源自外部开源社区文化，我认为 CLA 的支持者应该解释清楚为什么它们相对于其成本是必要或有益的。我怀疑大多数使用 CLA 的公司只是在没有经过严格审查的情况下模仿同行公司的行为。肤浅的来说，对于那些倾向于采用更复杂的手续、纸张和流程而不管业务成本如何的风险规避律师而言，CLA 是正常的。尽管如此，一些支持 CLA 的论据往往是先进的，值得考虑。

易于 再许可 （ relicensing ） ：如果管理得当，Apache 风格的 CLA 可以根据管理员的选择，为其提供有效的无限权力来进行分许可。这种做法有时被认为是可取的，因为可能需要依据一些其他开源许可协议再许可该项目。但是，回顾一些涉及大量贡献者的项目（所有这些项目都是在没有使用 CLA 的情况下取得成功）的重要再许可活动的历史案例，易于再许可的价值被夸大了。再许可变得困难很有好处，因为它会让项目产生稳定的法律期望，并鼓励项目在进行重大法律政策变更之前咨询其贡献者社区。在任何情况下，大多数“入站=出站”开源项目在其生命周期中从不尝试再许可，而对于少数这样做的项目来说，再许可将相对轻松，因为通常需要去联系的过去的贡献者的数量不会很大。

原创追踪：有的人声称 CLA 使项目能够严格跟踪具有一定法律效益的贡献的来源。目前尚不清楚在这方面使用 CLA 所取得的成就是因为通过保留 Git 提交历史这样的非 CLA 手段无法更好地处理。DCO 似乎更适合跟踪贡献，因为它通常在每个提交的基础上使用，而 CLA 是每个贡献者签署一次，并且在行政上与代码贡献分开。此外，原创跟踪通常被描述为对公众有益，但我知道项目无法对 CLA 接受记录提供透明的随时可行的公开访问。

许可撤销：一些 CLA 支持者警告说可能有一天，贡献者可能会试图撤销过去授予的许可。如果关注的范围是大量没有供职公司的具有判断力的个人贡献者，则不清楚为什么 Apache 风格的 CLA 与使用开源许可协议相比提供了更有意义的保护。而且，正如在讨论开源法律政策时提出的许多法律风险一样，这似乎是一种幻想的风险。多年来，我只听说过少数声称的许可撤销尝试活动，所有这些都在贡献者面临社区压力而退步时得到迅速解决。

未经授权的员工贡献：这是许可撤销问题的一个特例，最近已成为 CLA 倡导者共同提出的观点。当员工为上游项目提供贡献时，通常雇主拥有项目给予许可的版权和专利，并且只有某些管理人员有权授予此类许可。假设一名员工在未经雇主批准的情况下向项目提供了专有代码，雇主后来发现这一点并要求删除该项贡献或起诉该项目的用户。通过使用类似 Apache CCLA 及其陈述和签名要求的材料，加上一些适当的审查程序以确定 CCLA 签名者可能被授权签署（我怀疑大多数使用 CLA 的公司没有采取任何有意义的措施），可以将这种未经授权的贡献风险最小化。

基于常识和共同经验，我认为，在今天的几乎所有案例中，员工的贡献都是在雇主的实际或建设性知识基础上和同意下完成的。如果围绕开源软件存在高度诉讼风险，也许应该更加重视这种风险，但开源项目引发的诉讼仍然非常罕见。

更重要的是，我不知道任何针对“入站=出站”项目的非源自涉嫌开源许可协议违规的版权或专利侵权指控因使用CLA而被阻止的案例。特别是，当指出未经授权的贡献风险时，CLA 支持者经常引用专利风险，但 Apache 风格的 CLA 中的专利许可授权的设计范围非常狭窄。此外，企业对开源项目的贡献通常很少，规模较小（因此很容易更换），并且随着时间的推移可能会被丢弃。

备选方案

如果您的公司没有对反 CLA 案例买账并且对简单使用“入站=出站”感到不舒服，那么还有其他方法可以替代非对称且管理上繁琐的 Apache 风格的 CLA 要求。使用 DCO 作为“入站=出站”的补充至少消除了厌恶风险的 CLA 倡导者的一些担忧。如果必须使用真正的 CLA，则无需使 用Apach e模式（更不用说它的怪异衍生物）。考虑“Eclipse 贡献者协议”的非规范核心（基本上是包含在 CLA 内的 DCO），或者 软件自由保护协会 （ Software Freedom Conservancy ） 的 Selenium CLA，它仅仅是对“入站=出站”贡献策略进行仪式化。

作者简介：Richard Fontana 是红帽公司法律部门产品和技术团队的高级商业顾问。 他的大部分工作都集中在开源相关的法律问题上。

译者简介：薛亮，集慧智佳知识产权咨询公司总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

美国中央情报局（CIA）最近一改“神秘”形象，开始在社交网站上“抖机灵”。两周前，中情局在 Instagram 上发布一张“猜谜”照片，吸了一波流量，没想到7日却因在推特上分享的暗网链接“翻了车”。

“来洋葱网络（Tor network）找我们呀！”5 月 7 日，中情局一连在推特上发布了 4 条加密链接相关推文。中情局公布了其在洋葱网络的网址链接，承诺网友可以匿名通过该平台上向政府“提供信息”。

推特截图

中情局在推文中写到：“情报收集任务存在着安全、匿名、不可追踪等特点，洋葱网络也刚好具有同样特性。中情局信息一应俱全，如果想获得相关内容，请点击下方链接。”

推特截图

中情局此举也让网友感到疑惑：洋葱网络到底是不是间谍工具？推特上网友回复似乎不完全符合中情局的意。有网友断然拒绝：不用，谢谢！另有评论称：“原来中情局就是这么监视美国民众的。”

更有网友认为，中情局使用加密网络与罪犯和恐怖分子使用的是一样的，被讽刺称“肯定不会让人失望”。（海外网 张琪）

来源：cnBeta.COM

更多资讯

FBI 查获并捣毁暗网索引和新闻网站 Deep Dot Web

据外媒报道，美国 FBI 日前已查获暗网索引和新闻网站 Deep Dot Web。该网站的暗网现已被撤下，取而代之的是一个通知。根据通知了解到，FBI 联合电脑犯罪调查人员和欧洲执法部门并在接到搜查令后查封了该网站。

来源： 海外网
详情： http://t.cn/EoO361X

除 bug 务尽 Mozilla 再次更新 Firefox 以修复扩展被禁用的相关问题

上周末，Mozilla 意外地在桌面和 Android 上安装的 Firefox 浏览器上禁用了许多用户的附加组件，引发一阵混乱，一天后， Mozilla 推出 Firefox 66.0.4，许多问题就得到了解决，但事实上公司承认仍有一大批用户存在一些遗留问题，他们通常需要等待很长时间才会恢复正常，而使用今天新发布的 Firefox 66.0.5，就可以有立竿见影的疗效。

来源： cnBeta.COM

详情： http://t.cn/EoO3o8m

大连警方破获一起侵犯公民个人信息案 查获个人信息近亿条

大连警方近日成功破获一起侵犯公民个人信息案，抓获犯罪嫌疑人 1 名，查获公民个人信息数量近亿条。

来源： 新华网

详情： http://t.cn/EoO3NYO

（信息来源于网络，安华金和搜集整理）

消除一些关于 DevOps 的疑惑。

很多人初学 DevOps 时，看到它其中一个结果就问这个是如何得来的。其实理解这部分 Devops 的怎样实现并不重要，重要的是——理解（使用） DevOps 策略的原因——这是做一个行业的领导者还是追随者的差别。

你可能会听过些 Devops 的难以置信的成果，例如生产环境非常有弹性，就算是有个“ 癫狂的猴子 Chaos Monkey ）跳来跳去将不知道哪个插头随便拔下，每天仍可以处理数千个发布。这是令人印象深刻的，但就其本身而言，这是一个 DevOps 的证据不足的案例，其本质上会被一个反例#Proving_a_negative)困扰：DevOps 环境有弹性是因为严重的故障还没有被观测到。

有很多关于 DevOps 的疑惑，并且许多人还在尝试弄清楚它的意义。下面是来自我 LinkedIn Feed 中的某个人的一个案例：

最近我参加一些 #DevOps 的交流会，那里一些演讲人好像在倡导 #敏捷开发是 DevOps 的子集。不知为何，我的理解恰恰相反。

能听一下你们的想法吗？你认为敏捷开发和 DevOps 之间是什么关系呢？

1. DevOps 是敏捷开发的子集
2. 敏捷开发是 DevOps 的子集
3. DevOps 是敏捷开发的扩展，从敏捷开发结束的地方开始
4. DevOps 是敏捷开发的新版本

科技行业的专业人士在那篇 LinkedIn 的帖子上表达了各种各样的答案，你会怎样回复呢？

DevOps 源于精益和敏捷

如果我们从亨利福特的战略和丰田生产系统对福特车型的改进（的历史）开始， DevOps 就更有意义了。精益制造就诞生在那段历史中，人们对精益制作进行了良好的研究。James P. Womack 和 Daniel T. Jones 将精益思维（Lean Thinking）提炼为五个原则：

1. 指明客户所需的价值
2. 确定提供该价值的每个产品的价值流，并对当前提供该价值所需的所有浪费步骤提起挑战
3. 使产品通过剩余的增值步骤持续流动
4. 在可以连续流动的所有步骤之间引入拉力
5. 管理要尽善尽美，以便为客户服务所需的步骤数量和时间以及信息量持续下降

精益致力于持续消除浪费并增加客户的价值流动。这很容易识别并明白精益的核心原则：单一流。我们可以做一些游戏去了解为何同一时间移动单个比批量移动要快得多。其中的两个游戏是硬币游戏和飞机游戏。在硬币游戏中，如果一批 20 个硬币到顾客手中要用 2 分钟，顾客等 2 分钟后能拿到整批硬币。如果一次只移动一个硬币，顾客会在 5 秒内得到第一枚硬币，并会持续获得硬币，直到在大约 25 秒后第 20 个硬币到达。（LCTT 译注：有相关的视频的）

这是巨大的不同，但是不是生活中的所有事都像硬币游戏那样简单并可预测的。这就是敏捷的出现的原因。我们当然看到了高效绩敏捷团队的精益原则，但这些团队需要的不仅仅是精益去做他们要做的事。

为了能够处理典型的软件开发任务的不可预见性和变化，敏捷开发的方法论会将重点放在意识、审议、决策和行动上，以便在不断变化的现实中调整。例如，敏捷框架（如 srcum）通过每日站立会议和冲刺评审会议等仪式提高意识。如果 scrum 团队意识到新的事实，框架允许并鼓励他们在必要时及时调整路线。

要使团队做出这些类型的决策，他们需要高度信任的环境中的自我组织能力。以这种方式工作的高效绩敏捷团队在不断调整的同时实现快速的价值流，消除错误方向上的浪费。

最佳批量大小

要了解 DevOps 在软件开发中的强大功能，这会帮助我们理解批处理大小的经济学。请考虑以下来自Donald Reinertsen 的产品开发流程原则的U曲线优化示例：

这可以类比杂货店购物来解释。假设你需要买一些鸡蛋，而你住的地方离商店只有 30 分钟的路程。买一个鸡蛋（图中最左边）意味着每次要花 30 分钟的路程，这就是你的交易成本。持有成本可能是鸡蛋变质和在你的冰箱中持续地占用空间。总成本是交易成本加上你的持有成本。这个 U 型曲线解释了为什么对大部分人来说，一次买一打鸡蛋是他们的最佳批量大小。如果你就住在商店的旁边，步行到那里不会花费你任何的时候，你可能每次只会买一小盒鸡蛋，以此来节省冰箱的空间并享受新鲜的鸡蛋。

这 U 型优化曲线可以说明为什么在成功的敏捷转换中生产力会显著提高。考虑敏捷转换对组织决策的影响。在传统的分级组织中，决策权是集中的。这会导致较少的人做更大的决策。敏捷方法论会有效地降低组织决策中的交易成本，方法是将决策分散到最被人熟知的认识和信息的位置：跨越高度信任，自组织的敏捷团队。

下面的动画演示了降低事务成本后，最佳批量大小是如何向左移动。在更频繁地做出更快的决策方面，你不能低估组织的价值。

DevOps 适合哪些地方

自动化是 DevOps 最知名的事情之一。前面的插图非常详细地展示了自动化的价值。通过自动化，我们将交易成本降低到接近于零，实质上是可以免费进行测试和部署。这使我们可以利用越来越小的批量工作。较小批量的工作更容易理解、提交、测试、审查和知道何时能完成。这些较小的批量大小也包含较少的差异和风险，使其更易于部署，如果出现问题，可以进行故障排除和恢复。通过自动化与扎实的敏捷实践相结合，我们可以使我们的功能开发非常接近单件流程，从而快速、持续地为客户提供价值。

更传统地说，DevOps 被理解为一种打破开发团队和运营团队之间混乱局面的方法。在这个模型中，开发团队开发新的功能，而运营团队则保持系统的稳定和平稳运行。摩擦的发生是因为开发过程中的新功能将更改引入到系统中，从而增加了停机的风险，运营团队并不认为要对此负责，但无论如何都必须处理这一问题。DevOps 不仅仅尝试让人们一起工作，更重要的是尝试在复杂的环境中安全地进行更频繁的更改。

我们可以看看 Ron Westrum 在有关复杂组织中实现安全性的研究。在研究为什么有些组织比其他组织更安全时，他发现组织的文化可以预测其安全性。他确定了三种文化：病态的、官僚主义的和生产式的。他发现病态的可以预测其安全性较低，而生产式文化被预测为更安全（例如，在他的主要研究领域中，飞机坠毁或意外住院死亡的数量要少得多）。

高效的 DevOps 团队通过精益和敏捷的实践实现了一种生成性文化，这表明速度和安全性是互补的，或者说是同一个问题的两个方面。通过将决策和功能的最佳批量大小减少到非常小，DevOps 实现了更快的信息流和价值，同时消除了浪费并降低了风险。

与 Westrum 的研究一致，在提高安全性和可靠性的同时，变化也很容易发生。当一个敏捷的 DevOps 团队被信任做出自己的决定时，我们将获得 DevOps 目前最为人所知的工具和技术：自动化和持续交付。通过这种自动化，交易成本比以往任何时候都进一步降低，并且实现了近乎单一的精益流程，每天创造数千个决策和发布的潜力，正如我们在高效绩的 DevOps 组织中看到的那样

流动、反馈、学习

DevOps 并不止于此。我们主要讨论了 DevOps 实现了革命性的流程，但通过类似的努力可以进一步放大精益和敏捷实践，从而实现更快的反馈循环和更快的学习。在DevOps手册 中，作者除了详细解释快速流程外， DevOps 如何在整个价值流中实现遥测，从而获得快速且持续的反馈。此外，利用精益求精的突破和 scrum 的回顾，高效的 DevOps 团队将不断推动学习和持续改进深入到他们的组织的基础，实现软件产品开发行业的精益制造革命。

从 DevOps 评估开始

利用 DevOps 的第一步是，经过大量研究或在 DevOps 顾问和教练的帮助下，对高效绩 DevOps 团队中始终存在的一系列维度进行评估。评估应确定需要改进的薄弱或不存在的团队规范。对评估的结果进行评估，以找到具有高成功机会的快速获胜焦点领域，从而产生高影响力的改进。快速获胜非常重要，能让团队获取解决更具挑战性领域所需的动力。团队应该产生可以快速尝试的想法，并开始关注 DevOps 转型。

一段时间后，团队应重新评估相同的维度，以衡量改进并确立新的高影响力重点领域，并再次采纳团队的新想法。一位好的教练将根据需要进行咨询、培训、指导和支持，直到团队拥有自己的持续改进方案，并通过不断地重新评估、试验和学习，在所有维度上实现近乎一致。

在本文的第二部分中，我们将查看 Drupal 社区中 DevOps 调查的结果，并了解最有可能找到快速获胜的位置。

via: https://opensource.com/article/19/3/devops-most-important-tech-strategy

作者：Kelly Albrecht 选题：lujun9972 译者：zgj1024 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

加密你的数据并使其免受攻击者的攻击。

密码学俱乐部的第一条规则是：永远不要自己发明密码系统。密码学俱乐部的第二条规则是：永远不要自己实现密码系统：在现实世界中，在实现以及设计密码系统阶段都找到过许多漏洞。

Python 中的一个有用的基本加密库就叫做 cryptography。它既是一个“安全”方面的基础库，也是一个“危险”层。“危险”层需要更加小心和相关的知识，并且使用它很容易出现安全漏洞。在这篇介绍性文章中，我们不会涵盖“危险”层中的任何内容！

cryptography 库中最有用的高级安全功能是一种 Fernet 实现。Fernet 是一种遵循最佳实践的加密缓冲区的标准。它不适用于非常大的文件，如千兆字节以上的文件，因为它要求你一次加载要加密或解密的内容到内存缓冲区中。

Fernet 支持 对称 symmetric （即 密钥 secret key ）加密方式*：加密和解密使用相同的密钥，因此必须保持安全。

生成密钥很简单：

>>> k = fernet.Fernet.generate_key()
>>> type(k)
<class 'bytes'>

这些字节可以写入有适当权限的文件，最好是在安全的机器上。

有了密钥后，加密也很容易：

>>> frn = fernet.Fernet(k)
>>> encrypted = frn.encrypt(b"x marks the spot")
>>> encrypted[:10]
b'gAAAAABb1'

如果在你的机器上加密，你会看到略微不同的值。不仅因为（我希望）你生成了和我不同的密钥，而且因为 Fernet 将要加密的值与一些随机生成的缓冲区连接起来。这是我之前提到的“最佳实践”之一：它将阻止对手分辨哪些加密值是相同的，这有时是攻击的重要部分。

解密同样简单：

>>> frn = fernet.Fernet(k)
>>> frn.decrypt(encrypted)
b'x marks the spot'

请注意，这仅加密和解密字节串。为了加密和解密文本串，通常需要对它们使用 UTF-8 进行编码和解码。

20 世纪中期密码学最有趣的进展之一是 公钥 public key 加密。它可以在发布加密密钥的同时而让解密密钥保持保密。例如，它可用于保存服务器使用的 API 密钥：服务器是唯一可以访问解密密钥的一方，但是任何人都可以保存公共加密密钥。

虽然 cryptography 没有任何支持公钥加密的安全功能，但 PyNaCl 库有。PyNaCl 封装并提供了一些很好的方法来使用 Daniel J. Bernstein 发明的 NaCl 加密系统。

NaCl 始终同时 加密 encrypt 和 签名 sign 或者同时 解密 decrypt 和 验证签名 verify signature 。这是一种防止 基于可伸缩性 malleability-based 的攻击的方法，其中攻击者会修改加密值。

加密是使用公钥完成的，而签名是使用密钥完成的：

>>> from nacl.public import PrivateKey, PublicKey, Box
>>> source = PrivateKey.generate()
>>> with open("target.pubkey", "rb") as fpin:
... target_public_key = PublicKey(fpin.read())
>>> enc_box = Box(source, target_public_key)
>>> result = enc_box.encrypt(b"x marks the spot")
>>> result[:4]
b'\xe2\x1c0\xa4'

解密颠倒了角色：它需要私钥进行解密，需要公钥验证签名：

>>> from nacl.public import PrivateKey, PublicKey, Box
>>> with open("source.pubkey", "rb") as fpin:
... source_public_key = PublicKey(fpin.read())
>>> with open("target.private_key", "rb") as fpin:
... target = PrivateKey(fpin.read())
>>> dec_box = Box(target, source_public_key)
>>> dec_box.decrypt(result)
b'x marks the spot'

最后，PocketProtector 库构建在 PyNaCl 之上，包含完整的密钥管理方案。

via: https://opensource.com/article/19/4/cryptography-python

作者：Moshe Zadka 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出