ウェブサーバのTLS ChaCha20-Poly1305で通信させたい

以前にECDSAな証明書を作成したときにP-256を使ったけど、P-256は根拠は無いがなんか信用できないという人がいるのも確か。そこで来たるべくTLSv1.3時代を見据えてChaCha20-Poly1305やX25119にも対応させてみたい。速いらしいし。

サーバーOSは例によってFreeBSD、ウェブサーバはNginx、TLSに使うのはLibreSSLではなくOpenSSLとする。

OpenSSLの置き換え

X25519を使用するにはOpenSSL 1.1.0以上が必要だがFreeBSDのportsでOpenSSL(security/openssl)をインストールしている場合は1.0.xの筈なので非対応。security/openssl-devに変えなければならない。つい2ヶ月ほど前まではsecurity/openssl-devをインストールしようとすると多くの関連portsがビルドエラーになっていたが、急速に対応状況が改善していて2018年6月11日時点ではOpenSSLに依存しているportsの殆どがsecurity/openssl-dev対応になっている。一部非対応portsも残っているので油断はできないが。

/etc/make.conf(1行変更)
(変更前)
DEFAULT_VERSIONS+=ssl=openssl

(変更後)
DEFAULT_VERSIONS+=ssl=openssl-devel

OpenSSL ports置き換え手順 (portsツリー更新は省略)
### OpenSSLのオリジン替え
# portupgrade -o security/openssl-devel security/openssl
### 上のコマンドで反応しない場合はこちら、上で更新されたら↓の1コマンドは不要
# portupgrade -f -o security/openssl-devel security/openssl

### OpenSSLに依存しているportsを全て更新 (時間かかる)
# portupgrade -fr security/openssl-devel

Nginxの設定

server {
    listen 443 ssl http2;
    listen [::]:443  ssl http2;
    server_name hoge.example.com;

中略

    #RSAの証明書
    ssl_certificate      /path/rsa.pem;
    ssl_certificate_key  /path/rsa-key.pem;

    #ECDSAの証明書
    ssl_certificate      /path/ecdsa.pem;
    ssl_certificate_key  /path/ecdsa.key;

    #DHパラメータファイル (この記事の設定的には不要な筈だが、無いとNginxがエラーになる筈)
    ssl_dhparam          /path/dhparam4096.pem;
    
    ssl_protocols        TLSv1.2;
    ssl_prefer_server_ciphers  on;
    ssl_ciphers          ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;
    ssl_ecdh_curve       X25519:prime256v1;

中略

}

ECDSAの証明書が 無い or 使わない ならECDSA証明書の項目は削除でssl_cipherでECDSAを含む暗号スイートを削る。(半分になる)
今回は趣味でChaCha20-Poly1305を先頭に置いたが、サーバー側のCPUがIntelやAMDでAES-NIを効かせた処理速度を考えるとAESを優先させたいところ。逆にスマートフォンの閲覧者が多いサイトであれば(サーバー側が多少ツラくても) 非AES-NI環境で高速なChaCha20-Poly1305を優先してやると良いかも。
P-256が嫌いならssl_ecdh_curveから :prime256v1 を削るか別のに変える。

Nginxの再起動

###設定が致命的に間違っていないことを確認する
# service nginx configtest

###エラーが出ないならNginxを再起動する。
# service nginx restart

ブラウザで接続してみる

RSAの証明書のサイトでChaCha20-Poly1305 X25519 1
証明書がRSAなサイトでChaCha20-Poly1305 X25519な接続になるとブラウザではこのような表示。
(Chromeではページを表示して[F12]でデベロッパツールを開き[Security]タブを選択する)
ちなみに上の画像は「がとらぼ」をPC版のChromeで表示したもの。(2018年6月11日現在)

RSAの証明書のサイトでChaCha20-Poly1305 X25519 1
証明書がECDSAなサイトでChaCha20-Poly1305 X25519な接続になるとブラウザではこのような表示。
これは「がとらぼ」ではない別なサイトをECDHE-ECDSA-CHACHA20-POLY1305を最優先にして試したもの。

RSAの証明書のサイトでChaCha20-Poly1305 X25519 1
証明書がRSAなサイト(ここのこと)をQualysSSL LabsのSSL Server Testで見たもの。暗号スイートの優先順位も上の設定例で意図したとおりになっている。

ChaCha20って速いのかしら

