オープンソースプロジェクトを始める7つのアドバイス

プロジェクト手法ではなく…

私は今Enarxプロジェクトに関わっています。とても深く、です。すでにご存知かもしれませんが、これはオープンソースのプロジェクトで、信頼できないホスト上で機密性の高いワークロードの実行を可能にするプロジェクトです。

何年もオープンソースプロジェクトに関わってきましたが、このプロジェクトで初めて私は共同創立者となりました。

私たちは現状、コードや文書を十分用意し、ロゴもステッカーも（これ重要！）用意できている段階です。

プロジェクトはLinux Foundationグループ（Confidential Computing Consortium)に含まれるはずなので、順調です。さらにプロジェクトを加速させるためにも内容に関してもお伝えしていったほうがいいでしょう。はっきりさせておくと、Enarxは商用とエンタープライズアプリケーションになるプロジェクトです。十分には成熟しておらず、まだまだハードルやチャレンジがあるかもしれません。さらに言うと、私たちの歩んできた道は全てのプロジェクトも当てはまらないかもしれませんが、他のプロジェクトやこれからプロジェクトを始めようとする人への指針になればと思っています。

ここまで来るにはたくさんのサポートがあったことをまずお伝えします。

私はOpenSource.comから始めましたが、ここではたくさんのガイドが載っています。それに従っても間違ってしまうこともあるかもしれません。ただ、以下に考慮すべき点を挙げておきます。

1　クリティカルマスを目標に

私は幸いにもRed Hatと言う素晴らしい職場で働いています。ここでは全てのものがオープンソースですし、オープンソースとそのコミュニティを非常に重要だと考えています。そこで「クリティカルマス」企業と言うものを耳にしました。物事を実際に行っていくには十分な人々の関心が必要で、人々が無視できないものとする必要があるということです。共同創立者のNathaniel McCallumと私はプロジェクトに情熱的で、組織内でスポンサーを得ることに時間をかけました。（誰のことだかわかりますよね、皆さんに感謝です！）そしてエンジニア達に「売り込み」をして惹き込み、プロジェクトが止まれなくなるくらいほどにしました。

プロジェクトのいくつかは一人二人の貢献者しか得ることができずもたついてしまいますが、人々の興味を惹きつけるには、どんどん進めてくれる、ある程度の人数を集めることが必須なのです。

2　デモ

人々を巻き込みたければデモをすると良いでしょう。洗練されている必要はなく、しようとしていることが実現可能であること、あなたが成し得たいことを示さなければいけません。初期段階のデモではコマンドラインの出力だけでしょうが、UIプロダクトを提供するのでなければ、それでもいいんです。成し遂げようとすることと情熱、プロジェクトの大切さを伝えることが有益なのです。人は何かを「見たい」「体験したい」ので、形にしてやる気を見せることが近道なのです。

3　ライセンスを選ぶ

コードをオープンソースで作ると、他の人にも貢献してもらいたくなるでしょう。これはあまり重要ではなく、正しいオープンソースのライセンスを選択することが他の人の貢献度を高め、定義された用語の理解を深め、その貢献する人働いている組織とその人たち自身の貢献するハードルを下げるのです。

4　文書作成

開発者文書が最重要だと考えるかもしれません。それなければどうやって人が貢献してコードを書くことができるでしょうか。

初めのうちは必要ないと思っています。小さなプロジェクトではコードが何をするものか、何をさせたいか、何が欠けているかいるか、の説明をすることで何人かの人を巻き込むことができます。

しかしコードが何をするものでどう便利か説明する文書がないのに、どうやってたくさんの人が時間を割いてくれるでしょうか。

文書といっても、ちゃんとしたマーケティング用のものだったり正式なものである必要はなくて、どうしてそれをしなくてはいけないかと皆さんに伝えるものでなければいけません。

これは一番目のポイント、クリティカルマスに注力することにも通じています。文書、ユースケースを示すことで、「ポイント」でプロジェクトが実現したいことに説得力を持たせるのに役立ちます。

私たちはgithubウィキをメインの文書置き場にしていて、作成と同時にアップデートしています。これはもう少し改善できるかと思います。

5　見えるプロジェクト

プロジェクトがちゃんと見える状態でないと見つけてもらえません。私たちのプロジェクトはとてもラッキーで、Confidential Computing Consortiumができた上にそこで見せられるだけのプラットフォームをすぐに作ることができたので、クリティカルマスに届く状態です。

Twitterのアカウントもあり（@enarxproject）このブログとOpensource.comで記事も出しています。Red Hatのhttps://next.redhat.com/にてブログを出す機会にも恵まれ、プレスのインタビューも受けましたし出来るだけカンファレンスでも講演しています。私たちにはこのような良い機会がありましたが、全てのプロジェクトに適切なアプローチではないかもしれません。しかし知ってもらうことで、もっとたくさんの人々に貢献してもらえます。

6　歓迎しましょう

世間に知って頂けたとしましょう。次は何ができるでしょうか。そう、皆さんにプロジェクトに参加したいと思って頂きたいですよね。歓迎してもらえなければその参加数は少なくなって行きます。また上の方で私が何を言ったかに関わらず、しばらくすると技術文書も必要になります。そしてその人たちがあなたと話し合う方法が必要ですね。そうすることで評価されていると感じますから。

私たちの場合、Gitter（https://gitter.im/enarx/）で、毎日のスタンドアップ会議には参加したい人がみんな参加できます。最近ではそ課題データベース（https://github.com/enarx/enarx/issues）をGithubに作成しタコとで、スレッドの会話でタイムゾーンがあることから毎日のスタンドアップ会議の時間が合っていないことが明らかになりました。ので、会議の数を少なくとも週一とする配慮をしたのです。

7　仲の良い人と活動しましょう

私はとてもとてもEnarxプロジェクトチームのみんなと働くことが楽しいです。楽しく過ごし、冗談をかわし、笑って、共通の目標をシェアしています。Enarxの成功のためです。出来るだけ楽しんですること、それが大切だと思います。特にプロジェクトの初期段階では情熱的な人と楽しく仕事できる人が必要です。例えその人が地理的には数千キロ（マイル？）離れた場所にいても、です。そのように参加できなければ情熱もどんどん先細ってくるでしょうし勢いも失われ、プロジェクトは失敗に終わるでしょう。一緒に活動する人は選べるわけではないでしょうが、できればあなたの仲が良い人を選びましょう。

結論：「人」です。

この記事を書き始めるまでは気づきませんでしたが、全くプロジェクト手法が問題ではないのです。

人、です。

読み返せばどのアドバイスにも人の大切さが述べてあり、ライセンスの選び方にも、です。オープンソースプロジェクトとはコードではないのです。人なのです。どのようにシェアし、一緒に活動し交流するかなのです。

オープンソースプロジェクトはそれぞれ異なるものでしょうから、この7つのアドバイスが全て当てはまることはないでしょう。間違いなくEnarxはまだ成功と言い切れるものではありませんので、今の段階でこのようなアドバイスをすべきでないのかもしれません。しかし成功してきた今までのオープンソースプロジェクトを思い起こすと、やはり人と言うものはとても大切なのです。

