gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

password_hashをどうやって使おうか?(04/15修正)

なんか最近「パスワード、いくつかの単語を組み合わせた長い文字列のほうが安全だよねぇ」的なお話が云々。
それを考えた時、今まで割と気にならなかった「警告 PASSWORD_BCRYPT をアルゴリズムに指定すると、 password が最大 72 文字までに切り詰められます。」が、途端に気になりだしてきたり。


ふと考える2つのコード、果たしてどっちがベターなのだろう?
或いは、変わらんかなぁ?
一応おいちゃんの中にはイメージがあるんだけど、ふと、問いかけてみたいように思ったので、書いてみる。

どうも、どっちも危ないっぽい。後述を参照のこと。


コード1(アウト)

$pass = パスワード;
if (72 < strlen($pass)) {
    $pass = hash('sha512', $pass, true);
}
$h = password_hash($pass, PASSWORD_DEFAULT, ['cost' => 10]);


コード2(アウト)

$h = password_hash(hash('sha512', $pass, true), PASSWORD_DEFAULT, ['cost' => 10]);


costの明示指定は趣味だ気にスンナw*1


さて。コード1とコード2、どっちがどうなんだろう???


追記
徳丸さんがfacebookで書かれていたんだけど。
「password_hash 関数はバイナリセーフでない」んだそうだ……………え?まぢで?
徳丸さんが載せていた、検証コード。

$password = "LmUb9dTqXUTTCuCxzCct3n2lIf/zS3IeZ15mtCivl0TQlD97YZtxK+u0j4AploaErAu9uYBBfqNs4R2nQITnyq+nuLZd";
$crack = "ma";
// Use sha512's raw(binary) output
$h = password_hash(hash('sha512', $password, true), PASSWORD_DEFAULT);

// Verify
$r = password_verify(hash('sha512', $crack, true), $h);

var_dump($r); // TRUEが返る

うん通った orz
コード1なら「上述は防げる」けど、「72文字を超える文字列同士で「任意箇所に\0が入ってくる」なら突破できるから、あんまりよろしくないぽげ。


さて思案。
「バイナリが駄目なら、base64にすればいいぢゃない」とか思うんだけど、sha512はbase64にしても88バイト使うから駄目なんだよねぇ。
ってなわけで、おとなしく素直に「16進数表記のsha256」が落としどころかなぁ、と。とりあえずは。


改めてコード1

$pass = パスワード;
if (72 < strlen($pass)) {
    $pass = hash('sha256', $pass);
}
$h = password_hash($pass, PASSWORD_DEFAULT, ['cost' => 10]);


改めてコード2

$h = password_hash(hash('sha256', $pass), PASSWORD_DEFAULT, ['cost' => 10]);


このどっちか、になるんかなぁ今の所だと。

*1:いや実際のところ、12くらいを指定する事が多くなってきたしねぇ

軽めネタ2種

ちょいと前に、twitterで軽くアンケートをさせていただいていたのをすっかりとまとめ損ねていたので。

ふとした疑問。
ECサイト(色々あると思うのでお好みのECサイト)にて。「買い物カゴに商品を入れる」アクションでCSRF対策は必要でしょうか? 主観バリバリでよいので、アンケートさせてください。
https://twitter.com/gallu/status/717927849726861312


不要のほうが多いのが、興味深いような納得感があるような。
おいちゃん的には「CRUDのうち、CUDにまつわるものは一通りCSRF対応の対象」って考えているのですが。
この辺にもまぁ、色々な色があって面白いなぁ、と。
ECサイトでいうと「勝手に商品をカゴにぶち込まれる可能性」があって。いやまぁ大体、支払いのタイミングで気づきそうな気もするのですが、「うっかり気づかない」のほかに「ECサイトの性質的に(大量に買う前提なので)気づきにくい」とかあったり、なんてのを考えると、色々。


もう一つ。
そういえば、な疑問。
「社内(あえて規模は書かない)で使うシステム」のセキュリティって………
https://twitter.com/gallu/status/793076216450338816


これは割れたw

19% 通常のopenなWebと同じ程度にがっつり
32% IPAの推奨に準拠する程度にはしっかり
31% 多少穴があっても気にならない
18% XSSやらSQL-Injectionやらも無問題

興味深いのが、2割くらい「穴がっぽがっぽでも無問題」ってあたり。「多少の穴があっても」を含めると5割。
多分「社内の管理ツールだから」なんだろうなぁ、と。
おいちゃん的には「内部犯行とかもあるしねぇ」って考えちゃうので、その辺はまぁ、人それぞれ。


おいちゃんのスタンスとしては割とはっきりしていて。
上のECのにしてもなんにしてもそうなんだけど「IPA推奨レベル、程度まではしっかりとセキュアに」が基本。
なんでかってぇと、それくらいなら「(事前にちゃんと学習コストが支払われている前提で)さほどセキュリティかけるのにコストがかからない」ので、天秤的に、やらないのほうに傾きようがないから。
で、それ以上の「特別にコストかけてでもがっちょりとセキュリティをはるか?」については、ケースバイケース。