###AES-NL有効化状態で計測
% openssl speed -elapsed -evp chacha20
% openssl speed -elapsed -evp aes-128-gcm
% openssl speed -elapsed -evp aes-256-gcm
% openssl speed -elapsed -evp aes-128-cbc

###AES-NL無効化状態で計測
% setenv OPENSSL_ia32cap "~0x200000200000000"      ←(tcsh用環境変数セット)
% openssl speed -elapsed -evp chacha20
% openssl speed -elapsed -evp aes-128-gcm
% openssl speed -elapsed -evp aes-256-gcm
% openssl speed -elapsed -evp aes-128-cbc

上のコマンドをIntel Pentium G630T 2.3GHzという非常に非力なPCで実行してで比較してみた。aes-128-cbcはAES-NLが効きやすいので有効化・無効化の差をはっきりと示す為の参考程度で。
逆に言うといまどきのセキュリティ重視な設定のウェブサーバ用途ではAES-NLは以前と違いあまり恩恵がない?ハードウエアの性能によるかしら。

速度比較AES-NLオン 1
AES-NLを有効化した計測結果。3秒で何回計算したかというもの。緑が参考値のaes-128-cbcだが、AES-NL有効でChaCha20とほぼ同じくらいを出せたのは16バイトのブロックの場合だけ。もっとaes-128-cbcが高い値になると思っていたので意外。
他のサイズではChaCha20が圧倒。ざっくり見てaes-128-gcmの3倍の値を出している。

速度比較AES-NLオン 2
AES-NLを有効化した計測結果。上のグラフの結果から計算回数とブロックの大きさを掛けて速度にしたもの。(実際にはコマンド実行で両方の数値が表示される)
効率からみると8192バイトのブロックが最も良い数値になるのかしら。こちらもaes-128-cbcがChaCha20と対等だったのは16バイトのブロックのときだけ。他はChaCha20が圧倒。そして、256バイト以上のサイズのブロックではaes128-gcm, aes-256-gcm, aes-128-cbcで大して変わらないことに。

速度比較AES-NLオフ 1
AES-NLを無効化した計測結果。3秒で何回計算したかというもの。AES-NLが効いてないので緑のaes128-cbcが1/3ほどに低下している。他のaes128-gcmやaes128-gcmも激減というほど酷くはないものの数値の低下はある。

速度比較AES-NLオフ 2
AES-NLを無効化した計測結果。上のグラフの結果から計算回数とブロックの大きさを掛けて速度にしたもの。(実際にはコマンド実行で両方の数値が表示される)
圧倒的な差を見せつけてChaCha20が勝利。

今回はCPUがショボイというのもあってか「がとらぼ」の中の人の思惑通りというか都合良くもChaCha20以外の選択肢はないだろというような圧倒的な結果になったが、サーバのマシンの性能によっては必ずこうなるとは限らない筈なのでウェブサーバで実際に試してみて安全で効率の良さそうな暗号スイートの優先度を上げるというのもアリかも。もちろん閲覧者の皆がメジャーブラウザの新しいバージョンを使っているとは限らないのでどうしても接続互換性重視ということであればChaCha20-Poly1305が最優先ということにはならないだろうけど。

日本の銀行のSSL/TLS対応状況 2018年6月

セキュリティ基準であるPCI DSSのv3.2では2018年6月30日、つまり今月末をもって脆弱性のあるSSL3.0とTLSv1.0の実装(使用)を無効化しなければならないとなっている。TLSv1.1にも脆弱性があって非推奨になってる筈だけどPCI DSSでは1.1以上にしろということなので1.1は使えるのね。

最近ではYahoo! JAPANが2018年6月1日以降TLS1.0/1.1のサポートを順次終了っていうのがニュースになってたけど、これが本来のあり方で他のウェブサイトも倣って欲しいところだけど、PCI DSSでそうなってるから仕方なくといった感じでTLSv1.0だけ無効化してる業者をチラホラ見る程度。むしろ、うちはPCI DSS関係ないからって逃げてる企業が殆ど?

PCI DSSはクレジットカード業界用なので銀行には関係ないっちゃ関係ないんだけど、銀行も全く無関心ではなかった筈。そこで銀行コード1000番以下で信託銀行や外国の銀行を除いたものに「ゆうちょ銀行」を加えた銀行で「個人顧客向けのオンラインバンキングのログイン画面」のページを表示したときに使われているSSL/TLSがどうなっているか調べてみた。

