Tips – ページ 5 – kana.me 要

devel/libltdl22 (port directory error)

2010-12-152016-08-26 清水文行

portupgrade中

        - devel/libltdl22 (port directory error)
        - devel/libtool22 (port directory error)

1 2	- devel/libltdl22 (port directory error) - devel/libtool22 (port directory error)

毎度おなじみ/usr/ports/UPDATING を見ると、バージョン付きでなくなったものがいろいろあるようです。

# portmaster -o devel/autoconf devel/autoconf268
# portmaster -o devel/automake devel/automake111
# portmaster -o devel/libtool devel/libtool22
# portmaster -o devel/libltdl devel/libltdl22

# portmaster -o devel/autoconf devel/autoconf268

# portmaster -o devel/automake devel/automake111

# portmaster -o devel/libtool devel/libtool22

# portmaster -o devel/libltdl devel/libltdl22

か

# portupgrade -o devel/autoconf devel/autoconf268
# portupgrade -o devel/automake devel/automake111
# portupgrade -o devel/libtool devel/libtool22
# portupgrade -o devel/libltdl devel/libltdl22

# portupgrade -o devel/autoconf devel/autoconf268

# portupgrade -o devel/automake devel/automake111

# portupgrade -o devel/libtool devel/libtool22

# portupgrade -o devel/libltdl devel/libltdl22

で置き換えるように指示されていますが、多くの人がビルド専用でしょうから

# pkg_deinstall -R autoconf-\* automake-\* libtool-\*
# portsnap fetch && portsnap update
# portupgrade -o devel/libltdl devel/libltdl22

# pkg_deinstall -R autoconf-\* automake-\* libtool-\*

# portsnap fetch && portsnap update

# portupgrade -o devel/libltdl devel/libltdl22

で十分かも。

PDF -> e-mail添付 -> FAX送信でペーパレス続爆速インストールHylaFAX

2010-11-062016-08-26 清水文行

FAX受信 -> e-mailに引き続き今度は送信側。不適切な設定で勝手に使われるなどして莫大な電話代請求されても責任は取れませんので、細心のご注意を。HylaFAXクライアントを使用すればキューの制御もできて便利ですが、いろいろなOSで使えるような良いものを探すのも面倒です。今回はHylaFAX付属のfaxmailをPostfix経由で使用します。メールを読んでlatin1テキストならばそのまま、MIMEならば引っぺがして変換可能であれば変換してsendfaxに送り込んでくれます。

あて先の電話番号は [email protected] (Postfix master.cfで${user}使用) でも [email protected] (${extension}使用) でも良いですが、今回は簡単のために後者にします。まかり間違っても認証もなしに普通にインターネットから到達できる構成にしてはいけないです。

適切に設定されて動作している内部向け専用Postfixの etc/postrix/master.cf に

fax        unix -       n       n       -       1       pipe
  flags=q user=uucp argv=/usr/local/bin/faxmail -n -T -s a4 -t done -d ${extension}

1 2	fax unix - n n - 1 pipe flags=q user=uucp argv=/usr/local/bin/faxmail -n -T -s a4 -t done -d ${extension}

を追加。ここで指定したfaxという名のサービスに [email protected] で到達させるために、etc/postfix/transports(etc/postfix/main.cfでtransport_maps=regexp: で指定されている場合)に、

/^hoge\+\+?[-.0-9a-yA-Y]{5,13}@fax.test$/       fax:

1	/^hoge\+\+?[-.0-9a-yA-Y]{5,13}@fax.test$/ fax:

を、引っかかるような位置に追加。local_recipient_mapsが/etc/aliases.dbと指定されている場合はreject_unlisted_recipientが使えるように/etc/aliasesに hoge: root とでも追加してnewaliasesしておきます。etc/postfix/main.cfのmydestinationに@のドメイン部分であるfax.testを追加すればPostfixの設定終了でPostfix再起動。

HylaFAXのサーバはデフォルトでIPv6の*:4559をlistenしていて、クライアントはデフォルトでlocalhostのサーバにアクセスします。/etc/hostsで::1がlocalhostではなくてlocalhost-v6である場合には/usr/local/lib/fax/hyla.confに

Host: localhost-v6

1	Host: localhost-v6

を追加。パスワード無しでサーバにアクセスするために/var/spool/hylafax/etc/hosts.hfaxdに

localhost (/etc/hostsの::1の行の先頭)

1	localhost (/etc/hostsの::1の行の先頭)

を追加。この時点で

faxstatコマンドが認証無しで実行できてしまうようになります。続いて/usr/local/lib/fax/faxmail.confに

PageHeaders: Yes
AutoCoverPage: No
Headers: clear

PageHeaders: Yes

AutoCoverPage: No

Headers: clear

などをお好みで追加。/var/spool/hylafax/bin/notifyの内容を見ながら、お好みで/var/spool/hylafax/etc/FaxNotify作成。

TOADDR=FaxMaster@example.jp
NOTIFY_FAXMASTER=errors

1 2	[email protected] NOTIFY_FAXMASTER=errors

hfaxd(hylafax)再起動。ここまでで [email protected] 宛e-mailにPDFやPostScriptを添付しするとFAXとして送信されるようになりました。残念なことにfaxmailはMIMEではないメールの扱いがlatin1のみでtyperulesも効かないので修正が必要です。時間が取れたらパッチ作成。万が一電話番号を間違えたら自力でfaxstatしてfaxrmするのが手間ですが、PDF添付でFAXが送れるだけでも十分実用的。

桂花

2010-11-032021-11-16 清水文行

「桂花」民事再生法適用申請

あう。高校時代から桂花はえぞ菊などととともによく行き、今でもたまに寄るので衝撃でしたが、当面そのまま営業できるそうでよかったです。ありがとうございます、味千ラーメン(香港市場に上場してるのですね)。いやぁ、「九十九電機」民事再生法適用申請以来の衝撃でした。

p5-Compress-Zlib, p5-IO-Compress-Base, p5-IO-Compress-Zlib, p5-IO-Compress-Bzip2 -> p5-Compress

2010-10-152016-08-26 清水文行

Perl5.8のFreeBSDマシンにて

** Port directory not found: archivers/p5-Compress-Zlib
** Port directory not found: archivers/p5-IO-Compress-Base
** Port directory not found: archivers/p5-IO-Compress-Zlib

** Port directory not found: archivers/p5-Compress-Zlib

