我的团队不再采用标准的算法编程笔试，而是采用一套能够产出更多相关成果的流程。

作为初创安全公司 Profian 的首席执行官和联合创始人，我参与了我们聘请开发人员从事 Enarx 的工作。Enarx 是一个处理机密信息计算的安全项目，几乎完全用 Rust 语言 编写（少部分用汇编语言）。Profian 现在已经在这次招聘找到了所有要找的人，一些开发人员将在接下来的几周内开始工作。然而，Enarx 绝对欢迎新的贡献者，如果事情继续顺利，公司将来肯定会雇用更多的人。

招聘人员并不容易，加上 Profian 还有一系列特别的要求，这让招人变得更加困难。因此我认为分享我们如何解决这个问题应该还蛮有意思的，而且也会对社区有帮助。

我们寻找什么样的人才？

以下就是我前文提到的特别要求：

• 系统编程：Profian 主要需要那些喜欢系统层编程的人。这一层面的编程已经处于栈的底层，有很多直接与硬件或操作系统的交互。例如，要创建客户端-服务器部分，我们必须编写相当多的协议、管理加密等等，而这方面的工具还不是很成熟（请参阅下面的 “Rust” 一节）。
• Rust：项目几乎都是用 Rust 语言编写的，那些不是的则是用汇编语言写的（目前只有 x86 平台，尽管随着我们添加更多平台情况可能会有所改变）。Rust 是一门很新、很酷同时也令人兴奋的编程语言，但它同时也很年轻，并且一些领域没有你想要的所有支持或者没有你希望的那么成熟 —— 这包括从密码学到多线程库到编译器/构建基本架构。
• 分散各地的团队：Profian 正在建立一个能够及时通讯联系的团队。Profian 在德国、芬兰、荷兰、北卡罗来纳州（美国）、马萨诸塞州（美国）、弗吉尼亚州（美国）和乔治亚州（美国）都有开发人员。我在英国，我们的社区经理在巴西，我们有来自印度和尼日利亚的实习生。从一开始我们就知道团队很难聚集在一个地方工作，因此我们需要能够通过视频、聊天和（最不济的情况下）电子邮件与人交流和协作的成员。
• 安全：Enarx 是一个安全项目。虽然我们并不是专门在寻找安全专家，但我们需要能够将安全放在首位去思考和工作，并设计和编写适用于安全环境的代码的人。
• Git：我们所有的代码都存储在 Git 中（主要是 GitHub，还有一些存在 GitLab）。我们围绕代码的大部分交互都是围绕 Git 进行的，因此任何加入我们团队的人都需要能自如使用它作为日常工作中的标准工具。
• 开源：开源不仅仅是许可；更是一种心态，同时，这也是一种合作方式。大量开源软件是由不同地域的人创建的，他们甚至可能不认为彼此身处于一个团队。我们需要知道我们招的人不仅能在公司内部凝聚成一个紧密的团队，同时也能够与组织外部的人员协作，并接受 Profian 的“默认开放”文化，这里的开放不仅仅限于代码，还要有开放的讨论、沟通和文档。

我们是如何找到人才的？

正如我在其他地方提到的，招聘很困难。Profian 使用多种方式寻找候选人，它们取得了不同程度的成功：

• 领英招聘广告
• 领英搜索
• 特定语言的讨论板和招聘板（例如，Reddit）
• 外部招募人员（特别致敬来自 Interstem 公司的 Gerald）
• 口耳相传/个人推荐

虽然很难从质量方面判断这些来源如何，但如果没有外部招聘人员，我们肯定会在数量上苦苦挣扎（我们也有一些来自该途径的优秀候选人）。

我们如何筛选出想要的人才？

我们需要按照上述的所有要求衡量所有候选人，但并非所有要求都是同等重要的。例如，虽然我们热衷于雇用 Rust 程序员，但那些在系统级别具有强大 C/C++ 技能的人也能成为团队里有用的一份子，因为他们能够很快掌握 Rust 语言。另一方面，熟悉使用 Git 是至关重要的，因为我们无法花时间去培养新团队成员，让他们跟上我们的工作方式。

你可能会觉得很惊讶，但强大的开源背景并不是必需的要求，在类似模式中工作的心态是必需的，而任何有开源参与历史的人都可能对 Git 有很好的了解。同理，在一个分散各地的团队中工作的能力这一条件上，我们认为有过任意开源社区的参与经历都会是个积极的指标，因为有如此多的开源项目都是由分散各地的人们完成的。至于安全这一条件，我们则一致决定这只是一个“锦上添花”的条件。

