← 2026-04-09 の一覧へ戻るホーム
Veracrypt プロジェクトの最新情報

2026/04/08 16:23

Veracrypt プロジェクトの最新情報

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

概要：
Microsoft は事前の警告やメールもなく、VeraCrypt のドライバ署名アカウントを突然停止しました。これにより、新しい Windows リリースが利用できず、Linux や macOS の更新は影響を受けません。現在の Windows ビルド（v1.26.24）は 2011 年に発行された証明機関で署名されており、まもなく期限切れとなるため、システムボリューム以外をマウントするユーザーは Secure Boot の互換性が危ぶまれます。
Microsoft に連絡（チャット・メール・電話・サポートページ）を試みても、自動応答しか返ってきず、人間のエージェントに繋がりませんでした。著者は Microsoft アカウント回復フォームを利用し、そのページからカスタマーサポートエージェントへ連絡することを、可能な回復手段として提案しています。
コミュニティのメンバーは、Microsoft の Reddit / Twitter アカウントへの投稿や、CEO である Satya Nadella への詳細情報とエラー画面キャプチャ付きメール送信を推奨しています。また、暗号技術者、メディア関係者、米国議員に支援を求める戦略もあります。 Pete Batard というユーザーは、.ie ドメインの WHOIS 検証失敗による同様の問題を報告し、レジストラ請求書を提出した後で解決しました。
アカウントが 30 日以上無効のままであると復旧できなくなる可能性があり、その場合 VeraCrypt は新しい署名証明書を設定するか、非システムパーティション／ボリューム用にサイン不要なワークアラウンド（例：アーカイブ風プログラム）を採用せざるを得ません。その間、ユーザーは VeraCrypt の新しい Windows ビルドをインストールできず、Secure Boot ユーザーのマウント問題が生じ、セキュリティソフトウェアエコシステム全体で署名済みドライバの一時的なギャップが発生する恐れがあります。

本文

概要

ファイル

  • レビュー
  • サポート
  • ソースコード
  • フォーラム
  • チケット
  • ドキュメント
  • FAQ
  • 寄付（Faire un don）
  • メーリングリスト
  • Wiki

プロジェクトの最新情報

作成日：2026‑03‑30
更新日：4時間前

みなさん、こんにちは。

ここ数か月にわたる不在後、進捗を共有したいと思います。いくつか課題に直面していますが、その中でも最も深刻なのは、Microsoft が私が長年使用してきた Windows ドライバとブートローダの署名用アカウントを終了させたことです。ログインしようとした際に表示されたメッセージのスクリーンショットを以下に添付します。

Microsoft からはメールや事前警告は一切送られませんでした。終了理由も示されず、メッセージには「上訴はできない」とだけ記載されています。様々な窓口で問い合わせを試みましたが、自動応答・ボットしか返ってきず、人間に接続できませんでした。この終了は VeraCrypt 以外の作業にも影響し、日常業務にも支障を来しています。

現時点では選択肢がありません。VeraCrypt に関しては Windows のアップデートを公開できない状態です。Linux と macOS は更新可能ですが、ユーザーの大多数が Windows を利用しているため、Windows リリースを提供できないことはプロジェクトにとって大きな打撃です。提案や支援にはオープンです。

現行 Windows バージョンに関する実務的質問

現在のバージョン 1.26.24 は 2011 年版 CA で署名されており、まもなく期限切れとなります。これが SecureBoot にどう影響するかは明らかですが、ユーザーとしてシステム外ボリューム（パーティション・ファイルコンテナ）をマウントする際にどのような影響が出るでしょうか？ VeraCrypt をインストールするためだけでも SecureBoot を無効化しなければならないのでしょうか？ また、ポータブル利用への影響は？

署名されていないバージョンを自分でビルドした場合も同様の質問です。

返信例

Hi Mounir,

お話を聞いて本当に申し訳ありません。以下のリンクから Microsoft に連絡してみてください。そのページには「Microsoft アカウント回復フォームのヘルプ」というリンクがあります：