** Port directory not found: archivers/p5-IO-Compress-Base

** Port directory not found: archivers/p5-IO-Compress-Zlib

/usr/ports/UPDATING を見ると、p5-Compress-Zlibとp5-IO-Compress-* が p5-IO-Compressにまとめて置き換わったそうな。perl5.10以降の人はデフォルトのライブラリなので関係ないと。いつものように

# portsnap fetch && portsnap update
# pkg_info -R p5-Compress-Zlib p5-IO-Compress-\*

1 2	# portsnap fetch && portsnap update # pkg_info -R p5-Compress-Zlib p5-IO-Compress-\*

で依存しているものたちをメモ。

# portupgrade -o p5-IO-Compress p5-Compress-Zlib p5-IO-Compress-\*

1	# portupgrade -o p5-IO-Compress p5-Compress-Zlib p5-IO-Compress-\*

で置き換え完了したら

# portupgrade -fr p5-IO-Compress

1	# portupgrade -fr p5-IO-Compress

か

# portupgrade -f [依存しているものたち...]

1	# portupgrade -f [依存しているものたち...]

あたりで処理。

HTTPS Everywhere – 自分で任意に指定したサイトで自動的にhttpsになるようにする – Force-TLSをやめたときの覚え書き

2010-10-152021-11-16 清水文行

自動的にhttpsにするといえば、HSTSをFirefoxも4にて実装、とかのサーバ側で何かしないといけない仕組みの話題ばかりで、ブラウザ側に能動的に設定するための情報が探しにくくなったようです(Firesheepのおかげでまたそうでもなくなったようですが…)。かくて、自分で登録したサイトでhttpsを強制するFirefoxプラグイン Force-TLS

と、PC引っ越し用に覚え書きしましたが、あろうことか引っ越し先PCではサイトが追加できなかった(すごいところに設定ファイルがあったりするのだろうか)ので、問題の検証もせずにさくっと方針転換でhttps://addons.mozilla.org/firefox/tag/httpsを眺めてHTTPS Everyehereを試しました。https://www.eff.org/https-everywhere/rulesetsに従って簡単な正規表現を含むシンプルなXMLを作成。(2010/11/25追記: 自動更新版だと0.9.0よりtargetで1次フィルタするようになりました。targetが無いと気づかないうちにルール全体が無視されているので注意です。要エラーコンソールでの確認)

<ruleset name="HOGE">
  <target host="example.com" />     (自動更新版だと0.9.0より必要)
  <target host="www.example.com" /> (自動更新版だと0.9.0より必要)
  <rule from="^http://(?:www\.)?(example\.com/)" to="https://www.$1" />
</ruleset>

<target host="example.com" /> (自動更新版だと0.9.0より必要)

<target host="www.example.com" /> (自動更新版だと0.9.0より必要)

</ruleset>

書かれている場所に保管してFirefox再起動。さくっと動作。設定ダイアログにも指定したものたちがちゃんと登場。ファイル作る手間があるけどルールが汎用的に作れるのでこっちの方が便利かも。

2010/11/25追記: 一部であらかじめ登録されたサイトにしか使えないと受け取れる説明がされているようですが、HTTPS Everywhereは説明や上記のとおり、自分の好きなサイトを指定できます。

2010/11/25追記: 同じく一部で家庭用の無線LANでは不要と受け取れる記述もありますが、家庭用無線LANでも暗号化無しであったり弱い暗号でtap可能であれば同じこと(パスワード漏れ & セッションハイジャックされる可能性のある状態)です。モニタポートのある有線LANのスイッチングハブや、買うのが難しいでしょうがリピータハブにアクセス可能である状況もまた同じことです。Firesheepを相手に対策するのではなく、平文パスワードと、そしてセッションハイジャック対策としてクッキーを秘匿するためにHTTPSを使用すると考えなければいけないです。URLがhttps://で始まっていても、secure無しcookieで内容にHTTPが混在していたりJavaScriptでHTTPでアクセスしにいってしまっては元も子もないじゃん、というサイトもあり、今に始まった問題では全然ないですが、script kiddieでもFiresheepで簡単にセッションハイジャックできるようになったという状況のおかげでそのようなサイトが改善されるチャンスでもあります。

HSTSはSSL/TLSが有効なコンテキストにて、Apache HTTPDならば一番簡単な使い方で

Header set "Strict-Transport-Security" "max-age=ブラウザがこのことを覚えていて良い最大秒数"

1	Header set "Strict-Transport-Security" "max-age=ブラウザがこのことを覚えていて良い最大秒数"

とするだけです。

Windows で sockstat (lsof)

2010-10-062016-08-26 清水文行

fport(XP以前)とかの3rdパーティーのコマンドを使わずに素のWindowsだけでsockstat -46(lsof -i)したい時。

netstat -anb

1	netstat -anb

とか

netstat -ano
tasklist /svc | find "_pid_"

1 2	netstat -ano tasklist /svc \| find "_pid_"

netstatに-oなるオプションがあったり、find(fgrep)で””が必ず必要(command.comゆずりでcmd.exeも処理していないのか、はたまた処理してさらに”を渡しているのか…)だったり。

ある日ソフトエラーを目の当たりにする

2010-09-072021-11-16 清水文行

アプリケーションの計算結果のテストのためにDBで大量の検索、挿入、更新、そして照合用も含めてファイルも大量に新規作成、削除、読み込みを何日も連続で繰り返さなければならないことがあります。連続で読み続けたり書き出し続けたりするのでディスクキャッシュを数百メガバイトに設定したところで効く由もなく、連続稼動用を謳っているハードディスクを3,4台のストライピングで使用しても負荷が激しすぎで3,4週間程度でお亡くなりになるのでどんだけひどい仕打ちをしてるんだろうと思ってしまいます。古いflash SSDだったら即死するかもしれません。ハードディスク交換していてはエコじゃないので使用量を減らすとすると、DBのデータを最初にRAMディスクにコピーし、一時ファイルもRAMディスク上というのが良さげですが、いっそOSごとDRAMのRAMディスクにして物理ディスクレスにしてしまおう、ということで1年ほど前にRAMディスク化しました。