我们想让这个过程简单快捷。 Profian 没有设置专门的人力资源部门或人力职能，因为我们正忙于编写代码。以下是我们最终使用的招聘流程（实际流程中可能略有不同），我们试图在 1-2 周内完成招聘：

1. 初审：个人履历/简历/GitHub/GitLab/领英主页，决定是否面试
2. 我作为 CEO 和候选人进行一场 30-40 分钟的讨论，了解他们是否适合我们团队的文化，同时让他们有机会了解我们，并了解他们是否真的像在初审提交的材料中所说的那样精通技术
3. 由 Nathaniel 领导的有关技术方面的深入讨论，通常我也在场
4. 与团队其他成员谈话
5. 编码笔试
6. 快速决策（通常在 24 小时内）

编码笔试很关键，但我们决定不采用通常的方法。我们的观点是，许多科技公司钟爱的纯“算法编码”笔试对我们想要的几乎毫无用处：考察候选人是否可以快速理解一段代码，解决一些问题，并与团队合作完成以上的工作。我们创建了一个 GitHub 存储库，其中包含一些几乎可以正常运行的 Rust 代码（事实上，我们最终使用了两个，其中一个用于技术栈上层的人），然后让候选人修复它，在上面执行一些与 Git 相关的过程，并稍作改进，在此过程中添加测试。

测试中一个必不可少的部分是让候选人通过我们的聊天室与团队互动。我们安排了 15 分钟的视频通话时间用于设置和初始问题，两个小时用于做笔试（“开卷”——以及与团队交谈，鼓励候选人使用互联网上所有可用的资源），然后是 30 分钟的总结会议，在这个会议上团队可以提出问题，候选人可以思考任务。这个谈话，结合笔试期间的聊天互动，让我们了解了候选人与团队沟通的能力。候选人挂断电话之后我们通常会在 5-10 分钟内决定是否要雇用他们。

这种方法通常效果很好。一些候选人在任务上遇到困难，一些人沟通不畅，一些人在 Git 交互方面做得不好 —— 这些是我们没有雇佣的人。这并不意味着他们不是优秀的程序员或者以后不适合该项目或公司，但他们不符合我们现在需要的标准。在我们聘用的开发人员中，他们的 Rust 经验水平和与团队互动的需求各不相同，但 Git 专业知识水平以及他们在和我们讨论之后的反应始终足以让我们决定接受他们。

感想

总的来说，我不认为我们会对筛选过程进行大的改动 —— 尽管我很确定我们可以在搜寻过程环节做得更好。通过编码笔试，我们可以筛选掉相当多的候选人，而且很好地帮了我们挑选合适的人。希望通过了这次选拔的每个人都很适合这个项目并且产出出色的代码（以及测试和文档等等）。时间会证明一切！

本文最初发布于 Alice、Eve 和 Bob – 安全博客 上，经许可后重新发布。

via: https://opensource.com/article/22/2/how-we-hired-open-source-developer

作者：Mike Bursell 选题：lujun9972 译者：XiaotingHuang22 校对：wxy

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

对开源的信任是一个正反馈循环。

这是我即将在 Wiley 出版的《 计算和云计算中的信任 Trust in Computing and the Cloud 》一书中经过编辑的节选，也是我之前写的一篇文章 《信任与选择开源》 Trust & choosing open source 的延伸。

在那篇文章中，我提出了一个问题。当我们说 “我相信开放源码软件” 时，我们在做什么？作为回答，我认为，我们正在做的是确定有足够多的编写和测试该软件的人与我有类似的要求，而且他们的专业知识加在一起，使我使用该软件的风险可以接受。我同时也介绍了 “ 分布式信任 distributed trust ” 的概念。

在社区内分布信任的概念是亚里士多德提出的 “ 人群智慧理论 wisdom of the crowd theory ” 的应用，其中的假设是，许多人的意见通常比一个人或少数人的意见更有明智。虽然在某些情况下，最简单的形式显然是错误的 —— 最明显的例子是民众对极权主义政权的支持 —— 但这一原则可以为建立某些信息提供一个非常有效的机制。

我们称这种集体经验的提炼为“分布式信任”，它通过互联网上的许多机制收集。如 TripAdvisor 或 Glassdoor，记录了关于组织或其提供的服务的信息，还有像 UrbanSitter 或 LinkedIn，允许用户添加关于特定人的信息（例如，见 LinkedIn 的推荐和技能与个人档案中的认可部分）。从这些例子中可以获得的利益因网络效应而大大增加，因为随着成员数量的增加，成员之间可能的联系数量也成倍增加。