元の記事：https://aliceevebob.com/2019/12/17/7-tips-for-kicking-off-an-open-source-project/

2019年12月7日　Mike Bursell

タグ：オープンソース

コンフィデンシャルコンピューティング　ー新しいHTTPSとは？

デフォルトで付いてくるセキュリティなんてありません。

この記事は
https://aliceevebob.com/2019/12/03/confidential-computing-the-new-https/　を翻訳したものです。

ここ数年、「http://…&#8221」のようなウェブサイトはなくなってきました。これはやっと業界がウェブサイトにセキュリティが「ある」ことに気付いたからです。と同時にサーバーとクライアントどちらともHTTPS通信の設定をすることが容易になったからです。

同じような動きがクラウド、エッジ、IoT、ブロックチェーン、AI/MLなどのコンピューティングにも現れることでしょう。

ストレージ内に保存するデータやネットワークで転送されるデータはは暗号化すべきである、とは認識されていました。けれどプロセスしている間使用されているデータを暗号化するのは難しく、高価でした。

Trusted Execution Environment （TEE）などのハードウェアを使って、使用中のデータやアルゴリズムを保護します。コンフィデンシャルコンピューティングは、ホストシステムや攻撃されやすい環境のデータを保護するのです。

TEE　とEnarx Project（Nathaniel McCallumと共同創立しているプロジェクトです、参考： Enarx for everyone (a quest) and Enarx goes multi-platform ）に付いては何度かブログに投稿しています。
EnarxはTEEを使っていて、Enarkでプラットフォームや使用言語に依存せず、機密性が必要なアプリケーションやマイクロサービスなどのコンポーネントを安全に信頼できないホストにデプロイすることができます。

Enarxはもちろん完全にオープンソースで（Apache2.0のライセンス使用）です。
ワークロードを信頼できないホストで稼働させるのはコンフィデンシャルコンピューティングが保証するところです。これからは下記のような場合の機密性があるデータにコンフィデンシャルコンピューティングが普通に使われるようになるでしょう。：

ストレージ：ストレージインフラを完全に信用できないので、保存したデータは暗号化したい
ネットワーク：ネットワークインフラを完全に信用できないので、転送中のデータを暗号化したい
コンピューティング：コンピューティングインフラを信用できないので、使用中のデータを暗号化したい

信頼信用に関してはもっと言いたいことはあるのですが「完全に」という言葉が大切です。（これは推敲の最中に書き足しました。）
パケットを送ったりやブロックを保存したりするかどうか、上記のどのケースでもCPUやファームウェアなど、インフラをある程度信頼しなくてはいけません。というのも、それらを信頼できなければコンピューティングなんてできません。
（準同型暗号という技術があり提供されつつありますが、まだ限定的で技術も未完成です）

CPU周りで見つかる脆弱性があると、CPUを完全に信頼するかどうか、また乗っているホストの物理攻撃に完全に安全がどうか、というのは何度も出てくる疑問です。
どちらの疑問にも、「いいえ」と答えられますね。しかし拡張性とデプロイの費用の問題から現状ではベストな技術でしょう。

二番目の疑問については、誰も（もしくは他の技術）完全に安全だと偽装できないということです。私たちがすべきなのはthreat model を考慮し、この場合ではTEEが特定の要件に対して十分なセキュリティを提供できるかどうか決定する、ということです。

一つ目の疑問に関してはEnarxの当てはまるモデルは、特定のCPUセットを信頼するかどうかデプロイメントの際に全て決め打ちする、ということでしょう。
例えばQというベンダのR世代のチップに脆弱性が見つかったとしましょう。「ワークロードをQから出ているR世代のCPUにはデプロイさせず、Q社のSタイプ、Tタイプ、Uタイプのチップと、P社、M社、N社のCPUにはデプロイOKとする」と宣言できれば簡単ですね。

コンフィデンシャルコンピューティングが注目されていますが、そこに適応させるには3つの変化のステージがあると考えています。

1　ハードウェアの稼働性：
TEEがサポートされているハードウェアが手に入るようになったのはここ半年から一年の間です。IntelのSGXやAMDのSEVなど市場で鍵となる製品が出てきだことからもわかります。
これからもTEEが使えるハードウェアの製品が出てくると予想されます。

2　業界の受け入れ状態：
アプリケーションのデプロイメントとしてクラウドが急激に受け入れられているのに合わせて法規制や整備は扱うデータを保護するよう、組織や団体に対して要求を増やしてきています。
組織や団体は、信頼性のないホストでの機密性の高いアプリケーション（もしくは機密データを扱うアプリ）の稼働方法にざわざわしてきています。正確には、彼らが完全に信用できないホスト上で、のアプリに関してですね。

これは別に驚くことではないのです。もしマーケットが投資に値するものではなければ、チップベンダーはこの技術に投資しないでしょう。
Linux FoundationのConfidential Computing Consortium (CCC)の体制は、どれくらい業界がコンフィデンシャルコンピューティングの共通使用モデルを見つけようとしているか、オープンソースプロジェクトにこのような技術採用を勧めているか、の別のよい例ですね。

その一つがRed Hatが始めたEnarxはCCCのプロジェクトです。

3　オープンソース：
ブロックチェーンのように、コンフィデンシャルコンピューティングはオープンソースを使うことがとても簡単な技術の一つです。

機密性の高いアプリケーションを動かす場合、動いているもの自体を信用しなくてはいけません。CPUやファームウェアのようなものではなく、TEEの中でワークロードの実際の実行を手伝うフレームワークのことです。

良い言い回しがあります。
「私はホストマシーンとソフトウェアスタックが信用できないからTEEを使うんだ」

しかしTEEのソフトウェア環境に可視性がなければ、ただソフトウェアを別の不可視性の高い環境に移しただけです。
TEEのオープンソースによって、あなたやコミュニティ5トはプロプライエタリのベンダー仕様ソフトウェアにはできないチェックと監査ができるようになるのです。

このようにCCCはオープンな開発モデルをであるLinux Foundationに属しているのであり、TEEに関するソフトウェアプロジェクトにCCCに参加するよう、またオープンソースにするように推進しているのです。

このハードウェアの可動性、業界の受け入れとオープンソースの三つがここ15から20年の技術の変革を促進するものだと考えます。
ブロックチェーン、AI、クラウドコンピューティング、ウェブスケールコンピューティング、ビッグデータ、インターネット販売は全てこの三つが合わさって、今までになかった変革を業界にもたらしたのです。

デフォルトのセキュリティはここ何十年か必要だと訴えられているものですが、まだ達成されていません。正直なところ、それが本当に実現するかはわかりません。

しかし新しい技術が実現することで、業界で、特定のユースケースにセキュリティが浸透することがもっと実用的になり、そこに期待も集まるでしょう。

コンフィデンシャルコンピューティングは次の新しい変革を迎えようとしています。
そして読者の皆さんがその革命に参加する日が来るでしょう。オープンソースなのですから。

元の記事：https://aliceevebob.com/2019/12/03/confidential-computing-the-new-https/
2019年12月3日　Mike Bursell

プロジェクトとプロダクトとセキュリティコミュニティと

全てのオープンソースが平等に作られてメンテナンスされている訳ではないのです。

