Hyperledger Iroha

本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、Open Source Security Foundation (OpenSSF) バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。

これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください!バッジステータスは次のようになります。 プロジェクト 960 のバッジ レベルは passing です バッジステータスの埋め込み方法は次のとおりです。

これらはゴールドレベルの基準です。合格またはシルバーレベル基準を表示することもできます。

        

 基本的情報 4/5

  • 識別情報

    Iroha is a simple and straightforward DLT platform for asset and identity management. It has client libraries for mobile and web application development; novel consensus, called YAC, and SQL-powered validation.

  • 前提要件


    プロジェクトは、シルバー レベル バッジを達成しなければなりません。 [achieve_silver]

  • プロジェクトの管理・運営


    プロジェクトは2以上の "バス ファクタ"を持つ必要があります。 (URLが必要です) [bus_factor]

    Analysis over "dev" branch on December 4 2018: (this tool was used — https://github.com/aserg-ufmg/Truck-Factor/tree/master/gittruckfactor)

    2018-12-04 15:34:40 INFO hyperledger/iroha: Extracting and calculating authorship information... 2018-12-04 15:34:40 WARN DOACalculator:92 - No commits for test/module/irohad/ametsuchi/tx_presence_cache_stub.hpp TF = 7 (coverage = 46,18%) TF authors (Developer;Files;Percentage): Andrei Lebedev;314;21,23 Fyodor Muratov;185;12,51 Kitsu;178;12,04 kamilsa;134;9,06 grimadas;129;8,72 Akvinikym;104;7,03 Igor Egorov;101;6,83



    プロジェクトには少なくとも2人の関係を持たない重要な貢献者がいなければなりません。 (URLが必要です) [contributors_unassociated]

    https://poeditor.com/projects/view?id=171155

    We have unassociated contributors to our documentation, which has more than 20 pages in its printed version


  • その他


    プロジェクトは、各ソースファイルにライセンスステートメントを含まなければなりません。これは、各ファイルの先頭近くに次のコメントを含めることによって行うことができます: SPDXライセンス識別子:[プロジェクトに対するSPDXライセンス表現] [license_per_file]
  • 公開されたバージョン管理ソースリポジトリ


    プロジェクトのソースリポジトリは、共通の分散バージョン管理ソフトウェア(gitやmercurialなど)を使用しなければなりません。 [repo_distributed]

    Repository on GitHub, which uses git. git is distributed.



    プロジェクトは、新規または偶に参加する貢献者によって実行できる小さなタスクを明確に識別しなければなりません。 (URLが必要です) [small_tasks]

    Although we have https://github.com/hyperledger/iroha/issues?q=is%3Aissue+is%3Aopen+label%3Agood-first-issue in GitHub, we are switching now to Hyperledger JIRA board, where contributors can pick any task from the backlog: https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=215&projectKey=IR&view=planning



    プロジェクトは、中央リポジトリを変更したり、機密データ(プライベート脆弱性レポートなど)にアクセスするために、開発者に対して二要素認証(2FA)を要求する必要があります。推奨されませんが、2FAメカニズムは、SMSのような暗号化メカニズムを持たないメカニズムを使用することができます。 [require_2FA]

    All Iroha maintainers have 2FA turned on in GitHub with OTP generated in Google Auth app



    プロジェクトの2要素認証(2FA)は、偽装を防ぐために暗号化メカニズムを使用すべきです。ショート メッセージ サービス(SMS)ベースの2FA自体は、暗号化されていないため、この基準を満たしていません。 [secure_2FA]

    All Iroha maintainers have 2FA turned on in GitHub with OTP generated in Google Auth app


  • コーディング標準


    プロジェクトは、コードレビューの実施方法、チェックする必要があるもの、受け入れられる必要があるものなど、コードレビュー要件を文書化しなければなりません。 (URLが必要です) [code_review_standards]

    プロジェクトは、公開する前に、提案されたすべての変更の少なくとも50%を著作者以外の人がレビューして、それが価値のある変更であり、取り込みに反対する既知の問題がないかどうかを判断しなければなりません。 [two_person_review]
  • 作業ビルドシステム


    プロジェクトが再現可能なビルドを持たなければなりません。ビルドが発生しない場合(たとえば、コンパイルされないでソースコードが直接使用されるスクリプト言語)、「該当なし」(N/A)を選択します。 (URLが必要です) [build_reproducible]

    We use docker environment to build the code and all the dependencies are included in docker-build image here: https://hub.docker.com/r/hyperledger/iroha/ so anyone can reproduce the build


  • 自動テスト スイート


    テストスイートは、その言語の標準的な方法で呼び出すことができなければなりません。 (URLが必要です) [test_invocation]

    プロジェクトは、新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動化されたテストが実行される、継続的な統合を実装しなければなりません。 (URLが必要です) [test_continuous_integration]

    https://jenkins.soramitsu.co.jp/job/iroha/job/iroha-hyperledger/ test results are attached to every build, which is triggered with each commit



    プロジェクトは、選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがある場合、少なくとも80%のステートメント カバレッジを提供するFLOSS自動テストスイートを備えていなければなりません。 [test_statement_coverage90]

    選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがあれば、少なくとも80%のブランチカバレッジを提供するFLOSS自動テストスイートがプロジェクトに存在しなければなりません。 [test_branch_coverage80]
  • 優良な暗号手法を使用する

    一部のソフトウェアは暗号化メカニズムを使用する必要がないことに注意してください。あなたのプロジェクトが作成するソフトウェアが、(1) 暗号化機能を含む、アクティブ化する、または有効化し、(2) 米国(US)から米国外または米国市民以外にリリースされる可能性がある場合は、法的に義務付けられた追加手順の実行を要求される可能性があります。通常、これにはメールの送信が含まれます。詳細については、 Understanding Open Source Technology & US Export Controls「オープンソース技術と米国の輸出管理について」)の暗号化のセクションを参照してください。

    プロジェクトで作成されたソフトウェアは、ネットワーク通信すべてに対して、SSHv2以降、TLS1.2以降 (HTTPS)、IPsec、SFTP、SNMPv3などのセキュア プロトコルをサポートしなければなりません。FTP、HTTP、telnet、SSLv3以前、SSHv1などのセキュアでないプロトコルは、デフォルトで無効にしておき、ユーザーが特別に設定した亜場合のみ有効にしなければなりません。プロジェクトによって作成されたソフトウェアがネットワーク通信をサポートしない場合は、「該当なし」(N/A)を選択します。 [crypto_used_network]

    Right now we don't have implementation for this, but project roadmap already has items for TLS support in gRPC



    プロジェクトによって作成されたソフトウェアは、TLSをサポートあるいは使用する場合、少なくともTLSバージョン1.2をサポートしなければなりません。TLSの前身は、SSLと呼ばれていたことに注意して下さい。ソフトウェアがTLSを使用ない場合、「該当なし」(N/A)を選択します。 [crypto_tls12]

  • MITM(man-in-the-middle:中間者)攻撃に対応できる安全な配信


    プロジェクトウェブサイト、リポジトリ(ウェブからアクセス可能な場合)、およびダウンロードサイト(別々の場合)には、許容できない値を持つキー強化ヘッダーが含まれていなければなりません。 (URLが必要です) [hardened_site]
  • その他のセキュリティ上の課題


    プロジェクトは過去5年間にセキュリティレビューを実施していなければなりません。このレビューは、セキュリティ要件とセキュリティ境界を考慮しなければならりません。 [security_review]

    Security review was prepared for The Linux Foundation authored by Nettitude in 12th April 2018



    プロジェクトによって作成されたソフトウェアで強化メカニズムを使用しなければならないので、ソフトウェア欠陥がセキュリティ上の脆弱性を引き起こす可能性が低くなります。 (URLが必要です) [hardening]

  • 動的コード分析


    プロジェクトは、リリース前にプロジェクトによって作成されたソフトウェアの主要な製品リリースに対して、少なくとも1つの動的解析ツールを適用しなければなりません。 [dynamic_analysis]

    We use valgrind and sanitizers. We also use fuzzing for all client- and peer-facing components



    プロジェクトは、生成するソフトウェアに多くの実行時アサーションを含めるべきであり、動的分析中にそれらのアサーションをチェックするべきです。 [dynamic_analysis_enable_assertions]

このデータは、Creative Commons Attribution version 3.0以降のライセンス(CC-BY-3.0 +)のもとで利用できます。すべての人がデータを自由に共有および適応できますが、適切にクレジットを入れる必要があります。 誠とOpenSSFベストプラクティス バッジ貢献者のクレジットを入れてください。

プロジェクト バッジ登録の所有者: .
エントリの作成日時 2017-05-11 15:00:09 UTC、 最終更新日 2019-03-12 12:44:23 UTC 最後に2017-06-11 02:59:07 UTCにバッジ合格を達成しました。

もどる