分布式信任的例子还包括像 Twitter 这样的平台，一个账户的追随者数量可以被视为衡量其声誉，甚至是衡量其可信度的标准，我们应该以强烈的怀疑态度去看待这种计算。事实上，Twitter 认为它必须解决拥有大量追随者的账户的社会力量问题，并建立了一个为 “验证账户” 机制，让人们知道 “一个具有公共利益的账户是真实的”。但是有趣的是，该公司不得不暂停这项服务，因为用户对 “验证” 的确切含义或暗示的期望出现了问题：这就是不同群体之间对内容理解不同的典型案例。

那么，开源的相关性在哪里呢？开源的社区方面实际上就是建立分布式信任的一个驱动力。因为一旦你成为一个开源项目周围社区的一部分，你就会承担一个或多个角色，一旦你说你 “信任” 一个开源项目，你就会开始信任这些角色（见我之前的文章）。例如，架构师、设计师、开发人员、审查人员、技术写作、测试人员、部署人员、错误报告者或错误修复者。你对一个项目的参与越多，你就越是社区的一部分，久而久之，这就可以成为一个 “ 实践社区 community of practice ”。

Jean Lave 和 Etienne Wenger 在 《情境学习：正当的外围参与》 Situated Learning: Legitimate Peripheral Participation 一书中提出了实践社区的概念，团体在成员热情分享和参与共同活动的过程中演变成社区，导致他们的技能和知识共同提高。这里的核心概念是：当参与者围绕实践社区进行学习时，他们同时也成为社区的成员。

“正当的的外围参与既指在实践中知识技能身份的发展，也指实践社区的再生产和转化。”

Wenger 在 《实践社区：学习、意义和身份》 Communities of Practice: Learning, Meaning, and Identity 中进一步探讨了实践社区的概念：它们如何形成、对其健康的要求，以及它们如何鼓励学习。他认为，意义的可协商性（“我们为什么要一起工作，我们要实现什么？”）是实践社区的核心，并指出，如果没有个人的参与、想象力和一致性，实践社区将不会有活力。

我们可以把这一点与我们对分布式信任如何建立和构建的看法结合起来：当你意识到你对开源的影响可以与其他人的影响相同时，你对社区成员的分布式信任关系就变得不那么具有传递性（第二或第三手甚至更遥远），而是更加直接。你明白，你对你所运行的软件的创建、维护、需求和质量所能产生的影响，可以与所有其他以前匿名的贡献者一样，你现在正在与他们形成一个实践社区，或者你正在加入他们的现有实践社区。然后，你就会成为一个信任关系网络的一部分，这个网络是分布式的，但与你购买和操作专利软件时的经历相差不大。

这个过程并不会停止：因为开源项目的一个共同属性是“交叉授粉”，即一个项目的开发者也在其他项目上工作。由于多个开源项目之间的网络效应，使得对其他项目的重用和依赖性上升，导致整个项目的吸收量增加。

这就很容易理解为什么许多开源贡献者会成为开源爱好者或传道者，不仅仅是为单个项目，而是为整个开源项目。事实上，斯坦福大学社会学家 Mark Granovetter 的工作表明，社区内太多的强关系会导致小团体和停滞不前，但弱关系会使思想和趋势在社区内流动。这种对其他项目和围绕它们存在的社区的认识，以及想法在项目间的灵活性，导致分布式信任能够被扩展（尽管保证比较弱），超越贡献者在他们有直接经验的项目中所经历的直接或短链间接关系，并向其他项目扩展，因为外部观察或外围参与显示贡献者之间存在类似关系。

简单地说，参与开源项目并通过参与建立信任关系的行为会导致对类似的开源项目或只是对其他类似的开源项目产生更强的分布式信任。

这对我们每个人来说意味着什么？它意味着我们越是参与开源，我们对开源的信任度就越高，而其他人对开源的参与度也会相应提高，从而对开源的信任度也会提高。对开源的信任不仅仅是一个网络效应：它是一个正反馈循环！

本文最初发表于 Alice, Eve, and Bob，经作者许可转载。

via: https://opensource.com/article/21/1/open-source-distributed-trust

作者：Mike Bursell 选题：lujun9972 译者：MareDevi 校对：wxy

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

从 Rust 标准库学习一些有用的关键字。

