CLion で OpenJDK のコードを読むためのセットアップ

Mac OS 12.3 + CLion で読むためのセットアップ

(1) GitHub から読みたい時点のコードをクローンしてくる. ghq 使ったので、次のコード.

ghq get    \
  --shallow \
  --branch 'jdk-19+25' \
  https://github.com/openjdk/jdk.git

(2) Makefile を生成する. precompiled headers は使わない. なお、 ビルドできないので、デバッグオプションとか入れてもあまり意味ない

cd ~/ghq/github.com/openjdk/jdk

bash ./configure  \
    --disable-precompiled-headers

(3) compile_commands.json を作る. これ後で CLion に読み込ませることで、プロジェクトとして認識してくれる.

make compile-commands

(4) Java をコンパイルする. コンパイル時に JNI のヘッダーが出力される.

make java

(5) (3) で作った compile_commands.json をプロジェクトのルートディレクトリーに置く.

mv ./build/macosx-server-fastdebug/compile_commands.json ./

(6) (5) で移動してきた compile_commands.json ファイルを CLion でプロジェクトとして開く.

---

余談

CLion は Makefile をプロジェクトとして取り込むことができるので、上記の (4) をやった後に取り込んだが、失敗した.

セキュア・バイ・デザイン 3章前半

読書メモ、対象がでかいし、ダラダラ読んでたのであまりまとまってない

---

全般的にいわゆる DDD 本(エリック・エヴァンスの本)のエッセンスが提示されている章。議論はそれなりに花が咲きそうだけど、結論はエヴァンス本読めになりそう。以下は個人的におっと思った部分のみピックアップしている

3.1.1 対象のドメインを簡素化したモデル

モデルは現実の簡素化です。 …ここで言うモデルとは、特定の表現方法のことではないのです。モデルとは、その対象となる現実の中で何が本質だと考えているのか…、ということを捉えた結果なのです。(p.80)

モデルと言うと何らかの図で何かを表現したものと考えていたが、そうではなく、現実から何かを捨て現在の課題にとって重要なものが何であるかを選別する行為であると読める。もしかしたら、ここは原文では modeling になっているかもしれないと思った。

3.1.2 モデルの厳格さ

ドメイン・モデルは豊富な情報を失う代わりに、厳格さ、ふるまいの明確さを得る。

システム開発において、そのシステムのユーザーとなる人に目を向けることは明らかに重要なことです。そして、そのシステムはユーザーとなる人が慣れ親しんだドメインを認識できるように…常に使っている言葉をシステムで使うように選択しなければなりません。(p.84)

ユビキタス言語の重要性

開発者にとって、結果としてすべきことはコードを書くことです。…コンピューターに対して受け取ったデータをもとに定義したルールに従って処理を行うように指示するものなのです。まさに、このことが、システム開発において厳格さが求められる理由なのです。

アプリケーションの開発者が行うのはコードを書くことなので、コンピューターを厳密に動かすためにモデルには厳格さが求められる。

厳格さは下記のように導かれる

• ドメイン・エキスパートとの会話から導出
• 開発者地震が今までの経験を元に推測する

3.1.3 深い理解を捉えたモデル

自転車に乗るロボットを作るのであれば、自転車に乗ることに関してほとんどのエキスパート…が有する知識よりも深い知識を持っていることが求められます。(p.88)

開発者がドメイン・エキスパートの頭の中を覗けたとしても、そこにはそのまますぐに使えるモデルが見つからない…ドメイン・エキスパートの中には真のモデルがないのです。…最高のドメイン・モデルを作り上げるためには、開発者とドメイン・エキスパートとの共同作業が必要不可欠であり、そのことを時間を掛けて何度も繰り返し行うことでモデルを進化させていきます。(p.89)

3.1.4 モデルの作成はモデルの選択を意味する

モデルを作成するには、多くの可能性のあるモデルの中から意思を持って選択していき、その中で、開発するシステムに対して要求されることにもっとも適したモデルを選択しなければなりません。つまり、モデルの目的を定義するのです。(p.90)

ここまでのまとめ