https://support.microsoft.com/en-us/account-billing/get-help-with-your-microsoft-account-ace6f3b3-e2d3-aeb1-6b96-d2e9e7e52133

また「カスタマーサポートエージェントに連絡したい」というリンクもあります。すでに試されたかもしれませんが、再度ご確認ください。

Alex R さんの Reddit や X（旧 Twitter）への投稿を提案するアイデアも良いと思います。これらは適切な担当者へ転送されやすくなります。

アカウントが 30 日以上無効化されている場合、回復できない可能性があります。その際は新しいアカウントを作成し、ドライバ署名のために検証プロセスを再度行う必要があります。

少しでも役立つ情報になれば幸いです。ありがとうございます。
最後の編集：AJ B – 14 時間前

Microsoft の Reddit や Twitter アカウントへ投稿してもよろしいでしょうか？ それで注目を集められる可能性があります。

はい、大丈夫です。私はあまり SNS にいないので、これは役立ちます。ありがとうございます。

この状況を踏まえて、署名に依存しないプログラムを追加して、アーカイブの作成・抽出機能（リアルタイム変更は不要）を提供することを推奨します。これでターゲットを絞ったシナリオにも対応できます。

この件は残念な展開ですね、Mounir！ これはちょっと大げさかもしれませんが（アメリカのイディオムを使っています）、最近日本への転居に関わる何らかの小さな要因が、この説明不明のアカウント停止の根源になっている可能性はありますか？ 余計なことを考えてしまうのも私の趣味です。

本当に残念なお知らせですね。誰かがソフトウェアを報告し、違法行為に利用できると主張したためにアカウントが削除された可能性があります。一般的には監視・制御への傾向が強まっており、プライバシーへの尊重は薄れています。この制限を一時的でも回避する方法はありませんか？ たとえば現在のソフトウェアを非システムパーティションやボリュームに限定して使用できないでしょうか？

@idrassi
Microsoft CEO の Satya Nadella（satyan@microsoft.com）へメールを送ってみてください。最初の投稿から簡潔な詳細とエラーメッセージのスクリーンショットを添えて。以下はサンプルメールです。（テンプレートは省略します。）

まず、アカウントが本当に削除されたわけではなく、単に無効化・オフになっているだけだと思います。リサイクルビンに入った状態です… :)
暗号コミュニティや他の開発者（Bruce Schneier, Chris Titus, Niels Ferguson など）へ連絡し、Microsoft に関係する人物を知る人がいないか尋ねてみてください。あるいは Karen Easterbrook や Nathan Ide といった Microsoft 関係者に連絡しても良いでしょう。
メディア（Tom’s Hardware, Ars Technica, Wired, The Intercept, EFF）へも問い合わせ、プライバシーと暗号の分野で関連する Reddit サブを利用してください。また All‑in Podcast や Elon Musk のフォロワーとも接触するとよいでしょう。
さらに、米国議員（Tom Massie など下院議員、Rand Paul, Ron Wyden など上院議員）へ助けを求めることも考えてください。米国市民でなくても、多くのユーザーが米国にいるためプライバシー権利として訴える価値があります。
最後の編集：Preguntar Jeeves – 3 日前

Hey Mounir、Microsoft に共有できるメールアドレスはありますか？（私へ rafael@withinwindows.com でメールしていただければ、内部の関係者に転送します。）
最後の編集：Rafael Rivera – 6 時間前

Hi Mounir。あなたが直面した同じ問題を私は経験しました。Secure Boot の署名用開発者情報更新時にエラーが出ました（https://github.com/pbatard/rufus/issues/2918#issuecomment-3893620279 にスクリーンショットがあります）。
Partner Center 経由で Microsoft サポートに連絡し、問題を解決しました。私のケースでは「上訴はできない」はプロセスの別部分の定型文であり、正式なビジネス検証とは直接関係がありませんでした。
ドメイン名が .ie レジストラから取得されていたため、Microsoft が WHOIS データを自動的に検証できず、同じエラーが発生したようです。適切なデータ（主に最後の登録請求書）を提供するとサポート担当者は非常に協力的で、ビジネス検証を完了させてくれました。
あなたの問題も私と似ていると期待しています。Microsoft の誰かと連絡が取れれば、すぐに解決できるでしょう。
最後の編集：Pete Batard – 4 時間前