銀行名 SSL
3.0
TLS
v1.0
TLS
v1.1
TLS
v1.2
ホスト名 その他
みずほ銀行 表示 弱いのしかない, RC4
三菱東京UFJ銀行 表示 一応普通 順序が一部変
三井住友銀行 表示 弱いのしかない, RC4
りそな銀行 表示 優先順が酷い 使われるのは弱いかも, RC4
埼玉りそな銀行 表示 優先順が酷い 使われるのは弱いかも RC4
ジャパンネット銀行 表示 普通だがRC4あり
セブン銀行 表示 普通
ソニー銀行 表示 普通だがRC4あり
楽天銀行 表示 普通
住信SBIネット銀行 表示 一応普通 順序が一部変
じぶん銀行 表示 普通
イオン銀行 表示 危険, 再ネゴ
大和ネクスト銀行 表示 普通
北海道銀行 表示 弱い順
青森銀行 表示 弱い順
みちのく銀行 表示 弱い順
秋田銀行 表示 弱い順, 秋田銀行ドメインは弱い+ssl3
北都銀行 表示 弱い順
荘内銀行 表示 弱い順
山形銀行 表示 弱いのしかない, RC4
岩手銀行 表示 弱い順
東北銀行 表示 弱い順
七十七銀行 表示 弱い順
東邦銀行 表示 弱い順
群馬銀行 表示 弱い順
足利銀行 表示 弱い順
常陽銀行 表示 普通だが弱め
筑波銀行 表示 弱いのしかない, RC4
武蔵野銀行 表示 弱いのしかない, RC4
千葉銀行 表示 弱い順
千葉興業銀行 表示 弱い順
きらぼし銀行 表示 弱い順
横浜銀行 表示 弱い順
第四銀行 表示 弱いのしかない, RC4
北越銀行 表示 弱い順
山梨中央銀行 表示 弱い順
八十二銀行 表示 弱いのしかない, RC4
北陸銀行 表示 弱い順
富山銀行 表示 弱い順
北國銀行 表示 弱いのしかない, RC4
福井銀行 表示 弱い順
静岡銀行 表示 弱い順
スルガ銀行 表示 弱い順, RC4
清水銀行 表示 弱い順
大垣共立銀行 表示 弱いのしかない, RC4, ROBOT
十六銀行 表示 普通
三重銀行 表示 弱い順
百五銀行 表示 弱い順, RC4
滋賀銀行 表示 弱い順
京都銀行 表示 弱い順
近畿大阪銀行 表示 優先順が酷い 使われるのは弱いかも, RC4
池田泉州銀行 表示 弱い順
南都銀行 表示 普通だが弱め
紀陽銀行 表示 弱い順
但馬銀行 表示 弱い順
鳥取銀行 表示 弱い順
山陰合同銀行 Windows IE以外で利用不能のため調査できず
中国銀行 表示 弱いのしかない, RC4
広島銀行 表示 弱いのしかない, RC4
山口銀行 表示 普通
阿波銀行 表示 弱いのしかない, RC4
百十四銀行 表示 弱いのしかない, RC4, POODLE
伊予銀行 表示 弱い順
四国銀行 表示 弱い順
福岡銀行 表示 弱い順
筑邦銀行 表示 弱い順
佐賀銀行 表示 弱い順
十八銀行 表示 弱いのしかない, ROBOT
親和銀行 表示 弱い順
肥後銀行 表示 弱い順
大分銀行 表示 弱い順
宮崎銀行 表示 弱いのしかない, RC4
鹿児島銀行 表示 弱い順 RC4
琉球銀行 表示 弱いのしかない, RC4
沖縄銀行 表示 弱い順
西日本シティ銀行 表示 弱い順
北九州銀行 表示 普通
新生銀行 表示 順は良いがRC4あり, POODLE
あおぞら銀行 表示 弱い順
北洋銀行 表示 弱い順
きらやか銀行 表示 弱い順
北日本銀行 表示 弱い順
仙台銀行 表示 弱い順
福島銀行 表示 弱い順
大東銀行 表示 弱い順
東和銀行 表示 弱い順
栃木銀行 表示 弱い順
京葉銀行 表示 弱い順
東日本銀行 表示 弱い順
東京スター銀行 表示 弱い順
神奈川銀行 表示 弱い順
大光銀行 表示 弱い順
長野銀行 表示 弱い順
富山第一銀行 表示 弱い順
福邦銀行 表示 弱い順
静岡中央銀行 表示 弱い順
愛知銀行 表示 弱い順
名古屋銀行 表示 弱いのしかない, RC4, ROBOT
中京銀行 表示 弱い順
第三銀行 表示 弱い順
関西アーバン銀行 表示 弱い順
大正銀行 表示 弱い順
みなと銀行 表示 弱い順, RC4
島根銀行 表示 弱い順
トマト銀行 表示 弱い順
もみじ銀行 表示 普通
西京銀行 表示 弱い順
徳島銀行 表示 弱い順
香川銀行 表示 弱い順
愛媛銀行 表示 弱い順
高知銀行 表示 弱い順
福岡中央銀行 表示 弱い順
佐賀共栄銀行 表示 弱い順
長崎銀行 表示 弱い順
熊本銀行 表示 弱い順
豊和銀行 表示 弱い順
宮崎太陽銀行 表示 弱い順
南日本銀行 表示 弱い順
沖縄海邦銀行 表示 弱い順
きらぼし銀行の旧八千代銀行用 表示 弱い順
ゆうちょ銀行 表示 弱いのしかない, ROBOT

