アカウント名:
パスワード:
https://softantenna.com/blog/xz-backdoor/ [softantenna.com]
こりゃ一気にzstに移行する流れになんのかな
自分は、XZ Utilsよりも、libsystemd依存への見直しが進むといいなあと思う。
いま分かっている話では、sshdがlibsystemdを読み込み、それがliblzmaに依存しているので、sshdのプロセスにliblzmaが読み込まれ、それでバックドアを作れたという話ではないか。本来OpenSSH sshdにlibsystemd依存なんかないのに、主要ディストリビューションみんながlibsystemdパッチを当てているという。
Systemdは嫌いではないけど、様々なソフトウェアでlibsystemdをリンクする状況は好ましくないと思っている。せめてlibsystemdを細分化して、libsystemd-notification-client.soとかに分けていこうぜ、と思う。
畏れ乍ら申上げます結局は Smalltalk ( Squeak ? ) 的にシステムレベルライブラリなりを用意してそれを監視したければ監視するというスタイルに落着くものと
# 余談乍ら xz 但しデコーダに限りましては# 68000 ベースの AtariST 版が当初より発表されており# 嘗て嬉々として dis った ( 逆汗した ) 物ですが# どうやら自己解凍ファイルとなっている様であり解凍ルーチン抽出もタルくなって# そのまま放置となってしまったのは残念です## さてここからが本題なのですが X68k 用語で云う SPS.X 的なノウハウは確立されておりますので## 千載一遇のスラド祭りネタ且つエイプリルフール ( UTC ) ネタとしては## NetBSD/mews68k 移植者の某氏がほぼ同級生の電気部員同士だったので## どうですかねカルーく Ruby ポート ry### 某 X68k エミュ 関係者やら某エミュ首謀者やら某 Amiga ファンやらとの### 橋渡しに尽力させて頂きますのでどうかご一考 ry#### そんな事を申上げますと秘密を守れない男であると認識されそうですが#### 千載一遇のスラド祭り且つエイプリルフール ( UTC ) ネタという事で何卒ご勘弁賜りたく
自己レス。XZの件の少し前にliblzma含む一部ライブラリをdlopenで読み込むように変えたそうだ。https://github.com/systemd/systemd/pull/31550 [github.com]悪い意味でSystemdらしさを感じる。
> 自分は、XZ Utilsよりも、libsystemd依存への見直しが進むといいなあと思う。
細分化したら、悪意のあるコードの混入が回避できる、ってのは論理が飛躍してます。たとえば> せめてlibsystemdを細分化して、libsystemd-notification-client.soとかに分けていこうぜ、それで libsystemd-notification-client.so にバックドアが仕込まれない保証がどこにあるんでしょうか?
systemdを見直そうっていう主張は、事件の犯人はアニメ好きだった!つまり原因はアニメだ!アニメの表現を規制しようと騒ぐようなものです。話が飛躍してます。
> ともあれsystemdは滅ぼさねばならない (inittab過激派)
systemdが広まりだしたのは2012年ごろから。たとえばsystemctl --userみたいな便利機能が山盛り、しかも高性能ということで2024年の今ではwindowsのWSLにさえ採用されています。
にもかかわらず未だにinittabを主張しているってことは、systemdという技術革新が理解できず、脱落してしまった人なんでしょうね。
inittabが主力の分野と、systemdが主力の分野があるのは当たり前です。用途に応じて使い分ければいいだけの話です。
3000円程度で市販されているARM7でメモリ64MBのクラスの製品でもsystemdは普通に動きます。ARM9でメモリが16MBとか4MBの製品があるならsystemdは動かないでしょうね。そのときはinittabでしょうね。kernelもカスタマイズしないと駄目でしょね。
で、それがsystemdを滅ぼす理由になるんですか?
> なるでしょ組み込みでは。
理由になってないです。inittabでもsystemdでも使えるものは全部使えばいいじゃないですか。inittabもsystemdも滅ぶ必要がありません。選択肢は多いほうが良いのです。
ところで、どんどん墓穴を掘っているって自覚はあるんですかね?やり取りを振り返るとinittab過激派(墓穴1)組み込みを持ち出してきて(墓穴2)組み込みではsystemdが動かないからsystemdを滅ぼす(墓穴3)と言い出しています。systemdが動作しない世界で、systemdを滅ぼそうと主張するって、ドン・キホーテの主人公みたいな笑い話になってます。
なおドン・キホーテの話は笑い話とみせかけて実は啓蒙的な内容になってます。systemdのような新しい技術についていけなくなったエンジニアの末路はどうなるか?そのとき周囲の人間はどう接するべきか?とそのまま置き換えて読むことができる物語です。笑えるようで、実は笑えない話。エンジニアなら一度は読んでおいたほうがいいと思います。
私は過激派じゃ無いけど、UNIX元来のKISSとという思想とは逆の方向に突っ走ってるsystemdの方向性は、ちょっと何だか近寄りたくないなあ、という感覚があります。
起動に関するものだけならともかく、直接は関わらなくてもいいのにまで、その方が便利になるからと周りをどんどん巻き込んで行く様は、「systemdにあらずんばUN*Xにあらず」って感じで
過激派の気持ちもチョットわかる
liblzmaにバックドアを仕込まれても、sshdに影響ななくなるぜ、というはなししかしてないような。
あと、飛躍したこというと、sshdにバックドア仕込まれない保証はどこにあるんでしょうか?
> systemdを見直そうっていう主張は、事件の犯人はアニメ好きだった!つまり原因はアニメだ!アニメの表現を規制しようと騒ぐようなものです。
これも話が飛躍していないかな?systemd を細分化しようという主張は,きつねうどんを油揚げ抜きで注文するようなものだ!なら同意する。
ディストリビューションの systemd への依存の高さが狙われているのだから,そこを見直そうというのは真っ当な意見ではないか。ただ,systemd を細分化するくらいなら openrc でええやん,とも思うが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
xzにバックドア仕込まれる (スコア:1)
https://softantenna.com/blog/xz-backdoor/ [softantenna.com]
Re: (スコア:2)
こりゃ一気にzstに移行する流れになんのかな
Re:xzにバックドア仕込まれる (スコア:0)
自分は、XZ Utilsよりも、libsystemd依存への見直しが進むといいなあと思う。
いま分かっている話では、sshdがlibsystemdを読み込み、それがliblzmaに依存しているので、sshdのプロセスにliblzmaが読み込まれ、それでバックドアを作れたという話ではないか。本来OpenSSH sshdにlibsystemd依存なんかないのに、主要ディストリビューションみんながlibsystemdパッチを当てているという。
Systemdは嫌いではないけど、様々なソフトウェアでlibsystemdをリンクする状況は好ましくないと思っている。せめてlibsystemdを細分化して、libsystemd-notification-client.soとかに分けていこうぜ、と思う。
Re:xzにバックドア仕込まれる (スコア:2)
畏れ乍ら申上げます
結局は Smalltalk ( Squeak ? ) 的にシステムレベルライブラリなりを用意して
それを監視したければ監視するというスタイルに落着くものと
# 余談乍ら xz 但しデコーダに限りましては
# 68000 ベースの AtariST 版が当初より発表されており
# 嘗て嬉々として dis った ( 逆汗した ) 物ですが
# どうやら自己解凍ファイルとなっている様であり解凍ルーチン抽出もタルくなって
# そのまま放置となってしまったのは残念です
## さてここからが本題なのですが X68k 用語で云う SPS.X 的なノウハウは確立されておりますので
## 千載一遇のスラド祭りネタ且つエイプリルフール ( UTC ) ネタとしては
## NetBSD/mews68k 移植者の某氏がほぼ同級生の電気部員同士だったので
## どうですかねカルーく Ruby ポート ry
### 某 X68k エミュ 関係者やら某エミュ首謀者やら某 Amiga ファンやらとの
### 橋渡しに尽力させて頂きますのでどうかご一考 ry
#### そんな事を申上げますと秘密を守れない男であると認識されそうですが
#### 千載一遇のスラド祭り且つエイプリルフール ( UTC ) ネタという事で何卒ご勘弁賜りたく
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )
Re: (スコア:0)
自己レス。XZの件の少し前にliblzma含む一部ライブラリをdlopenで読み込むように変えたそうだ。
https://github.com/systemd/systemd/pull/31550 [github.com]
悪い意味でSystemdらしさを感じる。
Re: (スコア:0)
> 自分は、XZ Utilsよりも、libsystemd依存への見直しが進むといいなあと思う。
細分化したら、悪意のあるコードの混入が回避できる、ってのは論理が飛躍してます。
たとえば
> せめてlibsystemdを細分化して、libsystemd-notification-client.soとかに分けていこうぜ、
それで libsystemd-notification-client.so にバックドアが仕込まれない保証がどこにあるんでしょうか?
systemdを見直そうっていう主張は、事件の犯人はアニメ好きだった!つまり原因はアニメだ!アニメの表現を規制しようと騒ぐようなものです。話が飛躍してます。
Re:xzにバックドア仕込まれる (スコア:1)
Re: (スコア:0)
> ともあれsystemdは滅ぼさねばならない (inittab過激派)
systemdが広まりだしたのは2012年ごろから。たとえばsystemctl --userみたいな便利機能が山盛り、しかも高性能ということで
2024年の今ではwindowsのWSLにさえ採用されています。
にもかかわらず未だにinittabを主張しているってことは、
systemdという技術革新が理解できず、脱落してしまった人なんでしょうね。
Re:xzにバックドア仕込まれる (スコア:1)
ARM9とか使うような組み込みではメモリが足らんのですよ。いまだ busybox の init が主力。
Re: (スコア:0)
inittabが主力の分野と、systemdが主力の分野があるのは当たり前です。用途に応じて使い分ければいいだけの話です。
3000円程度で市販されているARM7でメモリ64MBのクラスの製品でもsystemdは普通に動きます。
ARM9でメモリが16MBとか4MBの製品があるならsystemdは動かないでしょうね。
そのときはinittabでしょうね。kernelもカスタマイズしないと駄目でしょね。
で、それがsystemdを滅ぼす理由になるんですか?
Re:xzにバックドア仕込まれる (スコア:1)
Re: (スコア:0)
> なるでしょ組み込みでは。
理由になってないです。
inittabでもsystemdでも使えるものは全部使えばいいじゃないですか。inittabもsystemdも滅ぶ必要がありません。
選択肢は多いほうが良いのです。
ところで、どんどん墓穴を掘っているって自覚はあるんですかね?やり取りを振り返ると
inittab過激派(墓穴1)組み込みを持ち出してきて(墓穴2)
組み込みではsystemdが動かないからsystemdを滅ぼす(墓穴3)と言い出しています。
systemdが動作しない世界で、systemdを滅ぼそうと主張するって、ドン・キホーテの主人公みたいな笑い話になってます。
なおドン・キホーテの話は笑い話とみせかけて実は啓蒙的な内容になってます。
systemdのような新しい技術についていけなくなったエンジニアの末路はどうなるか?
そのとき周囲の人間はどう接するべきか?とそのまま置き換えて読むことができる物語です。
笑えるようで、実は笑えない話。エンジニアなら一度は読んでおいたほうがいいと思います。
Re:xzにバックドア仕込まれる (スコア:1)
私は過激派じゃ無いけど、
UNIX元来のKISSとという思想とは
逆の方向に突っ走ってるsystemdの方向性は、
ちょっと何だか近寄りたくないなあ、という感覚があります。
起動に関するものだけならともかく、
直接は関わらなくてもいいのにまで、
その方が便利になるからと周りをどんどん巻き込んで行く様は、
「systemdにあらずんばUN*Xにあらず」って感じで
過激派の気持ちもチョットわかる
Re: (スコア:0)
>使えるものは全部使えばいいじゃないですか。
使えない奴は殺すしかないよな
Re: (スコア:0)
liblzmaにバックドアを仕込まれても、sshdに影響ななくなるぜ、というはなししかしてないような。
あと、飛躍したこというと、sshdにバックドア仕込まれない保証はどこにあるんでしょうか?
Re: (スコア:0)
> systemdを見直そうっていう主張は、事件の犯人はアニメ好きだった!つまり原因はアニメだ!アニメの表現を規制しようと騒ぐようなものです。
これも話が飛躍していないかな?
systemd を細分化しようという主張は,きつねうどんを油揚げ抜きで注文するようなものだ!
なら同意する。
ディストリビューションの systemd への依存の高さが狙われているのだから,そこを見直そうというのは真っ当な意見ではないか。
ただ,systemd を細分化するくらいなら openrc でええやん,とも思うが。