JFrogはJCenterとBintrayを閉鎖へ

原文(投稿日：2021/02/04)へのリンク

JFrogは、人気のあるJavaアーティファクトのJCenterホスティングサービス、GoCenter (Goパッケージをホスト) およびChartCenter (Helmチャートをホスト) を含むホスティングサービス Bintrayを閉鎖すると発表した。メッセージの中で、JFrogの開発者関係担当副社長であるStephen Chin氏は次のように書いている:

Bintrayは、バイナリを公開および配布するためのユニバーサルクラウドプラットフォームを無料でオープンソースコミュニティに提供しました。Bintrayは、JFrogがJava OSSライブラリ、パッケージ、およびコンポーネントのJCenterリポジトリをホストすることでJavaコミュニティのサポートを支援しました。GoCenterとChartCenterを立ち上げ、同様のサービスをGoとクラウドネイティブのコミュニティに拡張しました。

JFrogは、開発者が直面する新しい課題に対応するために進化しています。Bintrayが提供するサービスの多くは、現在、オープンソースコミュニティ向けのJFrogプラットフォームによって提供されています。同様に、GoコミュニティとHelmコミュニティは、それ以来、私たちのセンタのドロップインの代わりとなるそれら独自の中央リポジトリを作成しました。

JFrogプラットフォームの生産性を合理化するために、2021年5月1日にBintray (JCenterを含む) 、GoCenter、およびChartCenterサービスを廃止します。これらのサービスのユーザはそれぞれの正規リポジトリに移行する必要があり、引き続き他のバイナリ配布のニーズに対応できる無料および有料のJFrogプラットフォームクラウドサブスクリプションの両方を提供します。さらに、JFrogはDockerなどのHubと提携して、顧客とコミュニティが依存するインフラストラクチャが適切に維持されるように支援しています。

JCenterは、SonatypeによるMaven Centralのホスティングよりも摩擦が少なく、Javaアセットを公開するための軽量ソリューションとして注目を集めた。しかし、JCenterの何でもありの性質は、Maven Centralに合法的に公開された一部のアセットがJCenterにコピーされ、途中で悪意のある動作を導入することを意味した。そのような例の1つは、変更されたバイナリアセットのセットがMaven Centralと同じ座標 (coordinate) にアップロードされてインシデントレスポンスが作られた。アプリケーションのビルドパスが最初に構成されたリポジトリに応じて、既知の良好なバージョンまたは不良なバージョンのいずれかが取得される。

おそらく、JCenterの最大の成長は、Gradleがドキュメントと例でJCenterをデフォルトのリポジトリにしたときに起こった。たとえば、jcenter() をデフォルトとして使用することを提案するサンプルのgradleプラグインなどだ:

repositories {
    // Use jcenter for resolving dependencies.
    // You can declare any Maven/Ivy/file repository here.
    jcenter()
}

さらに、新しいAndroid Studioプロジェクトでも同じことが行われた (また今でもそうだ) 。gradle依存関係ガイドラインに従っている:

allprojects {
    repositories {
        google()
        jcenter()
    }
}

BazelプロジェクトもMaven centralよりもjcenterの使用が奨励されている:

maven_install(
    artifacts = [
        "com.google.code.findbugs:jsr305:1.3.9",
        "com.google.errorprone:error_prone_annotations:2.0.18",
        "com.google.j2objc:j2objc-annotations:1.1",
    ],
    repositories = [
        "https://jcenter.bintray.com/",
        "https://repo1.maven.org/maven2",
    ],
)

何をすべきか

jcenter() または jcenter.bintray.com を使用するJava、Gradle、Bazel、またはMavenビルドがある場合、build.gradle ファイルまたは settings.xml ファイルから参照を削除した後、それらが正しくビルドされることを確認する必要がある (まだAntまたはIvyでビルドしている場合は、より新しいビルドツールにアップグレードする必要がある) 。キャッシュプロキシを使用している場合は、成功したビルドを検証する必要があるかもしれない。ローカルマシンのクリーンな環境上に構築されていても、中間キャッシュからキャッシュされたアセットを調達している可能性がある。

以前にJCenterに転送したプロキシを操作する場合は、Maven Centralを指すようにプロキシを切り替えてから、プロキシキャッシュがそれ自体を再充填するようにすることを勧める。これにより、Maven Centralにない、依存しているアセットを特定し、修正措置を講じることができる (リポジトリキャッシュを削除するのではなく、名前を変更する必要がある。後で提供されないリソースが必要になった場合に備えるためだ)。過去に誤って悪意のあるアセットの依存がある場合は、アセットのハッシュが変更されていることがある。