リスト幅の制限でホスト名の「表示」にマウスカーソルを合わせるとホスト名を表示するようにした。クリックしちゃダメ。

これがまぁ驚いたことに6月8日の時点ではTLSv1.0を無効化しているところは1行も無い。それどころかいまだにSSL3.0を有効化しているのが2行、何をお考えなのかTLSv1.0だけを有効化しているのが1行というありさま。とりあえずこの3行のオンラインバンキングは滅べ。

TLSv1.1は本当は無効化が望ましいけどTLSv1.0を有効化している時点でもうどっちでも良い。でも、少なくともTLSv1.2は有効化しとけと言いたいのが百十四銀行。

採用している暗号スイートは銀行・オンラインバンキングを請け負ってる業者によってまちまちだけど、「普通」な設定(暗号強度の高いものを含み強度の高いものの優先順位を高くする)というのが意外と少なくて、弱い暗号スイートしか無いとか、強い暗号スイートが含まれるけど優先順位が弱い順なのでまず使われないというのが殆ど。これは銀行の変な横並び意識なのか金融庁の意味不明なご指導による賜物なのかは不明。
最初はIPAの「SSL/TLS暗号設定ガイドライン」のいうところの「セキュリティ例外型」にしてるのかと思ったけど、意味のある接続互換性優先でもなんでもなくて単に利用者全員が低い暗号強度で通信するようになってるだけなのよね。

で、接続互換性を大切にしてより多くの種類の端末・OS・ブラウザでオンラインバンキングを利用できるようにしているのかと思いきや、WindowsとIEを推奨とか、怪しいソフトウエアをインストールしないとダメ、その怪しいアプリはWindows専用だったり、酷いとWindows+IEでないとログインページに辿り着けないとか、どことはいわないけど山陰合同銀行とかもう何をしたいのか意味分かんない。
セキュリティ重視なら本来は強度が高く安全なプロトコル・暗号スイートを使える端末しか接続させるべきではなく、そういう方向で古いOS・ブラウザの切り捨てをすべき。

あと、銀行のサイトではフィッシング対策だとして怪しいアプリのインストールを推奨・強制するクセに、そして「フィッシング詐欺にお気をつけ下さい」「フィッシングサイトへの誘導にお気をつけ下さい」とさかんに警告するクセに、オンラインバンキングを利用しようとするとドメインが銀行のウェブサイトとは違う他所にあるところに案内も警告もなく移動させてログイン情報を入力させるのは、フィッシングサイトへの誘導と何ら変わらないんだけど銀行さんはどうお考えなのでしょうか。
ページを移動したらドメインが変わるというのに利用者が慣れてマヒするように仕向けてどうするよ?

Gecko Linuxの罠

openSUSE Leap 15.0がリリースされたので試してみたがあちこち変過ぎて常用を断念。LeapはローリングリリースのTumbleweedと比べればちょっとは安定版の筈なんだけど個人的に相性が非常に悪くて悪いところに当たりまくり。少しオシャレになったところでハングアップ頻発ではお話にならない。

で、他のLinuxディストリビューションのKDE Plasma5デスクトップを幾つか試したのだけど、これらもやっぱりちょっと変。今のところPlasma 5.12とMesa 18の組み合わせでは完成度が下がるみたい。

そこで、openSUSEの古いバージョンから贅肉を取り除いてスリム&エレガントになったみたいなGecko Linuxなら古いバージョンのソフトウエアが使われているから変なところが無いかなと思ってGecko Linux ローリングリリース版(≒openSUSE Tumbleweed)のPlasma5版を入れてみた。(以前に使っていたのはGecko Linuxスタティックリリース版≒openSUSE Leap)