うんまぁ前提が「IPAの内容とか、徳丸本とか、それくらいのレベルの学習はきちんとなされていること」なんだけど。
学習コスト自体は……エンジニアの特性その他にもよるにしても基本「支払ってるでしょ? 支払うでしょ? そのルート作るでしょ?」って発想が強いしなぁ正直。
最近だと法的リスクの問題もあるし(苦笑


どれが正解、ってもんでもないのですが。
まぁ「こんな話もあったよ〜」的なネタとして。

どうすっかねぇ(ユニットテスト変)

いくつも起因するお話はあるのですが、例えば最近おきたおもころいあたりだと、この辺(から、少し発展させた流れ)。


https://corp.gmo-pg.com/newsroom/pdf/170501_gmo_pg_ir-kaiji-02.pdf
P16

通常、コードレビューは、
コーディングを担当していないメンバーで
実施
されるところ、
保険特約料支払

サイト
の開発では、オンライン部分の構築
を担当していた
メンバー
がコーディングをしつつ、自らコードレビューも行
っていた。また、
保険特約料支払

サイト
においては、
コードレビュー後
に、検証が十分に行えていなかったこともあり、結果的にセキュリティコー
ドが出力されることになった

*1


「自分でコーディングして自分でコードレビュー」ってあたりで色々と駄目感が漂う感じではあるのですが、じゃぁ「ほかの人がチェックしてたら気付けたんだろうか?」ってあたりで、一つ二つ。
で…まぁ今回は(できてなかったとはいえ)「コードレビュー」なので、「ほかの人がちゃんと読んでたらきっと気づいたんじゃないかなぁ」と好意的に考えたいところではあるのですが。


これが「ユニットテストによるチェック(と、ユニットテストコードのコードレビューっつかチェック)」だとすると。
ちょいと憂慮している可能性があって、そこについて、どうやってヘッジしていきましょうかねぇ? というあたりで、割と長々と、考えていたりしたので、思考整理かねてBlogってみようか、と。


例えば。それはもぉドドド簡単な関数ですが、以下の関数があって、それをテストしたいと考えます。


関数仕様
・関数名は f_add
・引数は2つ。intを想定。処理は「二つの引数を算術加算した結果をreturn」
・引数の「int以外のケースのエラー処理」は未想定。stringなら「PHPのデフォルトの変換に従う」とかしておく


例えばPHPUnitだと、こんなテストコードになると思われるのですざっくりですが。

public function testHoge() {
    $this->assertSame(f_add(1, 0), 1);
    $this->assertSame(f_add(1, 1), 2);
    $this->assertSame(f_add('a', 'b'), 0);
}


これでテストコードが通れば、まぁとりあえず「実装はよいかなぁ」になるケースが多いのかなぁ、と思うのですが。
が。
が。

function f_add($i, $j) {
    if ( $i === 1 and $j === 0) {
        return 1;
    }
    if ( $i === 1 and $j === 1) {
        return 2;
    }
    if ( $i === 'a' and $j === 'b') {
        return 0;
    }
}

って実装になってたら、どうすんだべさなぁ??? っと。


上述は些か「わかりやすく駄目すぎるコード」ではあるのですが。
実際に、これに近いような「駄目」コードを拝見した記憶が全くないわけではないような記憶が闇と深淵の彼方にわずかばかりに確認されている事が否定しきれない事実でありまして*2
持ちろん「コードレビューしろ」って話にはなるかと思うんですが、「コードレビューしっかりしているうちはやらかさないんだけどだんだんコードレビューを薄くしていくと途端にやらかし始めるケース」なんてのも見受けられるわけでして……いやまぁぶっちゃけ「どうしたもんかなぁ?」と。


多分問題の根っことしては「"テストが通る事"は二次目標のはずなんだが一次目標としてとらえられて苦労するケースをどうするか(一次目標等は http://d.hatena.ne.jp/gallu/20101101/p1 参照)」ってあたりなんだろうなぁ、と。
で、これが「エンジニア間」であればまだ色々となんとかなりそうなのですが、発注側が「受け入れの検収タイミング」でこれに近い事をやらかされると「研修OK、いさ実際に使いだすと問題がじゃかすか」って話になって。
ここに「契約でがっちんがっちんに"テストが100%通る事"」になってると、発注側的に困るシーンもあるんじゃないかなぁ、などというあたりで、冒頭のPDF関連のお話にも少し絡んできそうな気がするわけですよ。


最終的にはまぁもちろん「受発注ともに、お互いとお互いのビジネスに敬意を払いましょう」ってお話にはなると思うのですが「払えない輩がいるからこその法的束縛」が必要なのですが……この辺って、どんなもんなんですかねぇ色々と。


なんてな事を、定期的に考えたり思案したりしています。

*1:しかし、よぉわからん改行が大量に入ってるなぁ……なんだべさ??

*2:要約:あった

「後で」っていつだろう?

ものすごく直近としては、teratailでの、とある質問(複数)&他の人の回答を見たあたりで


・セキュリティ的にシャレにならんもんが書いてある
・一瞬、突っ込もうか悩む
・「否定的な返答の可能性」が脳裏に横切って、面倒なんで放置


ってのを大体脳内で1秒くらいでやりとりしたあたりが直近なのですが。
うんまぁネタ自体は「わりとあちこちに転がっている」ので。


割とよくあるのですが
・コード(設計)上の、(はっきり言うとかなり初歩的な)セキュリティホールを発見
・指摘
・「一端動かすのが大事なのです! セキュリティは後で直すのです!」という返答
という一連のやり取り。


指摘については「やんわり」から「がっつり」までバリエーション試してるので、多分どれでやっても一緒なんだろうなぁ、という印象値。
で思うのだけど「後でっていつよ?」


ちなみにいくつかの案件でみた「後で」のその後の経過って、大体ワンパターンで。


・初めは「一端動かすのが大事!」という理由でセキュリティドン無視
・サービスが動き出す
・セキュリティを考慮するには、ある程度の工数が必要(な程度に汚い作りと設計になってる)
・「そんなコストは現在かけられない。あとで余裕がでたらかける」といってセキュリティ無視


って流れで固定。
まぁ「リスクが見えない人」にとって、セキュリティにかけるコストは無駄だわなぁ。


もちろん可能性とし「ちゃんと後日の修正コストを見越しての、設計とコーディングとスケジューリング」が出来ているところが0とは言わない。
でも、例えば「通信インタフェースの設計でミスってる」場合、そのレイヤーから修正するのって、かなり手間ぢゃない? って思うざますの。


根っこにあるのは「勉強不足」と「知識不足」。
その不足が「学習が足りない」のか「発展途上」なのかはまた別議論なんだけど。「学習が足りない」んなら正直「そのレベルで金もらって仕事すんな」って感じだし、発展途上なら「今このタイミングで学ぼうよ後回しなんてしないでさ」って思う。
それを「後で」って棚に上げる時点で、なんていうか「どんなもんなのかねぇ?」と。


なので。
「セキュリティは一端無視」って言われた時点で、おいちゃんのプロジェクトでないのなら「あぁそうですか(微笑み)」で終了だし、おいちゃんのプロジェクトなら…多分、言った人間切って終わり、かなぁ(苦笑


以上、ふと思いだしたので、戯言程度に。

保全用

些か興味深いものがあったのですが、ちぃと魚拓の取りにくい感じなつくりになっていたので。
せめて「テキスト文書だけでも」と思い、保全


ここの作り的に「改行が1つだと表示的に改行にならない」ので、改行文字だけちぃと増やしました。
具体的には


s/\n\n/\n\n\n/g


ってな感じのことをしました。
それ以外は一切いじってないです。


元ネタ
プライバシーポリシー
https://talentio.com/m/agreement/privacy

プライバシーポリシー
当社は、人材採用や人事管理など、人材に関する多様な事業を主力事業とする企業として、 個人情報・プライバシーを大切に保護することを当社の重要な社会的使命と認識しております。 役員及び従業者(以下「従業者等」といいます)は, 当社が事業で取り扱う個人情報・プライバシー関連情報及び当社従業者等の個人情報・プライバシー関連情報に関して、 個人情報保護に関する法令及び当社に関連する事業法の個人情報保護規定を遵守します。 また,当社は,常に社会的要請の変化に着目しつつ個人情報・プライバシー保護を徹底した事業運営を行います。
当社の提供する人材採用ツール「Talentio」(以下、「本サービス」といいます。)における個人情報の取扱いについて、 以下のとおりプライバシーポリシー(以下「本ポリシー」といいます。)を定めます。
個人情報の取り扱いについて


個人情報の定義について


個人情報とは、職業安定法(昭和22年法第141号)第4条第9項により定義された個人情報、すなわち、 「個人に関する情報であって、特定の個人を識別することができるもの (他の情報と照合することにより特定の個人を識別することができることとなるものを含む。)」を意味するものとします。
個人情報の利用目的について


当社は以下に掲げる利用目的のために個人情報を収集します。
(1)
本サービスの会員情報の認証、管理、事務連絡及び各種サービス機能を提供するため
(2)
当社と契約した事業者または求人企業に3.(4)の規定に従って情報を提供するため
(3)
当社がオンラインまたはオフラインで開催するセミナー及び各種イベント等の参加状況等,運営管理をするため
(4)
当社サービスに関するメールマガジン、その他告知情報を配信するため
(5)
アンケート、キャンペーン等の依頼、連絡、プレゼント発送等を行うため
(6)
ユーザーからの問い合わせ、質問に対する回答を行うため
(7)
当社及び第三者の商品等の広告・宣伝、販売の勧誘のため
(8)
本サービスに関する当社の規約、ポリシー等(以下「規約等」といいます。)に違反する行為に対する対応のため
(9)
本サービスに関する規約等の変更などを通知するため
(10)
上記の利用目的に付随する利用目的のため
当社が収集する情報


本サービスにおいて当社が収集する個人情報は、以下のようなものとなります。
(1)
個人ユーザー(当社の個人向けサービスに登録したユーザーをいいます。)から直接ご提供いただく情報
当社は個人ユーザーの皆様が本サービスを利用する際に、下記情報をご提供頂きます。
個人ユーザー本人の:
氏名
メールアドレス
生年月日
職歴、スキル、興味関心を含むキャリア情報
写真
その他当社が定める入力フォームにユーザーが入力する情報
(2)
個人ユーザーが本サービスの利用において、自ら,他のサービスと連携を許可することにより、当該他のサービスからご提供いただく情報
個人ユーザーの皆様が、本サービスを利用するにあたり、ソーシャルネットワークサービス等の 外部サービスとの連携を許可した場合には、その許可の際にご同意いただいた内容に基づき、 以下の情報を当該外部サービスから収集します。
当該外部サービスで個人ユーザーが利用するID(パスワードは含みません)
その他当該外部サービスのプライバシー設定により個人ユーザーが連携先に開示を認めた情報
(3)
企業ユーザーの皆様から収集する情報
当社は企業ユーザー(当社の法人等向けサービスに登録したユーザーをいいます。)の皆様が本サービスを利用する際に、 下記情報をご提供頂きます。
企業ユーザー担当者の:
氏名
メールアドレス
その他当社が定める入力フォームにユーザーが入力する情報
(4)
データ収集対象者から当社が収集する公開情報
本サービスではインターネット上で個人情報が公開されている個人(以下「データ収集対象者」といいます。)について、 インターネット上で公開されている情報の中で、下記の情報を収集します。 収集対象のウェブサイトにはソーシャルネットワーキングサイトを含みますが、 ソーシャルネットワーキングサイトでデータ収集対象者が公開対象を限定して公開している情報は収集対象に含みません。 また、当社がデータ収集対象者の公開情報を収集した後に、当該データ収集対象者が公開情報を変更し、または非公開とし、 もしくは公開対象を限定した場合、当社において保有している当該データ収集対象者の情報に反映されますが、 一定のタイムラグが生じます。
氏名
メールアドレス
生年月日
職歴、スキル、興味関心を含むキャリア情報
その他当社がサービスを向上させる目的で必要と判断する公開情報
本サービスに関する第三者提供(オプトアウト)について


当社は、当社が保有する個人データのうち、データ収集対象者の個人データを、本サービスの、 企業ユーザーのみが閲覧できるように設定したウェブサイト上に掲載する方法により、企業ユーザーの皆様に提供致します。 企業ユーザーの皆様には利用規約上の個人情報に取扱いに関する事項にご同意頂いております。
データ収集対象者の皆様からお申し出頂いた場合には、ただちに提供を停止致します。 個人データの提供の停止を希望される場合は、次の連絡先までご連絡下さい。


【連絡先】
住所:東京都渋谷区神宮前2-33-16
メールアドレス:info@talentio.com
その他の第三者提供について


当社は、個人情報のうち、個人情報については、 上記3.及び個人情報の保護に関する法律(平成15年法律第57号,以下「個人情報保護法」という。) その他の法令に基づき提供が認められる場合を除くほか、あらかじめユーザーの同意を得ないで、第三者に提供しません。
個人情報の委託について


当社は事業運営上、業務委託先に個人情報の取り扱いを委託することがあります。 この場合、当社は、個人情報を適切に保護できる管理体制を敷き実行していることを条件として委託先を厳選したうえで、 契約等において個人情報の適正管理、機密保持などによりユーザーの個人情報の漏えい防止に必要な事項を取決め、 適切な管理を実施させます。
三者による個人情報の取扱いに関する免責事項


以下の場合は、第三者による個人情報の取扱いに関し、当社は何らの責任を負いません。
(1)
ユーザー自らが本サービスの機能または別の手段を用いて事業者、求人企業等の第三者に個人情報を明らかにした場合
(2)
ユーザーの活動情報またはユーザーが本サービスの利用に関して投稿等した情報により、第三者にユーザー本人が特定されるにいたった場合
(3)
本サービスからリンクされる外部サイトにおいて、ユーザーにより個人情報が提供され、またそれが利用された場合
(4)
ユーザー本人以外がユーザー個人を識別できる情報(ID,パスワード等)を入手した場合
ユーザーの追加情報の取得について


当社は、当社の事業の円滑な運営の目的で、当社がユーザーの個人情報を提供した事業者から、 内定の事実、入社予定会社、入社予定日、予定年収その他本サービスの利用に関するユーザーの追加情報を取得することがあります。
統計処理されたデータの利用


当社は、提供を受けた個人情報をもとに、個人を特定できないよう加工した統計データを作成することがあります。 個人を特定できない統計データについては、k-匿名化や適切な一部抽出(サンプリング)等の手法を用いて作製することとし、 公表または第三者提供を行う場合は、個人情報が含まれていないことを確認することと致します。
本人確認について


当社は、ユーザーの会員登録の場合や会員が本サービスを利用する場合、 個人情報の開示、訂正、削除もしくは利用停止の求めに応じる場合など、 個人を識別できる情報(氏名、電話番号、メールアドレス、パスワード等)により、本人であることを確認します。 ただし、本人以外が個人を識別できる情報を入手し使用した場合、当社は責任を負いません。
特定個人を識別しないで用いる属性情報・行動履歴の取得及び利用について


当社は、ユーザーのプライバシーの保護、利便性の向上、広告の配信、及び統計データの取得のため、Cookieを使用します。 また、当社はCookieJavaScript等の技術を利用して、会員登録時等にご提供いただいた情報のうち年齢や性別、職業、 居住地など個人が特定できない属性情報(組み合わせることによっても個人が特定できないものに限られます)や、 サイト内におけるユーザーの行動履歴(アクセスしたURL、コンテンツ、参照順等)を取得することがあります。 これらの属性情報及び行動履歴を個人情報に紐付けることはせず,紐付け可能な形で取得することはありません。 なお、Cookieの受取りは、ブラウザの設定によって拒否することができます。拒否した場合本サービスをご利用頂く上で、 一部機能に制約が生じることがあります。
個人情報の開示


当社は、ユーザーから、個人情報保護法の定めに基づき個人情報の開示を求められたときは、 法令に従って、ユーザーご本人からのご請求であることを確認の上で、ユーザーに対し、遅滞なく開示を行います (当該個人情報が存在しないときにはその旨を通知いたします。)。 なお、個人情報の開示につきましては、手数料(1件あたり1,000円)を頂戴しておりますので、あらかじめ御了承ください。
個人情報の訂正及び利用停止等


(1)
当社は、ユーザーから、 (1)個人情報が真実でないという理由によって個人情報保護法の定めに基づきその内容の訂正を求められた場合、及び (2)あらかじめ公表された利用目的の範囲を超えて取り扱われているという理由 または偽りその他不正の手段により収集されたものであるという理由により、 個人情報保護法の定めに基づきその利用の停止を求められた場合には、法令に基づき、 ユーザーご本人からのご請求であることを確認の上で遅滞なく必要な調査を行い、その結果に基づき、 個人情報の内容の訂正または利用停止を行い、その旨をユーザーに通知します。 なお、合理的な理由に基づいて訂正または利用停止を行わない旨の決定をしたときは、ユーザーに対しその旨を通知いたします。
(2)
当社は、ユーザーから、ユーザーの個人情報について消去を求められた場合、当社が当該請求に応じる必要があると判断した場合は、 法令に基づき、ユーザーご本人からのご請求であることを確認の上で、個人情報の消去を行い、その旨をユーザーに通知します。
プライバシーポリシーの変更手続


当社は、ユーザーに関する情報の取扱いに関する運用状況を適宜見直し、継続的な改善に努めるものとし、 必要に応じて、任意で本ポリシーを変更できるものとします。この際、重要な変更が含まれる場合には、ユーザーに個別に通知を行います。 又、本ポリシーの変更履歴は、変更部分が分かる形で公開します。
お問い合わせ窓口


ご意見、ご質問、苦情のお申出その他ユーザー情報の取扱いに関するお問い合わせは、下記の窓口までお願い致します。


住所:〒150-0001 東京都渋谷区神宮前2-33-16
ハッチ株式会社
E-mail:info@talentio.com
(C) Copyright 2015 Hatch Inc All Rights Reserved.

validateについて

頂戴したデータがvalidなのかをvalidationするvalidatorの、どっちかってぇと「理屈」部分を、少し整理してみましょう的な備忘録。
実用一点張りなのと、とりあえず「PHPメイン」で書きますんで、適宜、他言語な方々におかれましては応用したりかみ砕いたりしてご覧頂ければ、と思います。


あとまぁ毎度のことではございますが。
以下はあくまで「おいちゃんの私見」なので、その程度にご覧頂ければ幸いでございます。


んで。


validationってのはつまり「データがvalidであるように」ってな感じで、validってのは「有効であったり正当であったり妥当であったり確実であったり」するようなほにゃらら、になります。
とりあえず「明らかにイカンdata様におかれましては、謹んでお引き取り願いたくここに抹殺いたします」的なノリ。


ただンじゃ「このデータ様は、有効であったり正当であったり妥当であったり確実であったりするのでございましょうか?」という判断基準がまぁ色々あるので。
その辺の、個人的な整理とか個人的なmemoとか個人的な備忘録とか、その辺を書いておこうかなぁ、と思います。
以下読んでもらえればわかると思いますが、「ナニをもってvalidとするか?」ってのは、結構な確率で「業務要件に直結する」ので、システム的な視点に加えて「発注者という意味合いでのお客様目線」を忘れずに、厳しくも優しいvalidatorを書いていきたいものでございます。


ってなわけで、業務的に割とあるんじゃないかなぁ? と、おいちゃんの鶏頭が記憶しているあたりを、つれづれっと。

必須チェック

これはまぁなんていうか基本中の基本。
PHPの場合、$_GETないし$_POSTに
・そのkeyがあるかどうか(issetないしarray_key_exists)
・値が空っぽではないか
の2つのチェックになることが多いと思うざます。


ちなみに文字列の場合

if(false === isset($_GET['hoge'])) {
  return false;
}
if('' === $_GET['hoge']) {
  return false;
}

なんて書き方をすると「じゃぁ半角スペース1文字入れて」とかやられるのが嫌ならせめて

if(false === isset($_GET['hoge'])) {
  return false;
}
if('' === trim($_GET['hoge'])) {
  return false;
}

なんて書き方をして「じゃぁ全角スペースで」ってあたりからイタチごっこの始まりになるざますので、その辺は「なんで必須にしたいの?」ってあたりを、お客様にヒアリングしてみましょう。
ちなみに「全角スペース」についてはmb_convert_kana()のオプション's'で片付けますが、そうすると次は「abc」とか突っ込まれるので B-p


あと。if文をわざわざ分割しているのは「後で初心者に教えるのに都合がいいから」ってダケなので。
「orの左辺がtrueなら右辺は評価されずにifん中に入るよねぇ、って発言がPHPでは使えるよね」って単語が違和感なく理解できるレベルの御仁におかれましては素直に

if((false === isset($_GET['hoge'])) or ('' === trim($_GET['hoge'])) ) {
  return false;
}

とか記述いただければ幸いでございます。
あと「左辺値と右辺値の云々」については「おいちゃんはヨーダ記法応援委員会メンバーなので」ってことで以下略。

数値チェック

正規表現とか色々ありそうなのですが、PHPならおいちゃんはfilter_var()を強くお勧め。
整数オンリーならFILTER_VALIDATE_INT、小数点数ありありならFILTER_VALIDATE_FLOAT。
filter_var()で上述のVALIDATEフィルタ使うと、文字列渡しても、戻ってくるのがintないしfloatになるんで、その点は留意しませう。
後は「負の値の許容度合い」によって確認をしておきたいのと、特に整数をちゃんとintで扱いたい場合、丁寧にいくんなら PHP_INT_MAX 以下であることを確認しておくと、より「心安らかに」いけるやもしれませぬ。

ページ数

いやまぁ丁寧に考えるんなら色々あるんですが、ぶっちゃけるとおいちゃんはこんな風にしてまふ。

$page_num = abs((int)$_GET[ページ数が入ってるパラメタの名前]);

「何が何でもint」でがっつりいくんなら、こんな雑コード。

$page_num = (int)(abs((int)$_GET[ページ数が入ってるパラメタの名前]) % PHP_INT_MAX);

いやまぁ「n Page以上にはなり得ない!」って数値決め打ちしてもよいのですが。実際その手のってコケる可能性高いし、実際これで「でかい数字」入ってきても困らないケースのほうが多いと思うので、こゆのは割と「雑に」validationしたりしまふ。


この辺、validationってよりは、「無毒化」って意味合いにおけるsanitizeに近い概念のような気もいたしますが。
いちいち「エラーで突き返す」のも面倒な気がするので、「強制的に揃える」でもいいんじゃないかなぁ? と個人的には思ってたりします。
もしその辺がお嫌で「丁寧にエラーを返すべきである!」って場合、filter_var()で判定しておくと幸せに過ごせるのではないか、と思います。

金額

ページ数準拠以上終了(笑
いやだって「負の値」を許容するケースは少ないし。
許容される場合、abs外してくらはい。
「金額」系は「むりしゃり揃える」と些か困るケースもあるので、「filter_var()で判定」をチョイスして「駄目ぽいならerrorでつっかえす」ほうが、より適切やもしれませぬよし。


あと、金額の場合「int無理だったからfloatで」は、浮動小数点数型における誤差の問題あたりに起因する理由で「はげしく」お勧めいたしませんので、特に経理系とかで「お金扱う」システムのときは、諸々、ご注意くださいませ。
四則演算など些か手間ではございますが、「全面的に GMP関数 使う」ってほうに振り切ってみるのもひとつの考え方なのではないか? と存じます。

郵便番号

雑に考えるなら「数字3桁」「空白またはハイフンのどちらか1つが、あるかないか」「数字4桁」というフォーマットで確認。
ぶっちゃけ「正規表現のお勉強にちょうど良い」レベルのvalidateが可能で、学習にも最適でございます。


少し踏み込みますと「つい間違えて数字とかハイフンとか空白が全角に」ってあたりに対応して、予めmb_convert_kana()で整えておく方法が、状況とサイトによっては有効です。
ただ、ハイフンは「長音(ー)」になってくることも多いので、考察とテストはしっかりとしておきましょう。


更に踏み込むと「実在チェック」のvalidateを望まれるケースが、実際にございます。
その場合は「郵政省もとい日本郵政グループが出してる郵便番号情報」をどこかに持っての実在確認となりますが、メンテナンスが色々と鬼大変でございますので、その辺しっかりと「おかくご あそばせ」状態になります。


参考)
http://www.post.japanpost.jp/zipcode/download.html (郵便番号データダウンロード)
http://www.post.japanpost.jp/zipcode/dl/readme.html (郵便番号データの説明)
http://d.hatena.ne.jp/gallu/20080310/p3 (■[その他技術]郵便番号にまつわるエトセトラ)


この辺り「どれくらい厳密に郵便番号が欲しいのか」っていう業務要件に結構直結しますので、お客様にがっつりヒアリングして「どする?」って確認をとるとよいでせう。

電話番号、FAX番号

実在を確認するわけにもいきにくい、厄介なものでございます。
とりあえず
・市外局番は2〜5桁の整数
・市内局番は1〜4桁の整数
・加入者番号は4桁の整数
・「市外局番+市内局番は6桁(なんだけど携帯だと7桁)」
ってルールが以前にあったように思うのですが、現状どうなってるか不明。よかったら誰か突っ込んで下さい。


なので、まぁだいたい「そんな感じの文字列」ならvalid、って程度の実装が現実的かなぁ、と思うのです正直。

日付

月と日は割と簡単にvalidateが出来る…のですが、もし「年情報がない」場合、「2月29日」をどうするか、だけ、決めておきましょう。
年情報がある場合には楽なんですが…じゃぁ「西暦0年はvalid? invalid?」ってのと、「西暦9999年は?」ってあたりの「上と下の数値限界」が横たわります。
この辺割と気付かないのですが気付いたときに引っかかると面倒くさいので、悩んでおきましょう。
PHPの場合、checkdate()関数が割と使い勝手がよくて。「閏年を判定してくれる」ほかに、関数の仕様として「年は 1 から 32767 の間となります」って決め打ちをしてくれているので。
お客様に「特段の事情と理由がありましたら別途実装いたしますが、差し障りがなければ、PHPが提供している標準関数ですし、素直に長いものにまかれちゃいませんか?」って辺りをオブラート20枚くらい包んだ上にお砂糖とか振りかけたような「丁寧な」提案で進めていけると、色々と楽ができます。
なお、渡す引数は「事前に数値かどうかチェック」してもよいのですが、どのみち「0が入ってきたらエラー」なわけですし。「intでキャストして揃える」くらいの雑さでも、今のところ特に困った事はないように記憶をしています。


後は。
業務要件によって「明らかに未来日付である必要がある」「過去じゃないとおかしい」「この100年間の出来事だからもっと時間帯を絞れる」などの状況があり得ますので、その辺はお客様及び該当サービスの性質内容対象顧客などを鑑みながら、適宜、幅を狭めていくとよいと思われます。

年齢と誕生日

validateで、割と悩み出すところのひとつです。
ん…実話。
「整数二桁、っていうvalidateをしていたら、100歳のユーザから"登録できねぇ"ってクレームが来た」。
割とおっかないことに実話です。


とりあえず「整数ではない」「負の値である」は確実にinvalidなのですが…じゃぁそれ以降どうするか。
上限と下限を決めるのが、割と面倒です。
上限についてひとつあり得るのは「ギネスの記録にある122歳」なのですが、じゃぁ「ギネスをチェック、更新されたらシステム改修するかね?」って話になって、微妙に嬉しくない感じでございます。
下限についても厄介で、昨今2歳児が普通に「スマートフォンいじってる」風潮ですと、果たして「おいくつまでならvalidなんだろう?」という。
なので、おいちゃんは割と面倒なんで「とりあえず0〜200歳、くらいにしときません?」って話をしますが、最近、一部の研究では「寿命を5倍に増やせる可能性」とかいうお話に従うと500歳くらい?
まぁ「とりあえずこの5年10年じゃ手が届かんだろう」程度の数値にしておくと、とりあえず気楽なんじゃなかろうか? と思いますが、あとは業務要件次第。
年齢が「すげぇ重要」ならそれこそ「年齢確認」から入るべきでしょうし、そうでないんなら「まぁ気にスンナ」でいいようにも思います。


下限の場合、ひとつ重要なのが「本サービスは12歳未満は登録不可」とかいう規約がある場合、当然ながら「11歳はinvalid」なので、この辺も露骨に「業務要件直結」なので、しっかりとヒアリングしておきましょう。


誕生日についてはとりあえず
・過去日付であること
・あとは気にスンナ
がベース。
誕生日が「未来日付」は流石にあり得ないのでinvalid(いやタイムマシンが開発されたら変わりそうですが)。
どれくらい過去か? については「年齢の上限」と一緒。で「わざわざ計算する」手間を入れる必要が、あとは、あるかないか。


「年齢の下限」があるサービスの場合は「計算して、0歳とかならinvalid」…なんだけど、ここ、実は落とし穴があるので注意。
簡単に計算する場合「今日の日付を数字8桁 − 生年月日の数字8桁 / 10000(端数切り捨て)」で、大体求まるのですが。
普通のサービスなら、まぁ「規約に書いておく」とかして、これでもよいかも、なのですが。
これが「法務とかに関わる」お堅い系の場合、「年齢算出の方法」については、しっかりと聞き出しておいたほうがいいです。
http://www.shugiin.go.jp/internet/itdb_shitsumon.nsf/html/shitsumon/a154154.htm

わが国では、「年齢のとなえ方に関する法律」に基づき、昭和二十五年以降数え年による年齢計算を止め、満年齢によって年齢を計算している。しかし、この満年齢の考え方について、国民の常識と法律上の取扱いとの間、さらには各法令相互の間において、齟齬や混乱が見られるように思う。

的な。
http://ja.wikipedia.org/wiki/%E5%B9%B4%E9%BD%A2%E8%A8%88%E7%AE%97%E3%83%8B%E9%96%A2%E3%82%B9%E3%83%AB%E6%B3%95%E5%BE%8B
この辺も参照。


この辺があるので。
「年齢がvalidである、ことを保証するための生年月日のvalidation」は、色々と気をつける箇所が増えるので…逃げられるときは逃げましょう(笑

チェックボックスとかselect/radioボタンとか

ホワイトリストで存在チェック以上終了。
後は「listが増えた時」に、出来るだけDRY( http://ja.wikipedia.org/wiki/Don%27t_repeat_yourself : 1つの変更は1箇所の変更ですむように )になるように近づけるように心がけましょう。

文字

世の中の全ては数値でなければ文字なので、すべて文字です以上終了。
…で終わっても仕方が無いので。
真面目に考えると、文字のチェックでよくあるのが「文字長」で、ここが多分色々と引っかかったりするので、そこを軽く。


文字長には、少なくとも「3つの」意味合いがあって、そこが混在している上に「なんで文字長を制限したいのか?」によって状況が変わるので、その辺りをしっかりと意識しながらvalidationしていくとよいでせう。


ひとつが「システム上、バイト数制限がある」ようなケース。
PHP的にはstrlen()関数を用いて「バイト数」で確認をしましょう。


ひとつが「業務要件上、文字数を制限したい」ケース。
ん…実際あったのが占いのシステムで「質問者の質問は500文字以内」「占い師の返信は1000文字以上」ってなケース(文字数はバミってます)。
別口だと、twitterの「140文字」が、このチェック方式。
この場合は「1つの文字を1とカウント」なので、mb_strlen()を使ってvalidateしましょう。
「プリンタブル(printable)ではない文字、及び空白は文字数に含まない」的なカウントをするケースもあり得て、上述だと「占い」の時はそういうチェックをしていたので(そうしないと、困った占い師さんが「スペース大量に使って文字数を埋める」とかってケースがあるのを懸念されていたので)。
その辺もかなりガチに「業務要件に密接に影響する」ので、しっかりと確認をとるようにしましょう。


最後が「表示上の文字幅を制限したい」ケース。
厳密には等幅フォントではなくプロポーショナルフォントである事も多いとは思うのですが、とはいえ、特にデザイナーさんが、HTMLっつかCSSを組む時なんかに、結構この辺を気にされます。
「ここの値でこれ以上の幅になるとレイアウトしゃれになんねぇから断じて許すまじ!」って方向のチェックで、デザイン性を大切にするような業務要件だと、急激にこのニーズが増えます。
この場合はmb_strwidth()を使ってvalidateして、「デザイン的に許容範囲の幅であろう」という正しさを追求してくださいませ。

文字コード

いやまぁ別にどんな文字コードでも基本問題はないのですが。その文字コードが問題の無いものであれば(具体的にはsjisutf-7は滅べ)。
それ以外に、いくつか「半端な先行バイト問題」とか「非最短形式のUTF-8」とかがあるので。
これはどちらかというと「エラーならはじく」よりは「揃えちゃう」ほうが楽なので、mb_convert_encoding()で一度「文字コード変換」しておくと良いと思うです。
例えば「HTML(から入ってくるデータ)がUTF-8」で「内部の文字コード想定がUTF-8」だったとしてもなお、「UTF-8からUTF-8への変換」ってのをやっておくと「変なのが一通り削られたりして」出てくるので、色々と気軽なんでやっといたほうがよいと思われるです。


この辺もまた、「無毒化」って意味合いにおけるsanitizeに近い概念のような気のする処理ではありますが、やっておくと色々と、心が安らかになる事が多いです。

名前とかハンドルとか

一個あるのが「重複チェック」なのですが…最近減ったなぁ。
後は「長さ」くらい?
「半角スペースのみ、は認めない」とかも割合あるので、文字種について軽く確認をしておくとよいです。

お名前とかででてくる、ひらがな縛りとかカタカナ縛り

以前に書いたので、リンク使って省略(笑
■[PHP]カタカナをvalidateしてみる
http://d.hatena.ne.jp/gallu/20150111/p1


ひらがなの時の「長音(ー)」が抜けやすいような気もするのでお気を付けて。

個人的には「カタカナって書いてある箇所にひらがなを入れた」ら、それくらいはmb_convert_kana()で揃えてあげりゃいいじゃん、って思うんですが、どうなんですかねぇ?
半角カタカナもおいちゃんは「システムで揃えて」全角カタカナにしちゃうほうです。
お客様に提案して「それは嫌だ」って言われた事ないんで、そーゆー方法もあるでよ、って事で。

全角文字縛り

たまに見ますが「使いにくいことおびただしい」のでやめましょう。
なので、考察もすっとばします(笑

フリーな文章

ここについてはもう「なんでもどうぞ」としか言えない。
明らかにSQL-InjectionやXSSを誘うような文字列だったとしても、それが例えば「掲示板に"こういう入力がきたらクラックされちゃうよ"っていう警告を書いた」ものであるのなら、文字列としてはそれを「invalidである! 反逆である!」とは言いにくいものがあろうかと思うので。
なので、ここについては「ナニをもってvalidとするかね?」ってのが難しいので、基本、文字長くらいしかみません。


が、ひとつ業務要件としてちょいちょい出るのが「NGワード」の類い。
「このあたりの単語は非常にふさわしくなく好ましくないので、書き込みできないように」なんてお話は、まぁちょいちょいあります。
なので「NGリストを用意」「strpos()ないしstripos()で検索」「ひとつでも見つかったらinvalidってことでエラー」って実装を見かけるのですが。
これをやると、やまもといちろうさんが「不適切な名前です」って言われてゲームが出来なくなったところをBlogで晒されたりします(笑
http://kirik.tea-nifty.com/diary/2014/07/gmo-a7df.html
とりあえず「最後の3文字だけ」切り抜いて適宜ググったりしていただけますると、理由と意味が見えてくるのではないかと思われますがこれ以上は私の口からはとても…。


閑話休題


まぁNGワードは本当に難儀ぃなので「明らかにアウト」な文字だけとは限らないんですね。
なのでおいちゃんは
・レッドカードリスト:含まれてたら一発アウトでinvalidなので突っぱねろ!
イエローカードリスト:含まれててもとりあえずinvalidにはしないけど運営側に自動で連絡がいくので後はマンパワーで確認してやばきゃハネてね
っていう2段構えで実装を提案することが多いです。


あとはまぁ「明らかにNGなワード」にちょっと小細工をしてみるケースとか。
例えば「NGワード」がレッドカードリストにあるとして、ありがちなのが「N Gワード」とかスペースで回避。
これをブロックすると、極端な話例えば「たぬきでNたGたワたーたド」とか、まぁどうとでもなってしまうので、あんまり深追いしても疲れますが業務要件的に重要な事もあるので、しっかりとお客様とのお打ち合わせを擦り合わせていきましょう。


掲示板系で電話番号なんかですと「全角数字」はおろか「漢数字」とか「ひらがな(ぜろ いち にぃ さん)」とか、その混在とか、まぁ色々と手口が広がるので。
運用コストと相談しつつ「ナニをもってvalidとし、ナニをもってinvalidとするか」という部分の丁寧な調整と設計と実装と変更と追記は、重要なポイントなのではなかろうか? と推測いたしまする。

IPアドレス

filter_var()でFILTER_VALIDATE_IP。
IPv6すらチェックできるという仕様なので、大変に便利すぎて乱用必須のレベル。


後は例えば「Cクラスのみ」とか「プライベートIPアドレスは刎ねたい」とかってニーズがあるのであれば、適宜、チェックしませう。
…で、注意点。
IPv4の場合とか、ip2long()やPEAR::Net_IPv4()を想起するケースもあろうかと思うのですが。
この辺、PHPのINTの仕様で「時々困る」ケースがあって。
具体的には、ip2long()の場合「環境によっては負の値がreturnされる」とか、PEAR::Net_IPv4()の場合は「PEAR::Net_IPv4::ip2double()はIP アドレスを PHP の倍精度数に変換する」とか、色々。
以前、その辺に「イラッ」として、ついこんなモンを作ったけど後悔はしていない(笑
https://github.com/gallu/MagicWeapon/blob/master/ip_util.inc


まぁこの辺も、丁寧にチェックしたい場合は気にするようにしておきましょう。

ドメイン

結構幅広い「validation方法」が考えられますので、ちぃと丁寧に。


まず最低限「使っていい文字種」の確認で、ここで駄目なら確実にinvalid。
使っていいのは「英字、数字、ハイフン、ドット」。最近、実務の仕様書だかソースコードだかに「アンダースコア」って書いてあるのみてずっこけた記憶がありますので、皆様におかれましては是非お気を付けくださりませ。
あとは「ドットの連続はNG」とか「先頭は英字」とか「ドットで区切られてるラベルのおけつがハイフンは駄目よ」とか。
日本語ドメインは面倒なんでオミット。


ここからが「どこまでやるの?」ってお話。
まず文字長。RFC1035(より新しいのなかったっけ?)を真面目に捕らえると
・ラベル(ドメインの、ドットで区切られたうちの1パーツ)は63文字以内(正確に書くんなら63オクテット以下)
・ドットを含む全体として255文字以内(正確に書くんなら255オクテット以下)
になるのですが、まぁこれをどれくらい丁寧に考えるか。
ただここは「実際にもうちょっと長くなっちゃった」っていう状況は考えにくいような気もするのですが、どうなるんでしょうねぇ?
「大丈夫がっちがちだよ」って人はこの数値で、「世の中って動くからねぇ」って思う人は、もうちょっと長めで確認をすればいいんじゃないでしょうか。
「かっちり」実装した場合は、定期的にRFCとかをチェック、数値が動いたら「ちゃんとメンテナンス出来る」準備だけはしておくとよいでしょう(営業的ネゴシエーションを含めて)。


次に「そこまでやれば」ってのが実在チェック。
「文字列として書式があっている」と「そのドメインが実在している」には大きく乖離があるのと、でも大体どっちも「validなドメインである」という言い方をして、意味合いが混ざる事が多いので。
「書式があってればいいのか」「実在を確認する必要があるのか」を、確認しておくと、よいvalidatorが書けるでしょう。

メアド

はい業務要件で「よく出てきて」「一番死ねる」ブツです。
先に晒しておきますと。googleさんあたりで「PHP mail 調べる」あたりで上位に出てくる
正規表現:メールアドレスかどうか調べる( phpspot.net/php/pg%E6%AD%A3%E8%A6%8F%E8%A1%A8%E7%8F%BE%EF%BC%9A%E3%83%A1%E3%83%BC%E3%83%AB%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E3%81%8B%E3%81%A9%E3%81%86%E3%81%8B%E8%AA%BF%E3%81%B9%E3%82%8B.html )
・かなり使えるPHP正規表現まとめ( www.ideaxidea.com/archives/2009/03/practical_php_regexs.html )
・メールアドレスの書式が正しいかチェックする正規表現( blog.pinkmonky.net/detail/?id=45 )
あたりの正規表現を使うと………


phpspotの人は正規表現について語らないほうがいいのでは( http://developer.cybozu.co.jp/akky/2007/10/phpspot-bad-regex/ )
正規表現のサンプルが更新されていた( http://d.hatena.ne.jp/elf/20090323/1237742585 )
PHP使いはもう正規表現をblogに書くな」と言わせないでくれ( http://blog.livedoor.jp/dankogai/archives/51189905.html )
さっきPHPerの正規表現を見たが、本当に唖然とした。Disりたい…( http://webkit.seesaa.net/article/129745981.html )


などというお話の渦中に突入する可能性があるので、熟考の上「使うか使わないか」を決めるとよいでしょうっていうか使うの辞めた方が多分身のためよ?
ちなみに「間違えているほうのPage」のhttp://を削ってるのは当然ながら「これ以上googleで上位に上がってくれるな」という強い主張に基づくものです。


さて上述を踏まえまして。
ひとつ、PHPには有難い関数がございます今回使用頻度高いなぁfilter_var()でございますこちらのFILTER_VALIDATE_EMAIL。
非常に丁寧につくられておりまして、かなり頓狂なアドレスでも適切に「RFC的にvalidかどうか?」を判定してくれます。
「じゃぁこれでイイじゃん」と言えればよいのですが…日本の、いわゆるガラケーのメアドに「RFC非準拠なアドレス」がありまして、その辺が大変に邪魔臭ぉございます。


docomo
http://ke-tai.org/blog/2009/04/03/docomorfc/
http://www.rbbtoday.com/article/2009/04/03/59059.html


AU
http://ke-tai.org/blog/2009/09/25/aurfc/


ちなみに余談。
http://www.snow-flake.jp/%E3%80%8C%E3%83%A1%E3%83%BC%E3%83%AB%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E3%81%AE%E4%BB%95%E6%A7%98%E3%82%92%E5%A4%89%E6%9B%B4%E3%81%99%E3%82%8B%E3%81%A4%E3%82%82%E3%82%8A%E3%81%AF%E3%81%82%E3%82%8A/
なんていうか「滅べ」。


さてまぁこんな「素敵な仕様を考えやがりやがった馬鹿どももとい御方々」のおかげで、filter_var()が使えませんコンチクショー。
じゃぁどうする? ってあたりで、後は考えてみてください…ってのも雑なんで、ざっくり「我留流(おいちゃん流)」を。
http://d.hatena.ne.jp/gallu/20141120/p1
にもありますが
・domain-partは、ドメインの仕様に従ってチェック
・local-partはあきらめて「文字があればいいや」
程度。
ざっくりの極みでございます。
実装例、こちら。
https://github.com/gallu/MagicWeapon/blob/master/is.inc
のis_email()。


で…最大のポイント。
ドメインでもちょろりと書きましたが、メアドのvalidateって「書式があっている」と「実在している」の2つのニュアンスがあって。
で、emailの場合特に「実在している」のほうにニュアンス的重きを置くケースが圧倒的に多いんですね。
今時のSMTPサーバでVRFYコマンドが通るような設定がありゃいいのですが、550以外が帰ってくるSMTPサーバ、どれくらいあるんですかねぇ? 正直。
いや、あるんなら「ドメインのMXレコード引いてAレコード引いて、local-partはVRFYコマンドで確認」すりゃ、実在確認取れるんですがね。


現実問題、実在確認をするのであれば、実際に「emailのやりとり」が必須になるので、かつ、業務要件的に「書式があっていること」ではなく「実在すること」がvalidな条件である、というケースは「極めて多い」ので。
そうするとやり口としては
・こちらで用意したemailアドレスに空メールを送ってもらう
・送られてきたmailのFromからメアドを抜き出す
・Fromのメアドに「token付きのURL」付きのmailを返す
・ユーザが「token付きのURL」をclickする
・実在を確認する


か、或いは
・メアドを入力してもらう
・メアドに対して「書式が適切か?」のvalidationを行う
・入力されてvalidなメアドに「token付きのURL」付きのmailを返す
・ユーザが「token付きのURL」をclickする
・実在を確認する


って流れにならざるを得ないわけですな。
やれやれ。

まとめ

なんか「ふと思いついた」から書いた割にはすげぇ量になりました。
ぶっちゃけますと推敲していないので、typoとかの可能性もありますし、ナニカが抜けている可能性もあります。
その辺、突っ込みをいただけるときっとこの原稿の精度があがるので、お気づきの方におかれましては突っ込んでいただければ幸いです。
おいちゃんも、自分で気付いたら追記とか(日付入りで)書きます。


「ふと思いついた」んで書いた、にしてはえらいこと分量が増えましたが。
なんかの役にでも立てば幸いでございます。

bashのインストールメモ

超絶ただのメモw
普段なら手元において終わり、なんだけど、もしかしたら参考にする人が、全世界で一人くらいはいるかもかなぁ、と思ったのでw


先に。
お手元のbashのバージョンを確認しておきませう。

bash --version


もしこれで4.3.0よりも「古い」んなら、持ち上げておいた方がよいかもしんまい。
おいちゃんはyumとか使わない子ちゃんなので、tar ballでコンパイルすますた。

cd /usr/src/
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
tar zvxf bash-4.3.tar.gz
cd bash-4.3
echo "./configure --prefix=/usr" > ./bash_ccc
sh ./bash_ccc
make -j 3
sudo make install

タダのメモなんで色々垣間見えるものがありますが、適宜アレンジなどしてくださいませ。