我使用 Rust 已经有几个月了，写的东西比我预期的要多——尽管随着我的学习，我改进了所写的代码，并完成了一些超出我最初意图的更复杂的任务，相当多的东西已经被扔掉了。

我仍然喜欢它，并认为谈论一些在 Rust 中反复出现的重要关键字可能会有好处。我会提供我个人对它们的作用的总结：为什么你需要考虑如何使用它们，以及任何其他有用的东西，特别是对于刚接触 Rust 的新手或来自另一种语言的人（如 Java；请阅读我的文章 为什么作为一个 Java 程序员的我喜欢学习 Rust）。

事不宜迟，让我们开始吧。获取更多信息的好地方总是 Rust 官方文档 —— 你可能想从 std 标准库开始。

1. const – 你可以用 const 来声明常量，而且你应该这样做。虽然这不是造火箭，但请一定要用 const ，如果你要在不同的模块中使用常量，那请创建一个 lib.rs 文件（Rust 默认的），你可以把所有的常量放在一个命名良好的模块中。我曾经在不同模块的不同文件中发生过 const 变量名（和值）的冲突，仅仅是因为我太懒了，除了在不同文件中剪切和粘贴之外，我本可以通过创建一个共享模块来节省大量的工作。
2. let – 你并不 总是 需要用 let 语句声明一个变量，但当你这样做时你的代码会更加清晰。此外，如果可以，请一定要添加变量类型。Rust 会尽最大努力猜测它应该是什么类型的变量，但它不一定总能在运行时做到这一点（在这种情况下，编译器 Cargo 会提示你），它甚至可能做不到你期望的那样。在后一种情况下，对于 Cargo 来说，抱怨你所赋值的函数（例如）与声明不一致，总比 Rust 试图帮助你做错事，而你却不得不在其他地方花费大量时间来进行调试要简单。
3. match – match 对我来说是新鲜事物，我喜欢使用它。它与其他编程语言中的 switch 没有什么不同，但在 Rust 中被广泛使用。它使代码更清晰易读，如果你做了一些愚蠢的事情（例如错过一些可能的情况），Cargo 会很好地提示你。我一般的经验法则是，在管理不同的选项或进行分支时，如果可以使用 match，那就请一定要使用它。
4. mut – 在声明一个变量时，如果它的值在声明后会发生变化，那么你需要声明它是可变的（LCTT 译注：Rust 中变量默认是不可变的）。常见的错误是在某个变量 没有 变化的情况下声明它是可变的，这时编译器会警告你。如果你收到了 Cargo 的警告，说一个可变的变量没有被改变，而你认为它被 改变 了，那么你可能要检查该变量的范围，并确保你使用的是正确的那个。
5. return – 实际上我很少使用 return，它用于从函数中返回一个值，但是如果你只是在函数的最后一行提供值（或提供返回值的函数），通常会变得更简单，能更清晰地阅读。警告：在很多情况下，你 会 忘记省略这一行末尾的分号（;），如果你这样做，编译器会不高兴的。
6. unsafe – 如其意：如果你想做一些不能保证 Rust 内存安全的事情，那么你就需要使用这个关键字。我绝对无意在现在或将来的任何时候宣布我的任何 Rust 代码不安全；Rust 如此友好的原因之一是它阻止了这种黑客行为。如果你真的需要这样做，再想想，再想想，然后重新设计代码。除非你是一个非常低级的系统程序员，否则要 避免 使用 unsafe。
7. use – 当你想使用另一个 crate 中的东西时，例如结构体、变量、函数等，那么你需要在你要使用它的代码的代码块的开头声明它。另一个常见的错误是，你这样做了，但没有在 Cargo.toml 文件中添加该 crate （最好有一个最小版本号）。

我知道，这不是我写过的最复杂的文章，但这是我在开始学习 Rust 时会欣赏的那种文章。我计划在关键函数和其他 Rust 必知知识方面编写类似的文章：如果你有任何要求，请告诉我！

本文最初发表于 Alice, Eve, and Bob 经作者许可转载。

via: https://opensource.com/article/20/10/keywords-rust

作者：Mike Bursell 选题：lujun9972 译者：mcfd 校对：wxy

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

在我学习 Rust 的过程中，我注意到了 Rust 一族的一些常见行为。

我是最近才 皈依 Rust 的，我大约在是 2020 年 4 月底开始学习的。但是，像许多皈依者一样，我还是一个热情的布道者。说实话，我也不是一个很好的 Rust 人，因为我的编码风格不是很好，我写的也不是特别符合 Rust 习惯。我猜想这一方面是因为我在写大量代码之前还没有没有真正学完 Rust（其中一些代码又困扰了我），另一方面是因为我并不是那么优秀的程序员。

