サンダーバード、RNP、および優れたAPIの重要性

最近、 API設計についてThunderbird開発者とチャットしました  。この会話の間に、私は上の私の考えで共有 RNP、  OpenPGPのの新しい実装Thunderbirdは最近の代わりに使用し始めていること はGnuPGを。



対話者は、RNP APIを改善する必要があるという私の論文に懐疑的で、「主観的ではありませんか。どちらのAPIが優れていて、どちらが悪いのですか？」と尋ねました。 APIを評価するための適切な指標がないことに同意します。しかし、原則としてAPIを判断できないことに同意しません。



実際、経験豊富なプログラマーのほとんどは、APIを見ると、悪いAPIを認識すると思います。この記事でさらに、優れたヒューリスティックを開発することが判明すると思います。これは、GnuPG、Sequoiaでの（およびそれ以上の）自分の経験に基づいて構築しようとします。  およびRNP。次に、RNPAPIについて説明します。残念ながら、このAPIは簡単に誤用される可能性があるだけでなく、欺瞞的であるため、セキュリティが重要なコンテキストではまだ使用しないでください。しかし、サンダーバードのターゲットオーディエンスは、ジャーナリスト、活動家、弁護士、およびそのコミュニケーションパートナーなど、脆弱であることが知られている人々です。これらすべての人々は保護を必要としています。私の意見では、これはThunderbirdがRNPを使用するかどうかについてもう一度考えるべきであることを意味します。



注：このメールも読むことをお勧めします：  ThunderbirdでGPLライブラリを使用しましょう！ これを ThunderbirdDevelopmentPlanningの 投稿に送信 しました。

悪いAPIの特徴は何ですか？

JustusとKaiでSequoiaを開始する前は  、3人でGnuPGに取り組んでいました 。私たちは自分たちでgpgを掘り下げただけでなく、その後の多くのgpgユーザーと話し合ったり協力したりしました。人々はGnuPGについて多くの良いことを言うことができました  。





gpgに対する批判に関する限り、最も重要なのはAPIに関する2種類の批判でした。最初の要約はこれです：gpgAPIはあまりにも独断的です。たとえば、gpgはキーリングアプローチを使用します。したがって、OpenPGP証明書は、個人キーベースにインポートされている場合にのみ表示または使用できます。ただし、一部の開発者は、最初に証明書を確認してから、それをインポートしたいと考えています。たとえば、キーサーバーでフィンガープリントを使用して証明書を検索する場合 、返された証明書が本当に必要なものであるかどうかを確認できます。そのURLは自己認証であるためです。これはgpgを使用して実行できますが、回避策としてのみ、それに埋め込まれているプログラミングモデルの原則をバイパスします。基本的な考え方は次のとおりです。一時ディレクトリを作成し、それに構成ファイルを追加し、gpgに代替ディレクトリを使用するように指示し、そこに証明書をインポートし、証明書を確認してから、一時ディレクトリをクリアします。これは、 後続のgpgユーザーとの会話に基づいてJustusによって追加され  た 公式の推奨事項です。はい、この方法は機能します。ただし、オペレーティングシステムに固有のコードを作成する必要があります。このコードは遅く、バグが頻繁に発生します。



私たちが何度も遭遇した別のクラスの意見は、gpgを使用するには、このメカニズムを乱用しないように、多くの非自明なことを知る必要があるということです。または、別の言い方をすれば、gpg APIを使用するときは、コードに不注意で脆弱性が導入されないように十分に注意する必要があり ます。



2番目の懸念事項をよりよく理解するために、EFAILの脆弱性を検討して ください..。 gpg復号化APIの主な問題：メッセージを復号化するとき、入力が破損している場合でも、gpgはプレーンテキストを出力します。この場合、gpgはエラーを返しますが、一部のプログラムは依然として破損した形式でプレーンテキストを出力します。では、なぜですか？何も表示しないよりも、メッセージの少なくとも一部を表示する方が間違いなく良いでしょう。 EFAILの脆弱性は、攻撃者がこれを利用 して暗号化されたメッセージにWebバグを挿入する方法を示してい ます。ユーザーがこの投稿を表示すると、Webバグが投稿から漏れます。ふぅ。



では、このバグは誰のせいですか？GnuPG  開発者  は それを主張しました 問題は、gpgを誤って使用するという点で、アプリケーションレベルにあります。