マニュアルとOEM元Q&Aは良い(しかしどちらも日本語訳はすごすぎ)のですが、なぜかそれらと輸入代理店のFAQがいい感じに違っている某商品、DDR2メモリを積めるものです。1年たった今になって、実はunbuffered ECC対応、さらにunbuffered non-ECCでもジャンパーを刺せば容量の1/9使ってをECCエミュレーションをしてくれる(ハミング符号だとすると比率から64ビットバス+8冗長ビットのエミュレーションですね)という結構優秀な機能を持っていることがわかりました(輸入代理店はECC非サポートと明記している)。コストパフォーマンスからはunbuffered non-ECCのメモリを使ってECCエミュレーションするのが一番良さそうです。

しかしインストール時はそんなことには気づいてなかったのでnon-ECCメモリでECCエミュレーションも使わずに1年近くたった先日、その日はきました。演算結果の検証エラー。

正解	検証対象
.19;5	.1995

正解は数値であるはずだったので、すぐに正解の方がおかしいことに気づくことができるのが不幸中の幸いです。別途ハードディスク上に圧縮して保管されている検証用データと比較すると、検証対象の値で正しいことがわかりました。面白いのでこのファイルの文字セットUS-ASCIIでのコードポイントを調べてみます。

	9	;
hex	3 9	3 b
bin	0011 1001	0011 1011

その他の1GB程度の正解ファイルの検証、さらにOSとports部分はTripwireしているので検証したところ違いは検出されず()、RAMディスク起動時のデータも同様、そしてその後このようなエラーも起きずにいるのでソフトエラーということで間違いないようです。ビット反転によく見える形で遭遇してしまいました。機材近辺でのノイズであればエラーが頻発してもおかしくないような気がするので日常の宇宙線か、太陽フレアか、などと空のかなたに思いをはせていたところ、こんな記事がありました。

Google: Computer memory flakier than expected　(邦訳 – なぜか思い入れがえらく強いタイトルになってます…)

周辺の状況などもあるでしょうから場所、そして何の作業をしているところか、などの条件をどうしているのかちょっとわかりませんが、温度なんかどーっちゅうこともない、ハードエラーの方がソフトエラーよりcommonである(ECC前提での話?)、など面白いです。温度が経年変化に与える影響なんかも調べられてるんでしょうか。時間ができたら元の論文読むべしです。

さらに温度といえばグーグルの最新のデータセンターは非常識なほど進化しているだそうで、自宅サーバなんて昔から室温50度超えになっちゃうようなところで並んで動いていたわけで進化なのかどうかは置いておくとして、かつて大学のコンピュータがある場所では壁一面にウルトラマンに出てくるような巨大なテープが回ってる箱が並んでいてエアコンがガンガンに効いている、なんてのはいったい何の話?ってなもんですね。

何よりも実感したのは、サーバだけじゃなくてテスト機にもECC使わないとだめじゃん、ということです。考えれば当たり前な話ですが、それを言い始めるとnon-ECCで良い仕事ってあるんだろうか…

追記: bitsquatting面白い!

定例外Windows Update KB2286198

2010-08-032016-08-26 清水文行

毎月第2火曜日の次の日ではないですが、各所から通知が飛んできている通り半月前の脆弱性に対する定例外の重要なWindows Updateが出ています。手動の方はご注意を。

server does not support RFC 5746, see CVE-2009-3555 (was: potentially vulnerable to CVE-2009-3555) Apache HTTPD + OpenSSLでRFC5746リネゴシエーション対応

2010-06-172021-11-16 清水文行

CVE-2011-0411 Plaintext command injection in STARTTLSはこちら

Bug 549641の変更をここのタイトルにも入れてみました(2010/9/14) 。元々「潜在的に脆弱」という微妙なメッセージから書き起こしたエントリなので、文章のつながりが悪くなったかもしれません。

CVE-2009-3555はDescriptionによればSSL3.0(とおそらくそれより前)とTLSプロトコルにおいて、”renegotioation”でMITM攻撃者がデータを挿入可能である、というものになり、去年の11月に業界(?)を震撼(?)させたものです。

この問題を解決するべくIETFのTLSな方たちは世のため他人のため、ものすごい勢いで”secure renegotiation”(安全な再ネゴシエーション)を定義して本年2月までにRFC5746にしてくれました。

表題のメッセージはFirefoxがhttps://なサイトにアクセスした場合や、ThunderbirdがSSL,TLSでPOP3, IMAP4, SMTPアクセスした場合などなどでエラーコンソールにログされるものですが、mozilla wiki Security:Renegotiationを超訳すると、「まだ問題があるwebサーバだらけで、今よく見えるように警告してしまうとそれを無視しましょうとのたまう人が出てきて、ユーザは似たような警告も含めて無視する習慣が付いてしまうだけで世の中が幸せにならない。だから潜在的に問題のあるサーバはそっとエラーコンソールにログするだけ」とのことです。実際にはRFC5746を実装していないwebサーバとのTLS/SSL使用時に表示されるので、webサーバ側にrenegotiationを全て無効にする形でのパッチが適用されている場合、webサーバとしてはCVE-2009-3555に対して脆弱でなくでもそれを通信中のフラグ(RFC5746対応している場合にはServerHelloのextentionのrenegotiation_infoが付いてくる)では検知できないのでFirefoxのエラーコンソールに表題のメッセージがログされます。

表題のメッセージを消す==webサーバをRFC5746のsecure renegotiationに対応させるためにすることをざっくり書くと、OpenSSLとApache HTTPD(mod_ssl)2.2系列の場合、

対象のwebサーバにhttps://で接続してFirefoxのエラーコンソールに表題のログが表示されることを確認。
先にOpenSSLを0.9.8m以降にアップデート。(2014/4/8現在1.0.1g以降をお勧め)
次にApache HTTPD 2.2系列の場合2.2.15以降(2010/9/14現在2.2.16以降をお勧め)にアップデートかリビルド。
再度https://で接続してFirefoxのエラーコンソールに表題のログが表示されなくなったことを確認。

となります。(悲しいことにrenegotiationしないと続行できない状況の場合、~~いまだRFC5746非対応であるIE~~(←末尾に追記)RFC5746非対応ブラウザなどで問題になり、わざわざmod_sslにSSLInsecureRenegotiationディレクティブを使用して古いrenegotiationを有効にせざるをえなくて困っているサーバ管理者の方も多いです)

その他にもご自分のwebサーバがインターネット上にあればQualys SSL LabsのSSL Server Testにて、SSL,TLS全般の確認ができます(表示されているように、別のURLで流れさるまでの何時間かURLと結果がさらされます(その後指定すればさらされないようになりました)。さらに上位と下位は別枠で表示してくれます)。結果のMiscellaneousのRenegotiationの項に、安全なのか古いリネゴが使えてしまう状態か、などが表示されます。

