バグやマイナーな仕様を利用したシナリオへの対応
Issue #54
new
- 対象消去されてもエリア移動せずに終了すると復活する
- F9でゴシップや終了印の状態が戻らない
これらを利用したシナリオが存在する。特に後者は有害なバグなので単なるエンジンのバージョン指定による互換動作はさせるべきではない。バージョン以外での互換動作指定方法を考えるべき。
Comments (33)
-
reporter
-
「バグ」という言葉に対して持っているニュアンスが違うのかもしれませんが、 意図しない誤りという意味であれば、1.20から1.28への変更で入り込むようなものなのでしょうか？
ここに貼るのは躊躇われましたが、Lyna氏も正規の挙動と認識しているように見えます。
-
reporter
このようなバグは入り込み得ます。というのは、実際に私が何度かやった事があるからなのですが。フィアルロード周りの処理を書きなおしたりすると、充分に発生しうるバグです。
とはいえ、バグなのか仕様なのかは結局分からない事です。逆アセンブルしても分かるのは書かれたコードだけで書いた人の意図は得られませんし、仕様にしては不合理すぎると私が思った所で、実際には意図的にそうされたものなのかもしれません。
バグという言葉が気になのであれば、このIssueのタイトルを「バグや仕様上の不備」のように変えるのはどうでしょうか。例えばゴシップがF9で戻らない問題などは、おそらく妥協の産物としての仕様なのではないかと私は思っています(全データを完璧に戻すのはものすごく大変です。実際、ゴシップのみならず、消耗したアイテムなどもF9で戻りません)。
-
うーん、たとえば自動選択の回復除外と双方回復についてはウンディーネやミタジマヘイシチロウ戦での明確な挙動違いがあるので納得はしないものの、 あまり関心がなさそうな部分で検証と実装の大部分をやって下さっていることで申し訳なく思い、 どうしても納得がいかなければ将来的に自分がフォークすれば良いだけだと結論したのですが。
旧エンジンの判定バグなどをフォローする一方で、実害がないCW側の挙動を バグや不備と決めてかかっているのは感覚的すぎるというか、とても奇異に映っているのが正直なところです。
-
reporter
感覚的すぎるというのは正確な指摘です。実際のところ、境界線上にあるものは感覚で判断するしかないのです。どちらにせよ証拠を挙げる事ができないからです。
また、バグか仕様かというのは、実は問題ではありません。それはどちらでもよいのです。ある挙動をバグや不備と呼ぶのに納得行かないのであれば、仕様と呼んでも構いません。私はそこにはこだわりません。ただ、今回の挙動は、簡単に判断して実装するには筋が悪いものだとは思います。
正直に言って「これ」という致命的な実害はまだ思いつかないのですが、システムの音声を上書きするという事は、例えばF9を押すとか、ダイアログを操作してOKを押すとか、設定画面を出すとか、セーブするとかいった、プレイヤー側に属している、絶対にシナリオ側から干渉できないはずの事柄に干渉できるという事です。経験則ですが、こうしたものは、後から思わぬ不具合や、新しい仕様を作る時の障害や、セキュリティ上の問題に繋がり得ます。それらは本当に思いがけない所からやってくるので、私は非常に警戒しています。ですから、安易に実装せず、仕様を練りなおして安全な形にしてから実装するか、本当にそれを必要とするシナリオが存在しないようであれば棚上げにしておくという選択をする事になります。
過去の例でいえば、ユーザに気づかれない内にシナリオフォルダの内容を改変してしまうという、JPDCのファイル保存の仕様上の問題は、しばらく機能自体を棚上げにした後、宿に保存枠を作るなどの対応方法をひねり出してなんとか実装しました。そのように作業する必要があります。
1.20以前のエンジンでの称号判定分岐の例で言えば、対応しないとほぼ動かなくなるシナリオが相当数あるという圧倒的な根拠がありましたので、互換モードを挟んで害のない形にしつつ実装せざるを得ませんでした。
この素材検索の挙動を実際に利用している(そしてその挙動がなければ不具合が出る)シナリオが存在すれば、どこまでやるべきか検討した上で実装する方向にならざるを得ませんが、それが存在しないうちは、私は何か説得力のある根拠が無い限りはこれを仕様として実装する事はないと思います。
あと、実際にそうしたシナリオがあっても、検討や実装の面倒さによっては後回しになるかもしれません。対象消去バグは利用しているシナリオを2件も確認していますが、まだ手を付けていません。これは完全に仕様を検討して実装する人(今のところは、つまり私)の都合です。ごめんなさい。
フォークするのはもちろん自由なのですが、色々と後が大変ですので、おそらくこの問題では(他の大抵の問題でも)次のような手を打ってどうにかする事を試みた方がよいのではないかと思います。
- この「仕様」には将来に渡って実害が無い事を証明する(ただし悪魔の証明に近いので不可能かもしれない)
- 将来の不安と実装上の困難に目を瞑ってでも実装するべき説得力のある根拠を示す
- 問題の少なそうな形に仕様を書き直して提案する
他にも色々手は考えられます。現在のCWPyの状況では、判断を下すのは私になると思いますので、要するに私を説得できればいいはずです。
さらに「やるべき事は決まってるのにお前は実装をサボっている。よし、それなら俺が実装してやろう」みたいな事になれば私はとても嬉しいのですが……。
-
CWPｙの理想形として、仕様が汚くなろうと危険や実害があろうとCWを完全にエミュレートする（ことを目指す）のか、 美意識や効率やセキュリティを追及するのかという話で自分（やCWの再現性への要求が高い人）の希望は前者で 長月さんの意識はわりと後者よりだと認識しています。
自分は当初はこの機能を利用しようと考えていましたし、Lyna氏があのように紹介していると言うことは誰かしら使う人がいるだろうと予想しており、実際に演出に利用しているシナリオを見つけてもいます。 またクリック音を変えるのはシナリオの雰囲気を変えるのに強烈なインパクトがありますから有力な前例がでれば多用されていくでしょう。
ただ自分としてはCWPyの普及を願っており、それが最優先です。保留する分には構いませんし、優先度が低いこともわかっています。 他に優先すべきことは山ほどあり、我々がこの部分で議論するとおそらく何時間も費やされるわりに実りが少ないと予想されますし、それに見合う貢献を自分ができてるとも思えません。とりあえずバグ扱いはエモーショナルな部分を刺激してしまうので仕様への言いかえにこだわりがないということであれば、それだけよろしくお願いします。
-
横から失礼します。「システム効果音の差し替え」について少々気になって調べてみたのですが、 私の調べ方が悪いのか、個人ブログ3件とTwitter上（Lyna氏を含めて2件）くらいしか出ませんでした。
新機能として発表されている事も考え、CW1.20→1.28の変更点を 「groupASK official fansite」、「踊る金狼亭」、「拾穂文庫第一分室」 にて調べてみましたが、いずれも効果音については触れられていないようでした。 私が見落としている可能性もありますが、仕様ならば堂々と記載されているはずです。
CW1.28(11)が公開されたのは2006年2月1日で、 CardWirthPyの開発が開始（初公開）されたのは2008年10月16日です。 この挙動が周知の事実ならば、初期段階で実装されているのではないかと思います。 （ファイル参照周りというだけでなく、シナリオの演出・要素・雰囲気に十分関わりそうなものなので）
以上のことから呼び方はともかくとして、私もこの挙動はバグ寄りだと判断します。 挙動自体は面白いとは思いますが……。
-
reporter
念のために言っておくと、私の目的はCWが今後も生き続けられるようにする事、シナリオ作者たちの仕事が無に帰さないようにする事であって、互換性はそれを実現するための手段に過ぎません。あまり筋の悪い仕様はソフトウェアの寿命を縮めます。時代に合わせた進歩も必要です。
私にとって、互換性向上は非常に優先度の高い目標です。しかし目的ではありません。その辺りに行き違いがありそうな気がします。どうも私の書き方が悪そうです。
実際に演出に利用しているシナリオを見つけてもいます。
これは最強の実装動機ですから、ぜひ紹介するか、それが無理ならどういう風に利用しているか書いていただけると助かります。例えばメッセージ送りの音の差し替えが目的なら、その部分だけ限定的にシナリオ内効果音を鳴らすような仕様で対応できるかもしれません。
1.28は本来の開発者の手から離れた特殊なリリースで、しばらく発見されなかった仕様や、仕様なのかバグなのかよく分からない挙動もいくつか含まれていました。代表的なのはメニューカードがPCの手前に来ることで、隠蔽機能の実装でバグったんじゃないかという疑いの声もあった事を記憶しています。
上にも書きましたが、問題なのはそこではなく、それを利用したシナリオがあるかどうかです。このIssueのタイトルを修正しておきましょう。
-
reporter
- changed title to バグやマイナーな仕様を利用したシナリオへの対応
議論を踏まえてタイトルを変更。「大きなバグ」→「バグやマイナーな仕様」
いい言葉が思いつかなかったのでマイナーな仕様にしましたが、もっといい言葉があるかもしれません。そういう言葉が見つかったらまた変更します。
-
＞Liarさん
CWには1.28のなりたち的事情以外でも公式には解説されていないというような挙動があり、 たとえばキーコードの○×判定は長いこと特に解説はなく、古山シウ氏が活用したことが普及の切っ掛けだったように思います。 当然ですが、GroupASKが解説していないものを全くの第三者が立ち上げている現在の愛護協会や解説サイトが拾い上げることは稀です。 それはバグか否かの判断には無関係かと思います。
＞長月さん
戦闘開始時の効果音が差し変わっているシナリオが存在します。プライベートのようなので名前は伏せます。 が、上述の通り、自分が望むのはPyの普及・拡大ですので他の方が優先度が高く、当面保留で構いません。 たとえば現在普及面でもっともネックになっている大きな課題は初回起動時のリソース読み込みの遅さだと思いますし、魅力的な新機能によってもユーザーを増やすことは可能です。細かな挙動合わせはプラスには違いないですがあまり大きなものではないです。（現在わかっているもので保留されているものは）それをこのように議論しつづけて時間を割いてもらうのは申し訳ないし、非効率にも思えるのです。（オープンソースなのですから、自分がどうしても納得いかないものは自分で実装してみて、マージが断られるならフォークするというのが筋だと思いますし）
WSN仕様はむしろ当面のあいだ慎重にならなくてもいいという考えになったのですが、現在のPyの普及率ではシナリオ作者は特に新しい機能を使いたい場合を除いて、主流であるクラシック形式（wsmDataVer4）で1.50/NEXT/Pyマルチ対応のシナリオを作るのが現実的です。その際に挙動が食い違うというのが問題ということです。
-
reporter
ありがとうございます。例の「でれれーん」という音を差し替えているシナリオが実在するのでしたら、まずはそれに対応しましょう。幸い、この音声は使われているのが一箇所だけなので簡単に対応できますし、問題もなさそうです(これがクリック音だったりすると、検討がものすごく大変です)。
意図して同じファイル名のファイルを置かなければ発生しない挙動なので、互換モードを挟んだりのクッションを置く必要はないと私は考えていますが、この辺りにご意見がある方は仰ってください。
-
reporter
pull request #1264
仮実装しました。問題が指摘された場合はやり方を変更するかもしれません(バトル開始音なら問題ないと思うのですが)。
さしあたり、ご指摘のシナリオで正しく動くかレビューをお願いします(なんか最近Issue番号を書いてもリンクが張られないような……bitbucket.orgのトラブルかな)。
-
reporter
レビューを終えて上の変更をマージしました。
今回は幸い1箇所でしか使われていない効果音だったので比較的安全に対応できましたが、クリック音やページ音などについては以下のような作業が必要です。
- 該当システム素材を使用している箇所を全て洗い出す(アクションカードも含む)
- 1.で作ったリストを、シナリオ側から上書きされても構わない箇所という条件で絞り込む(例えばステータスボタンのクリック音は明らかに上書きされるべきではない。カードのクリック音はかなり微妙。メッセージ送りの音は問題無さそう)
正直恐ろしく面倒そうなので、個人的にはそういうシナリオが出ない事を祈りたいです。
-
丸く収まったようで、よかったです。（第三者である自分が悪者のように割って入る程の事でもなかったような）
変更内容を覗いてみましたが、たった1箇所でもかなりの書き換えが必要なのですね……。
-
reporter
CWPyでは、歴史的経緯でスキン付属効果音とシナリオ内にある効果音で鳴らし方を変えているので、書き換えが多いのはそのためですね。
アクションカードの効果音を差し替えようと思ったら、たぶんもうちょっと作業が必要です。
-
結局ごり押ししてしまったような形になって恐縮です。対応ありがとうございました。 自分が過激かつ猪突猛進なのは自覚しているのでLiarさんのように中立的に言ってくれるのは助かります。
-
reporter
仮にそのまま実装するのが難しそうであっても、「これが必要」という想いがあるものは、どんどん主張していけば、色々な形でフォローは可能だと思います。
今後も積極的な話し合いで行きましょう。
-
reporter
pull request #1265で対象消去キャンセルを内部的に実装。
エリア移動に限らずパーティメンバが再配置されるタイミングでキャンセル不能になるのではないかと推測して試してみたところ、実際にそのようでした。
後はこの機能にアクセスするインタフェースをどうするか考え中です。互換性DBのカード配置モードオプション
zIndexModeに似たやり方がよいはずです。 -
reporter
pull request #1266で対象消去キャンセルバグに対応しました。
元々明白なバグであるため、互換性DBに特別な情報を追加しなければ有効にならないようにしてあります。
-
reporter
pull request #1269でF9のゴシップ・終了印が復元されない問題への互換動作を追加。
-
reporter
作ってみてから思い当たったのですが、ゴシップと終了印がF9で復元されない挙動の再現は、セキュリティ上問題があります。
現状のCWには悪意のあるシナリオというものはほとんど存在しませんが、プラットフォームとしては当然想定しておく必要があります。例えば主要なシナリオのゴシップを消してしまう、DDoSのように大量のゴシップを登録する、交易都市リューンのような重要なシナリオに済印をつけてしまう、というような悪意のある行為は、プレイヤーに気づかれずに行う事が可能です。
そのような処理が行われた後でシナリオ内でセーブしてしまった時、プレイヤーには問題を回避するチャンスが残されています。F9で離脱すれば全てが正常に復元されるはずです。
しかし、ゴシップや終了印が復元されない挙動を再現できるようにする事で、そのチャンスも潰す事ができてしまいます。
mode.iniでその機能を有効にしておけば、F9によってすら失われた情報を取り戻せなくなります。では
mode.iniではこれらの処理を有効にできなくして、互換性DBだけで扱えるようにすればいいかというと、これにも問題があります。互換性DBでキーとして使われているMD5ハッシュ値は、その気になれば衝突するハッシュ値を任意に作れてしまう脆弱なものです。CWのシナリオデータは末尾にいくらでも余計なバイト列をつけられるため、その気になれば、互換性DBに登録されていないシナリオを、登録されたシナリオに偽装することができます。普通であればそのシナリオが正しく動かないだけで済みますが、このようなセキュリティ問題が絡む場合は危険です。そもそも、F9はプレイヤーの専権事項ともいうべき操作であって、それをシナリオ側でコントロールできてしまうのは設計思想上も問題があります。一旦作っておいてなんですが、これらの機能はアクセスできないように殺してしまった方がよさそうです。幸い、この挙動を利用しているシナリオは1件しか確認されておらず、その内容も本筋と関係ないメッセージが1個増える程度の些細なものです。問題に目を瞑ってまで無理に対応する必要はないでしょう。
なお、同じくF9でパーティメンバが戻ってくる問題への対応については、思想はともかく、上述のようなセキュリティ上の問題はないと思われます(削除される情報がなく、挙動もプレイヤーから見て一目瞭然のため)。[追記]上の段落は内容が完全に誤っていたので取り消します。それは再配置前にシナリオを終了するとパーティメンバが戻ってくる問題で、F9は関係ありません。慌てていて勘違いしてしまいました。
-
reporter
pull request #1276で無効化。
-
えーと、流石にそれは過保護すぎると思いますね。 そもそも悪意を持って作ればシナリオ終了直前に特性クーポンを全消しする処理を入れて知らない間にセーブさせれば完全犯罪成立です。そんなものの対策をするのは不毛すぎます。また、冒険者の行動の結果交易都市リューンに済み印がつくシナリオも複数存在します。それはシナリオ作者のユーモアとして受け入れるべきだと思います。
自分はF9に関しても言葉通りシナリオが進行停止したときの「緊急避難」と思っているので元々ゴシップや消費アイテムの戻しまで行なう必要も感じていません。 冒険の結果、不本意にデータを失うのも含めてゲームなわけですから、お手軽リロード機能としてのF9やデバッグモードをゲーム性に組み込むべきではないと思います。
それとこれが一番重要なことかと思いますが、そのバグを意図的に利用したシナリオで進行不可能になるものの存在を確認しています。
-
reporter
これはユーモアやシナリオの演出などの問題ではなく、悪意のあるシナリオの問題です。そもそもCWはユーザのシナリオを追加していくものですから、エンジンのセキュリティの問題は避けられません。いつかCWのシナリオをWebから直接落として持ってくるような時が来るかもしれませんが、そうなれば、この問題は増大します。
たしかにご指摘のように、CWの特性上完全な回避は難しい問題ではありますが、回避できるものは回避できるようにしておくべきです。F9してもデータが完全には戻らないかもしれないという不安をユーザに与えるべきではありません。F9はゲーム性に含まれる機能ではなく、ユーザのシナリオを追加していくというCWの特性上どうしても必要なゲームの外側の機能です。
それとこれが一番重要なことかと思いますが、そのバグを意図的に利用したシナリオで進行不可能になるものの存在を確認しています。
上に書いたようにゴシップ・終了印問題への対応はできるだけするべきではありませんが、そういうシナリオがあるなら仕方ありません。MD5とSHA512を組み合わせるなどの方法で、比較的安全に互換性DBで対応する事ができるかもしれません。可能でしたら詳細を教えてください。
-
しかし現実的に考えて、シナリオからmode.iniの設定を変える手段はハッシュ偽装しかなく、ハッシュ一致させたところでゴシップ汚しのF9キャンセルを防ぐことができるだけで、対効果があまりにもしょぼく、実現性がなさすぎると思います。それなら動画再生なども対応シナリオが少ない割に危険だということにもなるでしょうし…。
CWには元々F9がなく、実装後もデータが完全に戻らないのは長年のCWの仕様（GroupASK版すべて）なのでどうしても必要ということはないと思います。説明しにくいのですが、ローグライクで「キャラクターをロストしそうになった時のいつでもダンジョン脱出ボタン」を付けることが必要と言われているような…。上述の通りシナリオのバグで進行不可能になることが多々あり、その場合のみに使うべきコマンドだと思っていますので、自分からはロスト・ペナルティ回避のためにF9を多用する「プレイスタイル」、ゲーム性への組み込みに見えます。 勿論戻った方がメリットが大きいとは思いますし、たしかNEXTでも修正されたようなので戻らない方をデフォルトにすべきとまでは思いませんが、オプション対応できるPyのメリットを殺すのは勿体なく思います。
シナリオについてはDMした通りです。
-
reporter
想定される攻撃の難度が高く威力が低いというのは仰る通りです。ただ、それを言ってしまうと、この機能を入れて仕様を不完全にしてまで対応する事のメリットもほとんどないという事になってしまうのです。
F9が完全に機能するというのは、CWPyが持つ大きなアドバンテージなので、この程度の事で殺す事はないという個人的な気持ちも、もちろんあります。私自身はほぼ使わない機能ですが、頻用するという人を何人か知っています。間違えてシナリオに入った時などに使うのだそうです。その時に、最初のメッセージが表示される前にゴシップが追加されたりしていても心配はないというのは大きな事のはずです。
このような揉め事を解決するにはデメリットを完全に潰したメリットだけの案を出すのが一番です(可能であれば)。という事で、もう少しうまい手を考えました。
mode.iniからはアクセスできないようにするのは大前提として、互換性DBの定義には工夫の余地があります。例えばある特定の名前のゴシップだけをF9処理の例外とするような設定は可能です。問題になるシナリオの問題になるゴシップだけを相手に処理するようにすれば、仮に攻撃できたとしても、その名前の、せいぜい単発のゴシップをつけたり消したりできるだけになります。ただ、問題のシナリオがすでに手に入らない・確認できない状態なので、現状この機能で相手にする必要のあるシナリオがありません。ですので、本当に必要になるまで現状の(機能を殺した)状態を維持したいと思うのですが、いかがでしょうか。
セキュリティは、CW以前に、現状のソフトウェア業界全体にとってのクリティカルな問題で、その面で後退しそうな変更は原則全て退けるという私の態度はそれを反映しています。今回のように想定されている攻撃がごく些細であっても、できるだけ穴は潰しておきたいというのが正直な気持ちです。それが結局ソフトウェアの寿命を延ばす事に繋がるからです。無理にとはいいませんが、お察しいただけると嬉しいです。
-
元々のCWの仕様であり、僅かながらにでもF9をシナリオの進行に組み込むシナリオが過去に存在し、 その挙動が必要なユーザはiniの互換モードを有効にしてそのシナリオを再生できるというメリットに対して、 iniでのオプション動作も許さないメリットが、 「ゴシップ汚しをしようとする嫌がらせシナリオが、Pyの挙動をピンポイントで狙い、ハッシュ偽装してまでF9回避を潰してくる」 という現実味のないリスクを潰すためというのは釣り合いが取れていないように思います。 自分としては互換DBという直接的な対処は元々好ましくなく、上級者がmode.iniでアクセスできるならそれに越したことはないという考えです。
セキュリティ意識についてはexeを実行させられたり勝手に通信してしまうというレベルなら理解できるのですが、PCや宿情報が書き替えられる程度のことは（悪意があろうと）やはり自分はシナリオの表現力・ユーモアの範疇に思います。それがお考えにどうしても反するのであれば自分は引かせていただきます。
-
reporter
少し誤解がありますので追加の説明をさせてください。
iniでのオプション動作も許さないメリットが、 「ゴシップ汚しをしようとする嫌がらせシナリオが、Pyの挙動をピンポイントで狙い、ハッシュ偽装してまでF9回避を潰してくる」 という現実味のないリスク
これは違います。
mode.iniを使えるようにした場合、ハッシュ偽装をする必要もありませんし、特定のゴシップに限定するような防御策も取れません。シナリオ側がmode.iniを追加するだけで100%コントロールできるようになり、エンジン側で回避する事はできなくなります。これは現実的なリスクです。CWは外部からシナリオを持ってくるという特性上、どうしてもセキュリティリスクがあります。具体的な攻撃の可能性にはJPDCなどによるファイルの書き換えやバグによる任意コード実行などがありますが、現実に最も容易なのは宿データの破壊です。これはCWの仕様上防ぎようのない所があります。プレイヤーにシナリオ終了時にいちいちゴシップを確認させる事はできません。しかし、何か挙動が変だと感じた時にF9で脱出する事は可能で、それによって救えるデータがあるかもしれません。
mode.iniを使えるようにすると、この部分の可能性を潰す事になります。仕様上攻撃は防ぎようがありませんが、だからこそ防げる攻撃は防ぐというのが私の考えです。無用なリスクは避けますし、今回の問題は回避可能なリスクのように思えます(そもそも私自身が考えなしに突っ走って穴を開けようとしたのです)。
開発者の責任として、そのリスクを無視・確実に回避できるという合理的な理由がない限り退く事はできません。できれば納得していただきたいのですが、無理にとは言えません……。
-
あ！ですね。はじめから同梱されている場合を失念しておりました。申し訳ありません。
「脆弱性のある設定が有効になっているときシナリオ開始時に警告する」というようなオプションなどを設けるという手もあると思いますが、 disableGossipRestorationの問題だけで付けるには過剰にも思いますし、 よくよく考えるとどの道この仕様はゴシップだけでは不足で、有限アイテム・付帯能力のロストも再現するべきでした。 （消耗アイテムを使って倉庫シナリオなどのゴシップを増加させF9→消耗アイテム復活ということが無限にできてしまいPy固有の問題になります。 そもそもそうしたデメリットがプレイヤーの安易なF9濫用の予防にもなっていたはずです。） pull request #1276をロールバックすれば済むことではないので、当面現状維持ということでいいと思います。
そもそも私自身が考えなしに突っ走って穴を開けようとしたのです
いえ、CWにはその風穴が空きっぱなしですし、実際それで15年以上問題はなかったはずです。 それをPyはデフォルトでは塞ぐようにしているのでそれで十分であり、オプションや互換モードで互換性を保つことの方が重要であるという認識は変わりません。 しかし、今回特別に強い思い入れは自分にはなく、恐らく今後もCWとの仕様合わせという観点から「オプションなしの仕様変更」には反対意見を述べることになってしまいます。それは不毛です。
積極的に議論に参加する人が増えればまた民主的に判断できて違ってくるかもしれませんが、 今のところ自分が長月さんに激突する恰好です。 「これほど強く反対されるなら今回は合わせよう」と思われるかもしれませんが、思想に合わないことで折れていただくのはこちらとしても本意ではなく、 またこのような僅かな挙動違いなら自分は納得できない部分をフォークするという解決も図れます。
ただ、かつて長月さんは「害がない」「利用しているシナリオが存在する」1.50/NEXTの仕様変更に対しての懸念を表明され、またCWPｙがそのフォローも目的としていると仰っていました。 それによって保守派の方々の賛同や理解を得られたと思っているのですが、 CWとの些細な仕様あわせやインターフェースを完全一致させることにセキュリティ意識や関心度合いなど理由はどうであれあまり積極的ではないことが、少なからずそちらとの摩擦をも引き起こしている節が見受けられるので、そこは留意しておいた方がよさそうです。「CWにもともとある仕様を（互換動作/非表示にするオプションなしに）上書きしたい」という思想は1.50/NEXTの悪戯な仕様変更と本質的には同じであると外からは解釈されえます。CWPｙがメインストリームになれば話は別ですが、いずれにせよ気が早いタイミングです。
-
reporter
15年問題なかったとはいえ、それでいいというわけではないのです。Microsoftのような大企業ですら、Webブラウザにスクリプティングが可能な機能を付け加えたために、しばらくしてから十数年も続くセキュリティ問題に苦しめられるようになり、しまいにはソフトウェアを丸ごと捨てる方針を取らざるを得ませんでした。今は問題ないように見えても、今後の事を考えると僅かでも油断できません。つけを払わされるのは、まずCWPyのユーザであって、それから開発者です(それは私ではないかもしれないし、私かもしれない)。私は将来に禍根を残すことを避けたいと考えています。その考え方の根は互換性問題と対立するものではなく実は同じで、互換性維持に勤しむのも、不維持のつけを払わされるのがユーザだからです(シナリオ作成の努力が無に帰すなどの形で)。
議論を通じて整理できたので、私の考える抵触してはいけない事の優先順位をはっきりさせておきます。
- 法的問題。この仕様に対応するとCWPyがいわゆるウィルス作成罪に引っかかる、というような事は絶対にできません。
- 脆弱性問題。脆弱性を作る仕様は対応できません。問題を変形させて安全な形で対応できる可能性はあります。
- 互換性問題。上記の1.2.に引っかからないかぎり、データの互換性を喪失する問題には対応できません。互換性DBを活かす余地はあるかもしれません。
ただ、かつて長月さんは「害がない」「利用しているシナリオが存在する」1.50/NEXTの仕様変更に対しての懸念を表明され、またCWPｙがそのフォローも目的としていると仰っていました。
これは上述の1.2.に触れないかぎりという事を付け加えておく必要がありますね。私自身も気づいていませんでした。申し訳ないと思っています。
とりあえず今回の件は、実際にF9の問題で対応が必要なシナリオが改めて出てきたら、可能な限り安全な方法を探してそれで対応する、という形にしたいと思います。激突とはいいますが、おかげで私自身考えをまとめられた所があります。こうした議論は有益です。色々ありがとうございます。
-
1.50およびNEXTには変数名に半角「=」が含まれているとセーブ時にその変数が保存されないというバグがあります。 （ラッキー氏が細かい解説をされています）
このバグは実質セーブしたかどうかをシナリオ側で検知できるので、利用しているシナリオがあります。 具体例としてはしろねこさんの「採点式ゴブ洞」、「生者の村」です。 特に後者はこのバグを進行の必須条件にしており、進行不能になるのでPyが対応から外されてしまっています。
じゃあデフォルトの挙動として合わせるべきかというと、逆に不具合が出るシナリオが存在します。 たとえば「Derivation～発端～」ではパズルの状態がリセットされてしまいます。また、今後も知らずに使ってしまうケースもあると思います。 なので、これは"enableVanishMemberCancellation"のような互換INIのオプションにした方が良いと考えます。 それならこのバグをあえて利用したく、なおかつPyにも対応したい人はINIを同梱してくださいと案内すれば良いので。
まず自分の方で試してみたのですが、処理自体は
xmlcreatorの当該箇所でname.find("=") <> -1して=を含む変数を除外するだけで良いように見えます。長月さんの見解を教えて頂けると幸いです。Rebootでは対応しないという場合は、仕様を乱したいわけではないので自分の方では単純に1.50に合わせたいと思います。
上記の脆弱性についてのお考えを改めて読ませて頂いてふと思ったのですが、PythonのXML処理モジュールには脆弱性があるようです。WSN形式はXMLを読み込むので知識のある人は悪意のあるジョークシナリオを作れてしまうのでは、と脳裏をよぎったのですが、これについては対策されていたり、あるいは構造上問題ないのでしょうか？(クソ質問だったらすいません)
-
reporter
=について、私はそうした挙動を仕様として組み込む事には反対です。理由は、セーブや緊急避難といった機能は基本的にいつでも同じように動くべきで、それが場合によっては機能したりしなかったりするとなると、ユーザは、用事ができたからCWを終了して出かけたり、シナリオで本当に詰まったからパーティを脱出させたりといった事を、安心して行えなくなるからです。
それがユーザに通知されずに行われるとなれば特に問題です。ユーザは知らないうちに一部データを失う事になってしまうかもしれません。これはCWPyがいつも避けようとしている致命的な問題です。
セーブや緊急避難を信頼できないものにするのであれば、信頼できる別の手段を用意するべきですが、それならばそもそものCWのバグに対処する代替手段を用意した方がよいと私は考えます。
状態変数リセットの問題を前提にしたシナリオは、デバッガを開いて当該変数を初期化すれば進行させる事ができます。
(そのようなシナリオは作者も将来プレイできなくなる事を前提にしているのでは、とも私は思うのですが、その点は実際に作者でもない私が考慮するべきではありません)
XMLの脆弱性について。これらは基本的にDOS攻撃的なものみたいですね。どうも防ぎようがなさそうに思えます。Pythonの処理系がうまくメモリ例外を飛ばしてくれればいいのですが。
とはいえ、最悪の場合はCWPyが落ちればいいだけですし、CWPyの外にまで被害を与えるほどの問題にはならないと思います。また、CWPyはたとえばセーブ中に落ちたら再開時に修復するという処理が入っています。
セーブせずにプレイしていたら最後のセーブの後のプレイが消えてしまうので、できれば防ぎたい所ではありますが、正直言って非常に難しいです。
上記した通り、そうした問題は致命的と考えているので、自動的に防がれるべきなのですが、現段階ではプレイヤーに自衛してもらう以外の手段がなさそうなのが苦しいところです。
-
reporter
ファイルパスについての問題に気づいたのでissue
#613を立てました。 - Log in to comment
Issue
#316より。CW 1.28以降では、
システム・～.wavといったシステム効果音と競合するファイル名の効果音ファイルをシナリオ内に入れる事で、システム効果音を差し替える事ができるようです。これは挙動からしてバグと思われますが、利用しているシナリオが出現した場合は対応する必要があるかもしれません。