メールユーザーエージェントは、ステータスコードDECRYPTION_FAILEDを尊重し、データを表示しないか、少なくとも、オラクルを作成せずに破損している可能性のあるメールを表示する適切な方法を選択することをお勧めします。メールが自信を刺激しないことをユーザーに通知します。



gpgはエラーを通知しました。アプリケーションはAPIコントラクトを尊重しません。私はGnuPG開発者に同意し、追加する必要があります。gpgインターフェースは、ユーザーに続行方法を指示しないため、時限爆弾でした（そして今でもそうです）。それどころか、簡単で一見有益な行動は間違っています。そして  この  種のAPI残念ながら、GnuPGでは一般的です。

良いAPIを作るものは何ですか？

gpg APIが独断的すぎて適切に使用するのが難しいという、これら2つのことを認識して、私の計画を形作りました。セコイアプロジェクトを始めたとき、私たちはそのような間違いを避けたいと同意しました。私たちの観察に基づいて、SequoiaAPIの開発の参照ポイントとして引き続き使用する2つのテストを実行しました。まず、高レベルのAPIに  加えて、独断的ではない低レベルのAPIが必要です。これは、ユーザーが禁止されていないことを実行することを妨げないという意味です。同時に、  APIはユーザーを適切な（ハードコードされた）ものに導き、適切なアクションを実行しやすくし、アクションを選択するときに最も明白にする必要があります。



すべてを可能にするがエラーを防ぐという、これら2つのわずかに矛盾する目標を達成するために、タイプと例の2つのツールに特に大きく依存してきました。APIコントラクトはコンパイル時に形式化され、特定の変換を強制するため、型を使用すると、意図しない方法でオブジェクトを使用することが困難になります 。例（コードスニペット）が  コピーされます。したがって、良い例は、関数を正しく使用する方法をユーザーに教えるだけでなく、ユーザーが関数を使用する方法にも大きく影響します。

タイプ

セコイアで型を使用する方法と、それらが優れたAPIの作成にどのように役立つかを例で示します。例をより明確にするために、OpenPGPに関するいくつかのコンテキストを思い出すと便利です。





OpenPGP



OpenPGPには、証明書、コンポーネント（キーやユーザーIDなど）、バインディング署名など、いくつかの基本的なデータ型があります。証明書のルートは、証明書のフィンガープリントを完全に識別するプライマリキーです（フィンガープリント=ハッシュ（プライマリキー））。証明書には通常、サブキーやユーザーIDなどのコンポーネントが含まれています。 OpenPGPは、いわゆるバインディング署名を使用してコンポーネントを証明書にバインドします。通常の主キーハッシュをフィンガープリントとして使用し、署名を使用してコンポーネントを主キーにバインドすると、後で追加のコンポーネントを追加できるように条件が作成されます。バインディング署名にはプロパティも含まれます。したがって、たとえば、サブキーの有効期間を延長するために、コンポーネントを変更することができます。結果として、複数の有効な署名を特定のコンポーネントに関連付けることができます。アンカー署名は基本的なだけでなく、OpenPGPセキュリティメカニズムに不可欠です。



有効なバインディング署名は多数存在する可能性があるため、必要なものを選択する方法が必要です。最初の概算として、必要な署名が、将来延期されていない、最新の、有効期限が切れていない、取り消されていない有効な署名であると想定します。しかし、有効な署名とは何ですか？セコイアでは、署名は数学的チェックに合格するだけでなく、ポリシーと一致している必要があります。例えば、による当社の能力にする 妥協の衝突に耐え、我々は唯一  の状況は非常に少数のSHA-1が可能。 （ PGPainlessに取り組んでいるPaul Schaubは  、最近、  これらの複雑さについて詳しく書いています。。）APIユーザーにこれらすべての考慮事項を念頭に置くように強制することにより、脆弱性の温床を作成します。セコイアでは、有効期限を取得する簡単な方法が安全な方法です。期待どおりに機能する次のコードについて考えてみます。

let p = &StandardPolicy::new();
 