ところが、更新リポジトリ・パッケージの関係でGecko Linuxは現在(2018年6月2日)は凄い地雷になっていた。油断してパッケージを入れると(システム再起動後は)真っ黒なデスクトップにマウスカーソルが表示されるだけのドッグランならぬマウスランになってしまう。それを回避してまともに使えるようにするのがこの記事。暫くして新しいGecko Linuxのイメージファイルが提供されるようになったら改善される筈だけど、いつかMesaのバージョンが上がったときにまた同じようにトラブる筈なので備忘録として残す。

インストール時の罠対処

Gecko Linuxのインストーラーはパーティションの設定だけが意地悪で他は普通。パーティションの指定の画面になったら「手動」を選び、「新しいパーティションテーブル」で全消し、MBRを指定。そしてリストの「未割当」を選んで「作成」からbtrfsで40GB程度取ってマウントポイント / を指定。同様に「未割当」を選んで「作成」からxfsなどでディスク空き容量の大部分を指定してマウントポイント /homeを指定。メモリが10GB以下なら8〜12GB、それ以上ならメモリと同量程度のスワップ(Linux Swap)を取る。
最低これくらい作成しておく。もっと分けるのは自由。各パーティションのフラグは必要がなければ触らなくて良い筈。
インストーラーの出来がちょっと悪いのでパーティション指定が不適切だとだいぶ待たされてインストールが進行してからインストールエラーになるので注意。その場合はインストールを最初からやりなおすことに。

インストール後の罠対処

とにかく大切なのは、下の手順を実行するまでアプリケーションなどのパッケージの追加をしてはいけないことと、インストール直後にデスクトップ上に存在するLanguage Installerを実行してはいけないこと。特にLanguage Installerはデスクトップ上にあるので実行したい衝動にかられるが対処するまで絶対動かしたらダメ。インストール直後の実行ならエラー大量に出るだけなので大きな影響は無いが、リポジトリだけ修正して実行したらデスクトップ破壊で最悪に。

Gecko Linuxの罠 1
左下の「アプリケーションメニュー」(WIndowsのスタートボタン相当)から「システム」を辿り「ソフトウエアのインストールと削除」を実行。おそらくリポジドリが使えないことによるエラーポップアップが表示される筈なのでリトライでも中止でもない中間の選択肢のボタンを押す。
なお、上の画像ではすでに日本語表示になっているが、インストール直後は英語表示。

Gecko Linuxの罠 2
最上段のメニューの「設定」から「リポジトリ」を選ぶ。

Gecko Linuxの罠 3
リポジトリのリストでURLがhttps://ではなくhttp://になっている行を選択して左下の方の「編集」を押す。それをhttp://になっている全ての行で繰り返す。ただしSkypeの行はどうでも良い。すべて完了したら右下の[OK]を押す。