但我喜欢 Rust，你也应该喜欢吧。它很友好，比 C 或 C++ 更友好；它为低级系统任务做好了准备，这比 Python 做的更好；而且结构良好，这要超过 Perl；而且，最重要的是，从设计层面开始，它就是完全开源的，这要比 Java 那些语言好得多。

尽管我缺乏专业知识，但我注意到了一些我认为是许多 Rust 爱好者和程序员的共同点。如果你对以下五个迹象点头（其中第一个迹象是由最近的一些令人兴奋的新闻引发的），那么你也可能是一个 Rust 程序员。

1、“基金会”一词会使你兴奋

对于 Rust 程序员来说，“基金会”一词将不再与 艾萨克·阿西莫夫 Isaac Asimov 关联在一起，而是与新成立的 Rust 基金会 关联。微软、华为、谷歌、AWS 和Mozilla 为该基金会提供了董事（大概也提供了大部分初始资金），该基金会将负责该语言的各个方面，“预示着 Rust 成为企业生产级技术的到来”，根据临时执行董事 Ashley Williams 说。（顺便说一句，很高兴看到一位女士领导这样一项重大的行业计划。）

该基金会似乎致力于维护 Rust 的理念，并确保每个人都有参与的机会。在许多方面，Rust 都是开源项目的典型示例。并不是说它是完美的（无论是语言还是社区），而是因为似乎有足够的爱好者致力于维护高参与度、低门槛的社区方式，我认为这是许多开源项目的核心。我强烈欢迎此举，我认为这只会帮助促进 Rust 在未来数年和数月内的采用和成熟。

2、你会因为新闻源中提到 Rust 游戏而感到沮丧

还有一款和电脑有关的东西，也叫做“Rust”，它是一款“只限多玩家生存类的电子游戏”。它比 Rust 这个语言更新一些（2013 年宣布，2018 年发布），但我曾经在搜索 Rust 相关的内容时，犯了一个错误，用这个名字搜索了游戏。互联网络就是这样的，这意味着我的新闻源现在被这个另类的 Rust 野兽感染了，我现在会从它的影迷和公关人员那里随机得到一些更新消息。这是个低调的烦恼，但我很确定在 Rust（语言）社区中并不是就我一个人这样。我强烈建议，如果你确实想了解更多关于这个计算世界的后起之秀的信息，你可以使用一个提高隐私（我拒绝说 "保护隐私"）的 开源浏览器 来进行研究。

3、“不安全”这个词会让你感到恐惧。

Rust（语言，再次强调）在帮助你做正确的事情™方面做得非常好，当然，在内存安全方面，这是 C 和 C++ 内部的主要关注点（不是因为不可能做到，而是因为真的很难持续正确）。Dave Herman 在 2016 年写了一篇文章《Safety is Rust's fireflower》，讲述了为什么安全是 Rust 语言的一个积极属性。安全性（内存、类型安全）可能并不赏心悦目，但随着你写的 Rust 越多，你就会习惯并感激它，尤其是当你参与任何系统编程时，这也是 Rust 经常擅长的地方。

现在，Rust 并不能阻止你做错误的事情™，但它确实通过让你使用 unsafe 关键字，让你在希望超出安全边界的时候做出一个明智的决定。这不仅对你有好处，因为它（希望）会让你非常、非常仔细地思考你在任何使用它的代码块中放入了什么；它对任何阅读你的代码的人也有好处，这是一个触发词，它能让任何不太清醒的 Rust 人至少可以稍微打起精神，在椅子上坐直，然后想：“嗯，这里发生了什么？我需要特别注意。”如果幸运的话，读你代码的人也许能想到重写它的方法，使它利用到 Rust 的安全特性，或者至少减少提交和发布的不安全代码的数量。

4、你想知道为什么没有 ?;、{:?} 、::<> 这样的表情符号

人们喜欢（或讨厌）涡轮鱼（::<>），但在 Rust 代码中你经常还会看到其他的语义结构。特别是 {:?} （用于字符串格式化）和 ?;（? 是向调用栈传播错误的一种方式，; 则是行/块的结束符，所以你经常会看到它们在一起）。它们在 Rust 代码中很常见，你只需边走边学，边走边解析，而且它们也很有用，我有时会想，为什么它们没有被纳入到正常对话中，至少可以作为表情符号。可能还有其他的。你有什么建议？