クライアントのRFC5746対応も必要ですが、表題のログがエラーコンソールに出ている時点で当然古いrenegotiationを問題視しているwebブラウザを使用していることになるのでここでは考えないことにします。webブラウザのRFC5746対応はmozilla wiki Security:Renegotiationに書かれているように~~https://ssltls.de/~~で確認できます(←末尾にちょっと追記)。有るべき姿はwebブラウザ、webサーバに限らず、「SSL,TLSを用いた全てのクライアントとサーバがRFC5746に対応していること」になります。

ではwebサーバとしてはCVE-2009-3555に対して脆弱でなくてもログされる場合(薦められた状態ではないですが)はというと…

例えばOpenSSLのChangeLogを見ると、

2009/11/5 Changes between 0.9.8k and 0.9.8l
   すべての renegotiation を無効にしてやったぜ。

1 2	2009/11/5 Changes between 0.9.8k and 0.9.8l すべての renegotiation を無効にしてやったぜ。

2010/2/25 Changes between 0.9.8l and 0.9.8m
   RFC5746実装。

1 2	2010/2/25 Changes between 0.9.8l and 0.9.8m RFC5746実装。

となっていて、またFreeBSD Security Advisoriesの2009/12/3 FreeBSD-SA-09:15.sslでは

  よく注意: このアップデートで、renegotiationは全部拒否しちゃうようになるからね

1	よく注意: このアップデートで、renegotiationは全部拒否しちゃうようになるからね

となっています。ソースレポジトリを見ると2010/6/15現在-CURRENTとRELENG_8(-STABLE), RELENG_8_1がOpenSSL 0.9.8nであり、他は OpenSSL 0.9.8eとかkとか + SA-09:15 ということになるようです。

さらにApache HTTPD 2.2.15のChangeLogでは、

  OpenSSL 0.9.8lより前とコンパイルした場合はクライアントがinitiateしたrenegotiationを拒否。
  OpenSSL 0.9.8m以降とコンパイルした場合は包括的修正が適用される

1 2	OpenSSL 0.9.8lより前とコンパイルした場合はクライアントがinitiateしたrenegotiationを拒否。 OpenSSL 0.9.8m以降とコンパイルした場合は包括的修正が適用される

となっているので、Apache HTTPD(mod_ssl) 2.2.15以降の2.2系列をOpenSSL 0.9.8m以降のライブラリでコンパイル、リンクすることでRFC5746のsecure renegotiation対応になります。

Apache HTTPDにSSLInsecureRenegotiation指定をしない前提でまとめていくと2010/6/15現在

FreeBSD 8.1(現在ベータ1,7月リリース予定)のOpenSSLは0.9.8nなのでRFC5746対応。したがってCVE-2009-3555に対しては脆弱ではない。

FreeBSD 8.0, 7.3, 7.1各セキュリティブランチを最新の状態にしている人のOpenSSLは0.9.8? + SA-09:15なのでRFC5746は対応していないが、renegotiationを全部無効にすることでCVE-2009-3555に対しては脆弱ではない。

OpenSSL 0.9.8l
あるいはFreeBSD 8.0, 7.3, 7.1各セキュリティブランチのOpenSSL(0.9.8? + SA-09:15)
+ Apache HTTPD(mod_ssl) 2.2系列全部
の場合は

表題のエラーコンソールログは表示される(RFC5746非対応)
CVE-2009-3555についてwebサーバは脆弱ではない(ただしrenegotiationがすべて無効)

OpenSSL 0.9.8m以降(2010/6/15現在OpenSSL 1.0.0a以降をお勧めします)
+ Apache HTTPD(mod_ssl) 2.2.15以降の2.2系列
の場合は

表題のエラーコンソールログは表示されない(RFC5746対応)
CVE-2009-3555についてwebサーバは脆弱ではない(RFC5746対応)

要注意なのは、Apache HTTPD 2.2.15にしただけで安心してしまう次のパターンでしょうか。現実的にMITM攻撃が成立するかは考えずにChangeLogからだけ言うとするとCVE-2009-3555に対してwebサーバは脆弱です。
OpenSSL 0.9.8k以下(FreeBSDの場合は0.9.8k以下かつSA-09:15のアップデートがされていない場合)
+ Apache HTTPD 2.2.15以降の2.2系列、
あるいは2.2.14 + http://www.apache.org/dist/httpd/patches/apply_to_2.2.14/CVE-2009-3555-2.2.patch
の場合は、

表題のエラーコンソールログは当然表示される(RFC5746非対応)
CVE-2009-3555に対しては * 脆弱である *
(クライアントがinitiateした場合のrenegotiationを拒否しているだけ)

まずサーバ側の古いrenegotiationの実装が一掃され(同時にメジャーwebブラウザが全部RFC5746対応するという壁も大きいようで)、そしてRFC5746実装が使用され、renegotiationの一部や全部を無効にしただけのパッチがおおよそ一掃されて、それからようやく表題のエラーコンソールのログが派手な警告なりエラーなりに格上げされることになると思われますが、まだまだかかりそうですね…
例:https://bugzilla.mozilla.org/show_bug.cgi?id=555952

FreeBSD 8.0, 7.3, 7.1 + Apache HTTPD(mod_ssl)で表題のエラーコンソールログが出なくなるようにする、つまりRFC5746対応にするには、2010/6/15現在SA-09:15ではOpenSSLのrenegotiationを全部無効にしているためApache HTTPD(mod_ssl)を2.2.15にするだけでは不十分であり、こどもの日にportsがOpenSSL 0.9.8mに対応された(2010/6/15現在1.0.0a対応)ので、これを使うのが早そうです。

# portsnap fetch
# portsnap update
# portinstall security/openssl
# env WITH_OPENSSL_PORT=yes portupgrade -f www/apache22
# ldd /usr/local/libexec/apache22/mod_ssl.so
/usr/local/libexec/apache22/mod_ssl.so:
        libssl.so.7 => /usr/local/lib/libssl.so.7
        libcrypto.so.7 => /usr/local/lib/libcrypto.so.7
        ...

# portsnap fetch

# portsnap update

# portinstall security/openssl

# env WITH_OPENSSL_PORT=yes portupgrade -f www/apache22

# ldd /usr/local/libexec/apache22/mod_ssl.so