let cert = Cert::from_str(CERT)?;
for k in cert.with_policy(p, None)?.keys().subkeys() {
    println!("Key {}: expiry: {}",
             k.fingerprint(),
             if let Some(t) = k.key_expiration_time() {
                 DateTime::<Utc>::from(t).to_rfc3339()
             } else {
                 "never".into()
             });
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

cert



 証明書です。ポリシーを適用することから始めます。 （ポリシーはユーザー定義ですが、原則として、  StandardPolicy で十分であるだけでなく、最も適切です）。実際、これは証明書のビューが作成される場所であり、有効なバインディング署名を持つコンポーネントのみが表示されます。重要なのは、それはまた、多くの新しいメソッドを変更して導入することです。たとえば、keysメソッドは、KeyAmalgamation  ではなくValidKeyAmalgamationを返すように変更され  ました。 （結果にはキーだけでなく、それに関連するすべての署名が含まれるため、これはマージです。このプロセスは塊魂と呼ばれる方がよいと 考える人もいます。..。 ¯\ _（ツ）_ /¯）ValidKeyAmalgamationには、上記の基準に従って有効なアンカー署名があります。また、key_expiration_timeのようなメソッドも提供します。これは、有効なキーでのみ意味があります。また、key_expiration_timeで使用される戻りタイプは人間工学的であることに注意してください。 key_expiration_timeは、生の値を返す代わりに、安全で使いやすいSystemTimeを返します 。



最初の「すべて許可」の原則に沿って、開発者は引き続き単一の署名へのアクセスを保持 し、サブパッケージ を  調査しますキーの有効期限が切れたときに、別の署名バインディングから検索します。ただし、Sequoia APIがキーの有効期限を正しく認識していると想定される方法と比較すると、他のアプローチはAPIと矛盾します。これは私たちの意見では良いAPIです。

の例

 Sequoiaライブラリの1.0リリースは、2020年12月に行われました。その9か月前に、フィーチャーコンプリートの状況に入り、リリースの準備が整いました。しかし、彼らは待って いました。ドキュメントと例をパブリックAPIに追加するのに次の9か月かかりました。 例については、Certデータ構造のドキュメントを  参照してください。何が得られるかを確認してください。私たちの投稿で指摘されているように、すべての機能の例を1つまで提供することはできませんでしたが、かなりのことを行いました。例を書くことへのボーナスとして、私たちはまた、いくつかの粗いエッジを見つけることができました。そして、それは私たちがその過程で磨きました。



リリース後、コードにSequoiaを含めた多くの開発者と話をすることができました。彼らのフィードバックに共通するスレッドは、ドキュメントと例の両方がどれほど有用であるかを認識することでした。これは私たちのコードですが、ほぼ毎日ドキュメントを調べて、独自の例をコピーしていることを確認できます。簡単です。例は特定の機能を正しく使用する方法を示しているので、なぜ最初からやり直すのですか？

RNP API

RNP は、主にRiboseによって開発されたOpenPGPの新しい実装です 。約  2年前、ThunderbirdはEnigmail をThunderbirdに統合すると同時に、GnuPGをRNPに置き換えることを決定し  ました  。サンダーバードがRNPを選んだという事実は、RNPを喜ばせるだけではありません。それはまた、RNPがメールを暗号化するためのOpenPGPの最も要求された実装になったことを意味します。



批判は否定的なものとして認識されやすいです。はっきりさせておきたいのですが、リボースが行っている作業は良くて重要だと思います。OpenPGPの新しい実装に時間と労力を費やしてくれた彼らに感謝しています。OpenPGPエコシステムは必死に多様性を追加する必要があります。しかし、これは、セキュリティが重要な状況で使用するための未熟な製品をリリースするための言い訳にはなりません。

セキュリティが重要なインフラストラクチャ

残念ながら、RNPは、私の意見では、安全に展開できる状態にはまだ達していません。 Enigmailは、データのプライバシーを懸念する人々だけでなく、自分自身の安全と対話者の安全を気にするジャーナリスト、活動家、弁護士によっても使用されていました。 2017年のインタビューで、ベンジャミン・イスマイル、アジア太平洋地域の章の頭 国境なき記者団は、言った：



私たちは、主に、当社のソースと自由に通信するためにGPGを使用しています。彼らが人権とこれらの権利の侵害について私たちに提供する情報は彼らにとって安全ではないので、私たちの会話の完全性を保護する必要があります。   組織からの 



ベンジャミン・イスマイルへのインタビュー国境なき記者団



サンダーバードは、この移行期間中であっても、これらのユーザーに可能な限り安全な体験を提供し続けることが重要です。

RNPおよびサブキーバインディング署名

セコイアで型を使用してAPIの誤用を困難にする方法について説明する際に、わずか数行のコードでキーの有効期限を確認する方法を示しました。まず、OpenPGPまたはRNPに不慣れな人に、RNPを使用して同じ機能を実装する方法を示す例から始めたいと思いました。次のコードは、証明書サブキー（キー）を繰り返し処理し、各サブキーの有効期限を表示します。注意として、有効期限はサブキーバインディング署名に保存され、値0は、キーが無期限になることはないことを示します。 

int i;
for (i = 0; i < sk_count; i ++) {
  rnp_key_handle_t sk;
  err = rnp_key_get_subkey_at(key, i, &sk);
  if (err) {
    printf("rnp_key_get_subkey_at(%d): %x\n", i, err);
    return 1;
  }
 
  uint32_t expiration_time;
  err = rnp_key_get_expiration(sk, &expiration_time);
  if (err) {
    printf("#%d (%s). rnp_key_get_expiration: %x\n",
           i + 1, desc[i], err);
  } else {
    printf("#%d (%s) expires %"PRIu32" seconds after key's creation time.\n",
           i + 1, desc[i],
           expiration_time);
  }
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

このコードを、5つのサブキーを持つ証明書でテストしました。最初のサブキーには有効なバインディング署名があり、有効期限はありません。2つ目は有効なバインディング署名を持ち、将来期限切れになります。3番目は有効なバインディング署名を持っていますが、すでに有効期限が切れています。4番目には無効なバインディング署名があり、それに従ってサブキーは将来期限切れになります。5番目の署名にはアンカーがまったくありません。出力は次のとおりです。

#1 (doesn't expire) expires 0 seconds after key's creation time.

#2 (expires) expires 94670781 seconds after key's creation time.

#3 (expired) expires 86400 seconds after key's creation time.

#4 (invalid sig) expires 0 seconds after key's creation time.

#5 (no sig) expires 0 seconds after key's creation time.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

まず、サブキーに有効なバインディングシグネチャがあるか、無効なバインディングシグネチャがあるか、またはバインディングシグネチャがまったくないかに関係なく、rnp_key_get_expiration呼び出しが成功することに注意してください。ドキュメントを読むと  、この動作は少し意外に思えます。それは言う： 

       .

 : 0 ,     .

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

キーの有効期限はバインディング署名に格納されているため、OpenPGPの専門家として、私はそれを次のように理解しています。rnp_key_get_expirationの呼び出しは、サブキーに有効なバインディング署名がある場合にのみ成功します。実際、有効なバインディング署名がない場合、関数はデフォルトで0になります。これは、上記のコメントを前提として、APIユーザーは次のように解釈することを期待します。このキーは無期限に有効です。



このコードを改善するには、最初に、キーに有効なバインディング署名があるかどうかを確認する必要があります。最近、CVE-2021-23991に対処するために、それを実行するためのいくつかの関数がRNPに追加されました  。特に、RNP開発者 キーが有効かどうかに関する情報を返すrnp_key_is_valid関数が追加されました。このアドオンは状況を改善しますが、開発者はこれらのセキュリティクリティカルチェックを実行するかどうかを明示的に選択する必要があります（Sequoiaの場合のように、すでに設定されているチェックを明示的に放棄するのではありません）。セキュリティチェックは有用な作業を行うことではないため、忘れがちです。セキュリティチェックが実行されていなくてもコードは機能します。また、何をチェックするかを正しく選択するには専門知識が必要なため、チェックは忘れられます。



次のコードはセキュリティチェックを提供し、rnp_key_is_validが無効と見なすキーをスキップします。

int i;
for (i = 0; i < sk_count; i ++) {
  rnp_key_handle_t sk;
  err = rnp_key_get_subkey_at(key, i, &sk);
  if (err) {
    printf("rnp_key_get_subkey_at(%d): %x\n", i, err);
    return 1;
  }
 
  bool is_valid = false;
  err = rnp_key_is_valid(sk, &is_valid);
  if (err) {
    printf("rnp_key_is_valid: %x\n", err);
    return 1;
  }
 
  if (! is_valid) {
    printf("#%d (%s) is invalid, skipping.\n",
           i + 1, desc[i]);
    continue;
  }
 
  uint32_t expiration_time;
  err = rnp_key_get_expiration(sk, &expiration_time);
  if (err) {
    printf("#%d (%s). rnp_key_get_expiration: %x\n",
           i + 1, desc[i], err);
  } else {
    printf("#%d (%s) expires %"PRIu32" seconds after key's creation time.\n",
           i + 1, desc[i],
           expiration_time);
  }
}

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

出力：

#1 (doesn't expire) expires 0 seconds after key's creation time.

#2 (expires) expires 94670781 seconds after key's creation time.

#3 (expired) is invalid, skipping.

#4 (invalid sig) is invalid, skipping.

#5 (no sig) is invalid, skipping.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

このコードは、有効なバインディング署名を持たない2つのキーを正しくスキップしますが、期限切れのキーもスキップします。これは、この関数が「...有効期限をチェックする」とドキュメントで警告されている場合でも、おそらく私たちが望んでいたものではありません。



期限切れのキーや証明書を使用したくない場合もありますが、それらに頼ることもあります。たとえば、ユーザーがキーの更新を忘れた場合、ユーザーはキーの有効期限が切れていることを確認してから証明書を確認し、この場合はキーを更新できる必要があります。gpg --list-keys



 期限切れのキーは表示され ませんが、証明書を編集するときに、期限切れのサブキーは引き続き表示されるため、ユーザーは有効性を更新できます。

$ gpg --edit-key 93D3A2B8DF67CE4B674999B807A5D8589F2492F9

Secret key is available.

sec  ed25519/07A5D8589F2492F9

     created: 2021-04-26  expires: 2024-04-26  usage: C   

     trust: unknown       validity: unknown

ssb  ed25519/1E2F512A0FE99515

     created: 2021-04-27  expires: never       usage: S   

ssb  cv25519/8CDDC2BC5EEB61A3

     created: 2021-04-26  expires: 2024-04-26  usage: E   

ssb  ed25519/142D550E6E6DF02E

     created: 2021-04-26  expired: 2021-04-27  usage: S   

[ unknown] (1). Alice <alice@example.org>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

期限切れのキーを無効にすべきでない状況は他にもあります。たとえば、アリスがボブに「1年間100ユーロを支払います」という署名付きメッセージを送信し、署名キーの有効期限が6か月であるとします。 1年が終わると、アリスはこの署名に基づいてボブに借りがありますか？はい、そう思います。署名は、添付されたときに有効でした。キーがすでに期限切れになっているという事実は関係ありません。もちろん、キーの有効期限が切れた場合、有効期限が切れた時点でキーによって封印された署名は無効と見なされます。同様に、メッセージは期限切れのキーで暗号化しないでください。



つまり、キーを有効と見なす必要があるかどうかは、状況依存です。rnp_key_is_validは何もないよりはましですが、名前にもかかわらず、この関数はキーが有効かどうかを判断する上で非常に微妙な違いがあります。



そのコミットの一部として、2番目の関数が追加されました  rnp_key_valid_till



。この関数は、「キーが有効であると見なされる前のタイムスタンプ...キーが有効でなかった場合、値としてゼロが返されます」を返します。この関数を使用すると、キーが有効であったかどうかを判断できます。このため、この関数がゼロ以外の値を返すかどうかを確認する必要があります。

int i;
for (i = 0; i < sk_count; i ++) {
  rnp_key_handle_t sk;
  err = rnp_key_get_subkey_at(key, i, &sk);
  if (err) {
    printf("rnp_key_get_subkey_at(%d): %x\n", i, err);
    return 1;
  }
 
  uint32_t valid_till;
  err = rnp_key_valid_till(sk, &valid_till);
  if (err) {
    printf("rnp_key_valid_till: %x\n", err);
    return 1;
  }
 
  printf("#%d (%s) valid till %"PRIu32" seconds after epoch; ",
         i + 1, desc[i], valid_till);
 
  if (valid_till == 0) {
    printf("invalid, skipping.\n");
    continue;
  }
 
  uint32_t expiration_time;
  err = rnp_key_get_expiration(sk, &expiration_time);
  if (err) {
    printf("rnp_key_get_expiration: %x\n", err);
  } else {
    printf("expires %"PRIu32" seconds after key's creation time.\n",
           expiration_time);
  }
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

結果：

#1 (doesn't expire) valid till 1714111110 seconds after epoch; expires 0 seconds after key's creation time.

#2 (expires) valid till 1714111110 seconds after epoch; expires 94670781 seconds after key's creation time.

#3 (expired) valid till 1619527593 seconds after epoch; expires 86400 seconds after key's creation time.

#4 (invalid sig) valid till 0 seconds after epoch; invalid, skipping.

#5 (no sig) valid till 0 seconds after epoch; invalid, skipping.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

今、私たちは私たちが望む結果を得ました！最初の3つのサブキーの正しい有効期限を表示し、最後の2つのサブキーが無効であることも示します。



しかし、詳しく見てみましょう  rnp_key_valid_till



。まず、OpenPGPでは、キーの有効期限は、キーが作成されたときからの符号なし32ビットインデントとして、これも符号なし32ビット形式で格納されます。したがって、関数はより広い型を使用するか、少なくともコードのオーバーフローをチェックする必要があります。 （私はこの問題を  報告しましたが、すでに修正されています。）



しかし、このわき柱を無視しても、機能はまだ奇妙です。 OpenPGPでは、キーは数期間有効である可能性があります。キーの有効期限が7月1日で、ユーザーが7月10日からのみ更新するとします。 7月1日から7月10日までの期間中、キーは無効でした。この間に生成された署名も無効と見なす必要があります。では、考慮される関数はそのようなキーに対して何を返す必要がありますか？さらに重要なことに、そのようなAPIのユーザーは結果をどのように解釈する必要がありますか？そのようなAPIを使用することはまったく適切ですか？ （ はい、私は尋ねました。）



セコイアでは、私たちは反対の方向に進みました。キーが有効であるという情報を返す代わりに、状況を反転させます。 APIユーザーは次のように尋ねる可能性があります。  このキーは時刻tで有効ですか。私たちの経験では、これは私たちが知っているすべての場合に実際に必要とされたすべてです。



RNPAPIでこの特定の問題を具体的に取り上げているとは思わないでください。これは私が最近考えていた 合併症です。 Thunderbird用の代替OpenPGPバックエンドを作成するためにRNPAPIを再実装したとき  、多くの同様の問題に直面し  ました。

結論

RNP開発者が犯した間違いは理解でき、言い訳になります。 OpenPGPは、他の多くのプロトコルと同様に複雑です。ただし、ファイル暗号化ツールだけでなく、柔軟性と信頼性の高いPKIを維持しようとすれば、大幅に簡素化でき ます。 



ただし、RNPAPIは危険です。 Thunderbirdは   、セキュリティが重要な状況で使用されます。 2017年のインタビューで、   組織犯罪と腐敗研究センター（OCCRP）のMichal'Rysiek 'Wozniakは、誰かの命が危機に瀕していることを明らかにしました。



私は本当に強く、我々はGnuPGのにすべてのこの時間を利用していなかった場合、当社の情報提供者とジャーナリストの多くが危険にさらされたり、バーの後ろであろうと信じている...



インタビュー と  ミハル「Rysiek」ウォズニアック汚職や組織の研究センターから犯罪



これはThunderbirdにどのように影響しますか？ 3つの選択肢があります。まず、ThunderbirdはEnigmailに戻る可能性があります。 EnigmailをThunderbird78に移植するのは難しいと思うかもしれませんが、多くのThunderbird開発者から、これはリフトで技術的に実現可能であると聞いています。しかし、ThunderbirdがEnigmailから離れることを選んだ理由の1つは、Enigmail開発者がユーザーがGnuPGを正しくインストールして構成するのを支援するために膨大な時間を費やさなければならなかったことです。したがって、このパスは理想的ではありません。



次に、Thunderbirdは別のOpenPGP実装に切り替えることができます。最近はたくさんあります。   から選択します。個人的には、サンダーバードはセコイアに切り替えるべきだったと思います。もちろん、私はセコイアの開発者なので、偏見があります。しかし、それはお金の問題ではありません。資金は私に支払います。自由市場では、おそらく今の収入の2倍の金額が提供されます。私はユーザーの保護に取り組んでいます。ただし、Sequoia APIと実装の利点は別として、この場合、Thunderbirdももう1つの点で勝ちます。つまり、この実装はすでに機能しています。数週間前、Thunderbirdの代替OpenPGPバックエンドであるOctopusをリリースしました 。 RNPと機能的に同等であるだけでなく、gpgとの統合など、以前は欠落していた多くの機能があり、いくつかのセキュリティホールにパッチを適用し、いくつかの非機能要件を満たしました。



第三に、ThunderbirdはOpenPGPの使用を完全に停止できた可能性があります。この決定は私には合いません。しかし、Thunderbirdの最も脆弱なユーザーのセキュリティについて何度か懸念しており、OpenPGPサポートをまったく提供しない方が現状よりも安全であると考えています。

---

MacleodVPSはAPI開発に理想的です。



上記のリンクを使用するか、バナーをクリックして登録すると、任意の構成のサーバーをレンタルした最初の月が10％割引になります。