5、Clippy 是你的朋友（而不是一个动画回形针）

微软的动画回形针 Clippy 可能是 Office 用户很快就觉得讨厌的“功能”，并成为许多 模因 的起点。另一方面，cargo clippy 是那些 很棒的 Cargo 命令 之一，应该成为每个 Rust 程序员工具箱的一部分。Clippy 是一个语言 整洁器 Linter ，它可以帮助改进你的代码，使它更干净、更整洁、更易读、更惯用，让你与同事或其他人分享 Rust 代码时，不会感到尴尬。Cargo 可以说是让 “Clippy” 这个名字恢复了声誉，虽然我不会选择给我的孩子起这个名字，但现在每当我在网络上遇到这个词的时候，我不会再有一种不安的感觉。

这篇文章最初发表在 [Alice, Eve, and Bob] 9上，经作者许可转载。

via: https://opensource.com/article/21/3/rust-programmer

作者：Mike Bursell 选题：lujun9972 译者：wxy 校对：wxy

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

互联网诞生之时我的个人故事。

最近，我和大家 分享了 我在 1994 年获得英国文学和神学学位离开大学后，如何在一个人们还不知道 Web 服务器是什么的世界里成功找到一份运维 Web 服务器的工作。我说的“世界”，并不仅仅指的是我工作的机构，而是泛指所有地方。Web 那时当真是全新的 —— 人们还正尝试理出头绪。

那并不是说我工作的地方（一家学术出版社）特别“懂” Web。这是个大部分人还在用 28.8K 猫（调制解调器，俗称“猫”）访问网页的世界。我还记得我拿到 33.6K 猫时有多激动。至少上下行速率不对称的日子已经过去了， ^[1] 以前 1200/300 的带宽描述特别常见。这意味着（在同一家机构的）印刷人员制作的设计复杂、色彩缤纷、纤毫毕现的文档是完全不可能放在 Web 上的。我不能允许在网站的首页出现大于 40k 的 GIF 图片，这对我们的许多访问者来说是很难接受的。大于大约 60k 图片的会作为独立的图片，以缩略图链接过去。

如果说市场部只有这一点不喜欢，那是绝对是轻描淡写了。更糟的是布局问题。“浏览器决定如何布局文档，”我一遍又一遍地解释，“你可以使用标题或者段落，但是文档在页面上如何呈现并不取决于文档，而是取决于渲染器！”他们想控制这些，想要不同颜色的背景。后来明白了那些不能实现。我觉得我就像是参加了第一次讨论层叠样式表（CSS）的 W3C 会议，并进行了激烈地争论。关于文档编写者应控制布局的建议真令人厌恶。 ^[2] CSS 花了一些时间才被人们采用，与此同时，关心这些问题的人搭上了 PDF 这种到处都是安全问题的列车。

如何呈现文档不是唯一的问题。作为一个实体书出版社，对于市场部来说，拥有一个网站的全部意义在于，让客户（或者说潜在的客户）不仅知道一本书的内容，而且知道买这本书需要花多少钱。但这有一个问题，你看，互联网，包括快速发展的万维网，是开放的，是所有都免费的自由之地，没有人会在意钱；事实上，在那里谈钱是要回避和避免的。

我和主流“网民”的看法一致，认为没必要把价格信息放在线上。我老板，以及机构里相当多的人都持相反的意见。他们觉得消费者应该能够看到书要花多少钱。他们也觉得我的银行经理也会想看到我的账户里每个月进了多少钱，如果我不认同他们的观点的话，那我的收入就可能堪忧。

幸运的是，在我被炒鱿鱼之前，我已经自己认清了一些 —— 可能是在我开始迈入 Web 的几星期之后，Web 已经发生变化，有其他人公布他们的产品价格信息。这些新来者通常被那些从早期就开始运行 Web 服务器的老派人士所看不起， ^[3] 但很明显，风向是往那边吹的。然而，这并不意味着我们的网站就赢得了战争。作为一个学术出版社，我们和大学共享一个域名（在 “ac.uk” 下）。大学不太相信发布价格信息是合适的，直到出版社的一些资深人士指出，普林斯顿大学出版社正在这样做，如果我们不做……看起来是不是有点傻？

有趣的事情还没完。在我担任站点管理员（“webmaster@…”）的短短几个月后，我们和其他很多网站一样开始看到了一种令人担忧的趋势。某些访问者可以轻而易举地让我们的 Web 服务器跪了。这些访问者使用了新的网页浏览器：网景浏览器（Netscape）。网景浏览器实在太恶劣了，它居然是多线程的。