/usr/local/libexec/apache22/mod_ssl.so:

libssl.so.7 => /usr/local/lib/libssl.so.7

libcrypto.so.7 => /usr/local/lib/libcrypto.so.7

...

最後の表示では、特に/usr/lib/や/lib/ではなくて、/usr/local/lib/libssl.so.*, /usr/local/lib/libcrypto.so.*であることを確認する必要があります。

あらかじめFirefoxでhttps://接続してエラーコンソールに表題のものがログされていることを確認した後、アップデート作業後にログされなくなればRFC5746対応完了です。

Windows関連ちょっとだけ追記(2010/9/14)。 2010年8月の月例(日本だと8/11あたり)のアップデート群に含まれていたKB980436: MS10-049: Vulnerabilities in SChannel could allow remote code executionによってWindowsのTLS/SSLスタックがRFC5746対応されましたが、それが使われるWindows XPのIEで https://ssltls.de/ のペンギンさんが表示されないのを確認しようとしてたこともあって時間がとれずに一月経ってしまいました。どうやらmod_nssを使った環境を作らないとちゃんと確認できなそうなので、先ほどざっと確認した現象だけ列挙しておきます。

Opera,Firefoxは結構前からペンギンさんが表示される。
KB980436が適用されたWindows Vistaではペンギンさんは表示される。
KB980436が適用されていてもWindows XP, 2003ではIEのバージョンによらず、ClientHelloのextentionでもSCSVでもペンギンさんは表示されない。
Windows XP(IE)のClientHelloのextentionにはtype 0xFF01(renegotiation_info)しかないが、Vista(IE)やOperaはそれに加えてserver_nameやstatus_requestなどがある。
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL にUseScsvForTlsという名前のDWORD値を作成して1をセットすると、Windows XP(IE)ではClientHelloのextentionが無くなる。Firefoxはserver_nameやstatus_requestなどがある。どちらもrenegotiatoin_infoは無く、cipher suiteに0x00FFが追加されている(SCSV)。

次はmod_nss環境を作成してnssのデバッグログを吐かせるところからになりますが、誰かとっくのとうに解決していたら教えてくださいませ。

なおWindows(IE,IISなど)で古いリネゴを拒否する方法はKB980436に書かれています。レジストリをいじって

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"AllowInsecureRenegoClients"=dword:00000000