この記事は　https://aliceevebob.com/2019/10/15/of-projects-products-and-security-community/　を翻訳したものです。

オープンソースは良いこと、です。
オープンソースは特にセキュリティ周りにはピッタリです。

このことに関しては前の記事　Disbelieving the many eyes hypothesisとThe commonwealth of Open Sourceでも書きましたが、さらに書き足したいと思います。

この記事ではオープンソースの機能、議論の余地はありますが、その欠点と利点についてついてです。さらにいうと、プロジェクトとプロダクトの違いです。

一面から話しますが（あらかじめ警告すると、組織にとっては「プロダクト」なのですが）、ここでちょっとした免責事項から始めましょう。

私はRed Hatに勤めています。そして、Red Hatはオープンソースをサポートすることで利益を得ている企業です。
これは良いことで、私はこの企業モデルを認めていますが、この記事に関してはバイアスがかかってることをはじめにお伝えします。

オープンソースがセキュリティに良いという理由は、問題があるときに何が起こっているか実際自分で見ることができる上、自分で修正することもできるからです。
もしくは現実的に言うと、問題が起こったオープンソースプロジェクトでセキュリティプロフェッショナルかつその分野のエキスパートでなければ、他の人が修正してくれるかもしれません。
その分野に詳しいセキュリティ関連の人が十分にいて、ソフトウェアプロジェクトの中の問題や脆弱性を解決してくれるのを願うばかりです。

ただ、それよりはもっと事態は複雑かもしれません。
組織としてはオープンソースを使用するには二つの方法があります。

・プロジェクトとして
コードを持ってきてどのバージョンを使うか決め、自分でコンパイル、テスト、管理をする

・プロダクトとして
ベンダーがプロジェクトを持ってきて、どのバーションか決め、コンパイル、テスト、サポートをパッケージにつけて売ります。ドキュメントやパッチ、アップデートも大抵含みます。

さて、「生」プロジェクトを使えばオプションがもっとあることを否定はできませんね。
最新バージョンをチェックして、コンパイル、テストを自由にでき、プロダクトバージョンよりも早く、さらに自分のビジネスとユースケースに合ったセキュリティパッチを当てることもできます。とても良いことのように思えます

しかしながら、セキュリティ特有の欠点があります。

1　セキュリティパッチの中には規制があるものがあります。（ブログ参照）限られた組織（大体はベンダーです）だけがアクセスできるものです。
大きなエコシステムと同時期にアクセスを得て修正できたとしても、チェックして、テストをしなければいけません。それもベンダーによってすでにされているかもしれません。（もちろん盲目的にパッチを当てることもできますが、しないで！）

2　必要性も緊急性がないのにコード変更をしたいという大きな欲求
をアップストリームプロジェクトに反映させることは、コードをフォークしているようなものです。
期日通りにアップストリームに入れこめたとしても、その期間中はアップストリームにない変更を維持していることになるので、他のセキュリティパッチがあなたのバージョンにすぐに当てられないと言う危険性があります。（これはセキュリティ関連ではないパッチにも当てはまりますが、セキュリティパッチの方が緊急性があります）
オプションとしてもちろんあなたのバージョンが他の人に使ってもらえるのであれば、プロジェクトのオフィシャルフォークにすることもできます。コミュニティにそこを推すこともできます、しかしその新しいバージョンを内部的または外部的にサポートし続けるか決めなければいけません。

3　ソフトウェアの全てのインスタンスを同じ環境で同じバージョンで稼働させているのでない限り、セキュリティパッチを古いバージョンにバックポートすることが必要です。そうするのであれば、はじめに修正を行った人と同等もしくは同等程度にセキュリティに精通していなければいけません。
この場合、オープンソースの「共同体」と言う利点を捨てるということです。つまり、コミュニティのスキルをコピーできるようなエキスパートを雇う必要があるからです。

プロダクトではなくプロジェクトをデプロイするということは、プロジェクトを内部でプロダクト化するようなものです。

セキュリティパッチの「共同体」の利点だけでなく、ベンダーサポートプロダクトモデルに本来ある「規模の経済」を失うことになります。

「範囲の経済」も失っているかもしれません。多くのベンダーはたくさんのプロダクトをサポートしています。それらのプロダクトサポートに重点を置いていない組織にとっては、ハードルが高い方法を使って、セキュリティ のエキスパートをあてがうことができるかもしれません。

このような経済学で見ると、ベンダーを使うことの「共同体」の利点がわかります。
たくさんの顧客が製品を使うということは、セキュリティパッチと主要な機能に収益構造とインセンティブを見出せるということなのです。

他のパッチや機能向上にリソースをあてがう場合もあるかもしれません。しかし、スキルのあるセキュリティエキスパートが不足しているということは、「比較優位」性が訴えるように、大きなコミュニティの利点のためにそのポジションを保持すべきなのです。

もし、ベンダーがオープンソースプロジェクトを製品化したバージョンを終わりにする、もしくはサポートを終了する場合どうなるでしょう。
そう、もちろん、ベンダー固有のソフトが持つ問題です。
ベンダーソフトの場合、3つのアウトカムがあります。

・ソフトウェアのソースコードにアクセスできないので、機能向上はできない
・あなただけがソースコードにアクセス権を与えられているが、広げることができないので孤立している
・全ての人がソースコードにアクセスできるが、機能向上させることができるコミュニティがないので、ソフトが消える、もしくはコミュニティがソフト周りを整えるのにものすごい時間がかかる

オープンソースの場合、選択したベンダーがビジネスを終了させたら、別のベンダーを使う、新しいベンダーに引き継いでもらう、自分で製品化する（その上で別の組織に提供する）、最悪の場合は内部で製品化して長期的な対策を練る、などのオプションがあります。

最近のオープンソースの世界では私たちコミュニティはオープンソースのコンソーシアムの成長とともに、これらのオプションを上手く使えるようになってきました。
コンソーシアムではソフトウェアのプロジェクトやそれに関わるプロジェクト周りで組織や団体、個人が集まって上記にあげた規模の経済と範囲の経済を模索しながら、コミュニティの成長促進、機能周りや追加機能を一律にしたり、まだ上手く定義されていないユースケースの一般的なセキュリティ周りや製品化をしたりしています。

例としては、Enarxプロジェクトも貢献しているLinux FoundationのConfidential Computing Consortiumでしょう。

オープンソースのソフトをプロジェクトとしてではなくプロダクトとして使うということは、トレードオフがあります。

しかし、少なくともセキュリティの観点から言うと、組織の経済についてはとても明確です。セキュリティのエキスパートを雇う立場出ないのであれば、プロダクトが一番ニーズにあっているのです。

元の記事：https://aliceevebob.com/2019/10/15/of-projects-products-and-security-community/
2019年10月15日　Mike Bursell

リモートワークをするときの7つのマイルール

もしオフィスをでなければいけないのであれば、犬の散歩に行きますね！

この記事は
https://aliceevebob.com/2019/08/13/my-7-rules-for-remote-work-sanity/
を翻訳したものです。

この10年から15年の間、ほとんど時間、リモートで仕事をしています。
ラッキーなことに私の仕事はリモートワークがぴったりで、勤めているRed Hatもその環境を整えてくれています。