時間の経過とともに、一部の開発者は労力の少ない公開メカニズムを選択したため、JCenterにはMavenCentralには存在しない多くの重要な依存が存在する可能性がある。さらに、2000年代のMaven Centralにアセットをアップロードする際の問題により、一部のユーザは歴史的に先送りになっている可能性があるが、Maven Centralへのアップロードに関する重大な問題は10年以上ない。いずれにせよ、アップロードとフィルタリングメカニズムは、アップロードメカニズムとは独立して提供される、グローバルに分散されたアセットのキャッシュへの入力であり、repo.maven.apache.org およびGoogleがホストする maven-central.storage.googleapis.com にアクセスできる。

JCenterの使用を奨励するGradle (したがってAndroidも) ビルドツールにより、Mavenビルドまたはリポジトリを使用するだけのストックより、これらのビルドツールやオペレーティングシステムを使用するストックの方に大きな影響が及ぶ可能性がある。

Bintrayとそのホストされているリポジトリは、今月末からの新しい更新については読み取り専用となり、4月末に閉鎖される。閉鎖の直後にアセットを取得するメカニズムがあるかもしれないが、JFrogはそのようなアクセスに対して課金する可能性がある。また、アセットは2週間後以降に利用できる保証はない。

JFrogはアセットマネージャ Artifactoryを提供しており、サポート契約を結んでいる製品のユーザは閉鎖の影響を受けないため、このパブリックフロントエンドがなくなる間は、製品の背後で有料で利用できる可能性があると述べている。他のアセットマネージャを使用するユーザはそのような優先アクセス権を持たないため、他のビルドツールまたはプロキシを使用している場合は、依存関係を修正または置換することを勧める。

Maven Centralへの移行

SonatypeのCTOである (Maven Centralを運営している) Brian Fox氏は、以前JCenterにアセットを公開することを選択した人たちにいくつかの提案をした (そしてその後ブログに書きいた) :

Bintray / jcenterの発表が原因でおかしくなり、JavaコンポーネントをMaven Centralに取り込む必要がある場合でも、心配する必要はありません。知っておくべきことがいくつかあります:

おそらく数年前に http://oss.sonatype.org にデプロイして以来、目に見えない多くの改善が行われています。検証とオンボーディングのプロセスが自動化されているため、座標 (coordinate) の承認がはるかに高速になり、多くの場合、自動的に行われます。

はい、まだ座標 (coordinate) を検証しています。これは16年ほどの間常に当てはまり、それは変わらないでしょう。座標 (coordinate) の検証は、人々が自分ではないプロジェクトのふりを (簡単に) できないようにする手段です。私は最近それについてここに書きました: https://blog.sonatype.com/malware-removed-from-maven-central

以前にBintrayにデプロイしていて、まだCentralにプロモートしている場合は、私たちのシステムですでに構成されているため、直接デプロイを開始するために必要なものが揃っているはずです。よくわからない場合は、チケットを作成してください。サポートします。

以前にBintrayにデプロイしていて、Centralにプロモートしていない場合は、セットアップを行う必要があります。座標 (coordinate) の処理方法を理解することは会話になります。これらの長年の要件については、ここで確認できます: https://central.sonatype.org/pages/choosing-your-coordinates.html

そして、これらすべてで、私たちは支援のためにここにいます、あなたが混乱したり苦労したりしている場合は、ただ尋ねてください。座標 (coordinate) の要件がプロジェクトで機能しないと思われる場合は、話し合い、理解してみましょう。必要に応じて私にツイートするか、@sonatype_ossrh か、上記のJiraでチケットを作成してください。

最後に、Centralにデプロイしていて、プロジェクトの依存のセキュリティ分析を確認したい場合は、これにも取り組んでいます。私に依頼してください、そして私はあなたと私たちが持っているものをプレビュースタイルで共有します。私たちはちょうどアルファプログラムを立ち上げようとしていました、そう YOLO (人生一度きり) です。ここにそれがあります。

もちろん、過去10年間にJCenterに公開したすべての人がプロジェクトを維持しているわけではなく、オープンソースソフトウェア業界で働き続けているわけでもないため、元のコードベースを移行できない可能性がある。統計的には、ソフトウェアの元の作成者または発行者が何人かに譲渡された可能性もある。これは可能だが、すべての依存が移行される可能性は低いため、他の組織のボランティアが後方ミラーを維持しない限り、一部のソフトウェアが永久に失われる可能性がある。

JCenterとBintrayの閉鎖によってどのような影響を受けますか? コメントで教えてください。