1 2	[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "AllowInsecureRenegoClients"=dword:00000000

で再起動すればサーバ(IISなど)が、そして

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"AllowInsecureRenegoServers"=dword:00000000

1 2	[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "AllowInsecureRenegoServers"=dword:00000000

で再起動すればクライアント(IEなど)が古いリネゴを拒否するようになります(いろいろ使えなくなるものが出るようなので、まだ不便かもしれません)。

その他の参考リンク

Port directory not found: math/libgmp4 からの～ Command failed [exit code 1]: /usr/bin/script -qa

2010-05-102021-11-16 清水文行

/usr/ports/UPDATINGによるとportmaster使ってる人は

# portmaster -o math/gmp math/libgmp4

1	# portmaster -o math/gmp math/libgmp4

で更新、とのこと。portupgradeで許してと、

# portsnap fetch && portsnap update
# portupgrade -f -o math/gmp libgmp

1 2	# portsnap fetch && portsnap update # portupgrade -f -o math/gmp libgmp

すると(as of 2010/5/10)、

===>  gmp-5.0.1 conflicts with installed package(s):
      libgmp-4.3.2

      They install files into the same place.
      Please remove them first with pkg_delete(1).
 ** Command failed [exit code 1]: /usr/bin/script -qa ..........

===> gmp-5.0.1 conflicts with installed package(s):

libgmp-4.3.2

They install files into the same place.

Please remove them first with pkg_delete(1).

** Command failed [exit code 1]: /usr/bin/script -qa ..........

あいたた。-oの時のconflictのチェックをするタイミングがおかしいような。原因を追究しなければいけないところですが、レポートはどんどんあがりそうだと言い訳をしてその場をしのぐべくUPDATINGに言われたとおりにportmaster使います。その前に念のためlibgmpに依存しているものを確認。

pkg_info -R /var/db/pkg/libgmp*

1	pkg_info -R /var/db/pkg/libgmp*

出てくるパッケージをメモ、

# portmaster --check-depends
# portmaster -o math/gmp libgmp

1 2	# portmaster --check-depends # portmaster -o math/gmp libgmp

もしもメモしたパッケージがアップデートされない場合は

# portupgrade -fr math/gmp

1	# portupgrade -fr math/gmp

か

# portupgrade -f [メモしたパッケージ]

1	# portupgrade -f [メモしたパッケージ]

で解決。

全然関係ないですがLLVM全盛の世の中GCCのメッセージを眺めていて、一晩かけてSONYのNEWSでコンパイラをコンパイルしているところを眺めていた十数年前など思い出しつつ、GCCともお別れの季節が近づきつづあるようです。

http://llvm.org/demo/ VM自体はホストの時代に戻ってる気がしますが、CGIでコンパイルとか今風で最高に面白いデモです。

ActionScript3.0のDataGridでCheckboxを使いたい [AS3] – Checkbox CellRendererを作る

2010-05-062021-11-17 清水咲里

Using a CheckBox in a DataGrid in ActionScript 3.0 [AS3](⇐ In English)

ビジネスアプリケーションにとってデータの操作は基本中の基本。だから、GUIコンポーネントを提供する言語だったら、データをリスト表示したり並べ替えたりする機能やコンポーネントがある、と想定してもおかしくありません。ActionScript3.0にもあります。

今回はActionScript3.0で、そのリスト表示の中にチェックボックスを表示する方法について、Adobe社のオンラインドキュメントに掲載されているサンプルに追加機能を加えながら解説します。これができると、例えば社員教育の受講管理で、リスト上で受講ステータスチェックボックスにチェックを入れればその人を受講済みにできたり、複数のレコードを選択して処理する場合に、処理チェックボックスにチェックが入っている行だけ処理をする、などということができます。もちろんコントロールキーを押しながらクリックして複数選択する、という手もありますが、「これってユーザに優しくないよね」と常日頃思っている人には、チェックボックスのほうが良いかもしれません。

データのリスト表示や操作をするコンポーネントは一般的に、データ部分を提供するものと、そのデータの表示の仕方を指定して操作するものとに分ける、というパターンを使って作られていますが、ActionScript3.0もそのパターンで、データをグリッド(grid)表示するDataGrid、そのDataGridにデータを提供(provide)するのがDataProvider、そして、DataGridのそれぞれの列やセルの表示/描画の仕方を指示する(render)のがCellRenderer、という組み合わせになっています。デフォルトではデータをテキスト表示をするCellRendererが提供されています。

このDataGridのひとつの列をCheckboxにするには、fl.controls.CheckBoxクラスを拡張してfl.controls.listClasses.ICellRendererインターフェイスを実装した新しいクラスを定義し、チェックボックスにしたい列のcellRendererプロパティに、そのクラスを指定します。詳細なやり方はActionScript3.0のマニュアル「カスタムCellRendererクラスの定義」の「ICellRendererインターフェイスを実装するクラスを使用してカスタムCellRendererを定義するには」のセクションに記載されています。しかし、このページに掲載されているサンプルは動かすとエラーになるので、その代わりに、「DataGridCellEditorのオンラインマニュアルの(なぜか)コメント欄に記載されているコード例が一番参考になるでしょう。CellRendererを作成するのが初めてのかたは、まずはこのコード例を、そのまま試してみることをおすすめします。

このコード例ではDataGridの選択状況がチェックボックスと連動する作りになっています。今回、著者はチェックボックスが独立して機能するようにしたかったので、この記事ではこのコード例をベースに、その変更点について解説します。

では変更点を見ていきましょう。まずはfunction set selected()です。Adobe社のコード例では、ここでチェックボックスの選択状況をセットしていますが、このメソッドは、DataGridの行が選択された際に呼び出されます。一番最初にDataGridを表示した時点では、このメソッドは呼び出されないので、セルの値がチェックボックスにチェックに反映されず、チェックボックスは常にチェックが入っていない状態で表示されます。セルをクリックして初めてセルの値がチェックボックスに反映されます。また、ここでチェックボックスの選択状況をセットすると、DataGridの選択状況とチェックボックスの選択状況を連動させることになるため、ショッピングカートや冒頭で例示したような「社員教育受講管理」など、チェックボックスが単独で機能しないといけない場合に対応できません。DataGridの行を選択したらチェックが入るのではなく、チェックボックスをクリックしたらチェックが入ったりはずれたりして欲しいのです。なので、このロジックは後述のfunction set listData()とtoggleSelected()で実装します。ただし_rowSelected属性をセットしている部分は、DataGridを選択した際に表示色などを変えるときに使うので、残しておきます。

override public function set selected(value:Boolean):void {
    _rowSelected = value;
}

override public function set selected(value:Boolean):void {

_rowSelected = value;

}

次にtoggleSelected()ですが、Adobe社のコード例では”don’t set selected or dispatch change event.” (selected属性に値をセットしたり、CHANGEイベントを送出しないように)と書いてありますが、上記のset selected()で記述した理由で、selected属性はここでセットします。

override protected function toggleSelected(event:MouseEvent):void {
    var dg:DataGrid = this.parent.parent.parent as DataGrid;
    var fName:String = dg.getColumnAt(_listData.column).dataField;
    var newStatus:Boolean = (_data[fName] == true ||  _data[fName] == "true" || _data[fName] == 1);
    super.selected = _data[fName] = newStatus;
}

override protected function toggleSelected(event:MouseEvent):void {

var dg:DataGrid = this.parent.parent.parent as DataGrid;

var fName:String = dg.getColumnAt(_listData.column).dataField;

var newStatus:Boolean = (_data[fName] == true || _data[fName] == "true" || _data[fName] == 1);

super.selected = _data[fName] = newStatus;

}

これで、DataGridの選択状況とは関係なく、チェックボックスをクリックすれば正しい値がセットされる、チェックボックスらしい動きになります。もう一つやりたかったのは、DataGridを最初に表示したときにセルのBooleanの状況を正しくチェックボックスに反映することです。それがもう一箇所の変更点set listData()になります。set listData()は、DataProviderがDataGridにセットされるタイミングと、DataGridで何か変更が起きるタイミングの2箇所で呼び出されます(DataGrid.selectable=trueのとき)。その前者のタイミングを利用したいので、上記のset selected()で実装するはずだったロジックをこちらに移動するわけです。

public function set listData(ld:ListData):void {
    _listData = ld;
    
    var dg:DataGrid = this.parent.parent.parent as DataGrid;
    var fName:String = dg.getColumnAt(_listData.column).dataField;
    var newStatus:Boolean = (_data[fName] == true ||  _data[fName] == "true" || _data[fName] == 1);
    super.selected = newStatus;
}

public function set listData(ld:ListData):void {

_listData = ld;

var dg:DataGrid = this.parent.parent.parent as DataGrid;

var fName:String = dg.getColumnAt(_listData.column).dataField;

var newStatus:Boolean = (_data[fName] == true || _data[fName] == "true" || _data[fName] == 1);

super.selected = newStatus;

}

これでDataGridの初期値がDataProviderのデータで埋まったときに、チェックボックスがセルの値を正しく表すようになります。

上記の変更を加えたCellRendererをDataGridのカラムにセットすれば、”true”や”false”という文字列の代わりにチェックボックスが表示されるようになります。このままでも使えますが、もしDataGridのListEvent.ITEM_CLICKイベントを拾って処理をするアプリケーションに使う場合は、最後にもう一工夫必要です。それはチェックボックスのCLICKイベントがListEvent.ITEM_CLICKEDに変換されるのを止めることです。なぜなら、今回実装しようとしている、DataGridとは連動せず単独に動作するチェックボックスの場合、チェックボックスをクリックするという行為の目的は、チェックボックスの値を変えることであり、DataGridの行を選択する、という目的ではないからです。

public function CheckBoxCellRenderer() {
    super();
    this.addEventListener(MouseEvent.CLICK, handleClick, false, 0, true);
}
 
private function handleClick(ev:Event):void {
    ev.stopImmediatePropagation();
}

public function CheckBoxCellRenderer() {

super();

this.addEventListener(MouseEvent.CLICK, handleClick, false, 0, true);

}

private function handleClick(ev:Event):void {

ev.stopImmediatePropagation();

}

これでOKです。

ところで、どこかのフォーラムの書き込みで、Adobe社のサンプルを見て「こんなに長いコードを書かないといけないの？！」と驚いている人を見かけました。確かにぱっと見ただけですと、ただチェックボックスを表示したいだけのわりには長く見えるかもしれませんが、要点はこの記事に書いた点だけで、他の6～7割のコードは全て表示スタイルに関するものです。まずは表示スタイルは何もいじらずそのままにして使ってみると、見た目ほど複雑ではないことに気が付かれると思います。

なお、このコードは著者がアプリケーション開発の過程で試行錯誤の結果導き出した一つの手法であり、皆様の参考用に掲載しているものです。ご
利用の条件につきましては、「サイトのご利用条件」をご一読ください。また、このコードは弊社が開発しているアプリケーションで実際に使われています。したがいまして、今後改善やバグ修正がされる可能性がありますが、変更が入りましたら随時この記事を更新します。

LimeSurveyをインストール

2010-04-282021-11-16 清水咲里

オープンソースのアンケートシステム、LimeSurveyをFreeBSDにインストールしました。いつもの「実験君」です。データベースにはPostgreSQLを使います。

まだ使い始めたばかりなので、LimeSurvey自体についての感想や応用方法については後日に取っておきます。今回は現時点でマニュアルには載っていなかったインストールに関する情報を補足します。なお、この情報はLimeSurveyのForumにも投稿し、投稿後に気づいたこともこのブログとForumの両方に追記するようにしていますが、こちらのブログの内容が最新情報になります。

FreeBSD&PHP5.2&PostgreSQLという組み合わせでLimeSurveyを導入するには、以下の3つのPHPのextensionが必要になります。

PGSQL

これを入れないと、データベースに接続できず、インストールスクリプト(/limesurvey/admin/install)を実行した直後に”Database connection failed”というエラーメッセージがブラウザ上に表示されます。

これを入れないと、インストールスクリプト(/limesurvey/admin/install)を実行した直後に”ArrayObject not found”というエラーメッセージがブラウザ上に表示されます。SettingsStorageというクラスがArrayObjectを継承して定義されているからです。

CTYPE

これを入れないと、新しいアンケート(survey)を保存する際に、”Fatal error: Call to undefined function ctype_alnum()”というエラーメッセージがブラウザ上に表示されます。

他はマニュアル通りで問題なく動き始めたのでかなり幸先が良く、フォーラムも活発で、UIや機能も大分頑張って作った感がにじみ出ているので、かなり期待しています。

使用感や応用についてはまた後日ご報告します。

/limesurvey/admin/install

プログラムを作るプログラムを作れ – プログラムを自動生成せよ

2010-04-202021-11-16 清水文行

2013/8/9 追記: 右脳左脳うそ説やプラナリアの記憶の場所など興味深い話がある中で、右脳プログラミング環境だそうです。どうなっていくでしょう。

何の文脈も無く「プログラムを作るプログラムを作れ」と言われた場合、まずそれを言われた方のITスキルやバックグラウンドを知らないと延々と禅問答が続いてしまいそうです。プログラムとはコンピュータへの命令のことなので、それを作るプログラムとなるとコンピュータへの命令を作るコンピュータへの命令を作ることになりますね。最初から直接命令すればよいじゃん、となってしまいます。

各種言語のコンパイラはプログラムを出力するプログラムですし、古くからあるlexとyaccあたりで新しく構文を解釈してプログラムを出力するプログラムを作れば、lexとyaccはプログラムを作るプログラムを作るプログラムでしょうか。

program to create programなどのフレーズでいろいろ検索してみます。Visual Basicのようにコンポーネントをたくさん準備しておきそれらを配置、接続していくもの、イベントに対するアクションもあらかじめ複数準備し、視覚をベースにプログラミングするものがまず目に付きます。準備しなければいけないものは無数ですが、多くの作成者を満足できるレベルになれば便利です。あとは各種言語用のエディタも出てきます。確かにプログラムを組むため(ソースコードを書くため)のプログラムです。そして決められた形式の設計書に基づいて各種言語のソースコードを自動生成と称して出力するプログラムもたくさん登場してきます。UMLとJavaがその典型でしょうか。自動生成されたソースコードは設計書に書かれた枠だけができるため、実際に必要なロジック、つまりほとんどの部分は自力で追記していくことになります。

もしコンピュータへの命令の仕方を知らない方が言った言葉であるとすると、きっと自分で理解できる命令の仕方を作って欲しい、つまり自分にも使えるプログラミング言語、あるいはプログラミング言語までにも至らないプログラムする方式を作って欲しいということなのかと想像できます。自分で理解ができる命令の仕方という意味で考えてみると、最善はしゃべった言葉をそのまま理解して実行してくれるということになるでしょう。サイロン、ターミネーターがそんな感じだと思われます。

かつて自分が小学生であった頃、親に「マイコン」を買ってもらうための殺し文句に「英語の勉強になる」というものがありました。残念ながら自分の親は共にホストコンピュータを触っているような人達だったのでそれはまったく通じませんでしたが、知らない人にはコンピュータは英語で動作していると思われていたのかもしれません。そしてそのような古き良き時代、日本語を入出力できる日本語BASICならぬ、日本語で動作するBASICなるものがマイコン雑誌の広告に出ていたりしたものです。日本語であればプログラムができると思う層を取り込む試みだったと思われますが、1,2年もしないうちに見なくなったと記憶しています。

もし I < 100 ならば I = I + 1900

半べそです。そもそも知らない人にはIFやらTHENやらが日本語になったところで I = I + 1900 で、そんなアホな、です。実際には英語も含めて自然言語を完全に理解するプログラムはいまだにできていません。言語は進化することを考えると言語の進化も取り込めるようにする必要もあるでしょうし、自然言語は前後の文脈が無いと理解不可能な場合が頻繁にあります。受け身や敬語のように前後の文脈どころか発言者の立場までわかっていないといけない場合もあるでしょう。人間の脳は小さい頃からお勉強してそれらを学んできたのですね。

現在でも日本語でプログラムを書けるようなプログラミング言語は作られているようですが、みな教育用のようです。英語と日本語が大きな壁になる場合には有効な教育方法だと思われます。一方、実際のプログラミング言語で予約されている「英単語」は数十の場合が多いので数十単語覚える方が早いのかもしれません。利用したわけではないので時間があれば「パソコン」を買ってもらえた今、実際に日本語プログラミング言語を使って楽しみながら確認してみたいです。

日本語英語の壁を考えないとして、現在の自分で理解ができる命令の仕方となると、やはり何かしらのプログラミング言語、あるいはプログラミング言語のソースコードを作成するためのかなり限定的な枠組み、ということになるでしょうか。プログラムを作るプログラムがあってもプログラミングができる人間の脳は必要とされている状態で、ロボコップがそんな感じです。

ターミネーターはストーリーにはもう大分できていないといけないくらいの時期だったかと思いますが、スカイネット様への納期を死守するには越えなければいけない高い山が続々とあるようです。あれ、スカイネット様をまず納品しないといけないのでしたっけ。

以上は飲み屋でMetaMojiという会社の記事から始まってまだ世の中はロボコップかねぇという話になるまでを思い出しながら書いたもので、とりとめが無いです。お後がよろしゅう。

devel/php5-pcre (port directory error)

2010-04-152021-11-16 清水文行

PHP5のportupgrade中に

 - devel/php5-pcre (port directory error)

1	- devel/php5-pcre (port directory error)

が出たので、/usr/ports/UPDATINGを見ると、 php5-dbase php5-ncurses php5-pcre php5-spl php5-ming php5-mhash がコアになったから消して、php5と依存してるもの全部リビルドせいとのご指示。

pkg_info -R php5-dbase php5-ncurses php5-pcre php5-spl php5-ming php5-mhash

1	pkg_info -R php5-dbase php5-ncurses php5-pcre php5-spl php5-ming php5-mhash

で依存しているものたちをメモ。

pkg_deinstall -f php5-dbase php5-ncurses php5-pcre php5-spl php5-ming php5-mhash

1	pkg_deinstall -f php5-dbase php5-ncurses php5-pcre php5-spl php5-ming php5-mhash

で消し去ったら

2011/10/17 追記(archiver/php5-zip参照): /usr/local/php/ext/php_config.h に、必要の無い行がある場合は削除します(pcre spl以外は実際に存在していたか特に確認していません)。

# cd /usr/local/include/php/ext
# cp -p php_config.h php_config.h.prev
# fgrep -v -e ext/pcre/ -e ext/spl/ -e ext/dbase/ -e ext/ncurses/ -e ext/ming/ -e ext/mhash/ php_config.h.prev > php_config.h

# cd /usr/local/include/php/ext

# cp -p php_config.h php_config.h.prev

# fgrep -v -e ext/pcre/ -e ext/spl/ -e ext/dbase/ -e ext/ncurses/ -e ext/ming/ -e ext/mhash/ php_config.h.prev > php_config.h

間違いの無いようにファイルも

# /bin/sh
# for p in pcre spl dbase ncurses ming mhash; do [ -f "$p/config.h" ] && mv -v "$p/config.h" "$p/config.h.prev"; done
# exit

# /bin/sh

# for p in pcre spl dbase ncurses ming mhash; do [ -f "$p/config.h" ] && mv -v "$p/config.h" "$p/config.h.prev"; done

# exit

とでもしてリネームしておきます。追記部分終了

最後に

portupgrade -fr lang/php5

1	portupgrade -fr lang/php5

か

portupgrade -f [依存しているものたち...]

1	portupgrade -f [依存しているものたち...]

あたりで処理。あとは一応php.iniを見直し。

あ、その金庫、横に鍵が張り付けてありますが中身大丈夫ですか?

2010-04-102021-11-16 清水文行

「動けばよいってもんじゃない」ですが、ショッピングカートはその最たるものの一つです。かつてネット通販が出始めの頃、いろいろなケースに出会いました…

最も多かった問題が、返信メールに記載されたURLをクリックするとログインもしていない(そういう通販サイトにはcookieとかセッションとかいう概念が存在しません)のに住所から注文内容から確認できるものです。メールにURLを記載しなければ良いという話でもなく、注文するときはそのようなシステムと知らないわけで、注文終わってからあーやばい通販だったかと学習することになります。今では使う通販も決まってきて新しいシステムの通販に手を出すことはほとんどないのでそういう思いをすることもまずないですが、いまだに某大手ISPのアンケートシステムでも使われてました。海外のTシャツ屋、今は無くなってしまった書店、今もある比較的大手の通販、などなど何度か出会いました。「該当URLが404を返すようにして、あと恐ろしいのでカードの情報も削除しておいてね」とお願いすると、そのすべてから「URLにランダムな文字列が入っているので大丈夫!」(鍵が貼り付けてある金庫なので当然大丈夫じゃないです。念のため)「SSLだからデータは安全!」(通信路の暗号化であり、しかもメールで送られてきてしまったURLは暗号化されていないうえに両端ではデータは復号化された状態なので全然大丈夫じゃないです…)と笑い話にもならない自信満々のお返事を頂戴したものです。

このたび「noindex,nofollow,noarchiveと書いてあるし、user agentでロボットはじいているから大丈夫!」という説も増えたようですが、何にせよ鍵が横に貼り付けてある金庫を、メールで送ったりブラウザから送信させておいて、その金庫の中身が大丈夫だと言ってしまうのはこれまた…

今時ですとブラウザに各種ツールバーをインストールされている方も昔よりも格段に多いでしょうから、tappingやらbrute forceされるまでもなく、そして自らが認識しているかどうかにかかわらず閲覧しているURLが他ホストに自動的に送られている場合も、セキュリティのためなどと称して多数あることでしょう。また別の側面では「ランダムな文字列」が実は順番の数字のBASE64エンコードだったりソルト無しハッシュ値のような、なんちゃってランダムだったときにもノーガード公開状態となります。

このようなシステムを作ってしまう人がここ十数年絶えることなく出続けてきたわけですから、webアプリ作成者の常識に期待することをあきらめるとすると今回のような深刻な犠牲者を増やさないためにはどうすればよいでしょうか。セキュリティソフトと呼ばれるものの中には生のまま特定の情報が送受信される場合に通信を遮断する機能を持つものがありますが、メールで送られてくるURLの場合のように他人のシステムから送られてきてしまう場合、そしてそのページに問題がある場合にはいかんともしようがありません。良さそうなのは、ショッピングカートに限らず鍵付き金庫をばら撒くようなシステム採用サイトのレピュテーションサービスでしょうか。コミュニティーベースでしか成立しそうにないですが、消費者保護とサービス提供者の常識確保のために政府にやっていただければ良いですね。そしてやはり経営者さん、特に消費者の不利益に直結するサイトを運営されている経営者の方たちも「動けばいいってもんじゃない」を考えていただけるとありがたいです。

と今回の某通販での大惨事の記事を見て思ったことでした。