2006年8月アーカイブ

高木浩光＠自宅の日記に「サイボウズが再び「闇改修」をしたので電話で抗議したが無駄骨だった」という記事がポストされていた。今回のポイントはJVN#31125599の「サイボウズOffice 6における情報漏えいの脆弱性」です。要するにBasic認証などの手段が講じられていない限り、インターネット側からサイボウズOfficeを展開するサーバにアクセスできる場合アカウントの有無に関わらずユーザ及びグループに関する情報を取得できる問題です。これは、know94spaceの日記の記事「サイボウズ不具合」によるとほかならぬサイボウズ自身のサイボウズOffice 6 ファイルナビというソフトで顕在化するようです。

問題があるのはサイボウズの今回の問題のアップデートにおける対応です。サイボウズはこの脆弱性を含め3つの既知の脆弱性に対応しました。しかし、サイボウズ社のサイトの「重要なお知らせ」で告知されているされている「サイボウズ製品で発見された脆弱性についてのお知らせ」では、JVN#31125599の脆弱性については記述されず他の2つの脆弱性のみが記述されているようです。(2006.09.01現在)

他の2つの脆弱性、すなわちディレクトリトラバーサルの脆弱性とSQLインジェクションの脆弱性は高木浩光＠自宅の日記の記事によればログインしない限り実効的な脅威とはならないとされます。しかし、JVN#31125599の脆弱性はログインしていない者に対しログイン名等不正アクセスに必要な情報の一部を与えてしまいます。結果的に、この脆弱性のセットはJVN#31125599の脆弱性を考慮に入れるかどうかで想定される脅威の水準が大幅に変わることになると考えます。

ところが、サイボウズ社はJVN#31125599の脆弱性をリリースノートの方にのみ記載し「重要なお知らせ」には記さなかったため利用者に脅威の水準を誤まらせる危険を犯したと考えます。これは、件の高木氏の日記の中の対話を見る限りサイボウズ側の対応のポリシーに問題があると考えざるを得ません。このようなポリシーを取るようでは私は、サイボウズ社の製品を使う気にはなれません。

マルチコア化の進展でどうやって並列化されたプログラムを能率的に開発するかというのが一つのトピックになっています。実際問題、どうするのかというのは幾つかのアイディアが提起されてきたジャンルであるかと思います。古くはトランスピュータとOccamでしょう。トランスピュータは並列コンピューティング向けに考案されたプロセサであり、Occamはそのトランスピュータ上で動くコードを作るための言語です。

Occamは言語使用としてスレッド的な機能を持っているのでOccamで書かれたコードは半ば自動的にマルチスレッドになります。例えば、

PAR
	x := x + 1
	y := y * 2

この例のようなコードだとxに1を足すという動作とｙを2倍する動作が並列して実行されます。C言語などの言語仕様に並列化を含まない言語と異なり、並列化を特別視せずにプログラミングすることが可能な仕様となっています。 勿論、80年代当時の言語であるので現在主流のオブジェクト指向の言語群と異なりクラスなどの機能を持ってはいませんが当時としては極めて先進的な思想であったのは確かです。

時代は下って、2002年にMicrosoft ResearchのNick Bentonらによって発表されたPolyphonic C#という言語も独特な並列化プログラミングを見通した仕様を持っています。Polyphonic C#はC#の拡張仕様の一つでプレビュー版が公開されたCωの実験的な実装に仕様が取り込まれています。特徴としては関数の非同期呼び出しとChordという独特のSynchronize patternの記述によって簡便に並列化と同期を記述することが出来ることです。

async postEvent(EventInfo data) {
	// large method body
}

この例のようなコードだとpostEventというメソッドは処理の終了を待たずに呼び出し元に制御を戻します。Polyphonic C#もスレッドを明示的に用いなくてもプログラムをマルチスレッドか出来ると考えていいでしょう。

カメリアさんの「ゼーガペイン #21」など随所で、冥王星がIAUの総会で惑星の列からはずされた件が話題になっています。実際、Wikipediaの関連アーティクルでも更新合戦の様相を呈していますし、各種ニューズサイトでも沢山の報道があります。

• 朝日新聞「冥王星外し、惑星数８に　国際天文学連合が新定義」
• 毎日新聞「太陽系惑星：冥王星を除外　賛成多数で最終案採択　ＩＡＵ」

言うまでもなく、今回の件は「惑星」の定義に起因します。元々、冥王星は他の惑星と比べていささか厄介な点が多いです。離心率など軌道に関してもそうですし、単純に大きさに関しても月より小さいなど惑星と定義するには大きなハードルがあります。これが、今まで惑星と定義されてきたのはアメリカ人が見つけた唯一の惑星であることなど論理よりも情理、あるいは政治的な面が大きいとされています。

しかし、最初の冥王星発見から時間も経過し関連するデータも信頼性の高いものが揃ってきました。そうなると、科学という論理が重要な世界で情理や政治で真理を捻じ曲げるのは困難になってきます。そうなると、方法論としては情理を通す論理を作るか、論理を取って情理をはずすかということになります。今回は後者が使われたわけです。

ただ、今回の件でつくづく感じたのは松本零士も老いたよなということですね。毎日新聞の記事「太陽系惑星：冥王星除外　安易な拡大懸念、社会的意義で議論割れ－－ＩＡＵ」でコメントが載っています。

冥王星こそが太陽系の果てで、そこを離れることが太陽系から外宇宙に旅立つことだと描いてきた。今回の決定は、論理的には正しいのだろうが、多くの人が少年のころから抱いていた夢にも配慮してほしかった。心構えができていないうちに突然決まってしまった感じがする

 このコメントでどうも、おかしいなと思うのは心構えが出来ていないうちにですね。心構えなど待っていては科学というのは機能しません。夢に配慮といいますが、私は宇宙に抱く夢は一つの天体が惑星と定義されるか否かで変化するほど安いものだとは考えません。コミックのガンスリンガーガールで確かクラエスの台詞だと思いましたが、ジンクス一つで壊れるのは偽者の恋だというような台詞がありましたけど、惑星の定義で壊れる夢は偽者の夢ではないかと思います。

この辺に関しては、セレス・カロン・2003UB313を追加する案が有力だった17日の時点の朝日新聞の記事「教科書は？占星術は？　惑星の新定義に反響続々」でのガイナックスの神村靖宏氏の発言の方が健全であると思います。

ＳＦはもともと虚構の世界。地球の学会が定義を変えたからといって、我々が勝手につくった１１番惑星がなくなるわけではない

実際問題、夢というものは学会の基準に左右されるようなものではないはずです。権威がなければ語れない夢というのは非常に悲しく思いますね。実際、SFに限らず現代をベースに虚構を作る以上、現代が揺れ動くのは止めようがないことだと思います。倫理というのならばある程度の普遍性を持ち出すことも可能なのかもしれませんが夢を持ち出されてもね。

IronPython 1.0 RC2がリリースされていたので少々触ってみました。走らせて見たのはこんなコードです。まあ、単純に言うとPythonというかTkinterのチュートリアルのコードに似せて作ったWindows Formsのコードです。イベントのハンドラがないので何も出来ませんけどね。

import clr
clr.AddReferenceByPartialName("System")
clr.AddReferenceByPartialName("System.Windows.Forms")
clr.AddReferenceByPartialName("System.Drawing")

from System import *
from System.Drawing import *
from System.Windows.Forms import *

class MyForm(Form):
	def sayhi(self):
		print "hi there, everyone!"
	def createWidgets(self):
		self.QUIT = Button()
		self.QUIT.Dock = DockStyle.Left
		self.QUIT.Text = "QUIT"

		self.hi_there = Button()
		self.hi_there.Dock = DockStyle.Right
		self.hi_there.Text = "hello"
		
		self.Controls.Add(self.QUIT)
		self.Controls.Add(self.hi_there)
	def __init__(self, master=None):
		self.createWidgets()

myForm = MyForm()
Application.EnableVisualStyles()
Application.Run(myForm)

Microsoft がゲームプラットフォーム XNA の開発環境の無償版をリリースするようです。ゲームを開発し他人に遊んでもらうには Creater's Club (仮称) のアカウントを有償で取得する必要があるとされています。Creater's Club 上にホストされたタイトルは Creater's Club アカウント保有者のみがアクセスできるとされています。従って、プレイするにも Creater's Club のアカウントが必要です。Microsoft のプレスリリースによればCreater's Club は年額 $99 の予定です。

ただし、Xbox 360には既に Xbox Live Arcade というゲームの配信システムが存在しますから、Creater's Club 上のタイトルを有料配信するという手はあるでしょう。恐らく、有望なタイトルの配信は考慮されるだろうと思います。少なくとも、そうすることでソフトへのライセンス料に依存するビジネスモデルを破壊せずにエンドユーザの作ったコンテンツを流せるプラットフォームを構築することは可能でしょう。興味深い発想だと考えます。

XNA Game Studio Express はVisual Studio Team System をベースとした、XNA Studio と同様にVisual Studio Express をベースとしています。ITmedia の記事によればAutodeskのファイル交換フォーマットとGarageGamesのTorqueツールが組み込まれるようです。ITmedia の記事だけではファイル交換フォーマットが不明ですが、Autodeskというところから類推して Autodesk FBX でしょうね。フォーマットとしてなら DXF も考慮できますが情報量の問題を考えると FBX でしょう。

 各種 Web log の XML-RPC API を活用したアプリケーションである Windows Live Writer のベータバージョンが公開された。本アーティクルもWindows Live Writer によって記事の作成を行っている。

Web log への記事の投稿手段は幾つか考えられる。一つの方法は各種 Web log サービスの Web Form を使って行う方法である。この方法のメリットは言うまでもなく管理画面を開ければほとんどのWeb ブラウザによって記事を書けることである。反面、ユーザインターフェイスに課題を残すことも多い。

例えば、標準的な HTML の Form を使ってユーザインターフェイスを構築すると HTML 要素やスタイルを意識しなければ記事の作成は難しくなる。さりとて、DHTML を駆使して WYSWYG的なインターフェイスを構築しようとするとx場合によってはパフォーマンスの問題が出る。例えば、Windows Live Spaces のユーザインターフェイスのパフォーマンス不足を訴える声が、Manack's Space の記事 「Windows Live Spaces」にあるがこれは、Windows Live Spaces の記事の入力フォームが多くのイベントをECMA Script でハンドルしているためであると考える。

 いまひとつの方法はローカルのアプリケーションから Web log の API を利用して記事の投稿を行う方法である。この方法はローカルの専用アプリケーションを用いて、記事の編集を行うためいわゆるユーザ体験 (User Experience) を高めやすいと考える。

高木浩光＠自宅の日記の記事「日本の恥：アップデートプログラムに電子署名しない日本のパソコンメーカーたち」によれば、日本のパソコンベンダーの多くが自社で提供するアップデートの類に電子署名を行っていないようです。言うまでもなく、電子署名を行っていないアップデートはその真正性を担保することが出来ないため偽のアップデートにすりかえられる懸念が常にあります。いわゆる外資系に分類されないベンダーで電子署名を入れているのはソニーのう一社のみで残る、富士通・日立・東芝・NEC・松下電器・シャープ・エプソンダイレクトは全滅です。Lenovo (IBM)、Dell、HPといったいわゆる外資系は電子署名があったようです。高木氏の記事では触れていなかったのでゲートウェイのサイトにあったGXシリーズ用のモデムドライバの入ったアーカイブPCI_SoftV92_7_12_09_00.exeを取得し調べてみたところ電子署名は見当たりませんでした。

高木氏の記事にあるとおり、日本政府は「政府機関の情報セキュリティ対策のための統一基準」で、「電子署名により当該ソフトウェアの配布元を確認すること」としています。従って、現状ではソニー以外の国内ベンダのパソコンは統一基準に抵触し購入した場合、政府機関ではオンラインアップデートが困難になります。これは日本の同氏の言うとおり恥以外の何者でもなく、有害無益です。本来、VPNのような信頼性が担保できるネットワーク以外で無署名のネイティブ実行ファイルを配布すること自体がセキュリティ上のリスクです。勿論、私的にソフトウェアを作る私のようなオンラインソフトウェアの作者などはいかんともしがたい状況もある。しかしながら、企業という電子署名をいくらでもつけられるはずの事業体がその責任を全うしないのは正当化する理由が思いつかないです。

Dead or Alive Extream Beach Volley　の続編に当たる Dead or Alive Extream 2　のアナウンスが流れてきていますね。今目にしているのはファミ通のニューズです。今回はビーチバレー以外にジェットスキーがメインゲームとして用意されるようです。それ以外にもミニゲームがあるようですね。物自体はDead or Alive 4のエンジンの流用のようです。エンジンの製作には手間もかかりますし、現状では性能に問題のないエンジンですからほぼ適当なチョイスでしょう。

IT proの記事『「bleedingsnort.orgにはアクセスしないで」，ドメイン名の期限切れで悪質サイトに』よれば、 bleedingsnort.org のドメイン名がBleeding Snort teamと関係のない第３者に取得された模様。Bleeding Snort teamは侵入検知ソフト「Snort」のシグネチャやセキュリティ情報を提供している。現在、取得されたドメインはBleeding Snort teamと無関係の怪しいプログラムをダウンロードさせようとするサイトとして供されている模様。

「匣の向こう側 - あまりに.NETな」の記事「NDoc2 is officially Dead」によれば　Ndoc 2 の開発が中止された模様です。

I have decided to discontinue work on NDoc 2.0 and no longer participate in any open-source development work.

NDoc は.NET Framework 1.x に対応したドキュメント生成ツールとしてデザインされ私自身も利用してきました。ともあれ、中止されては仕方がないので、Microsoft 自身による Sandcastle にとりあえず移行するつもりでいます。