リンク:

コメント (33)

_________________________________________________

エンドユーザーがどれだけ賢くても関係ない。

コードベースやプロジェクトに詳しくないユーザーにビルドスクリプトをレビューさせるのは、ユーザーを失敗に導くための設定に過ぎない。


残念ながら、唯一の確実な解決策はAURが「これがあるから素晴らしいものが持てない」と言うか、少なくとも根本的に動作を変えることだと思う(つまり、レビューや承認を必要としないように)。

_________________________________________________

AURのインストールスクリプトは必ずチェックしろ(シンプルでわかりやすいテキストファイルだから)で、すぐにシステムに何をしているのか、どこからデータを取得しているのかがわかる(Archを使う人は簡単なスクリプトファイルを読めるはず)。

俺たちの脳が、最高のアンチウイルスだ。

セキュリティに関する教育が、Linuxで安全に過ごすための最良の選択肢だ。


今回はPKGBUILDの中じゃなくて、ランチスクリプトの中にあった。すべてを見なきゃダメだ。

ArchではChromeにランチスクリプトがあるのは普通で、これがchrome-flags.confの動作方法だ。これが本物のランチスクリプトだ。 そこにcurlを追加してマルウェアをダウンロードさせている。


そうだね…AURをインストールする前にすべてを確認するべきだ…もし自分のシステムが大事なら(大抵の人はArchをインストールするのはシステムを大事に思っているからで、使うときに何が起こるのかを正確に知りたいから)。

AURは公式パッケージじゃなくてコミュニティのもので、セキュリティはコミュニティ全体の責任の一部だと思う。

‘ランチスクリプト’もインストールプロセスの一部で、PKGBUILDだけじゃない。(俺はAURをインストールするためにグラフィカルツールを使っていて、インストールする前にこれらのファイルにアクセスできる。)

実際のGoogle ChromeのAURをチェックした(インストールするのに4つのファイル…すごく大きなアプリだけど、ほとんどはPKGBUILDだけ)。

PKGBUILD(70行):長いけど、何をしているのかは理解しやすい。

google-chrome.install(10行)

eula(html、内部にJSがあるか確認)

google-chrome-stable.sh、ランチスクリプト(8行)

チェックするのが不可能だとは思わない、安全であることを確認するために。

(メインのChrome AURパッケージはちょっと極端な例だけど、投票スコアや古さ、メンテイナーを見れば…このAURは安全だってわかる)


Archを使う人は簡単なスクリプトファイルを読めるはず

あまりにも多くのArchユーザーが、インターネットのあちこちからコピー&ペーストしている。Arch派生のゲーマー向けディストロではさらに悪化している。彼らのユーザーの多くはCLIの文字列をコピー&ペーストして、FPSを最適化するための奇妙なEnvvarsのリストを集めている。


CachyOSのユーザーができるだけ多くの新しいユーザーに広めるために、何でもスパムしているのは良いことだね。


全く同意する。 Archは悪い意味で「メインストリーム」になりつつある。TikTokやYouTubeで「Archをインストールしてリスニングするのがクール」と見られているから(「俺を見てくれ」的なソーシャルメディアの症候群)。 もはやArchの質の問題じゃなくて、ただのハイプだ。 これは残念ながら、Archにとって起こりうる最悪のことかもしれない。

でもありがたいことに、ハイプはすぐに他の何かに移るだろう…


コードを一日中見ていない人にとって、悪意のあるコードの行はどんな感じに見える?


スクリプトがパッチを適用したり、未知または非常に新しいソースからソースやバイナリをダウンロードしたりするとき…

一般的に、インストールスクリプトが読みやすくないように作られているとき。 通常はかなり読みやすい(俺は一日中スクリプトを読んだり書いたりしているわけじゃない 😁)

でも、投票数が多いAURパッケージや古いパッケージ、よく知られたメンテイナーがいる場合は、リポジトリパッケージと同じくらい安全だと考えてもいい。