例えばお客様とオンサイトの会議が多くあったり、主要なサービスコンポーネントに従事しているなど、全ての仕事がリモートワークに合うわけではもちろんないですが、多くの組織がリモートワークを検討しています。

また、なるべく「家から働く」「家で働く」などのフレーズをなるべく避けるようにしています。
後者のフレーズの方が良さそうだ、と聞いたこともありますが、多くのリモートワーカーにとっては正確な言い方ではないでしょう。

実際、私の職種にぴったり合う言い方でもありません。
私の仕事はリモートで、会社によって机や椅子、会議室やインターネットアクセスが準備された仕事場はないのですが、いつも家で過ごしているわけではありません。

一ヶ月に平均して3日から1週間ほどは出張です。カンファレンスで講演したり、実際会っての打ち合わせだったりがあるのです。
この間、大体は連絡のつく状態であり、メールをチェックできることになっています。緊急の連絡やメールにも関わらず出張の機会は増えたり減ったり、です。

オープンソース

私がリモートで働ける理由の一つに、勤めているのがオープンソースソフトの会社であることもあります。
今、Enarxというとてもクールなプロジェクトに従事しています。そのソフトに貢献している仲間は欧米にいて、それ以外にも世界中から問い合わせがきます。

スタンドアップ会議はバーチャルでビデオを使います。
プロジェクトからは少なくとも二人は参加し、私は大体はデスクの横で実際立って参加します。

コードは全てgithub（もちろんオープンソースです！訳注：ブログの発信当時は、です。今はマイクロソフトに買収されています）を使っていて、頻繁に顔を合わせる必要も特にありません。
例えば特別な機会にはどこにいてもケーキを買って一緒に祝い、ステッカーをラップトップにつけて、ブランドとチーム感を大切にしています。
チャットとIRCのチャネルがあって色々な方法でコミュニケーションをしています。
まだ小さなチームですが今の所うまくいっています。
リモートチームとどのように働くかのアドバイスはOpensource.comにたくさん載っています。

環境

出張していないときは基本、自宅にいます。天気にもよりますが通勤もします。30〜45秒の短い通勤です。
私のオフィスは家とは別れていて庭にあり、オフィスチェアやデスク、ラップトップのドッキング、モニター、ウェブカメラ、電話、キーボードとプリンターがあり、部屋の中ははっきりと仕事関連のものだけです。

仕事をする環境を作るのに、大切なものもあります。人によって違うでしょうが、私の場合はこんな感じです。

・ソノス。アンプと良いスピーカーに接続したホームサウンドシステム。
・ソファ。大体、飼っている犬に占領されています。時々猫。
・本棚。本が床に散らばらないように。
・紅茶を淹れるファシリティー。私はイギリス人なので、これは最重要。
・冷蔵庫。紅茶に入れるための牛乳、ビールとワインが入っています。（ご心配なく。就業時間中に飲酒はしません。メインキッチンの冷蔵庫に入らなかったんです）
・大きく開く窓と夏に必要なブラインド（エアコンはありません。先ほど言ったでしょう？私はイギリス人なので）
・床暖房と暖炉。冬に必要です。（床暖房は暖炉が暖まるまで必要なのです）
・NUCのパソコンとモニター。仕事にあまり関係ない作業をするため
・蜘蛛も少々

何が必要かはワークスタイルにもよりますが、仕事に関係ないものが実は大切です。まあ、蜘蛛は要らないかもしれませんが。
これは仕事場を心地よくするためなのです。
例えば集中するために音楽をよく聞きます。飼っている犬や猫とソファーに座って、大量のドキュメントを読みます。
お茶を淹れる場所と冷蔵庫がなければ、米国人になっちゃいます！

マイルール

どうやったらうまくいくでしょう。

まずは私たちのほとんどは、他の人と連絡をすることが好きですよね。

リモートワーカーの中にはシェアワークスペースを借りてそこで働く人もいるでしょう。そういう人はオフィスの環境が好きだったり、仕事に集中できる場所が自宅にないのかも知れません。

他にもコーヒーショップやボート（羨ましい！）で働く人もいるでしょう。一年の半分をオフィスで過ごし、残りを別荘で働く人もいるでしょう。

どのようにするにしろ、あなたにとって最適な場所を探すのが大切です。
以下は私がよくやること、その理由です。

1　なるべく仕事をする時間を決めましょう。
公式的には（同僚の皆さんへFYI、イントラに載っています）イギリス時間午前10時から午後6時まで働いています。
これは、多くの米国の同僚の働いている時間に重なっていて、朝はジョギングやサイクリングをしたり、犬と散歩しています。（下記参照）
最近はあまり時間はないですが、時間を柔軟的に前後させて、大体決まった時間を働くようにしています。

2　ちゃんと起床して紅茶を一杯頂く
オフィス環境にいると大体、他の人の会話やお茶のお誘い、会議室でのミーティングやランチに出かける、などでいい意味で邪魔が入ります。
このようなことは自宅ではありません。なので、ちゃんと体を動かしてデスクに3〜4時間座りっぱなしにならないようにしています。
座りっぱなしは健康によくないですし、作業が非効率になります。
もちろんお茶をもっと楽しめるようにするのも大切です。

3　体を動かさないでいると、通知してくれるアプリ
新しいものですがとても気に入ってます。
一時間体を動かさないと、時計（携帯やPCでもあるでしょうけど）がエクセサイズをするように、と教えてくれます。
他にも色々勧めてくれるのですが、大体無視して、紅茶をいただきます。（なぜだかは、もうわかるでしょう？）

4　デスクの上下稼働機能を有効活用
立ったり座ったりしながら、体勢を変えるようにしています。
姿勢にもいいですし、もっと体に気をつけるようになります。

5　犬の散歩
外に出て少し考え事をしたい時や少しメールの長いディスカッションから離れたい時には、犬の散歩に出かけます。
ずっと仕事のことを考えていないとしても、散歩に行くのは効率的な仕事にとても有効ですし、長目の散歩になってしまってもその日は少し多めに働いて調整します。

6　家族とのルール
私の家族は、私がオフィスにいるときは働いていると知っています。
電話で連絡することも、それが無視される可能性があることも、もしかしたら窓から今時間があるか覗きこむこともあります。でももし対応できなかったら、しません。
例えば紅茶用の牛乳がない！などの緊急事態には相談次第で調整するので、ケースバイケースですね。

7　カフェで紅茶を頂く、大抵はケーキも。
時々違った環境に行ったり、実際に人と話をしたいこともあります。
そんな場合には車に飛び乗って10分、カフェに行きます。
美味しいケーキと紅茶を出すお店を知っているんです。

上に挙げたものは全ての習慣ではないかもしれませんが、私の日常を保つのに大切な事です。

皆さんのルールは違ったものかもしれませんが、ルールを作り、同僚や友達、家族にそのルールがあることを知ってもらうことはとても大切です。

リモートワークは簡単なことではなく、規則化しなければいけないことがあります。でもそんな規則によって、8時間座りっぱなしを防いで、ゆとりが生まれるのです。

元の記事：https://aliceevebob.com/2019/08/13/my-7-rules-for-remote-work-sanity/
2019年8月13日　Mike Bursell