セキュア・バイ・デザイン 10章

クラウドによるセキュリティの原則を説明。その構成要素についても解説している。

クラウド的考え方によるメリット

• クラウドの提供する可能性（機能）を余すとこなく活用できる設計
  • 12 Factor App
  • Cloud Native
  • 3 つの R(後述)
• 12 Factor App + PaaSでの稼働(伸縮性 elasticity) = Cloud Native

10.2 環境に格納された構成情報

• アプリケーション可能のための構成情報の管理がセキュリティ的にも重要だが、場合によって複雑になる
  • 構成情報をコードに持たせると危険
    • コードにアクセスできるすべての人がアクセスできてしまう
    • 複数の環境にデプロイする必要が発生すると構成情報ファイル化する
  • 構成情報をファイルに記述すると危険
    • 監査証跡なしにファイルを読める
    • ファイルにアクセスできる人がすべてアクセスできる
    • コードを外部の開発者と共有するときに危険性に気づく
  • デプロイ環境に構成情報を配置するとリスクを移転できる
    • デプロイ環境から構成情報を取得するように変更することで、構成情報とコードが分離される
    • (+)問題はアプリケーションからインフラに移動し、アクセス制御、監査証跡の取得が容易になる
    • (-)開発者からインフラ関係者に問題が移動しただけになるため、暗号化などのさらなる仕組みが必要になる
    • (-)復号化の仕組みを入れるためにアプリケーションに複雑さが混入する。解決は 3 つの R

10.3 stateless アプリケーション

• インスタンス数でスケールアップするため、可用性向上
• メモリリーク・サーバー乗っ取り等の障害で破棄できるので完全性向上(?)
• 同、可用性向上

10.4 ログをファイルに残す危険性

• 相反する性質
  • システムの悪用につながる機密性の高い情報
  • アクセスをよくしたい利活用できる情報
• ログファイルの問題
  • 機密性が低い/漏出を防ぐ手段が乏しい/漏出後の追跡が難しい
  • だれも編集してないことの保証が難しく完全性に乏しい
  • インスタンス破棄、ディスク容量の制限などで可用性が低い
• ログのサービス化
  • ログをサーバーのインフラに依存させない
  • ログのカテゴリ化、ユーザーの分類によりアクセスを制御、アクセス履歴により監査証跡も取得 = 機密性の担保
  • ログの書き込みは信頼できるリソース(アプリケーション)に限定 = 完全性の担保
  • サービスのスケールによりインフラのリソース問題を解消 = 可用性

10.5 システム管理プロセス

• bad
  • ssh接続/秘伝のスクリプト・SQL によるメンテナンス
• good
  • システム管理プロセスのシステム化

これ、クラウド関係ないんじゃ…

10.6 サービス検出と負荷分散

• サーバーインスタンスが定期的に生成・破棄されるので必須の技術

10.7 エンタープライズセキュリティの 3 つの R

• Rotate
  • パスワード等のシークレットを定期的に変更する
• Repave
  • サーバーインスタンスを定期的に生成・破棄する
• Repair
  • ソフトウェアが更新可能になったらすぐに更新

    従来のセキュリティとの違い

• 従来
  • 変化を防ぐアプローチ
• クラウド
  • 変化を促すアプローチ

セキュア・バイ・デザイン 2 章

読書会に参加するので、まとめておくだけ

• 2.1 ビジネスルールの観点における完全性の問題
  • 不正なデータ入力によって損失が発生してた
  • 不正なデータに対するサブシステムの振る舞いが異なっている
• 2.2 浅いモデリング
  • 最初にモデリングできたと思ったあとに深く考えることをやめたその場しのぎのモデリング
  • 冊数、IDなどを Int 等の抽象的な型で表現できていることで満足(暗黙的に表現した概念)
  • 型がドメインでどのように機能するのかは理解できてない
• 2.3 深いモデリング
  • 概念の表現ではなく概念の理解に向かう
    • 下限・上限、許される文字など
  • 専用の型を用いる
• まとめ
  • モデルの不完全性から不具合=セキュリティ上の欠陥が生じる