«前の日(08-22) 最新 次の日(08-24)» 追記

ポケットを空にして。

1985|10|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2100|01|

「人の心に残るというのが大事」と言う話。

何か連絡がある場合はメールでどうぞ(過去の日記へのツッコミは基本的にみていません)
プレゼントは随時受け付けております :-) ここ最近のツッコミ/トラックバックリスト。

  1. Henrich (08-28)
  2. kmuto (08-24)
  3. なるひこ (08-24)


2007-08-23 この日を編集

spam 被害

ここしばらくの嫁の人からのメールが spam 扱いになっていた orz


2008-08-23 この日を編集

fedora サーバ (RHEL も?) 侵入される

うーむ、この話が即座に話題にならないってーのはどうなのかと思いつつ。lwn 経由fedora announce な blog(追記:…あ、一次情報としてはmailing list アーカイブの方がいいですな)。どうやら fedora のサーバが侵入されてしまったらしい。

ここまでは「あぁ、fedora もやられてしまったか、大変だよねぇこういう話って。管理者の方々お疲れさまです」で、「もしかしたら以前の Debian Openssl 問題で発生した悪い ssh 鍵をそのまま使ってたのかなぁ、そうだとしたら申し訳ないなぁ」と思っていたのだが、アナウンス内容とRed Hat Enterprise Linux の errata を見て、そこに記載されている事柄について私は目を疑った。

まず「パッケージのサインに使うサーバが侵入されている」、つまり信用して入れたパッケージなのにサインが侵入者のものになっているのではないか?という話なのだ。key 自体のパスフレーズは解析されてないようだ、と fedora announce にはあったが、もう一点、Red Hat の errata から引用

In connection with the incident, the intruder was able to sign a small number of OpenSSH packages relating only to Red Hat Enterprise Linux 4 (i386 and x86_64 architectures only) and Red Hat Enterprise Linux 5 (x86_64 architecture only). As a precautionary measure, we are releasing an updated version of these packages, and have published a list of the tampered packages and how to detect them at http://www.redhat.com/security/data/openssh-blacklist.html

意訳すると「今回の件で影響を受ける可能性があるのは RHEL 4 (i386,x86_64) と RHEL 5 (x86_64) の OpenSSH パッケージだけで、念のためにアップデートのパッケージを用意して、チェックのためのスクリプト (openssh-blacklist) を用意したよ」なのですが、いや、それって影響めちゃくちゃでかくないですか? RHEL のソースを rebuild してる CentOS とかこういう場合どう対処するんでしょうか。

ちなみに Debian/Ubuntu でも Openssh-blacklist というパッケージがありますが、これは弱いssh鍵だと sshd が接続を拒否するものなので RHEL のとは別物です。

また、

It is important to note that the effects of the intrusion on Fedora and Red Hat are *not* the same. Accordingly, the Fedora package signing key is not connected to, and is different from, the one used to sign Red Hat Enterprise Linux packages. Furthermore, the Fedora package signing key is also not connected to, and is different from, the one used to sign community Extra Packages for Enterprise Linux (EPEL) packages.

「今回の fedora の鍵用サーバと RHEL とは別サーバだからね」と fedora announcement にはありますが、ではなぜに RHEL でも errata がでてチェックスクリプトがあるのでしょう?

なお今回の場合、顧客である Red Hat Network に subscribe している者を優先的に対応したという話もありますが、これはやはり subscription でビジネスを行っている Red Hat としては至極まっとうな対応で、この様なクリティカルな場合には保険になるというアピールに結果的にはなっているのかもしれません。

なお、この様なリスクは、おそらくどのようなディストリビューションであっても同様に存在していると私は思います。何にしてもこの件に付いては一次情報の確認を行った上で、詳細な続報と識者の意見が期待されます。

さらに追記:大垣さんのblogでは、openssh の問題と書いてあったが、私は「まだ問題が明らかになっていない」というスタンス。しかしはてブ数は圧倒的にあっちが多いです(笑)

CentOS は大丈夫、というアナウンスがでてた

lwn.net からうちのは何重にも守られてて限られた人しかアクセスできないし、openssh パッケージのソースも確認したけど大丈夫な様子だという声明が。でも、原因分かって無いからまだ安心できない。

オープンソースのビジネス利用:神話と実態

オープンソースのビジネス利用:神話と実態という記事がまともそうなのでメモ。最初の神話1-10は全くそうだよね、と常々思っていることばかりだったのでまだ内容は未見。

コンシューマには受け入れられない、論

うーん、一般ユーザにリーチしてきているからだと思うけど、コンシューマには受け入れられない論は説得力ないなーとコメントしてみた。それにコメントには書かなかったが、サーバだって、「は?Linux?なんでそんなの使うの?」とか「Windows をサーバに使うなんてありえないだろ」というのを覆してきているし。

歴史を振り返るのは行き先を考えるときに必要。行き先を決めるのは自分だけど(国家などの強制が日本では強くないのがありがたいことだ)。


2011-08-23 この日を編集

これは何のメッセージだ

cups (1.5.0-5) を設定しています ...
Starting Common Unix Printing System: cupsd.
lpinfo: 未知

何、「未知」って…

本日のツッコミ(全3件) [ツッコミを入れる]

_ なるひこ [lpinfo は CUPS の一部なので、http://svn.easysw.com/public/cups/tag..]

_ kmuto [CUPS 1.2くらいまで翻訳してたけど、CUPSのUIのi18n化が残念すぎるせいもあるんだよね。メッセージカタロ..]

_ Henrich [なるほど、ちょっと見てみましたが確かに作業し辛そうなpoですな。]


2014-08-23 この日を編集

DebConf14でしたよ

ポートランドでした。