ACM

ACM通信

首页 / 的意见 / 文章 / 必须和不可以 /全文

Kode恶性

必须和不可以

作者:George V. Neville-Neil
ACM通信，2019年8月，第62卷第8期，30-31页
10.1145 / 3341227
评论

认为: 打印手机应用程序 ACM数字图书馆全文(PDF) 数码版分享: 通过电子邮件发送在reddit分享在StumbleUpon分享在黑客新闻上分享在推特上分享在Facebook上分享

亲爱的KV,

我加入了一家小型安全初创公司，负责撰写我们的内部安全流程。问题是，我不是一个作家，我是一个软件工程师，每当我开始试图写我们的过程，我要么盯着一个空白的屏幕，直到我感到沮丧，然后把目光移开做其他的事情，或者我只是写了很多句子，后来似乎没有什么意义。我相信一定有一个模板，可以让我把所有这些事情以一种有用的方式写在我的脑子里，但我不确定去哪里找。例如，我想要一种方法向人们描述他们应该和不应该使用我们的软件做什么，以及必须如何使用它，以提供他们期望的安全属性。当我试着写这方面的文章时，我看到的是一种意大利面条般的文字交织在一起。

纠结的

亲爱的纠缠,

通常情况下，我的回答是，要想完成大量的写作，唯一的方法就是痛饮三天，然后在清醒之前，坐在键盘前，把你的心和灵魂倾注到你的文本缓冲器中，保存你的工作，在阅读你写的东西之前再痛饮一次。也许行不通，但御术师应该会很有趣。

事实上，我要做的是向你们推荐一个20多年的文档，RFC 2119。KV之前提到过RFC(征求意见);这是一组可以追溯到20世纪70年代早期的文件，其中描述了互联网协议和许多其他协议。对于那些不熟悉这些文档的人来说，它们总是使用少数关键字来指定协议的哪些部分是必须的或可选的:“关键字‘必须’、‘必须’、‘必须’、‘必须’、‘应当’、‘不应当’、‘应该’、‘不应该’、‘建议’、‘可以’和‘可选’”(参见“rfc中用于指示需求级别的关键字”;https://tools.ietf.org/html/rfc2119）

这些词的意思用ASCII编码在两页里，这是一种古老的文本交流标准。这些关键词的唯一强调形式是大写的。事实证明，为了清晰地交流，没有必要使用花哨的格式;事实上，花哨的格式往往会分散你想要传达的信息。

不，我不仅仅是建议你使用这样的语言;我相信你必须使用这些条款作为书面，然后引用RFC。通过引用来让一群人理解你的意思，或者用一份知名且编写良好的文档击败他们，可以为你节省很多时间和麻烦。文件越长，争论的地方就越多，要挑的毛病也就越多。减少挑剔可以节省很多时间。

当您计划在安全文档中使用这些术语时，请注意:必须谨慎使用这些词，以达到最大的效果。一长串“必须”和“不能”的清单会让人感到乏味和无聊，并失去读者的注意力。粗心的读者会犯错误，在这种情况下，它们将是安全错误，这是您的文档试图帮助他们避免的错误类型。让我再分享一段来自RFC的内容:“这些术语经常用于指定具有安全影响的行为。不实现MUST或SHOULD，或做规范规定的MUST not或SHOULD not所做的事情，对安全性的影响可能非常微妙。文档作者应该花时间详细说明不遵循建议或需求的安全影响，因为大多数实现者不会从产生规范的经验和讨论中获益。”

这段话的意思是:“解释你自己!”没有背景或解释性材料的声明对于那些不深入了解计算机安全或一般安全的艺术和科学的人来说是无用的。同时像攻击者和防御者那样思考需要一种特殊的心态，而大多数人都做不到这一点;因此，如果您希望阅读文档的人遵循您的指导，那么您必须带领他们踏上从无知到知识的旅程。只有这样，你才能期望他们在熟悉和特别不熟悉的情况下正确地执行你的指导。

作者

乔治诉Neville-Neil（kv@acm.org)是Neville-Neil Consulting的东主及ACM队列编辑委员会。他从事网络和操作系统代码方面的工作，教授各种与编程相关的课程，并鼓励您的评论、俏皮话和与他相关的代码片段通信列。

版权归作者所有。
向所有者/作者请求(重新)发布权限