这为什么是个问题呢？在网景浏览器之前，所有的浏览器都是单线程。它们一次只进行一个连接，所以即使一个页面有五张 GIF 图， ^[4] 也会先请求 HTML 基本文件进行解析，然后下载第一张 GIF，完成，接着第二张，完成，如此类推。事实上，GIF 的顺序经常出错，使得页面加载得非常奇怪，但这也是常规思路。而粗暴的网景公司的人决定，它们可以同时打开多个连接到 Web 服务器，比如说，可以同时请求所有的 GIF！为什么这是个问题呢？好吧，问题就在于大多数 Web 服务器都是单线程的。它们不是设计来一次进行多个连接的。确实，我们运行的 HTTP 服务的软件（MacHTTP）是单线程的。尽管我们花钱购买了它（最初是共享软件），但我们用的这版无法同时处理多个请求。

互联网上爆发了大量讨论。这些网景公司的人以为他们是谁，能改变世界的运作方式？它应该如何工作？大家分成了不同阵营，就像所有的技术争论一样，双方都用各种技术热词互丢。问题是，网景浏览器不仅是多线程的，它也比其他的浏览器更好。非常多 Web 服务器代码维护者，包括 MacHTTP 作者 Chuck Shotton 在内，开始坐下来认真地在原有代码基础上更新了多线程测试版。几乎所有人立马转向测试版，它们变得稳定了，最终，浏览器要么采用了这种技术，变成多线程，要么就像所有过时产品一样销声匿迹了。 ^[5]

对我来说，这才是 Web 真正成长起来的时候。既不是网页展示的价格，也不是设计者能定义你能在网页上看到什么， ^[6] 而是浏览器变得更易用，以及成千上万的浏览者向数百万浏览者转变的网络效应，使天平向消费者而不是生产者倾斜。在我的旅程中，还有更多故事，我将留待下次再谈。但从这时起，我的雇主开始看我们的月报，然后是周报、日报，并意识到这将是一件大事，真的需要关注。

1. 它们又是怎么回来的？ ↩︎
2. 你可能不会惊讶，我还是在命令行里最开心。 ↩︎
3. 大约六个月前。 ↩︎
4. 莽撞，没错，但它确实发生了 ^[7] ↩︎
5. 没有真正的沉寂：总有一些坚持他们的首选解决方案具有技术上的优势，并哀叹互联网的其他人都是邪恶的死硬爱好者。 ^[8] ↩︎
6. 我会指出，为那些有各种无障碍需求的人制造严重而持续的问题。 ↩︎
7. 噢，不，是 GIF 或 BMP，JPEG 还是个好主意，但还没有用上。 ↩︎
8. 我不是唯一一个说“我还在用 Lynx”的人。 ↩︎

via: https://opensource.com/article/19/3/when-web-grew

作者：Mike Bursell 选题：lujun9972 译者：XYenChi 校对：wxy

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

从输出的哈希值反推回输入，这从计算的角度是不可行的。

无论安全从业人员用计算机做什么，有一种工具对他们每个人都很有用：加密 哈希（散列） hash 函数。这听起来很神秘、很专业，甚至可能有点乏味，但是， 在这里，关于什么是哈希函数以及它们为什么对你很重要，我会作出一个简洁的解释。

加密哈希函数，比如 SHA-256 或者 MD5，接受一组二进制数据（通常是字节）作为输入，并且对每个可能的输入集给出一个 希望唯一 hopefully unique 的输出。对于任意模式的输入，给定的哈希函数的输出（“哈希值”）的长度都是一样的（对于 SHA-256，是 32 字节或者 256 比特，这从名字中就能看出来）。最重要的是：从输出的哈希值反推回输入，这从计算的角度是 不可行的 implausible （密码学家讨厌 “ 不可能 impossible ” 这个词）。这就是为什么它们有时候被称作 单向哈希函数 one-way hash function 。

但是哈希函数是用来做什么的呢？为什么“唯一”的属性如此重要？

唯一的输出

在描述哈希函数的输出时，“ 希望唯一 hopefully unique ”这个短语是至关重要的，因为哈希函数就是用来呈现完全唯一的输出。比如，哈希函数可以用于验证 你 下载的文件副本的每一个字节是否和 我 下载的文件一样。你下载一个 Linux 的 ISO 文件或者从 Linux 的仓库中下载软件时，你会看到使用这个验证过程。没有了唯一性，这个技术就没用了，至少就通常的目的而言是这样的。

