Guest User

コーディングスタイルと TLS とエラーと私

a guest
Mar 5th, 2014
254
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. <html>
  2. <head>
  3. <link href="http://www.tedunangst.com/flak/rss" rel="alternate" type="application/rss+xml" title="flak rss">
  4. <style>
  5. body {background-color: #fcf4e8;font-size: 1.0em;color: #121;}a {text-decoration: none;color: #181;}a:hover {color: #1c1;}h1, h2, h3, .sidebar, .topbar, .sf {font-family: sans-serif;}img {max-width: 100%;}.main {margin: 0 auto;max-width:960px;}.content {width: 70%;float:left;}.sidebar {width: 25%;float: right;}.toc {padding: 2px;bottom: 0;position: fixed;background: #121;color: #fcf4e8;opacity: 0.4;}.toc a {color: #fcf4e8;}.toc:hover {opacity: 1.0;}.post {border-bottom: 1px dotted gray;}.post p a:hover {text-decoration: underline;}.topbar {background-color: #ece4d4;padding: 4px;}.topbar form {float: right;}.code {white-space: pre-wrap;word-wrap: break-word;font-family: monospace;background-color: #ece4d4;}span.code {padding: 0.1em;}div.code {padding: 1em;}.comment {margin-left: 10%;width: 70%;border-top: dotted gray 1px;}.linklike {border-bottom: 1px dotted;cursor: pointer;}.sf {font-size: 0.8em;}.fr {float: right;}@media screen and (max-device-width: 480px) {body {font-size: 2.2em;}div.code {font-size: 0.5em;}}@media screen and (min-device-width: 481px) and (-webkit-min-device-pixel-ratio: 2) {body {font-size: 1.4em;}}@media screen and (max-width:980px) {.content {width: 95%;}.sidebar {width: 95%;float: left;}.sidebar div {float: left;}}@media screen and (min-width:1240px) {body {font-size: 1.2em;}.main {max-width: 1200px;}}@media screen and (min-width:1620px) {body {font-size: 1.4em;}.main {max-width: 1600px;}}
  6. </style>
  7. <title>
  8. コーディングスタイルと TLS とエラーと私
  9. </title>
  10. </head>
  11. <body>
  12. <div class="main">
  13. <div class="topbar">
  14. <!-- guest<form action="/flak/search" method="GET"><input name="t" ></form> -->
  15. </div>
  16. <div class="content">
  17. <div class="post">
  18. <a name="top"></a>
  19. <h2><a href="http://www.tedunangst.com/flak/post/thoughts-on-style-the-TLS-and-errors">コーディングスタイルと TLS とエラーと私</a></h2>
  20. <div>
  21. <p>
  22. やりたいわけではなかったのですが、さいきん公開された GnuTLS の脆弱性のせいで、なんだか、すり減ったタイヤに溝を付け直すようなことになっています。忙しい一週間でした。今回はマジで。
  23. <!-- The disclosure of the recent GnuTLS vulnerability forces me, as if against my will, to retread some tired ground. It’s been a busy week. For serious this time. --><p>
  24. <a name="review"></a><h4>おさらい<!-- review --></h4><p>
  25. 一週間という言葉は広く捉えていただくとして、以下はすべて必読の記事です。
  26. <!-- This may stretch the definition of one week slightly, but here’s all the required reading. --><p>
  27. <a href="https://www.imperialviolet.org/2014/02/22/applebug.html">Apple Secure Transport が secure じゃない件</a>。 #gotofail
  28. <!-- <a href="https://www.imperialviolet.org/2014/02/22/applebug.html">Apple Secure Transport is not</a>. #gotofail --><p>
  29. OS X で Secure Transport を使わないあなたには、<a href="https://hynek.me/articles/apple-openssl-verification-surprises/">Apple OpenSSL 衝撃の事実</a>があります。親切も過ぎたるは及ばざるが如しと言ったところでしょうか。(訳注: TEA を無効にしないと、trusted CA を制限できなかったり、callback がエラーにならなくなったりと独自のおせっかい動作をする)
  30. <!-- If you choose to forgo Secure Transport on OS X, there are <a href="https://hynek.me/articles/apple-openssl-verification-surprises/">Apple OpenSSL surprises</a>. Better is worse, or something like that. --><p>
  31. <a href="http://www.gnutls.org/security.html#GNUTLS-SA-2014-2">GnuTLS がバグを“goto fail;”で直した件</a>。(訳注: <a href="https://www.gitorious.org/gnutls/gnutls/commit/6aa26f78150ccbdf0aec1878a41c17c41d358a3b">返り値のためにgotoを二重にしたパッチ</a>)
  32. <!-- <a href="http://www.gnutls.org/security.html#GNUTLS-SA-2014-2">GnuTLS fixed a bug by adding “goto fail;”</a>. --><p>
  33. 皆さんご存じのとおり、<a href="https://secure-resumption.com/">トリプル握手は有害と思われ</a>。そこにはこんな一文も: 「主要な TLS 実装はどれも素数判定をしていない。」
  34. (訳注: TLS のリジュームと再ネゴの両方が可能な善良サーバに対して、同じクライアント証明書を受け取ることのある悪サーバが MITM できる。DH の場合、pre-master secret を制御するために素数どころか偶数を使う exploit が可能で、たいていバレない)
  35. <!-- As everyone should know, <a href="https://secure-resumption.com/">shaking three times considered harmful</a>. Contains this sentence: “None of the mainstream TLS implementations performs a primality test.” --><p>
  36. 技術的に新しい話題ではありませんが、投稿が新しいので <a href="https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html">OpenSSL の AES-GCM が ARM では定数時間じゃない件</a> と、その末尾の各種バグも。
  37. <!-- It’s not technically a new issue, but since it was posted recently as well, <a href="https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html">OpenSSL AES-GCM isn’t constant time on ARM</a>. A variety of other bugs at the end of the post. --><p>
  38. <a name="fail-hard"></a><h4>断固エラー処理<!-- fail hard --></h4><p>
  39. 以前 <a href="http://www.tedunangst.com/flak/posts/login-pushover">login_pushover</a> の作業をしていたとき BSD auth で気づいたことがあります。それは<b>積極的保証</b>が必要ということ。正しく終了するだけでは不十分で、ちゃんと返答チャネルに“authorize”という文字列を書き込まなければいけないのです。もし何かのバグでうっかり <span class="code">exit(0)</span> しちゃったときも、出力がなければ失敗ということにするためです。ステータス文字列と返り値で、いわば自前の二要素認証です。
  40. <!-- When I was working on <a href="http://www.tedunangst.com/flak/posts/login-pushover">login_pushover</a>, I noticed something about BSD auth. It requires <b>affirmative confirmation</b>. It’s not enough for the authenticator to exit successfully, it must write the string “authorize” to the reply channel. If some bug accidentally causes it to call <span class="code">exit(0)</span> without printing anything, that counts as failure. In a way, it is its very own two factor auth. Status string and exit code. --><p>
  41. これをコーディングスタイルとは呼びたくありません; むしろコーディングパラダイムと呼ぶべきでしょう。そしてこれこそ TLS が、内部実装からライブラリ API, そしてプロトコルに至るまですべての段階において固守すべき、なのに固守していないものです。断固エラーにすべき場面で「良い人」になってしまうのは、あるあるですね。
  42. <!-- I wouldn’t call this a coding style; it’s more a coding paradigm. And it’s one that TLS fails to adhere to at all levels, from internal implementation, to library API, to protocol. It’s far too easy to fly right by what should have been a hard error. --><p>
  43. <a name="error-diffusion"></a><h4>エラーの浸透<!-- error diffusion --></h4><p>
  44. 実例をもうひとつ。ちょうど <a href="http://marc.info/?l=openbsd-cvs&amp;m=139395147818859&amp;w=2">signify でチェックサム検証</a>するよう機能追加したんですが、これってかなり the unix way に反しています。コマンドをパイプラインで繋げればいいんですから。じっさい man page も最初はそう勧めていました。
  45. <!-- Another example. I just added a feature to do <a href="http://marc.info/?l=openbsd-cvs&amp;m=139395147818859&amp;w=2">checksum verification in signify</a>. It’s so not the unix way, when you could pipeline commands together. Indeed, that’s what the man page suggested to start. --><p>
  46. <div class="code">$ signify -V -e -x SHA256.sig -m - | sha256 -C - bsd.rd
  47. (SHA256) bsd.rd: OK
  48. </div><p>
  49. 大丈夫そうですね。でも何か問題が起きたらどうでしょうか?
  50. <!-- Looks good. But what if something goes wrong? --><p>
  51. <div class="code">$ (echo catastrophic failure; false) | sha256 -C - bsd.rd
  52. $ echo $?
  53. 0
  54. </div><p>
  55. 無言、そして<i>正常に</i>終了です。
  56. <!-- No message, and <i>successful</i> exit. --><p>
  57. ここにおいて、ふたつ別個の問題点が露呈しています。第一に、sha256 がおめでたい奴で、ゴミでも喜んで受け取り、エラーにすべきところでエラーを出さないということです。(これは我々自身の、しょーもないミスです。OpenBSD で、-c が厳しすぎると言って -C を追加したんです。[訳注: bin/md5/md5.c rev 1.70]) しかし第二は、<i>sh が</i>パイプラインから返り値を取れなくしているということです。エラーがあるのに、なくなっている。一言で言えば、これは Apple の OpenSSL バグそのものです。
  58. <!-- There are two distinct problems revealed here. First, sha256 is a too happy to accept garbage and doesn’t indicate failure when it should. (This is our own damn fault. We added -C in response to -c being too strict.) But second, <i>sh</i> makes it unpossible to get the exit status from the front of a pipeline. The error is there, and then it’s not. In a nutshell, this is the Apple OpenSSL bug. --><p>
  59. <a name="rules"></a><h4>規約<!-- rules --></h4><p>
  60. 必然的に、議論はこの種のバグを防ぐコーディング規格へと向かいます。おそらく最も有名な工業規格は MISRA C ですが、私は好きじゃありません。
  61. <!-- Inevitably, the discussion turns to coding standards that would prevent these bugs. Perhaps the best known industry standard is MISRA C. I’m not a fan. --><p>
  62. 1. 三項演算子の禁止。ええ、すばらしいルールです。けど最近いつ、三項演算子を使ったせいでセキュリティ問題が起きたという話を聞きました?
  63. <!-- 1. No trigraphs. Alright, great rule. But when is the last time you heard about a security failure caused by somebody using trigraphs? --><p>
  64. 2. まぎらわしい変数名の禁止。<span class="code">tls</span><span class="code">t1s</span> は同じに見えるので規格違反ですよ、と。ええ、すばらしいルールです。でもこんなこと、誰がやるんです? OCC (obfuscated code contest) 以外では誰も見たことありませんよ。見たことがあるのは <span class="code">inputLen</span><span class="code">outputLen</span> をごっちゃにする人たちです。太陽のように明らかな変数名だというのに。
  65. <!-- 2. No visually confusing variable names. It is a violation of the regulation to name two variables <span class="code">tls</span> and <span class="code">t1s</span> because they look the same. Alright, great rule. But who does this? I have never seen anybody do this outside of an obfuscated code contest. What I have seen is people mixing up <span class="code">inputLen</span> and <span class="code">outputLen</span> despite their clear as day names. --><p>
  66. 3. ソースファイルは改行で終わらねばならない。ファッ!? 歴史上どこを見ても、C ファイルの最後に改行を足すパッチで修正されたセキュリティバグなんてありませんが。
  67. <!-- 3. Source files must end with a newline. What? Never in the history of ever has a security bug been patched by adding a newline to the end of a C file. --><p>
  68. お役所仕事っていうのはこういうものです。「C ファイルはすべて改行で終わっていますか?」ええ、たぶん。「でもどうしてそう言えるんです? 遵守のための手順は? その手順をテストするためにいつ改行のないファイルをチェックインしましたか?」
  69. <!-- This is some serious bean counter shit. “Do all your C files end in newlines?” Yeah, probably. “But how do you know? What is your process for ensuring compliance? When did you last test your process by trying to check in a file without a newline?” --><p>
  70. まあ、これほど常軌を逸しているとは言いませんが、はっきり言って、<i>if に必ず {} を付ける</i>ルールも近いところ行ってると思います。それはなぜか。コンピューティングにおいてムーアの法則に従っていないリソースがひとつあるとすれば、それは垂直解像度だからです。使える行数に余裕なんてありません。
  71. <!-- I obviously think the <i>every if must have braces</i> rule is treading close to the above rules, although I’ll admit it’s not quite as outrageous. Why? If there is one computing resource which does not follow Moore’s Law, it’s vertical resolution. I need all the lines I can get. --><p>
  72. Go でプログラミングするときには私も要求どおりの括弧スタイルを使いますよ。彼らは C のひねくれたところを減らしたいのですね、分かります。でも私、気づいてしまったんです。Go 設計者は自分たちのやったことを後から理解したんですよきっと。だってこんなスタイルを唱道して行数を縮めさせているんですから。
  73. <!-- When I program in Go, I use their required brace style. They want to reduce some of C’s oddities. I get that. But then I notice that the Go designers apparently realized what they’ve done, because they advocate a style like this to collapse vertical lines. --><p>
  74. <div class="code"><span style="color: #008000; font-weight: bold">if</span> rv, err <span style="color: #666666">:=</span> foo(bar); err <span style="color: #666666">!=</span> <span style="color: #008000; font-weight: bold">nil</span> {
  75.     <span style="color: #008000; font-weight: bold">return</span> err;
  76. }</div><p>
  77. 私はまだ慣れなくて、これがどうもゴミの詰め合わせに見えるんですよね。
  78. <!-- I’m not used to it yet, so that looks like a jumbled mess to me. --><p>
  79. いっさい goto を使うべきでないと主張し戦う人たちがいます。関数は return をひとつしか持つべきでないという人たちもいます。私の心からの願いは、このふたつの団体が一緒にならないことです。そんなことになったら、彼らのコードはどれほど複雑に絡み合った冗長な条件分岐のかたまりと化すことでしょう……。
  80. <!-- I’ve seen people contending that one should never use goto. I’ve also seen people contending that every function should only have a single return. I sincerely hope these two groups don’t work together. What a tangled mess of redundant conditionals their code would be. --><p>
  81. <a href="http://www.fallacyfiles.org/baserate.html">base rate fallacy</a> (基準率の誤謬 [訳注: ある病気 D は、ホモが三倍かかりやすい 病気だとする。ホモに占める D 病患者の割合が、ノンケに占める D 病の割合の三倍ということだ。Pat という人が D 病と診断されたとすると、Pat がホモである確率はいくらだろうか? 75% と答えるのがこの誤謬。実際にはパラメータが足りない。ホモが人口の 1 割、そのうち 3 割が D 病だとすると Pat がホモである確率はわずか 25% になる]) に注意するようお勧めします。括弧のない if を使っているコードが何億行あるでしょうか? もっと重要なこととして、そのコードへ無思慮に括弧を突っ込んだらバグがいくつ発生するでしょうか? (そうです、こういうコードはあまりに多く存在しており、括弧を追加するとすれば無思慮にやるしかないのです。)
  82. <!-- I recommend considering the <a href="http://www.fallacyfiles.org/baserate.html">base rate fallacy</a>. How many billions of lines of code use braceless if? More importantly, how many bugs will be introduced by mindlessly tossing braces into that code? (And yes, there’s so much code like this, the only way braces would be added is mindlessly.) --><p>
  83. さて、「新米プログラマがヘマをしやすいのは <span class="code">if/goto</span><span class="code">strcpy</span> のどっち?」と訊かれたなら、私は迷わず strcpy に賭けます。しかし GNU Linux のプログラマは全員「真のプログラマというのはミスしないものだ」と言って、<span class="code">strlcpy</span> の恩恵なしで苦行を続けています。陰謀論がお好きなら、ここ掘れワンワンですよ。
  84. <!-- On the other hand, if you asked me which a novice programmer was more likely to screw up, <span class="code">if/goto</span> or <span class="code">strcpy</span>, my money is on strcpy every time. Yet entire generations of programmers on GNU Linux toil away without the benefit of <span class="code">strlcpy</span> because real programmers don’t make mistakes. If you’re looking for a conspiracy, I recommend digging under this rock. --><p>
  85. <a name="conspiracies"></a><h4>陰謀論<!-- conspiracies --></h4><p>
  86. 私が陰謀論を信じていたら、「GnuTLS プロジェクトは<span class="code">+    goto fail;</span> などというパッチで皮肉な笑いを取ろうと企んでいるんだよ! (Ω ΩΩ<な、なんだってー)」と言うところです。
  87. <!-- If I believed in conspiracies, I’d say the GnuTLS project conspired to make their patch include <span class="code">+    goto fail;</span> for ironic comedic effect. --><p>
  88. 問題はどこですか。突如、ありあまるほど明白になったのは、だれも TLS スタックをテストしていないということ、そしてそれが、ちゃんとしたテストスイートをだれも持っていないからだということです。こ れ は あ や し い。でもいつから<i>自分の使っている TLS スタックはよくテストされている</i>と錯覚していました? それに関して自分で、情強市民であるあなたは、何をしてきましたか? 今週末 <i>Futurama: Into the Wild Green Yonder</i> を観ましたが、こう言っていましたよ。「スローガンを連呼する道もあるし、行動を起こす道もある!」「前はどうしたんだったっけ?」
  89. <!-- What is the problem? One thing that’s suddenly become abundantly clear is nobody tests their TLS stack because nobody has a decent TLS testsuite. That looks suspicious, but when exactly did the <i>the TLS stack I’m using is well tested</i> thought appear in your head? What have you, concerned citizen, done about it? This weekend I watched <i>Futurama: Into the Wild Green Yonder</i>. “We can either chant slogans or we can take action!” ... “What was the first choice again?” --><p>
  90.  
  91. </div>
  92. <div class="sf">
  93. Posted 2014-03-04 18:11:28 by tedu Updated: 2014-03-04 18:11:28<br>
  94. Tagged: <a href="http://www.tedunangst.com/flak/tag/security">security</a> <a href="http://www.tedunangst.com/flak/tag/thoughts">thoughts</a><br>
  95. </div>
  96.  
  97.  
  98.  
  99. </div>
  100.  
  101. <div style="margin-bottom: 2em"></div>
  102. <div class="toc">
  103. <a href="#top">top</a>
  104.  
  105. - <a href="#review">review</a>
  106.  
  107. - <a href="#fail-hard">fail hard</a>
  108.  
  109. - <a href="#error-diffusion">error diffusion</a>
  110.  
  111. - <a href="#rules">rules</a>
  112.  
  113. - <a href="#conspiracies">conspiracies</a>
  114.  
  115. </div>
  116.  
  117.  
  118. </div>
  119. <div class="sidebar">
  120. <h1><a href="http://www.tedunangst.com/flak/">flak</a></h1>
  121. <div>
  122. <h3>recent [<a href="http://www.tedunangst.com/flak/rss">rss</a>]</h3>
  123. <ul>
  124.  <li><a href="http://www.tedunangst.com/flak/post/thoughts-on-style-the-TLS-and-errors">thoughts on style, the TLS, and errors</a>
  125.  <li><a href="http://www.tedunangst.com/flak/post/too-much-email-protection">too much email protection</a>
  126.  <li><a href="http://www.tedunangst.com/flak/post/a-brief-history-of-one-line-fixes">a brief history of one line fixes</a>
  127.  <li><a href="http://www.tedunangst.com/flak/post/signify-backport">signify backport</a>
  128.  <li><a href="http://www.tedunangst.com/flak/post/Heroku-subscription-status">Heroku subscription status</a>
  129.  <li><a href="http://www.tedunangst.com/flak/post/login-pushover">login_pushover - two factor auth with pushover</a>
  130.  <li><a href="http://www.tedunangst.com/flak/post/Facebook-Zero">Facebook Zero</a>
  131.  <li><a href="http://www.tedunangst.com/flak/post/comcast-ping-times">comcast ping times</a>
  132.  <li><a href="http://www.tedunangst.com/flak/post/the-finitely-probable-machine">the finitely probable machine</a>
  133.  <li><a href="http://www.tedunangst.com/flak/post/new-gold-standard-for-useless-mobile-site">new gold standard for useless mobile site</a>
  134.  
  135. </ul>
  136. </div>
  137.  
  138. <div>
  139. <h3>tags</h3>
  140. <ul>
  141.  <li><a href="http://www.tedunangst.com/flak/tag/software">software</a>
  142.  <li><a href="http://www.tedunangst.com/flak/tag/programming">programming</a>
  143.  <li><a href="http://www.tedunangst.com/flak/tag/rants">rants</a>
  144.  <li><a href="http://www.tedunangst.com/flak/tag/openbsd">openbsd</a>
  145.  <li><a href="http://www.tedunangst.com/flak/tag/thoughts">thoughts</a>
  146.  <li><a href="http://www.tedunangst.com/flak/tag/review">review</a>
  147.  <li><a href="http://www.tedunangst.com/flak/tag/web">web</a>
  148.  <li><a href="http://www.tedunangst.com/flak/tag/security">security</a>
  149.  <li><a href="http://www.tedunangst.com/flak/tag/computers">computers</a>
  150.  <li><a href="http://www.tedunangst.com/flak/tag/c">c</a>
  151.  <li><a href="http://www.tedunangst.com/flak/tag/gadget">gadget</a>
  152.  <li><a href="http://www.tedunangst.com/flak/tag/moviereview">moviereview</a>
  153.  <li><a href="http://www.tedunangst.com/flak/tag/magreview">magreview</a>
  154.  <li><a href="http://www.tedunangst.com/flak/tag/bugs">bugs</a>
  155.  <li><a href="http://www.tedunangst.com/flak/tag/business">business</a>
  156.  <li><a href="http://www.tedunangst.com/flak/tag/mailfail">mailfail</a>
  157.  <li><a href="http://www.tedunangst.com/flak/tag/flak">flak</a>
  158.  <li><a href="http://www.tedunangst.com/flak/tag/philly">philly</a>
  159.  <li><a href="http://www.tedunangst.com/flak/tag/quote">quote</a>
  160.  <li><a href="http://www.tedunangst.com/flak/tag/bookreview">bookreview</a>
  161.  
  162. </ul>
  163. </div>
  164.  
  165. </div>
  166. </div>
  167.  
  168. </body>
  169. </html>
RAW Paste Data