BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース OpenJDKはSecurityManagerの非推奨を提案

OpenJDKはSecurityManagerの非推奨を提案

ブックマーク

原文(投稿日:2021/04/19)へのリンク

OpenJDKプロジェクトは、SecurityManagerを非推奨にする手段としてJEP-411を提案した。承認された場合、これは複数年にわたるプロセスの最初のステップになる。このプロセスは、OpenJDK Quality Outreach Campaign影響を受けるプロジェクトを、削除される前に代替案に導くものである。

JEPへの投票はまだ行われておらず、廃止は即時の削除を意味するものではない。賛成投票により非推奨プロセスが開始される。また、将来の削除によって以前のJavaバージョンにさかのぼって影響が及ぶことはない。SecurityManagerを削除する動きは、数年間(2016)進行中アプレット非推奨プロセス(2017)最近のフェーズ(2021)に倣う。JEP-411は、非推奨の説明を提供する。

「Security ManagerはJava 1.0から始まっています。これは、クライアント側のJavaコードを保護するための主要な手段ではありません。そして、サーバ側のコードを保護するために使用されることはめったにありません。Javaを前進させるために、従来のアプレットAPI(JEP 398)と連携して、Security Managerの削除を非推奨にする予定です。」

オリジナルのSecurityManagerは、クライアントPCで実行されるポータブルコードに対する防御として1996年に設計された。アプレットは、JavaScriptの初期バージョンには存在しなかった機能を追加するためにNetscape NavigatorのNPAPI(Netscape Plugin API)内で設計され、使えるようになった。

SecurityManagerの使用はアプレットの外部で発生し、影響を受けるいくつかのプロジェクトが特定されている。JEP-411を支持して発言した人もいる。InfoQは、Jakarta EEのセキュリティリーダーであるArjan Tijms氏と、Jakartaメーリングリストでの最近の議論について話した。

今、私は長い間、サーバ側のコードでセキュリティマネージャーを使用しない/依存しないことを主張してきました。信頼できない可能性のあるコードを自分のサーバで実行するという考えは、厄介で、とにかくやらないことだと思いました。単一のサーバインスタンスで複数のアプリケーションを実行している場合でもです。

  -Jakarta EEのセキュリティリーダーであるArjan Tijms

長いRedditスレッドは、Omnifacesでの2014年のTijmsの以前のコメントを引用し、次のように述べている。「Java SEセキュリティマネージャは、コードレベルの保護に使用されます。これは、サーバが信頼できないコードを実行することは非常にまれであるため、Java EEで必要になることはめったにないレベルの保護です(たとえば、インターネットから信頼できないアプレットを実行するブラウザなど)。」

Iron Clad Javaの著者であるJim Manico氏は、「私は文字通り、エンタープライズ開発で[SecurityManager]を使用したことはない」と述べている

SecurityManagerを使用しているプロジェクトは、さまざまなチャネルを通じてOpenJDKプロジェクトに参加できる。Apache LuceneのプロジェクトリーダーであるUwe Schindler氏は、影響を受けるプロジェクトとしてApache SolrElasticSearch/OpenSearchを特定した。これらのプロジェクトのアプレット以外のユースケースには、プラグインがホストに影響を与えることなく情報を読み取る機能が含まれている。他のプロジェクトには、セキュリティではなくSecurityManagerを監視に使用するApache NetBeansが含まれている。監視機能は、JDK Flight RecorderおよびContrast Community Editionなどのサードパーティシステムに移行された

議論が進行中であり、非推奨に賛成する投票であっても、影響を受ける当事者が代替案を得るための十分な時間が提供される。

この記事に星をつける

おすすめ度
スタイル

BT