同じ日のほかのニュース

一覧に戻る →

2026/04/09 0:40

私、macOS XをNintendo Wiiにポート（移植）いたしました。

## Japanese Translation: --- ## 改良された要約 Mac OS X 10.0（Cheetah）は、Nintendo Wii 上でネイティブに動作するようにポートされ、コンソールをキーボード/マウス入力と GUI サポート付きの完全機能型デスクトップへ変貌させました。プロジェクトのコアは、*ppcskel* をベースに最初から書き直されたカスタムブートローダーです。このブートローダーは、Wii の PowerPC 750CL CPU を起動し、メモリレイアウトを設定し、最小限のデバイスツリー（root → cpus → PowerPC,750; memory）を作成します。SD カードから XNU カーネルをロードし、実行中にカーネルバイナリをパッチ（MEM1/MEM2 用の BAT 設定と USB Gecko へのコンソール出力）し、制御を XNU に渡します。 ブートローダーが提供する主要ドライバーは次の通りです： - **SD‑カードドライバー**：Starlet MINI IPC コマンド（IPC_SDMMC_SIZE, READ, WRITE）を介して IOBlockStorageDevice を実装し、XNU が SD カードからルートファイルシステムをマウントできるようにします。 - **フレームバッファドライバー**：0x01700000 に RGB フレームバッファ（640×480 @ 16 bpp）を提供し、Wii のアナログテレビ出力用に YUV へ変換して Mac OS X GUI を実現します。 - **USB サポート**：PCI デバイスのニブ（NintendoWiiHollywoodPCIDevice）を作成し、AppleUSBOHCI をパッチして受け入れさせ、OHCI ドライバーからバイトスワップ処理を除去することでリバースレトルエンディアンハードウェアに対応し、USB キーボード/マウス機能をフル実装します。 ブートローダーは Apple Partition Map を解析し、起動可能なパーティションを一覧表示し、/chosen/memory‑map ノード経由でカーネル拡張を直接メモリにロードできるようにするため、改変されていない Mac OS X インストーラーパーティションからのインストールも可能です。必要なカーネル変更は最小限（BAT 設定、“hollywood” I/O ベース取得、フレームバッファキャッシュ整合性修正）で済み、その他すべてのドライバーはブートローダーが提供します。 この成果は、歴史的にサポートされていなかったプラットフォーム――Nintendo Wii――でも Mac OS X Cheetah をエンドツーエンドで動作させることを示し、ホビイストに低コストのレトロコンソールとして機能するデスクトップコンピュータを提供します。

2026/04/09 4:23

**ソフトウェア開発者のためのUSB：ユーザースペース USB ドライバー作成入門**