Gecko Linuxの罠 4
1つ前の画面で「編集」を押すと表示される窓。下側のテキストボックスのURLを編集(http://をhttps://に変更)して[OK]を押す。(これを1つ前のリストの該当行の分だけ繰り返す)

以上で「リポジトリが読み取れない」エラーは発生しなくなる。

ただし、これだけだとパッケージをインストールした際に中途半端に既存のデスクトップ環境周りパッケージが更新されることになってデスクトップ環境が破壊されて何も操作できないという最悪の結果になる。そこで、中途半端ではなく全体的にTumbleweed相当に更新してしまうことにする。packmanリポジトリで入っているマルチメディア系のパッケージに影響するかもだけど、それは後に別途更新すれば良い。

ターミナル(アプリケーションメニュー→システム→Konsole)を開く。

$ sudo zipper refresh && zipper update
または
$ sudo zipper update

GnuPG証明書関係の質問にはyes、パッケージのコンフリクト(が発生)したら「インストールする(置換する)」系の選択肢を選ぶ。
更新されるパッケージの数はおそらく大量の筈で、クリーンインストール直後の実行で1400程度(2018年6月2日現在)もあるのでかなり時間はかかる。
システムを再起動してデスクトップ環境が表示されることを確認する。問題が発生するとしたらログイン直後あたりの筈。
問題なければ以後は言語インストールやパッケージのインストールを行っても大丈夫。

Gecko Linuxの罠 5
言語の更新
Gecko Linuxをインストールすると最初からデスクトップ画面上にあるLanguage Installerアイコンをダブルクリックで実行、またはアプリケーションメニューから「システム」を辿りLanguage Installerを実行。
xtermの窓が開いて勝手に進行する。リポジトリが正常であれば特に停まることなく最後まで自動進行する筈。最後まで進むと上の画像のようにYast2の窓が自動的に開く。
上部のタグで[View]をクリックする。
[Language]を選択する。

Gecko Linuxの罠 6
左列でja Japaneseの行を探し、チェックする。
右列で利用したいパッケージにチェックする。
以下、最低でもチェックしたいもの。

  • fcitx-mozc (Mozcと日本語入力メソッドFcitx)
  • kde-l10n-ja
  • libreoffice-l10n-ja (Libre Officeを使うなら)
  • desktop-translations

Gecko Linuxの罠 7
また、上部の[search]タブでパッケージ検索状態にする。
インストールしたいパッケージ名などで検索してインストールする。
以下、最低でもチェックしたいもの。

  • plasma5-addon-lang
  • plasma5-desktop-lang
  • plasma5-integration-plugin-lang
  • plasma5-workspace-lang
  • fcitx-qt5
  • fcitx-gtk3
  • kf5-kcm-fcitx
  • kf5-kcm-fcitx-icons
  • mozc-gui-tools (fcitx-mozcをチェックしたのにチェックされてなければ)

必要なパッケージにチェックしたら右下の[Accept]を押す。

日本語入力の設定は以前とほぼ同じ。Fcitxで必要なパッケージが一部変わっている程度。以前あったfcitx-config-kde4, fcitx-config-kde4-iconsが無くなって代わりにkf5-kcm-fcitx, kf5-kcm-fcitx-iconsが必要になったくらい。
Fcitxの自動起動設定と~/.profile に1行追加するのも以前と同じ。
システムを再起動するかログアウトして再ログイン。

マルチメディア系パッケージの罠

Gecko LinuxはPackmanリポジトリが標準で採用されていてまともに動画再生できるVLCが最初から使えるのでベースになっているopenSUSE本家より良いよというのがウリだったが、上のようにパッケージ更新を行うと動画再生が満足にできなくなる(筈)。

Gecko Linuxの罠 8
「ソフトウエアのインストールと削除」でvlcやffmpegを検索し右列のインストール済みリストを見ると古いバージョンが入り乱れた状態であることがわかるので必要に応じて削除、またはvlcやffmpeg周りをすべて削除して再度必要なパッケージだけインストールでも可。依存関係にあるパッケージの何が削除されたか、インストールされたかを必ずメモして消し忘れ入れ忘れがないようにする。

おそらくこれだけではまだ動画が再生されない筈。
何故か重要な3つ(4つ)のパッケージが漏れてるのでインストールする。

  • libvdpau_va_gl1 (VDPAU driver with OpenGL/VAAPI backend)
  • Mesa-dri (DRI plug-ins for 3D acceleration)
  • gstreamer-plugins-vaapi (Gstreamer VA-API plugins)
  • intel-vaapi-driver (Intel Driver for Video Acceleration (VA) API for Linux)

最後のIntel Driverは誰にとっても必須なのかは不明。
Mesa-driのインストールではMesa18の入れ替えを確認されるので入れ替える(ベンダー替え)。今回は入れ替えてもデスクトップ環境は破壊されない筈。

これでVLCによる動画再生が出来るようななった筈。
簡単な確認方法としてはターミナルで cvlc 手持ちの動画ファイル名 を実行してどのようなエラーが出るかまたは出ないかを見る。エラーが出るならそのエラーメッセージを見れば何が足りないか判るのでそのパッケージをインストールする。

パッケージのインストール・削除は上のように「ソフトウエアのインストールと削除」で行っても良いが、ターミナルで操作するなら以下。openSUSEと同じ。(パッケージのインストール・削除時に使用するもののみ)

  • zypper se キーワード (パッケージの検索) se = searchの省略形
  • zypper in パッケージ名 (パッケージのインストール) in = installの省略形
  • zypper rm パッケージ名 (パッケージのアンインストール) rm = removeの省略形
  • zypper ve (パッケージの依存関係(全体)の正常確認) ve = verifyの省略形

最後に「アプリケーションメニュー」→「設定」→「KDEシステム設定」で、「ワークスペーステーマ」を選択して「デスクトップテーマ」からどれかを選択する。これをしないとデスクトップテーマ無選択状態によりパネル表示が壊れるなど不具合が発生する可能性あり。

関連記事: