OpenOffice.org日本語版のセキュリティ対策の不十分な状況と参加の呼びかけ

(4/23 12:46微調整)
私はOpenOffice.org日本語プロジェクトリード、かつ、OpenOffice.org Quality Assurance project leadで、さらにsecurity teamのメンバーである(なぜsecurity teamか? これはFreeBSD portingという利害である。何でもやっておくものだ;ただ、立場上情報を公にはできない。確認したくばmahoを指名して、セキュリティ報告をせよ)。

現状、OpenOffice.org日本語版を官公庁など公共機関で利用するには、セキュリティ対策が不十分である。そして誰でも参加できて、参加し、結果報告するだけで、対策できる。またプロセスの改善への参加も大歓迎である。なおアシストの「OpenOffice.org支援サービス」では、セキュリティポリシーは私には教えていただけ無かった。公開してないようでもある。情報を待っている。少なくともリリース品質保証には一度も参加していただいていない。つまりセキュリティ脆弱性については深く考えてないと考えられる。皆さんの参加を求めている。

昨年、高知県は、OpenOffice.orgを不採用とした。セキュリティ対策の不備が理由のひとつである(庁内の PC 約 3,000 台に、Microsoft Office 2007 と Windows Vista を採用)これは妥当な判断である。私も国民としてOpenOffice.orgの採用を全く賛成できない。最悪のシナリオでは、防衛省が機密文書をOpenOffice.orgで書いたとして、脆弱性から機密文書がネットに流れてしまったら、外交上の問題に発展する可能性というのも考えられるだろう。その上、「不採用」こういう判断を多くの自治体が積み重ねると、日本でのOpenOffice.org普及の大きな足かせになってしまう。そうなってしまわないため、ぜひ皆さんにこの点を改善していただきたいと思って、このブログエントリを書いた。
(会津若松市役所は大丈夫である。補遺を参照)

構成は

OpenOffice.org日本語版のセキュリティについて。日本語プロジェクトの機能について。リリース品質保証の状況。まのままでは公の機関で使うのが危険なこと。公的機関などで使うためにどういう参加が必要か。補遺。この順に説明する。

OpenOffice.org日本語版のセキュリティについて。
OpenOffice.orgのセキュリティー脆弱性の修正であるが、現在、リリースを行うことで修正しており、修正パッチなどのリリースは行っていない(以前あったことはあるが)。だから日本語版のリリースをすることがとても重要である。

日本語プロジェクトの機能について。

OpenOffice.org日本語プロジェクトの機能で重要なものに「どこからか」出てくる日本語版のリリース候補の品質保証をし、そして、リリース許可、アナウンスを行うというものがある。何も日本版に限ったわけではなく、3.2.0リリース候補5が公式化されるプロセスを見ると、英語版、ドイツ語版、フランス語版、PowerPCLinux版なども品質保証をへて、リリースされていることがわかる。プロセスとしても定義されている。
> Each Localization team or Native-Language project should,
> regardless of its resources, time and manpower,
> run some QA (Quality Assurance) tests on its localized builds.

誰が行うか? jaでは誰でも参加できる。みなボランティアである。テスターも優秀になってきるが、プロフェッショナルと思える人は少ない。テストもかなりぬるいことをやっている。


リリース品質保証の状況

グッデイ榎さんのアナウンスを見よう(これは私も二年ほどやった)。OpenOffice.orgはリリースを細かく行うことで、アップデートパッチの提供はしていない。例えば、3.2.0がリリースされたら、セキュリティーチームから、3.2.0でセキュリティ脆弱性についての情報を公開する(もちろん私は事前に知っているが口外できない)。先にも述べたが、また、リリース品質保証(この言葉も私が定義した)わたしからグッデイ榎さんになり、(見習い修了)相当安定したが、やはりリソースは足りてないといわざるをえない。

いまのままで、官公庁で、企業で、使うのは危険だということ。

3点ある。1点目セキュリティ脆弱性を修正したバージョン(先にも述べたがほぼ毎リリース、現在のところパッチは提供されず、リリースを細かくしている。)を日本語プロジェクトが毎回、タイムリーにリリースできるとは限らないからである。2点目。セキュリティ警告などの提供は、日本語プロジェクトが公式に行うべきであるが、それがタイムリーに行えてないこと。3点目リリース品質保証にセキュリティ脆弱性に関する評価をしていないこと。

確かに榎さんにリリース品質保証担当者になっていただいた後、他のボランティアはさらに頑張っている。何と英語版と同時のリリースもコンスタントになった。私の頃はかなり遅れていたのだ。榎さんはコミュニティに誠意を尽くしているが、非常に重い重い負担を榎さんにかけている。そう、あたりまえのように榎さんにはどんどん仕事が増えている。彼は彼で業務もある。いつ倒れても、日本語プロジェクトとしては補充は効かない。プロジェクトリードである私はQAをコーディネートせねばならない。私ももうこれも二年近くやった。他にもOOoに限っても仕事が山の用にある(他のブログエントリ参照)もう動けないのだ。協力を募る。そもそも、リソースがものすごく細いのだ。

公的機関などで使うためにどういう参加が必要か。

そんなに肩肘はる必要は全くない。

• 一点。まずリリース品質保証に参加し、状況を理解することである。これは誰でもできる。 例:榎さんのアナウンス。
• リリース品質保証のプロセスの改善への協力。参加すれば足りないことだらけだとすぐ分かる。
• リリース品質保証のプロセスにセキュリティ脆弱性への評価をいれる(難しいだろけど)
• セキュリティアラート翻訳への協力。なんと! 未だに日本語プロジェクトでは、榎さんを中心に、ポリシー策定を行っている最中であるし、 セキュリティー速報の日本語訳を行うのに2-4週間もかかっている! ぜひ参加していただきたい。

タイムリーに参加すれば、一体何が起こっているかわかる。さらに、なれればそんなに時間はとらないだろう。

皆さんの参加をお待ちしている。

以上

補遺
会津若松市役所情報政策課からは、目黒純さんが参加してくださいっていて密に連絡をとっている。従って、会津若松市はもし、緊急の場合でも目黒さんを通じてセキュリティ対策が可能である。しかしこれは良い状況ではない。

OpenOffice.org FreeBSD portingの思い出 Sander Vesik

(2010/4/24 17:26微調整)
FreeBSDへのportingは私が初めたわけではなく、Martin Blappもやっていた。彼とはOpenOffice.org conference 2003でハンブルグで会った。まぁいきなり話がそれたが、Sander Vesikはリリースエンジニアで、エストニアで働いてた(と記憶している)彼は、実際に手を動かす貢献者には非常に暖かい目を持っていて、「私は協力したい」とだけいって成果だけをむしり取る人間には厳しかった。そして私にもやさしかった。

FreeBSD porting 1.0, 1.1 は私も参加したがMartin Blapp(mbr)とAlexander Kabaev(kan)がすでに終えていた。特にld.soの振る舞いが奇妙で、kanのプロの仕事が無ければできなかった。ここは悔しかったが私には分からなかっただろう。私の役割はパッチのupstreamだと思う。

だが、ここらへんで、mbrのooo on FreeBSDへの興味は尽きてしまったようで、私の出番となる。ビルドを通すようにするだけでも大変であった。もちろんチェックアウトさえ! 記憶ではこのころは、Celeron 333@500MHzを使っていて、ビルドにも時間がかかった(また、時々idlcかなんかがストップしてた; ld.soが悪くて)。その後やっと研究者として給料をもらったため、Pentium 4 2.4GHzのマシンを買ってかなりビルドが速くなったことを覚えている。アキバのUSER'S SIDEで買った。その時店員さんが私を知ってくれいた。FreeBSDでOpenOffice.orgやっていらっしゃる人ですよね、と。うれしかった。

結局javaldxが鍵だったのだ。
javaldxというのは奇っ怪な(失礼)Java判別プログラムで、FreeBSDでは当時Javaはオフィシャルなものがなく、サポートも始まったばかりで、ないないづくしであった。ビルドも当然うまくゆかず、色々試すうちに結局、Javaを無効にし、ビルドを続けるということをしていた(こういう地道なしかし重要な仕事はDebianグループに多い。心から尊敬する)。こうするとビルドは通る、走りもする、しかし、なぜかうまくゆかない。こういう事態が長く続いた。デバッグトレースもLinuxとの比較もほぼ同じ。ただ、Javaが無いだけ。


ここを助けてくれたのが、Sander Vesikだった。彼はなぜか私にパッチをくれて、それは、短いjavaldxに対するパッチであった。それでなんとこれでjavaldxが動き、javaを有効化できたのだ。
そして、なんとOpenOffice.org 2(へ向けてのマイルストーン)が立ち上がったのだ。とてもうれしかったし、それはコミットログにもあらわれている。
おそらく彼は私より先にOpenOffice.orgをFreeBSDで立ち上げたんだろう。悔しさもあるが、絶望をすくってくれたのも彼だった。

とてもありがたかった。

そんな彼だが、色々あってSUNを辞めてしまった。今彼はどこにいるのだろう?

Stephan Bergmann! PPCOOOの重大なバグ修正をありがとう

MacOSX リリースエンジアリング(もう既にportingは終わった)で一番心に残っている出来事は、
Stephan Bergmannによるバグ修正である。北京のOpenOffice.orgカンファレンスに参加した理由は、Stephan Bergmannに会いたかったというのも一つ理由だ。そもそもMacOSX PowerPC版というのは、ハンブルグによってサポートされておらず、他のコミュニティメンバーの自主的な努力によって継続しているわけであるが、やはりリソースも足りないわけで、バグが生き残ることもある。これがそれだ。

どんなバグか。ビルドを提供しているときに、i18npoolとか、instsetoo_nativeなどというモジュールをビルドするとき、予期せずに落ちていた。Tigerだとより落ちにくいこともあったり、gccのバージョンにもよることがあったりなかったり、など、再現性もなかったりあったりで、全くわからなかった。特にinstsetoo_nativeはOpenOfficeorgのパッケージを作成するモジュールで、ビルドには大変時間がかかる。たとえば一本5分として、90コあれば450分。7-8時間かかるわけである。Issueは次のように上げた#i87969#, MacOSX : regcomp fails at instsetoo_native on PPCや、
#i77664#, MacOSX : build fails at i18npool/source/localedata/data conditionallyなどである。この原因は"regcomp"にあるが、これをトラックするのは至難の技であったし、私にはできなかった。
おそらくbridgeが怪しいというのは見込んでいた。だから、Stephan Bergmannさんに聞いてみたかったのだ。北京では色々事情を話してくれた。Solarisのhelpcontent2も時々落ちるとか、こういったよく分からないバグがいくつかある、時間が無い、と、半ば諦めかけていた。忙しそうであったし。もうどうしようもなく、彼のやさしさに頼ってしまった。しかもハンブルグにはPPC Macがない。

そこで、Stephan Bergmannさんは、なんと、ハンブルグから日本のマシンにアクセスしてくれたのだ。他にJoachimさんや、われらがヒーローHDUさんもアクセスしてくれた。マシンはグッデイに送って、そこで電源だけ入れてもらった。何というコラボレーション。

結局、gcc-uno bridgeのバグが発見された。Issue 96647として処理された。DEV300_m33, 34, 35, 36というマイルストーンがMacOSX PowerPC上でビルドできた。そしてとても私も楽になった。

MacPowePC、3.2.0英語版の品質保証について

OpenOffice.org MacPowerPC版 3.2.0が久しぶりにリリースされた。(ただいまどうしようもなくリンク切れ...)私はMac版のOpenOffice.orgについて、リリース候補の提供を行ってきた。元来誰がやってもいいのだが、信頼してもらえるかが重要となる。そして、リリース候補をリリースにしてもらうのは、品質保証QAプロジェクトの役割だ。

ただ、品質保証プロジェクトはマックについて知っているわけではない。従って、誰かMacについて詳しい人にパッケージをテストしてもらって、というふうになる。各言語は強いリリース品質保証のチームがあるが、英語は言語プロジェクトになっておらず、このようなものは比較的弱いのだ。Aquaになってからは、Intel版もリリースされたためか、PPC版の需要は少し減った気がする。が、英語版はボランタリーの担当者がいなくなれば、頓挫してしまうのだ。

そして懸案の英語版のリリースであった。なんと、2.4.0 PPC
2.4.1 Intelが最終版だったのだ。まぁIntelは問題ないのだが、2008年3月から全くPowerPC版のリリースが途絶えた。品質保証をしていたのはJames Mckenzieという人で、熱心にやってくださっていたのだが、3.0.0付近で力尽きてしまったようだ。

それからもPowerPC版の要求は幾つかあり、たとえば、Issue 95549などがある。個人的には北京でOpenOffice.org conferenceがあったとき、HamburgのOliver-Rainer Wittman (writer project co-lead)さんから直接「家ではMacPPCだがいつリリースされるのか」尋ねられたこともある。

さて、今回ヒーローが現れ、3.2.0のリリースにこぎつけた。Marcus Langeのよびかけで、フランスチームが答えたpapayaさんである。TCMテストを行ったのだ。結局Issue 110113として処理された。関係者はJean-Baptiste Faure(フランスチームリード)とMarcus Lange(QAエンジニア@SUN)である。もちろん私のビルドが使われている。releas@へのポストも参照のこと。

OpenOffice.orgのソースコードを毎マイルストーンでチェックアウトしている

私は、2005年9月くらいからOpenOffice.orgのソースコードをマイルストーン毎にチェックアウトしている。

これはどうしてこんなことをやっているか。簡単な、無駄なこと、とおもうかもしれないが、品質保証の一貫である。
OpenOffice.orgは巨大なソフトウェアであるため、常識が通じない。

• CVSではチェックアウトに2時間くらいかかっていたし、tagが行われても時々失敗していた。なぜかチェックアウトできないモジュールもあったし、そもそもtagができてないのもあった(それからsvn, mercurialに管理ツールは移っていった)。
• マイルストーンのタグは打たれていたが、これは本当にハンブルグがやっているビルドと等価なんだろうか。外側から確認したい(時々そうではなかった; このリリースエンジニアリングはハンブルグ以外手出しできない)。時々Issueで私のビルドとハンブルグのビルドの違いからどういうバグか推察するということも行われたことがある。それほど信頼していただいた。
• MacOSX, FreeBSDへの移植の問題。放置しているとたくさん問題が出てくる。とにかく細かく指摘しつづけることが重要。
• 一体何言語サポートされているのか知りたかった。
• なお、md5, sha256はPavel Janik経由である中国の方からリクエストをいただいた。

私が行うチェックアウトは品質が高い。

• というのもMacOSX, FreeBSDでビルドが通ることをチェックしてあるからだ。
• FreeBSDでは私がコミッターであるという特権を使い、md5, sha256を記録している。good-dayのftpサーバががのっとられたとしても、FreeBSDと私の信頼性からソースの正当性はチェックできる。

最後に私はOpenOffice.orgで何言語あるか、知りたかった。私がビルドを提供することで、何言語あるか一目瞭然となる。これを暫く続けた後、当時10程度の言語しかビルドをしてこなかったハンブルグが、多くの言語をビルドする用になってきた。Joostがそのポリシーをあげていた。80%UI, Helpがあればビルド提供するだったと思う。