## Japanese Translation: ``` USB デバイスの操作は、libusb を使用してユーザー空間だけで完全に処理できるため、カーネルレベルのドライバ開発は不要です。 例として、Fastboot モード（VID 18d1 / PID 4ee0）にある Android フォンを挙げます。接続すると `lsusb` は「Google Inc. Nexus/Pixel Device (fastboot)」と表示し、カーネルドライバは付いていません。また、ベンダー固有クラスインターフェースが 2 つのバルクエンドポイントを公開します：コマンド送信用 OUT 0x02 とレスポンス受信用 IN 0x81。 libusb のホットプラグコールバックはこのデバイスの到着を検出し、Fastboot コマンドを自動的に発行できます。典型的な手順は次のとおりです： 1. `libusb_control_transfer` を使用して GET_STATUS リクエストを送信します。2 バイトの応答はデバイスがセルフパワーであり、リモートウェイクアップをサポートしないことを示します。 2. GET_DESCRIPTOR リクエストを送信して完全なデバイスディスクリプタ（ベンダー／プロダクト ID、USB バージョン等）を取得します。 3. バルク OUT 0x02 を介して Fastboot コマンドを発行します（例：「getvar:version」を 64 バイトにパディング）。 デバイスは IN 0x81 で 4 文字のステータス（「OKAY」または「FAIL」）と任意のペイロードを返します。 同じユーザー空間アプローチは、バルク転送に依存する他の USB プロトコルにも適用できます。主な作業はカーネルコードを書く代わりにプロトコルロジックを実装することです。これにより OEM 向けドライバ開発が簡素化され、ブートローダーのテストが迅速化し、カーネルモジュールなしでカスタム USB デバイスの高速プロトタイピングやデバッグが可能になり、組込み開発者と広範な USB エコシステムに恩恵をもたらします。 ```

2026/04/08 17:53

**コードを読む前に実行しておくべき一般的な Git コマンド** - `git fetch --all` *リモートの全ブランチとタグを取得します。* - `git status` *現在のブランチと未コミットの変更点を確認します。* - `git checkout <branch>` *対象となる機能やバグ修正用ブランチに切り替えます。* - `git pull --rebase` *ローカルブランチを最新の upstream コミットで更新します。* - `git log --oneline --graph --decorate -5` *簡潔なコミット履歴を表示し、文脈を把握します。* - `git diff origin/<branch>..HEAD` *まだプッシュしていない変更点を確認します。* - `git rev-parse HEAD` *現在のコミットハッシュを取得（参照に便利）。* - `git tag --list` *利用可能なタグ一覧を表示し、バージョン管理に役立てます。* - `git show <commit>` *特定のコミットの詳細と差分を調べます。* これらのコマンドで、コードを掘り下げる前にリポジトリの状態を素早く把握できます。

## 日本語訳: 以下の文章を日本語に翻訳してください。 ### 修正版要約 この記事は、ソースファイルを検査する前にコードベースの簡易監査が隠れた健康リスクを明らかにできる方法を示しています。これは5つの簡潔な Git コマンドを実行することで達成されます。 1. `git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20` 過去 1 年間で最も変更頻度が高い上位 20 ファイルを一覧表示し、潜在的な「ドラッグ」スポット（高い変更率）をフラグ付けします。 2. `git shortlog -sn --no-merges` コミット数で貢献者をランク付けします。単一人物が 70 % 超を占める場合はバスファクターが低く、過去 6 ヶ月にその貢献者がいない場合は危機的状況を示唆します。 3. `git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20` バグ関連コミットが最も多いファイルを特定し、変更率データと照合して最高リスクコードをピンポイントします。 4. `git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c` 月ごとのコミット数を表示し、活動の加速または減退（例：半月間のドロップ）が重要人物の離脱を示す可能性があります。 5. `git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'` リバートとホットフィックスの数をカウントします。頻繁なリバートはデプロイ/テストが不安定であることを示し、ゼロの場合は安定性またはコミットメッセージ不足を意味する可能性があります。 これらの指標（変更ホットスポット、バスファクター問題、バグクラスタ、プロジェクトモーメンタム、火災対策頻度）は、コード複雑度測定だけよりも欠陥予測精度が高いと示されています（Microsoft Research 2005）。記事はスクワッシュマージワークフローが著者データを歪めることを警告しています。最初の監査に1時間を費やした後、筆者は特定されたリスクスポットに対して週単位で詳細調査を計画しています。関連研究としてはエンジニアリングチーム速度、Vim 使用、レガシー Rails 監査、Rails `default_scope` が引用されています。この手法は開発者に迅速なコミット履歴ベースの診断を提供し、高リスクファイルへの詳細コードレビューを集中させることでバグ削減、チームレジリエンス、およびリリース信頼性の向上を実現します。