技術的なスキルの問題じゃなくて、常識の問題だ。


はは!どこを見ても、初心者にArchを勧めているのが見える!評判や人気のYouTuber、SteamOSがそれに基づいているから、Archは今や完全な初心者に最も推奨されるディストロの一つになっている。


(ただの俺の意見…多くの人には気に入られないかもLOL)

俺にとっては、初心者の定義による。Linux初心者とコンピュータ全般の初心者がいる。

慎重にスイッチの準備をする初心者(VMでテストしたり、読んだり…)と、ISOを取ってきてブートして、何かが自分の思うように動かないとすぐにここに投稿する初心者(自分で調べることもせずに 😅)。

でも、ArchやEndeavour、CachyOS(俺は3つとも試した)を完全な初心者に勧めるファンボーイは、LinuxとArchの「最悪の」敵だと思う。

これらのディストリビューションは、MintやFedoraよりもインストールやメンテナンスが「技術的」だ…

完全な初心者にこれらを始めるように言うのは、彼ができないかもしれないという大きなリスクを取ることになるし、Linuxに嫌気がさしてWindowsやMacに戻ってしまうかもしれない。

Arch(や他のもの)に行くのは、Linuxを知っていて、もっと安心しているときに選ぶべきプロセスだと思う。

*** 警告、放射性部分 ***

SteamOSはArchに基づいている、Manjaroのように(OMG、何を言ってしまったのか 😅)

技術的なバックグラウンドなしでインストール/メンテナンスができるように基づいている。

スイッチを入れると、動く…それだけ。

でも、確かに、歩き方を知らないのに走りたい人もいる…

_________________________________________________

AURの不安定さは何年も前から知られている(俺は少なくとも4年前に指摘したし、俺が最初ではなかった)けど、ほとんど何も対策が取られていない。

一般的に使うためにパッケージを簡単にインストールできるようにするものを作ったとしても、安全に使うためには自分でPKGBUILD、インストールスクリプト、インストールするコードを確認できる必要がある。

AURのユーザーの大多数は、redditやLLMが提案したパッケージのためにコマンドラインでyayparuを打って、ランダムなコードを自分のシステムにYOLOしている。

Archのユーザーベースが増えるにつれて、AURを利用した攻撃も増えるのは避けられなかった。


それはランダムなPPAやOBS、さらにはFlatpakとどう違うの?


その通り。AURはそれらのモデルと変わらないし、俺たちはそれらを推奨しない!

AURが悪化しているのは、不安定なコードを見つけやすくしているからだ。少なくとも怪しいPPAやFlatpakでは、自分でコードを探しに行かなきゃいけないけど、ツールがそれを表面化させている。


いい仕事だ!4年前にマニュアルを読めたんだから、もしかしたらArchユーザーになれるかもね!

ただ、非公式なガイドや明示的に避けるべきプラクティスが、明らかに「YOLO」する人たちのために作られていないディストロに悪影響を与えるのはどうかと思う。

Archは貢献者のために貢献者によって作られたもので、他の人は自分の責任で使えるだけだ。君が一日中議論したミームティーンエイジャーは、全く重要じゃない。


ミームティーンエイジャーは、経験豊富なArchユーザーの数を何倍も上回っている。

Archは貢献者のために貢献者によって作られた

俺の言いたいことは、一般的に使うための不安定なツールを作らない方がいいってことだ。


つまり、誤用される可能性のあるツールは存在すべきじゃない、もしくは少なくとも公開されるべきじゃないってこと?再考した方がいいよ、それは馬鹿げた立場だ。ほとんどのツールはそうだ。

ミームティーンエイジャーの数がどう関係あるのかはわからない。インターネットで健康や医療について話す人のほとんどは無知だから、無視している。それが医療専門家が何か間違っているとか、知識を共有すべきじゃないってことにはならない。