オープンソースと悪人と

この記事は
https://aliceevebob.com/2019/07/30/open-source-and-well-bad-people/
を翻訳したものです。

オープンソースのコードを書いている人にとって、オープンソースソフトというものは誠実なものに見えます。
コードを書いて、皆さんのような善人な方がコードを書き足し、テストをし、文書を作成し、ソフトを使うのです。
オープンソースとは、世界をどんなに良くしてくれていることか！

「悪の帝国と呼ばれる組織や会社」ですら、オープンソースを受け入れ、幸福と愛情あふれる場所になり、コミュニティを支援し、オープンソースは良いものとして採用し布教しているのです。

多くのオープンソースライセンスは、1組織がコードを書き換え、その書き換えたコードをリリースすることなく利益を得ることほぼ不可能なようにできています。
オープンソースの魂はライセンスで、実際に世界を良くしているのです。

この大部分には賛成します。

が、世間で鵜呑みにされたような憶測（それが何であれ）が広まっているのを見ると、不思議に思います。
というのも、オープンソースを使っている全ての人が善人ではないというのは皆さんご存知でしょう。

クラッカー（悪事を行うハッカー）はオープンソースを使います。
薬物の販売人もオープンソースを使っています。
人身売買者もオープンソースを使います。
テロリストだって使っているでしょう。
彼らももしかしたらパッチやテスト、文書作成に貢献しているかもしれません。実際はほとんどないと思いますが。でも一般的に彼らは善人ではないのです。

中には「まあ、中には少しはそういう人もいるかもしれないけど、耐えられる範囲だろう」と肩をすくめてしまうような人もいるでしょう。オープンソースで悪事を働く人に比べたらもっと多くの人がオープンソースによって助かっているでしょうから、引き続き喜んで貢献するでしょうね。
あるいは、オープンソースに貢献するのではなく、どうせ人のためにならないのだから、悪人度合いが低い方を受け入れてしまう、というところでしょうか。

これは実際に有効なことで、 ジョン・スチュアート・ミルの言う功利主義として知られています。（私は哲学者ではないので、非常にざっくりと話していることを了承ください）これはこう説明されることもあります。

「行動は、人類の幸福全体を促進するのにちょうど良く釣り合う」

私もオープンソースが「人類の幸福全体を促進」すればいいと願っています。問題は犯罪者だけが皆さんのオープンソースコードを使うわけではないことです。

実際に「日陰なコト」を行うビジネスもありますし、政府が批判する人間を抑圧することも、警察が市民を監視することもあるでしょう。
これも皆さんコードなのであり、悪事にも使われるのです。

悪事とはなんでしょう。
これは功利主義の哲学に対する反論でよく出ますね。何が良いことで何が悪いことなのかと定義するのは難しいのです。
法を遵守している我々一般の人は、人身売買をするのは悪いことだ、と思います。しかし、中にはグレーゾーンなものもあるのです。

例えばタバコ製造、石油化学の会社、プラスチックの製造業、LGBTQ＋の人々を支持しない組織、銃の製造業などです。
意図的に範囲を大きくしています。また、最後の例はあえて選んでいます。

オープンソースの活動を初期に行なっていたのはESRで知られるエリック・レイモンドです。彼は銃を持つ権利をずっと支持しています。彼は公にされている批判をハッカーコミュニティに取り入れ、小銃保持の権利を声に出して支持しています。ESRにとってはこれが「自由」なのです。

彼を批判するつもりはないですが、これは賛成できません。
ただこれで彼が良いと考えているものは私が考えているものと違うことは明確でしょう。
LGBTQ+に関してはとてもリベラルに受け入れていますが、オープンソースのコミュニティにいる人がみんな同じ考えを持っているわけではないでしょう。
オープンソースコミュニティをリベラルだと述べていますが一般論として受け入れられていません。

ハッカーのための辞書として公表されているのですが、平均的なハッカーとは

ふんわりと穏健リベラル。従来の右派左派の政治全体を拒絶するリベラリストの代表を除く。
保守的に一般化して言うとハッカーはどちらかと言うと反独裁主義者。
つまり従来の保守主義と「極」左派は非常に珍しい。ハッカーは非ハッカーよりも大体
a）攻撃的な非政治主義で
b）特異的もしくは特異な政治アイデアを抱き実際日々そう生きようとしている
ジャーゴン・ファイル

少し古いかもしれませんが、この説明は多くのオープンソースコミュニティ内で、コミュニティの一部として意識している人たちが共感するものです。

ただオープンソースのコードの「良い使い方」は「良い組織」が決める、と言うのは、コミュニティとして明らかに賛成できかねます。
もしできたとしても、悪人とされる人々を止められるようなライセンスを作るのは非常に可能性が低いでしょう。

元の記事：
https://aliceevebob.com/2019/07/30/open-source-and-well-bad-people/
2019年7月30日　Mike Bursell

HSMって何？

セキュリティ強化には重要なHSM。ただ、どのプロジェクトにも当てはまるわけじゃありません。

今週も3文字略語です。（訳注：毎週分まだ訳せてません、頑張ります）

HSM（Hardware Security Module）のお話です。

HSMって何だ？何に使うんだっけ？どうして検討する必要があるの？

その話をする前に、「鍵」特に、暗号鍵について考えてみましょう。

最近のほとんどの暗号は、実装されているアルゴリズムは特定の簡単なもの（ブロック暗号）で公開されていますし、一般的にも受け入れられています。

アルゴリズムを知っているかとかどのように動いているかは問題ではないんです。というのは問題になるのは鍵の安全性だからです。

例として、AESアルゴリズムでデータを暗号化したいとします。これで特定のタイプの（対称）暗号化ができます。（この例では1つのAESタイプだけ使うこととします。実際はいくつも微妙な違いがあってここでは省きますが、ポイントは変わりません）

このアルゴリズムには二つのデータを与えられます：

暗号化したい、平文のデータ
暗号化するための鍵

結果としてでたデータは一つです。

暗号化されたデータ

この暗号化されたデータを復号するには、AESアルゴリズムに鍵を入れ込見ます。すると元の平文データが出力されます。

この仕組みは非常によく出来ています。鍵が盗み出さなければ、です。

ここでHSMが出てきます。鍵はとても大切です。以下の場合、とても攻撃を受けやすいのです：

– 鍵の作成時：もし、暗号鍵を作成した時にヒントとなるビットを埋め込めたら、そのデータは悪意を持って複合される可能性が高くなります。

– 鍵の使用時：データを暗号化したり複合化している間、鍵はメモリ上にあります。つまり、そのメモリを覗き見ることができれば、データを盗み見ることができます。（下記の「サイドチャネルアタック」参照）

– 鍵の保存時：鍵の保存時にしっかりと保護していない限り、鍵が盗まれる可能性があります。

– 鍵の転送時：鍵を使用する場所と違うところに保存している場合、そこに転送する時に盗みとられる可能性があります。

HSMは上記の全ての場合に役立ちます。

これが必要となる理由としては、鍵の作成、使用、保存、転送時に、システムの安全性が不確実な場合があるからです。