如果两个不同的输入产生了相同的输出，那么这样的哈希过程就称作“ 碰撞 collision ”。事实上，MD5 算法已经被弃用，因为虽然可能性微乎其微，但它现在可以用市面上的硬件和软件系统找到碰撞。

另外一个重要的特性是，消息中的一个微小变化，甚至只是改变一个比特位，都可能会在输出中产生一个明显的变化（这就是“ 雪崩效应 avalanche effect ”）。

验证二进制数据

哈希函数的典型用途是当有人给你一段二进制数据，确保这些数据是你所期望的。无论是文本、可执行文件、视频、图像或者一个完整的数据库数据，在计算世界中，所有的数据都可以用二进制的形式进行描述，所以至少可以这么说，哈希是广泛适用的。直接比较二进制数据是非常缓慢的且计算量巨大，但是哈希函数在设计上非常快。给定两个大小为几 M 或者几 G 的文件，你可以事先生成它们的哈希值，然后在需要的时候再进行比较。

通常，对哈希值进行签名比对大型数据集本身进行签名更容易。这个特性太重要了，以至于密码学中对哈希值最常见的应用就是生成“数字”签名。

由于生成数据的哈希值很容易，所以通常不需要有两套数据。假设你想在你的电脑上运行一个可执行文件。但是在你运行之前，你需要检查这个文件就是你要的文件，没有被黑客篡改。你可以方便快捷的对文件生成哈希值，只要你有一个这个哈希值的副本，你就可以相当肯定这就是你想要的文件。

下面是一个简单的例子：

$ shasum -a256 ~/bin/fop
87227baf4e1e78f6499e4905e8640c1f36720ae5f2bd167de325fd0d4ebc791c  /home/bob/bin/fop

如果我知道 fop 这个可执行文件的 SHA-256 校验和，这是由供应商（这个例子中是 Apache 基金会）提供的：

87227baf4e1e78f6499e4905e8640c1f36720ae5f2bd167de325fd0d4ebc791c

然后我就可以确信，我驱动器上的这个可执行文件和 Apache 基金会网站上发布的文件是一模一样的。这就是哈希函数难以发生碰撞（或者至少是 很难通过计算得到碰撞）这个性质的重要之处。如果黑客能将真实文件用哈希值相同的文件轻易的进行替换，那么这个验证过程就毫无用处。

事实上，这些性质还有更技术性的名称，我上面所描述的将三个重要的属性混在了一起。更准确地说，这些技术名称是：

1. 抗原像性 pre-image resistance ：给定一个哈希值，即使知道用了什么哈希函数，也很难得到用于创建它的消息。
2. 抗次原像性 second pre-image resistance ：给定一个消息，很难找到另一个消息，使得这个消息可以产生相同的哈希值。
3. 抗碰撞性 collision resistance ：很难得到任意两个可以产生相同哈希值的消息。

抗碰撞性 和 抗次原像性 也许听上去是同样的性质，但它们具有细微而显著的不同。抗次原像性 说的是如果 已经 有了一个消息，你也很难得到另一个与之哈希值相匹配的消息。抗碰撞性 使你很难找到两个可以生成相同哈希值的消息，并且要在哈希函数中实现这一性质则更加困难。

让我回到黑客试图替换文件（可以通过哈希值进行校验）的场景。现在，要在“外面”使用加密哈希算法（除了使用那些在现实世界中由独角兽公司开发的完全无 Bug 且安全的实现之外），还有一些重要且困难的附加条件需要满足。认真的读者可能已经想到了其中一些，特别需要指出的是：

1. 你必须确保自己所拥有的哈希值副本也没有被篡改。
2. 你必须确保执行哈希算法的实体能够正确执行并报告了结果。
3. 你必须确保对比两个哈希值的实体确实报告了这个对比的正确结果。

确保你能满足这些条件绝对不是一件容易的事。这就是 可信平台模块 Trusted Platform Modules （TPM）成为许多计算系统一部分的原因之一。它们扮演着信任的硬件基础，可以为验证重要二进制数据真实性的加密工具提供保证。TPM 对于现实中的系统来说是有用且重要的工具，我也打算将来写一篇关于 TPM 的文章。

via: https://opensource.com/article/20/7/hash-functions

作者：Mike Bursell 选题：lujun9972 译者：Yufei-Yan 校对：wxy

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