俺の言いたいことは、愚かなことをするのを簡単にするツールを書いているなら、観客を自分自身から守る必要があるってこと。

AURがパッケージをレビューする知識を持ったプログラマーのためだけに作られたとしても、脆弱性を見つけてインストールするのを簡単にするモデルは依然として悪い。

_________________________________________________

AURを使うのをやめろ。Manjaroはデフォルトで無効にしているのが正しい。地球上でAURよりも安全でないソフトウェアリポジトリはない。


地球上でAURよりも安全でないソフトウェアリポジトリはない。

NPM:挑戦受けて立つ


デフォルトで有効にしているのはどこ?

それに、AURはPPAよりも安全ではない。少なくともAURではすべてを読み、パッケージを自分でビルドすることが奨励されている。PPAではパッケージがそのまま渡されて、自分でどうやってビルドされたかを見ることはできるけど、奨励されてはいない。


人々はPPAをあまり使わない。2018年からPPAを使っていない。UbuntuにはSnapやFlatpak、そしてArchとは違って公式ベンダーからの直接サポートがある。Google ChromeをインストールするにはAURを使わなきゃいけない。


ArchにはSnapとFlatpakがある。いくつかのものはネイティブパッケージとしての方が理にかなっているけど、WiFiドライバーをFlatpakとして入手するのは難しい。

AURのChromeは、GoogleがDebian/Ubuntu用に提供しているのとまったく同じ.debをダウンロードしていて、ただ再パッケージ化されているだけだ。


いくつかのFlatpakは、パッケージが悪く作られていたり、Flatpakの設計に問題があったりする。例えば、KeePassXCやPlasma IntegrationをFlatpakブラウザで使うことはできない、少なくとも徹底的な手間をかけない限り。


でもこの場合(google-chrome-stable)、外部スクリプトをダウンロードするために追加の行を実行している。


PPAはまだ人気だ。俺は公式ソースから使っている人しか見たことがない(Chrome PPAのように)。


Chrome PPAはdebパッケージと一緒に自動的にインストールされる。人々は更新されたnvidiaやmesaドライバーのためにPPAを使う。


もちろん。AURのすべてのソフトウェアをFlatpakや公式Archリポジトリにパッケージ化した後に言ってくれ。

_________________________________________________

AURパッケージを調べるのはそんなに難しくない。これらのステップでかなり進む:

  • PKGBUILDを読む。通常は非常に短い。
  • リモートソースを確認する。正当なアップストリームからのものか?もしそれがプロプライエタリなバイナリ/パッケージなら、ベンダーのサイトから来ていて署名されているか?オープンソースなら本物のリポジトリか?
  • パッチ、スクリプトなど、パッケージのgitリポジトリから取得したファイルをチェックする。内容が正常か確認し、疑わしいと思ったら触らない。

AURパッケージが他のAURパッケージに依存している場合(例えばffmpeg-amd-fullなど)、信頼が大きな要因になることがあるが、より可能性の高いケースでは、そのパッケージが本当に必要か再考すべきだ。

アップストリームの安全性は、パッケージングレベルの安全性とは異なる質問だ。アップストリームが誰で、彼らを信頼できるか(PR手続き、リリース手続き、ユーザーベースのサイズ、関与している人数、メンテイナーの履歴など)をよく理解しておくべきだ。実際のソフトウェアは、パッケージングスクリプトよりも監査するのがはるかに大きな努力を要する。

あまりエリート主義になりたくないが、これが難しすぎるならArchは君には向いてないかもしれない。少なくともAURは向いてない。

AURヘルパーはコミュニティにとって害だ。

_________________________________________________

AURだから大丈夫で、SNAPじゃないから。もしこれがSnapストアだったら、Linuxユーザーは大騒ぎしていただろう…


その通り。Snapストアはソフトウェアを審査しているふりをしている。


そこに公開されているものの中には、正しく動作しないものもあるから、非常に徹底したプロセスではないことは確かだ。