もし鍵がメールの暗号化に使われるとして、もしそこに侵入されてしまったらとてもみっともない事態に陥ります。もし、これがあなたが持っている全てのクレジットカードのチップに関するものだったら、もっと大変なことになります。

もし、そのコンピュートシステムで十分な権限を持っていれば、その権限者はメモリを見て、鍵を得ることもできます。TEE（Trusted Esxecution Environment

）環境でなければ、の話ですけれどね。

もっとタチの悪いことに、メモリを見ることができなくても、暗号鍵（もしくは、暗号化データ、平文データ）に関する情報を引き出して、攻撃を仕掛けることができます。このタイプの攻撃は通常「サイドチャネルアタック」と呼ばれます。

これは車のエンジンのシリンダーやバルブと同じようなもので、ボンネットを通してエンジンに耳を澄ますのと同じようなことです。エンジン構造はそのつもりではなかったとしても、エンジン部品からエンジンについての情報を盗み見ることができる、ということです。

HSMはそのような攻撃を防ぐように作られているのです。

ではHSMの定義をお話ししましょう。

HSMとはハードウェアの一つで、ネットワークやPCIのようなものを介して、システムに付随された暗号化作業を行うことができる保護ストレージを持っています。そしてサイドアタック、物理的にこじ開けようとしたり、コンポーネントに物理ケーブルを差し込んで電気信号を読み取ろうとする、などの色々な攻撃から保護する物理防御機能を持っています。

数々のHSMは、色々なタイプの攻撃を耐えられることを証明するため

FIPS140などの標準化の認可を取得しようと検査を受けています。

以下にHSMの主な使用方法を挙げます。

鍵の作成

鍵の作成は上で述べたように、とても大切な作業です。ただサイドアタックが非常に効果的に行われる部分でもあります。HSMは（比較的）安全な鍵の生成をし、鍵に求められる適度なランダム性があります。

鍵の保管

HSMは何者かが侵入しようとした場合に保管されている鍵を破棄するようにできているので、鍵の保管には適しています。

暗号化処理

鍵をHSMという安全な場所から別のシステムに転送して危険に晒すより、暗号化前の平文をHSMに置いてしまってはどうでしょう（できれば転送する場合には転送用の鍵を使ってです）。そしてHSMにすでにある鍵で暗号化させ、暗号化したデータを送り返せば？（ここでも転送中は転送用の鍵を使います）こうすることで転送中と使用中の攻撃の機会を減らします。これがHSMの鍵の使い方です。

通常のコンピューティング処理

全てのHSMがこの使い方をサポートするわけではなく（他のほとんどの方法はサポートされますが）、鍵とアルゴリズムたくさん使って機密作業をするのであれば、アプリケーションをHSMで動くように書くことができます。

これは例えばAIやMLのような、前に書いたような古いやり方とは違って、非常に機密性のある場合です。

簡単に保証できるものではありませんが、実行環境は往往にして非常に制限があります。「正しい」ことをするのは難しく、間違いを犯すのは簡単です。すると思っていたよりも大変安全性の低いことになります。

結論　HSMを使うべき？

HSMはPKI（Public Key Infrastructure）プロジェクトなどにはルートオブトラスト（信頼性の基点）としてとてもいいものです。

使うのは難しいでしょうが、PKCS#11インターフェース（Public Key Cryptography Standard ）を提供しているはずなので、共通化した作業は簡易化されています。機密鍵や暗号化の要件がある場合、HSMをシステムで使うのは賢明な選択ですが、どうやって静的化して使うのはアーキテクチャと設計の段階で必要で、構築の十分前段階でする必要があります。

日々のプロビジョニングからプロビジョニングの解除の時まで、HSMの作業は非常に注意して行う必要があることを十分に考慮してください。HSMの使用はとても意味があることですがとても高価で拡張性は多くの場合あまりありません。

HSMはとても機密性の高いデータとその作業を行うというユースケースには特に最適ですが、軍用や政府、ファイナンスに使われることが多いのです。

HSMは全てのプロジェクトに合うものではないのですが、機密システムの設計と運用の武装化に大切なものなのです。

元の記事：https://aliceevebob.com/2019/06/11/whats-an-hsm/

2019年6月11日　Mike Bursell

タグ：セキュリティ

HSMって何？

セキュリティ強化には重要なHSM。ただ、どのプロジェクトにも当てはまるわけじゃありません

この記事は　https://aliceevebob.com/2019/06/11/whats-an-hsm/　を翻訳したものです。

今週も3文字略語です。（訳注：毎週分まだ訳せてません、頑張ります）
HSM（Hardware Security Module）のお話です。
HSMって何だ？何に使うんだっけ？どうして検討する必要があるの？
その話をする前に、「鍵」特に、暗号鍵について考えてみましょう。

最近のほとんどの暗号は、実装されているアルゴリズムは特定の簡単なもの（ブロック暗号）で公開されていますし、一般的にも受け入れられています。
アルゴリズムを知っているかとかどのように動いているかは問題ではないんです。というのは問題になるのは鍵の安全性だからです。

例として、AESアルゴリズムでデータを暗号化したいとします。これで特定のタイプの（対称）暗号化ができます。（この例では1つのAESタイプだけ使うこととします。実際はいくつも微妙な違いがあってここでは省きますが、ポイントは変わりません）

このアルゴリズムには二つのデータを与えられます：

1. 暗号化したい、平文のデータ
2. 暗号化するための鍵

結果としてでたデータは一つです。

1. 暗号化されたデータ

この暗号化されたデータを復号するには、AESアルゴリズムに鍵を入れ込見ます。すると元の平文データが出力されます。
この仕組みは非常によく出来ています。鍵が盗み出さなければ、です。

ここでHSMが出てきます。鍵はとても大切です。以下の場合、とても攻撃を受けやすいのです：

- 鍵の作成時：もし、暗号鍵を作成した時にヒントとなるビットを埋め込めたら、そのデータは悪意を持って複合される可能性が高くなります。

- 鍵の使用時：データを暗号化したり複合化している間、鍵はメモリ上にあります。つまり、そのメモリを覗き見ることができれば、データを盗み見ることができます。（下記の「サイドチャネルアタック」参照）

- 鍵の保存時：鍵の保存時にしっかりと保護していない限り、鍵が盗まれる可能性があります。

- 鍵の転送時：鍵を使用する場所と違うところに保存している場合、そこに転送する時に盗みとられる可能性があります。

HSMは上記の全ての場合に役立ちます。
これが必要となる理由としては、鍵の作成、使用、保存、転送時に、システムの安全性が不確実な場合があるからです。

 もし鍵がメールの暗号化に使われるとして、もしそこに侵入されてしまったらとてもみっともない事態に陥ります。もし、これがあなたが持っている全てのクレジットカードのチップに関するものだったら、もっと大変なことになります。

もし、そのコンピュートシステムで十分な権限を持っていれば、その権限者はメモリを見て、鍵を得ることもできます。TEE（Trusted Esxecution Environment
）環境でなければ、の話ですけれどね。

もっとタチの悪いことに、メモリを見ることができなくても、暗号鍵（もしくは、暗号化データ、平文データ）に関する情報を引き出して、攻撃を仕掛けることができます。このタイプの攻撃は通常「サイドチャネルアタック」と呼ばれます。

これは車のエンジンのシリンダーやバルブと同じようなもので、ボンネットを通してエンジンに耳を澄ますのと同じようなことです。エンジン構造はそのつもりではなかったとしても、エンジン部品からエンジンについての情報を盗み見ることができる、ということです。
HSMはそのような攻撃を防ぐように作られているのです。

ではHSMの定義をお話ししましょう。

HSMとはハードウェアの一つで、ネットワークやPCIのようなものを介して、システムに付随された暗号化作業を行うことができる保護ストレージを持っています。そしてサイドアタック、物理的にこじ開けようとしたり、コンポーネントに物理ケーブルを差し込んで電気信号を読み取ろうとする、などの色々な攻撃から保護する物理防御機能を持っています。

数々のHSMは、色々なタイプの攻撃を耐えられることを証明するため
FIPS140などの標準化の認可を取得しようと検査を受けています。

以下にHSMの主な使用方法を挙げます。

鍵の作成
鍵の作成は上で述べたように、とても大切な作業です。ただサイドアタックが非常に効果的に行われる部分でもあります。HSMは（比較的）安全な鍵の生成をし、鍵に求められる適度なランダム性があります。

鍵の保管
HSMは何者かが侵入しようとした場合に保管されている鍵を破棄するようにできているので、鍵の保管には適しています。

暗号化処理
鍵をHSMという安全な場所から別のシステムに転送して危険に晒すより、暗号化前の平文をHSMに置いてしまってはどうでしょう（できれば転送する場合には転送用の鍵を使ってです）。そしてHSMにすでにある鍵で暗号化させ、暗号化したデータを送り返せば？（ここでも転送中は転送用の鍵を使います）こうすることで転送中と使用中の攻撃の機会を減らします。これがHSMの鍵の使い方です。

通常のコンピューティング処理
全てのHSMがこの使い方をサポートするわけではなく（他のほとんどの方法はサポートされますが）、鍵とアルゴリズムたくさん使って機密作業をするのであれば、アプリケーションをHSMで動くように書くことができます。
これは例えばAIやMLのような、前に書いたような古いやり方とは違って、非常に機密性のある場合です。

簡単に保証できるものではありませんが、実行環境は往往にして非常に制限があります。「正しい」ことをするのは難しく、間違いを犯すのは簡単です。すると思っていたよりも大変安全性の低いことになります。

結論　HSMを使うべき？

HSMはPKI（Public Key Infrastructure）プロジェクトなどにはルートオブトラスト（信頼性の基点）としてとてもいいものです。

使うのは難しいでしょうが、PKCS#11インターフェース（Public Key Cryptography Standard ）を提供しているはずなので、共通化した作業は簡易化されています。機密鍵や暗号化の要件がある場合、HSMをシステムで使うのは賢明な選択ですが、どうやって静的化して使うのはアーキテクチャと設計の段階で必要で、構築の十分前段階でする必要があります。

日々のプロビジョニングからプロビジョニングの解除の時まで、HSMの作業は非常に注意して行う必要があることを十分に考慮してください。HSMの使用はとても意味があることですがとても高価で拡張性は多くの場合あまりありません。

HSMはとても機密性の高いデータとその作業を行うというユースケースには特に最適ですが、軍用や政府、ファイナンスに使われることが多いのです。
HSMは全てのプロジェクトに合うものではないのですが、機密システムの設計と運用の武装化に大切なものなのです。

元の記事：https://aliceevebob.com/2019/06/11/whats-an-hsm/
2019年6月11日　Mike Bursell

信頼と、オープンソースを選ぶということ

この記事は
https://aliceevebob.com/2019/06/18/trust-choosing-open-source/
を翻訳したものです。

ずっと昔、遠い遠いところで（よくある表現でしょ）、私はトラストとセキュリティという標準化文書の下書きに関わっていました。（標準化に関わっていたことがなければ恐怖に感じるでしょうけれど、関わったことがあれば普通のことですよ）
この文書は　ETSI GS NFV-SEC 003: Network Functions Virtualisation (NFV);NFV Security; Security and Trust Guidanceと呼ばれ、セクション5.1.6.3は「推移的トラスト」についてでした。
複雑で長い文書で、とても自信を持ってできた仕事です。
（私は調査員の一人で、また文書のほとんど特にトラストのセクションを記述しました。）この文書は題名からもわかる通りトラスト周りの重要な問題に対応しているものです。

この中でこう定義されています。

「推移的トラストは、CがBを信用しているので、AはBというものを信頼する」

その文書のどこにもオープンソースソフトのことは書いてありません。
公平を期すために、どのソフトやベンダーにも偏らないように記述してあります。標準化に関わる多くの企業はベンダー仕様のソフトに注目しがちです。さらにいうと私は当時Red Hatに勤めていませんでした。

Red Hatに転職し、基本的に標準化の世界から遠ざかることになるのですが、オープンソースについては考えるようになりました。
また、トラストに関してももっと深く考えるようになりました。ビジネス、組織や企業でオープンソースをどうやって使うようになるのか、と。

オープンソースが「それ自体は」他のベンダーソフトと比べて特に安全ではないにしても、どうしてオープンソースがさらに安全性を高めることができるだろうか、と別の記事にも書いています。

どうしてこのことが信頼、特に推移的トラストに関わるのでしょう。
オープンソースとトラストがどうリンクするかについて私はずっと考えていました。大部分が拡散したトラストについてです。
拡散したトラストとブロックチェーンは同じように扱われることが多いです。喜ばしいことです。信頼とはブロックチェーンに確実に関係しているという事実を無視しがちな罠に陥いることが多いからです。暗に言われているだけでちゃんと定義していないからです。

ただし、ここで私が興味を持っているのは、オープンソースソフトを使用するかどうかを選択する方法としての分散した推移的な信頼（トラスト）です。
これは、オープンソースのセキュリティなどの非機能的な詳細についてだけに言えることではなく、ソフト自体の場合についてもです。

「オープンソースソフトを信頼しています」とは、どういうことでしょう？
それは、コードを書きテストをした十分な数の人間が私と同じような要件を提示している。ソフトを使用することのリスクを受け入れることができるだけ十分な経験がその人間にはある。そう私たちが決断しているということと同じなのです。

以下にさらに興味深いことを挙げます。

・ユースケースと要件に合ったデザインがされていると、アーキテクトと設計者を信頼している、ということ
・その設計に合ったようにコードが書かれていると開発者を信頼している、ということ
・お互いのコードのレビューがされていると開発者を信頼している、ということ
・ソフトが正しく文書化されていると、文書化チームを信頼している、ということ
・ユースケースに合ったテストが書かれ、行われ、チェックがされているとテスターを信頼している、ということ
・ユースケースに合った方法でデプロイしているとコードをデプロイした人を信頼している、ということ
・バグレポートをしているとコードをデプロイした人を信頼している、ということ
・バグレーポートを受け取った人がちゃんと修正していると信頼している、ということ

もちろんもっと色々なケースはあるでしょうが、話を進めるには十分でしょう。
ベンダー仕様のソフトを選択すれば信頼関係はもっと明確で絆が強いものでしょう。もし期待した品質のものでなければ別のベンダーに移行するか期待した仕様になるよう元のベンダーに作業するよう言うからです。

オープンソースソフトの場合はもっと漠然としています。
デザイナーやソフトウェアエンジニア、テスターなどの関与した人を見つけることは少なくともできるでしょう。でもその人たちに与える影響力はずっと小さいでしょうね。
おかしなパラドクスがあるのですが、ベンダーソフトには主張できてソフトウェアの方向性に対する影響力は比較的大きいです。（お金がかかってくるので）
ところが、オープンソフトに比べると欲しいものを得る事ができると確信したり、実際何が開発で起こっているかはっきりと見えません。

これはオープンソースだと、「私自身」が上にあげたどの項目にも参加する事ができるからです。
私、もしくは私の所属する組織は、アーキテクトにも設計者にも、文書作成やテスター、もちろんデプロイしたりバグ報告したり、どの役割にもなれるからです。
もしオープンソースへの影響は他の人と同等であれば、分散された信頼は推移する事が少なくなります。

作成、メンテナンス、要件やソフトウェア品質に対してみんな平等で、分散された信頼関係ネットワークの一部になります。
ベンダー仕様のソフトを買った場合に経験するような排除感は減るのです。

では、何故ベンダーからオープンソースソフトウェアを買ったりライセンスを得たりするのでしょう。
それは、そうすることで、上記に挙げた分散された信頼のネットワークの利点を得つつ、サポート、パッチ、トレーニングなど他のリスクを訴えることができるからです。

ソースから直接コードを得ることもできるでしょう。しかしこれはソフトを使用する人たちがそのリスクを選んだということではありません。またこれはオープンソースコミュニティに参加している人たちも例外ではありません。

信頼とは、とても複雑なものです。そして他のものや人を信頼するのも複雑です。別のブログでも少し書きましたが。
ただ私は決定したことに関して、どうして決定したのかと考え理解することは非常に大切なことだと思います。それはリスク周りの情報に基づいた選択をするのに必要だからです。

元の記事　https://aliceevebob.com/2019/06/18/trust-choosing-open-source/
2019年6月18日　Mike Bursell

大勢がレビューしていても信用しないという仮説

大勢がレビューしているから、バグがないという考え方。これは神話です。

この記事は　https://aliceevebob.com/2017/04/04/disbelieving-the-many-eyes-hypothesis/　を翻訳したものです。

コードを書くことは大変な作業です。
ソースコードを書くのは、もっと大変です。もっと、もっと大変なのです。

セキュリティの機能を実装するコードを書いているとわかりますが、このようなコードは詳細まで精査されたアーキテクチャとデザインに基づいています。

さらに世界中でレビューされるというプロセスを経た、パーフェクトで破られることがないスタンダードが反映されているかもしれません。
（「パーフェクトで破られることがない」まあ、本当かどうかは置いておいて、そう仮定しましょう）

が、このようにデザインとアーキテクチャが素晴らしくても、実際のソフトウェアに組み込むのはとても特殊なことです。

数学的にソフトウェアが正しいと証明されても、実現しようとしている機能が正しく実装できるソフトウェアを書くということは、科学と芸術の間にあるようなものです。（デザインとアーキテクチャに寄るとは言っても結局自分が何をしたいかに寄るのですが。）

ソフトウェアをデバッグしたり、ソフトウェアに踏み入ることでその正確さを推測しようとする人にとっては、当然のことです。ただ、このブログ記事のポイントではありません。

誰も（コードを5行以上書いたことがある人、Perlでだったら6行）実際にソフトウェアがこのプロセスでパーフェクトになるとは思わないでしょう。
しかしソフトウェアは出来るだけパーフェクトでバグがないよう作るべきだ、というのはわかってもらえると思います。
だからこそ、コードレビューはソフトウェア開発の中心なのです。

ラッキーなことに（少なくとも私的には）、私たちが日々使うコードのほとんどはオープンソースです。これは誰もがコード見ることができ、何千もの人にレビューしてもらうことができる、ということです。

ここで問題が生じます。
オープンソースがたくさんの人にレビューされるということは、全てのバグが解決されるという考え方があります。

これは神話です。とても危険な都市伝説です。

先ほどの考えには二面性があります。
一つ目は、「ビルドすれば、出来上がる」という間違った考え方です。
世界中に全てのウェブサイトがリストされていた昔、そこにあなたのウェブサイトを登録すれば皆さんに見てもらえると思った時代があったでしょう。
（私も登録しました。見てもらえました。これは奇跡です）

同じように、オープンソースプロジェクトは（おそらく）少なかったので、たくさんの人がコードレビューしてくれました。
このような時代は終わりました。ずっと昔に。

二つ目に、セキュリティの機能を、良い例として暗号化の基礎などですが、正しくレビューできる人はすごく少ないのです。

ベンダー特有のコードに問題が少ないという訳ではありません。むしろ、正反対です。
ベンダー特有のコードのデザインやアーキテクチャがレビューに対してオープンになっていない、ということではなく、コードを見てくれる人が少なくてヒエラルキーなプレッシャーと組織的な考え方に寄る危険性がとても大きいということなのです。

「ベンダーのコードは安全だ」というのは神話というより、フェイクニュースでしょうね。
多くの企業がセキュリティソフトを隠したい理由がよくわかります。
「知的財産の保護」と彼らがよく言うのは、実際リリースするのに安全ではないからなのではないか、と心配してしまいます。
私にとってセキュリティソフトとは、一貫して「オープンなソース」なのです。

では、何ができるでしょう。
セキュリティを気にする企業や組織はリソースを割いて機能を実装したりコードのチェックやレビューができるはずです。そして、そうする責任があると私は考えます。
その部分に私の勤めるRed Hatがコミットしているのです。

同時にオープンソースコミュニティはクリティカルなプロジェクトをサポートし、コードに含まれるレビューの数を増やそうとする方法を探しているのです。（例えば Linux Foundationの Core Infrastructure Initiativeです）

さらに学術組織に、オープンソースソフトの大切さをハイライトすることはもちろん、セキュリティソフトの書き方とレビューという暗黒アートを
生徒に訓練させるよう推奨する必要があります。

改善できることはあるでしょう。事実、改善もしています。
「多くのレビュー（略）神話」はコードを改善できないという訳ではなく、むしろできるということを認識しなければいけません。ただ、もっとエキスパートのレビューが必要だということです。

元の記事：
https://aliceevebob.com/2017/04/04/disbelieving-the-many-eyes-hypothesis/
2017年4月4日　Mike Bursell

1 クリティカルマスを目標に

2 デモ

3 ライセンスを選ぶ

4 文書作成

5 見えるプロジェクト

6 歓迎しましょう

7 仲の良い人と活動しましょう

結論：「人」です。

オープンソース

環境

マイルール

鍵の作成

鍵の保管

暗号化処理

通常のコンピューティング処理

結論 HSMを使うべき？

結論 HSMを使うべき？

1　クリティカルマスを目標に

2　デモ

3　ライセンスを選ぶ

4　文書作成

5　見えるプロジェクト

6　歓迎しましょう

7　仲の良い人と活動しましょう

結論　HSMを使うべき？

結論　HSMを使うべき？