「curl」を含む日記 RSS

はてなキーワード: curlとは

2018-05-24

anond:20180524113936

そうじゃなくて、プログラマ美徳的な話をしている。

だってキーボードをたたき続ければいつかはシェイクスピアが書けるが、プログラマシェイクスピアを書くためにはcurlシェイクスピアの原文が書いてあるソースダウンロードするだけでいい。

そこをがんばってソース上にシェイクスピア文章を書こうとしたりすることを、我々からすると「無駄コード」という。

最小の努力で最大限の効果を生み出せるように努力しんさい。努力しないでいい努力を。

2018-04-24

anond:20180424104238

んでも今ワイが使ってるAWSインスタンスから普通にcurl打つくらいなら疎通するし、DNSで弾いてる以外のことはしてないと思う。

多分googleDNSフィルタリングしてんだな。

2018-01-31

anond:20180130221601

一番最初Homebrewを落としてくるときなんだけど、素のOSX LoinのcURLを使ってHomebrew用のcURLを落とす過程で、セキュリティ接続エラーが起きてるみたいだ。

困らないケースって、その人がHomebrewを導入したタイミングではまだレポジトリが高いセキュリティ要求してなかったとか、

あるいはFinkMacPortsから移行する場合、新しめのOpenSSLcURLを入れていたかセキュリティ接続ができたんじゃないか、と思う。

とにかく、素のLioncURLHomebrewcURLを落としてこれない。セキュリティ証明書問題かもしれないが、そのあたりはよく分からいからなんかもういいってなってる。

なんせ、brew doctorはLionってだけで警告を出すし、どうも10.8以上が推奨環境じゃなかろうかと。

2018-01-30

HomebrewMacPortsかってやつ

最近事情ではOSX lionまではMacPorts一択ってことでいいんだろうか。

Homebrewインストール段階で、Curlの7.58.0が入ってこない。opensslパスを通しておいても、結局いろいろダメ

MacPortsだとCurlがちゃんと入る。

2018-01-25

WindowsでPython2系でUnicode

最悪な組み合わせだということに気づいた

64bitだから入れたAnaconda(というかSpyder)は

コンソールなりエディタなりどこかしら化けるし

でもまたPyCharmで頑張れるほど元気はないし

もうUnicode扱うときはRでいいかな…

RはRでcurlうまいこと扱えなくて禿げそうなんだけどさ…

2018-01-03

Qiita無能を見分けるたった一つの方法

hogehogeの紹介

hogehogeの使い方を紹介します。

インストール

まずはインストールします。

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

2017-05-02

マストドンAPI

マストドンリポジトリ

ttps://github.com/tootsuite/mastodon

マストドンAPIリファレンスAPI実装済みのライブラリ(サードティ)の紹介

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md

マストドンAPIに関するドキュメントが置いてあるディレクトリ(色々ある)

ttps://github.com/tootsuite/documentation/tree/master/Using-the-API

マストドンアプリ認証にdoorkeeperを使ってるので認証APIはこっちを参照する必要がある

ttps://github.com/doorkeeper-gem/doorkeeper/wiki

マストドンドキュメントで紹介されてるAPI実装済みのライブラリ(サードティ)を使うのが一番ってっとり早い

以上

=====

わざわざ自前でAPIを叩くコードを書く

step1

アプリマストドンサーバー登録する

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#apps

POST /api/v1/apps

必要データをPOSTするだけ、難しくない

アプリ登録をわざわざコーディングする場合ライブラリとして作って提供する場合くらい(?)

(アプリ複数インスタンス対応させる場合はやはりコード書くしかないけど)

(登録したIDを自前サーバーで持って同一アプリで共有するとか?)

別にhtmlフォーム作って送信するだけでも登録できる

(ローカルhtmlファイル作ってブラウザ表示して必要入力してsubmit送信するだけ簡単)

<form name="regsterapp" method="POST" action="http://SERVERNAME/api/v1/apps">

<input name="client_name" type="text" value="">

<input name="redirect_uris" type="text" value="urn:ietf:wg:oauth:2.0:oob">

<input name="scopes" type="text" value="read write follow">

<input name="website" type="text" value="">

<input type="submit"></form>

step2

ユーザに対してのアプリ認証

doorkeeperについて知る必要がある

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

このページに書いてあるgrant_type=password認証法ではread権限しか貰えないぽい

grant_type=authorization_codeで認証する必要がある、これ読めば早い

ttps://github.com/doorkeeper-gem/doorkeeper/wiki/Authorization-Code-Flow

GET /oauth/authorize

必要パラメータ(※1)つけたリンクアプリ認証したいユーザに踏んでもらい許可を押してもらった上でそこで表示されるコード(RETURNED_CODE)を使う必要がある

(自前サーバーなどでリダイレクトで受け取ることもできるけど)

その表示されたコード(RETURNED_CODE)を使って次のAPIを叩くと認証完了する(アクセストークンをゲットできる)

POST /oauth/token

これもただのPOSTになるのでそんなに難しくない

さっきのアプリ登録みたいにhtmlとかで簡易にもできるけどアプリ秘密キーを使うので公開はダメでしょうな

※1

ttp://SEVERNAME/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&scope=read+write+follow

scopeというパラメータで取得したい権限指定する必要がある

step3

認証終わってアクセストークンをゲットしたらもうAPI使えるので

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

これの2番目に書いてあるようにHTTPのヘッダに Authorization: Bearer ACCESS_TOKEN を加えてから

APIの叩けばよい

toot(トゥート)はAPIドキュメントではstatusという表現になってる

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#statuses

POST /api/v1/statuses

がtootするためのAPI

2016-12-25

Sophos Homeman-in-the-middle attack を受けた

結論: Sophos Homehttps通信を乗っ取ってhttpで返してくる

2016-06-29

anond:20160629135046

右も左も分からんかったのと、python勉強たかったんで、

pythonによるウェブスクレイピング」っていう本読んでるんですよ

curlでもスクレイピングできるんすね。

curl自体初めて聞きました

簡単クローリングなら、curlの方がいいってことですね

本に従ってbeautifulsoap使ってますそれから本の内容的にデータ分析のためにmysql使い始めました


将来的には、クロールしてデータかき集めて、自動取引なんぞに取り組みたいと思ってまして。

からmysql使うのなれとくもいいんではないかと思ってます

素人判断なので、間違ってたら教えてください

2016-04-26

anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、アプリ認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げますさらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。

セキュアでないトークン

トークンベース認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなもの設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分プラットフォーム自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。

トークンベースシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的スクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。

もし生成されるトークン予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまます。筆者は、fortune 500 クラス大企業による OAuth ベースサービス一種の単調増加 ID (おそらくデータベースフィールド?) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在トークン ID を見て、その後の ID を予測すれば、続く任意ユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。

このクラス攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意OAuth ベースサービスが外部レビューセキュリティを証明してもらえる可能性はあまり高くありません。

本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通実装における」OAuth がよくやる使い方ではサーバ信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。

一方、一部の OAuth ベース実装乱数必要性クライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。

クロスサイトリクエストフォージェリ (CSRF)

本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクユーザが貼れる、掲示板メッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法CSRF に立ち向かうべく設計された数々のテクニックフレームワークがあります。これらのシステムの多くは、OAuth ベースのもの統合すると使いものにならなくなったり、サイト攻撃さらしかねない行為を促すことがあります

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装ユーザ特定の外部サイトから連れてくるよう要求しまから、この防御策は執行できません。OAuth サーバリダイレクトする膨大なサードパーティドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要がありますOAuth の背後にある原則ひとつOAuth ベースサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています理想認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的ホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能オンオフ中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者CSRF 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ CSRF トークン指定するようにと、オプショナルな state パラメータ定義していますしかしながら、OAuth ベースサービス一般的state の長さや文字種を制限し、要求どおりそのままでさないことがあるようです。そこで、おかし互換性問題が起こるため、多くの OAuth ベースサービス利用者リダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されていますstate パラメータの別の懸念は、EVS 側で stateアクセスのある人はだれでも、リクエスト改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。

OAuth ベース API の利用者は、自分アプリサービス登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的危険の伴うアイディア姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効パラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険ものstate パラメータに詰めこもうとし始めたり、浅薄システムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザ不適切なページに誘導する危険性が出てきます。これは「10.15. オープンリダイレクト」に分類されます

こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザ大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通実装における」OAuth の低品質設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベース利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています

ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります

章のまとめ

セキュリティに関して言えば、「普通実装における」OAuth仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースサービスの中には、種々の攻撃に対して無防備でいることを利用者公然要求するものがありますサービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要セキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質プログラミング習慣を招いていますOAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティ提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。

この記事についていえば、個人的蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所OAuth に使っているのを見たまま開発者コピーした結果というものもあります

OAuth ベースサービス開発者もその利用者側の開発者も、OAuth ベースプラットフォーム実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラス攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装仕様書セキュリティガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルセキュリティを実現することはできません。

真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます

ユーザビリティ関連

(略: ふつう実装では、サービス側がプラグを引き抜くようにして自由利用者出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)

(略: サービスからは API 利用者という大きすぎる単位しか見えないので、たとえばビデオカメラアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位対策としてユーザ開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)

(略: ふつう実装SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリcURL 的なもので API を叩こうとしても、JavaScript必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新メタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバlocalhostで立てるとかアホか。)

(略: オープンソースしづらい)

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる

2015-04-15

FedoraSkypeを入れるのが簡単になった

基本的にはFedoraを気に入っているのだが、

Skypeflashなど一部ソフトの導入手順の面倒さがネックだった。

この辺りがUbuntuLinux Mintでは簡単で羨ましかったのだが、

fedyというソフトを使うことである程度は解決できるようだ。

http://satya164.github.io/fedy

fedyは手順の面倒な設定やインストールを簡単にするソフトのようで、

導入は次のようにすれば良いよう。

※fedy-installerはただのシェルスクリプトで、後で消して問題ない。

curl -o fedy-installer https://satya164.github.io/fedy/fedy-installer
chmod +x fedy-installer
sudo ./fedy-installer

Skypeインストールは次のようにする。

sudo fedy -e skype_linux

skype_linuxはタスク名前で、Flash場合はadobe_flashLight Tableの場合light_table、Sublime Text 2の場合sublime_text2といった具合。

GUI版のfedyがイケてない気はするけど、

とりあえずSkypeインストールできてよかった。

2015-04-07

curlの-cと-b

curlコマンドが非常に便利で、最近はよくお世話になっている。

しかし、-cと-bどちらがcookieの保存なのかcookieの送信なのかで混乱し、

何度か「bはbakeの略な気がするから多分…」といった勘違いミスを起こしてしまった。

※保存するのは-c(--cookie-jar)、送るのは-b(--cookie)

長いオプション名のほうが比較的混乱しにくいので今のところはそちらを使うようにしているが、

短いオプション名の由来が分かればそちらを使いたい…。

2015-03-10

http://anond.hatelabo.jp/20150310162715

スノーデンがNSAハッキングを行った方法っていうのが「curl使ってぶっこ抜いたwwww」だからな。

内部関係者ローカルネットならそういうこともありえる…とも技術者なら考えちまうんだけど、常識的に考えると「ないわwwwww」なんだよな。

ただ、「シークレット情報ぶっこぬいたったwww」って言葉はすげーきょうりょくなハッタリだから信じてしまいそうになるが。

2014-12-27

アマゾンってShift_JISだったんだ

curl -I www.amazon.co.jp
HTTP/1.1 200 OK
Date: Fri, 26 Dec 2014 18:15:41 GMT
Server: Server
Set-Cookie: skin=noskin; path=/; domain=.amazon.co.jp
pragma: no-cache
x-amz-id-1: 1JV2AXRHPS0QYM1FAPZY
cache-control: no-cache
x-frame-options: SAMEORIGIN
expires: -1
x-amz-id-2: qJ/Gs9U7frPN5clBOBuyeTM+Ds4AMVEf90iZNjMT88NxGQe0+XqAaZQNIZH6LQjU
Vary: Accept-Encoding,User-Agent
Content-Type: text/html; charset=Shift_JIS

2014-12-22

advent calendarに、他人記事をコピぺする行為について。(追記あり)

すこし前、go advent calendarの遅延投稿について話題になりましたね。

go advent calendar↓

http://qiita.com/advent-calendar/2014/go

私自身、AC自体責任を持って記事を書けとまでは求めていません。楽しく記事を書くのが一番ですから書けなかったり、遅れてしまっても仕方がないと思います

ただ、遅延投稿した彼がとった行動が到底理解し難いものでした。

彼の記事-gobrewでバージョン管理(追記あり)

http://qiita.com/7yan00/items/916d5804f0397f9af272

qiita記事を読む限り、自分で書いたとの内容がありますね。

gobrew - 複数バージョンGoも簡単に管理、切り替え

http://www.moongift.jp/2014/05/gobrew-%E8%A4%87%E6%95%B0%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%AEgo%E3%82%82%E7%B0%A1%E5%8D%98%E3%81%AB%E7%AE%A1%E7%90%86%E3%80%81%E5%88%87%E3%82%8A%E6%9B%BF%E3%81%88/

見た瞬間アレ?と首を傾げてしまいました。

curlwget どちらかでいいのに2回とも同じことをしています

2度installしているのですから

自然過ぎます

記事ではどちらか一方でときちんと記されていますね。

彼は高校生らしいですが、既にある記事コピペ(元記事の方がまし)したような記事qiita投稿するのは、高校生でも良くないということがわかると思います。おそらくACを書いていないことで煽ったユーザー炎上してしまったので、急いで記事を書こうとしたが書けなかったのでしょう。

コピペが一部だから問題ないのでは?という意見もありますが、記事の内容と量を確認してほしいと思います

最後にadvent calendarを必ず書かなくてはいけないなどの責任は無いと私は思いますしか記事を書けなかったかコピペというのはすこしおかしいのではないでしょうか?論文コピペして理研に入った人も今話題です、彼の行動力は認めるけれど、将来が心配になりました。

マナーを守れば楽しいACになると私は思います

追記

彼がこの記事確認したのかqiita記事に追記されています

goを書いている他のひとに迷惑がかからないようにと願っています

2014-05-20

http://anond.hatelabo.jp/20140520171210

スノーデンがcurlぶんまわしだけでNSA機密情報ぶっこ抜いた、って話を聞いた時点から「主要機関セキュリティは存外甘い」なんてのは想定の範囲内だったよ。

運のいいことに、プログラマとかGEEKとかNARDは群れないか群れても弱いから抜本的な対策を取らないでいいだけで。

2014-02-27

Apple's SSL/TLS bug (22 Feb 2014)の意訳

例のAppleSSL/TLSバグの件、日本語情報がなかったので意訳しました。

Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。

Apple's SSL/TLS bug (22 Feb 2014)

https://www.imperialviolet.org/2014/02/22/applebug.html

(Hi Adam Langley, Than you for your blog! We really appreciate you.)

-----

昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。
それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。

その答えは既にハッカーニューストップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。
そして現在、俺たちはその誤った情報を正すステージに来ているんだ。

ほらここに、Applebugがあるんだ。:
static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
 OSStatus        err;
 ...

 if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
  goto fail;
 if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
  goto fail;
  goto fail;
 if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
  goto fail;
 ...

fail:
 SSLFreeBuffer(&signedHashes);
 SSLFreeBuffer(&hashCtx);
 return err;
}(Quoted from Apple's published source code.)
(訳者注:(Quoted from Apple's published source code)→sslKeyExchange.c)

2行のgotoがあるだろ。
2行目のgotoは、見て分かる通り常に発動する。
変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。
それって成功したのと同じなんだよね!

この署名検証処理は(訳者注:SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージ署名検証するものだ。
このServerKeyExchangeでは、"the ephemeral key"(通信のための一時的な鍵)を交換するためのDHE や ECDHE という暗号スイートが使われる。
そのサーバーは言うんだ。
「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね!」

今、もし"the ephemeral key"と証明書関係が破たんしているならば、すべては無意味なんだ。
これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った(つまり適当にその辺で作った)鍵を使ったり、そもそもハンドシェイク署名しなかったりってことができるってことなんだよ!

そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵秘密鍵を持っているってことの証明が、何もないんだ。

これはSecureTransport(というライブラリ)に入っていて、以下に影響する。
・iOS 7.0.6より前(俺は7.0.4で確認した)
・OS X 10.9.2より前(10.9.1で確認した)
(訳者注:つまりiOS 7.0.6、OS X 10.9.2で解決した)

これはSecureTransportを使っているすべてに影響するけど、ChromeFirefoxはそうじゃない。
ChromeFirefoxSSL/TLSのためにNSSを使っている。
でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね)


超特急テストサイト作ってみたよ。https://www.imperialviolet.org:1266
ポート番号に気を付けてね。(テストサイトCVE番号になってるよ)
443は通常通りに動いているからね。

ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキー署名しているんだ。
君がもしポート1266のHTTPSサイトアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:)


それってつまり証明書チェーンは正しいってことで、そしてハンドシェイク証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。

またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。
攻撃者は、この暗号スイートを使うサーバー自分で建てるようになるだろう。

また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。
でも攻撃者は使うプロトコルをある程度選ぶことができるから安心できないよ。
(訳者注:サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。)
でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。
同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。
(2つのうち、1つ目のほうがだいぶ好ましい。)

俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。
(更新:このバグOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。)

こんなような微妙バグって、悪夢だ。
俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。


ここに、今回の問題を明らかにするコードがある。:
extern int f();

int g() {
 int ret = 1;

 goto out;
 ret = f();

out:
 return ret;
}
もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。
本当にビックリだよ!!!

ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。
(ピーターネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない!)

if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。
でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。

テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。
TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。
俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも)

コードレビューはこの種類のバグについて効果的でありえる。
ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。
Appleコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。
でも、誰もがそんなにいい仲間を持てるわけじゃないよね。


最後に。昨日、Apple証明書ホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、
それは OS Xコマンドラインcurlを使うと、IPじゃない証明書でもIPHTTPSにつながっちゃうってだけだったよ。変だけど。
Safariはこの問題には関係なかったよ。

2013-09-27

君たちが増田に書いた記事を全部削除してしまおう!

ハローエブリバディ。

皆様、自分増田に書いた恥ずかしい記事を削除したいとか考えちゃっていたりしませんか?

心当たりのあるあなたに。思い切って、全部の記事を削除してしまいましょう!

というわけで、増田の全記事を削除するシェルスクリプト作成いたしました。

以下に説明するので、皆様使ってみてくだされ。

1.まず、適当bashwgetが使えるunixマシンログインします。

Linuxmacでも大丈夫。でもmacwget入ってないかもしれません。curlでも行けるけど…今回はwgetで。

ユーザとかは特に関係ありません。

レンタルサーバであっても、wgetコマンドが使えるのならば動作するはずです。

まずはwgetと打ってパスが通っているかコマンドが使えるかチェック!

2.以下のスクリプトを、適当コピーしてmasuda_delete.shとでも名前をつけてログインしたマシンに保存します。

おっと、保存する前に「"{!!!!!!PLEASE INPUT MASUDA ID!!!!!}";」の部分に自分増田ID入力して、

「"{!!!!!PLEASE INPUT MASUDA PASSWORD!!!!!}"」の部分に増田ログインパスワードを入れるのを忘れないで!

大丈夫ローカルで実行するだけだからパスワード漏えいとかは気にする必要はありませんよ。

シェルスクリプトなので、実行属性を付けるのを忘れずに。

chmod +x masuda_delete.sh

で実行属性が付けられますよ。

  #! /bin/bash
  cookie="/home/${USER}/cookie"

  HATENA_ID="{!!!!!!PLEASE INPUT MASUDA ID!!!!!}"
  PASS="{!!!!!PLEASE INPUT MASUDA PASSWORD!!!!!}"

  URL="http://anond.hatelabo.jp/${HATENA_ID}/"
  LOGIN_URL="https://www.hatelabo.jp/login"
  ua='Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9A405 Safari/7534.48.3'


  #LOGIN
  wget -q \
         --user-agent="$ua" \
         --load-cookies="$cookie" \
         --save-cookies="$cookie" \
         --post-data="key=${HATENA_ID}&password=${PASS}&mode=enter&backurl=http://anond.hatelabo.jp/&autologin=1" \
         "${LOGIN_URL}" \
         -O - > /dev/null
  echo "LOGIN END."
  while :
  do
  article_list=(`
      wget -q \
      --load-cookies="$cookie" \
      --save-cookies="$cookie" \
      "$URL" \
      -O - |egrep -o "edit\?id=[0-9]+"|egrep -o "[0-9]+"`)
  if [ 0 -eq ${#article_list[*]} ]
  then
  break
  fi
  for article_id in "${article_list[@]}"
  do
  src=`wget -q -O - \
      --load-cookies="$cookie" \
      --save-cookies="$cookie" \
      "${URL}/edit?id=${article_id}" `
  csrf=`\
       echo "$src"|egrep -o 'name="rkm"[^/]+'|\
       egrep -o "value=.+"|egrep -o '".+"'|\
       egrep -o '[^"]+'`
  wget -q -O - \
         --load-cookies="$cookie" \
         --save-cookies="$cookie" \
         "${URL}/edit" \
         --post-data="rkm=${csrf}&mode=confirm&id=${article_id}&delete=%8d%ed%8f%9c%82%b7%82%e9" > /dev/null
  echo "DELETE ARTICLE_ID=${article_id}"
  done
  done
  echo "DELETE COMPLETE!"

3.作成したスクリプトファイルを実行します。

./masuda_delete.sh

時間はかかるけど、今までに書いた増田の全部の記事を削除しに行くよ!

いかがでしょうか?

自分過去をすすぎ落とすことによって、新たな人生が歩めるような気がしてきたんじゃないでしょうか?

それでは、これからも良い増田ライフを!

さあ、使ってみてくれ。

http://anond.hatelabo.jp/20130927131033

てか、はてダスーパーpre記法がことごとく使えないのは何とかならんですかね……

追記

ソース中の&は半角の&に置換しないと動きませぬ……

増田システム勝手に置換してるせいです。もうしわけない……

2012-09-03

iTunes Festivalをダウンロードしたいので備忘録2012年ver.

WindowscurlWiresharkインストールしておくやり方。

1. Wiresharkアーティスト名_index_vob.m3u8?token~のURLコピペcurlダウンロード(アーティスト名_desktopなんちゃらじゃない方。もしdesktopの方にしかtokenがついてなかったら、それを付け足してダウンロード)

2. テキストエディタで開くとxx.tsファイル名が並んでいるので、以下のように上のファイルURLと同じ文字列を追加

http://同じURL/xx.ts?token以下も同じ文字列

3. ファイルが500個くらいあるので適宜面倒じゃないやり方でダウンロード

tokenチケットさえついてれば普通ダウンローダーでもいけるし連番だからどうとでもなる。

最初からtoken込みで追跡できるsnifferなら3の手順だけでいいんだろうけど、探すのが面倒なので今年はこのやり方でいく。

2012-01-07

事務職リーマンwebサービス作ってみた

Webシステムとは縁遠い事務職のリーマンが、ある日思い立って、ニッチな用途の検索エンジンサービス作ってみたので、ちょっと書いてみようと思います

ちなみに、検索エンジンといっても、googleカスタム検索とかのお茶濁し系じゃなくて、apache Solrというオープンソース検索エンジンを、VPS上で動かしているという、それなりに本

気度の高いものです。

なんで素人がそんな物騒なものを動かす羽目になったかは、後述。

アイデアときっかけ

やりたい構想みたいなことを思いついたのは、もう6、7年前ほど前のこと。初めて独り暮らしを始めたときに、ひどく不便を感じたことがあり、こんなサービスがあったら便利だなあ、

と、ぼんやり妄想していました。

ちなみにその妄想をふと高校の同期に話したとき、そのサービスはどこにあるのか?!と、えらくがっつかれたのを、覚えてます。まあ、俺と同じく偏執狂の奴だったからだと思います

が。

ただ、しがない事務職リーマンということもあり、当然、技術も無く、そのときは、やるならこんな名前サービス名だろうなあ、とか、そんな妄想レベルで、話は終わっていました。

そんな感じで、5年ほど月日は経ち、なんとなくリーマン人生の流れも見えてきたところで、以前、妄想していたことを、ふと思い出しました。

5年も経ったら、さすがに自分が考えたようなこと、誰かがやっているだろうと調べてみたところ、意外なことに、競合になるようなサービス存在せず。ちょうど異動があって、少し時

間が出来たこともあり、じゃあ、着手してみようかと思い立ちました。

やりたいことは非常に面倒だった

やりたいことは、大手サイト情報検索。ただ、商品ページ内の特定情報、それも、商品ごとに正規化されていない表記を、正規化して抽出する必要があったので、大手サイトの既設API

だけではとても実現不可能でした。

まあ、だからこそ、5年間、誰もやろうとしなかったんでしょうが

ということで、とても一発では解決できなさそうな内容だったので、自分でなんとか実現できそうな機能に細分化して、各個撃破していくことにしました。

面倒なサービスをどう実現するか

随分と考えた結果、

以上に区分できると考えて、これらを各個撃破していくこととしました。

また、技術もなく、プログラミングも出来ず、ましてやlinuxサーバのお守りをしたことなんて当然ないので、インターネット上に置くサーバですべての処理を完結させるのではなく、イ

ンターネット上に置くリソースは最小限に留め、できる限り、勝手がわかる自宅のwindowsパソコンで処理を行うことにしました。

ちなみにさらっと結論だけ書いてますが、ここまで至るまでに、いろいろと調べ続たり、考え込んだりしていたので、思い立ってから3ヵ月は掛かってます。。。

検索エンジン周りの開発

さて、やる方針を決めたあと、はじめに着手したのは、要の検索エンジンサーバです。

いろいろとググって調べて、mySQLというやつか、apache Solrというやつかに絞りましたが、結局、Solrを使うことにしました。

MySQLのほうが実績は多そうだったのですが、Solrのほうが検索専門で、滅茶苦茶動作が速いらしいということ、MySQLでも出来るが特に速度が遅いらしい全文検索機能も使いたかったこ

と、あとファセット機能ジャンル絞りこみに便利に使えそうだったので、というのが理由です。

ちょうどSolr本が発売されていたこともあり、それを参考に、自分が使うように設定ファイルを変更していきました。

しかし、初めは設定ファイルの内容も意味不明な上に、私の書き方も雑なのか、少しいじっただけでまったく動かなくなる。結局、設定ファイルを一文字ずつ変更しては動作検証、とい

った始末で、進捗は地を這うよう。ある程度思い通りにSolrを扱えるようになるまで、3ヵ月以上掛かったでしょうか。。。

さらに、検索エンジンフロントエンドSolr検索結果を、htmlに変換するプログラム)も書かなければならない。プログラミングが出来ない人間には、これが本当に辛かった。

Solr本に、いろんなプログラミング言語でサンプルがあったのですが、迷った末に、わずか数行なら書いた(≒コピペした)経験があるという理由で、javascriptを苦渋の選択。

しかし、選択はしてみたが、基礎が本当に無いから内容がサッパリ頭に入ってこない。こちらも、わかるところから本当に1文字ずつ変えていくといった手探り状態。

プログラミングについては、今回のためだけだから、といった理由で、一切基礎をやらずに着手したのが裏目に出たのか、サンプルのソースをモノにして、書き上げるのに、ゆうに半年

以上。本当に時間が掛かりました。

kanzen21.comに衝撃を受ける

さらに、Solr周りで計9ヶ月間ハマっていた頃、忘れもしない、kanzen21のおっさん彗星のように現れて、衝撃を受けることになります

大手サイトのページをクロールして検索エンジンを作る手法は、私と考えていた構想の枠組みとまさに「完全に一致」な訳で。。。

図書館事件に注目していたのも同じで、あまりの一致具合に衝撃を受けっぱなしでした。

その後の成り行き等も含めて、興味深く観察させて頂き、本当に参考になりました。

クローラ周りとかの開発

そんな感じで紆余曲折もありましたが、ようやく難題だった、プログラミング関連に目処が立ってきたので、あとはクローラと肝心のデータ処理です。ここからは、勝手知ったるwindows

の領域なので、多少の安心感があります

まず、クローラですが、専用のクローラwindows用に探してきたり、それを設定するのも大変なので、今回はテレホーダイ時代に使っていたような、フリーweb巡回ソフトを利用する

こととしました。指定のhtmlダウンロードしてくるだけなので、別に変に新しいものに手を出す必要もないので。

また、ダウンロードしてきたhtmlファイルについては、これまたフリー日本語処理ツールでcsv方式に加工することにして、処理ルール部分を相当に作り込みました。

このあたりは、全体を通して見てもキモの部分なんですが、ある意味ちょっとしたパズル感覚だったので、プログラミング言語の部分と違って、かなり楽しかったです。

あとは、msdosバッチファイル(これは前から知っていた)で、これらの処理を繋ぎcygwincurlかいうツールで、連続して検索エンジンサーバcsvファイルアップロードする

仕組みを作りました

検索エンジンサーバには、容量は少ないが、安くて高性能という、今回の用途にピッタリだった、さくらVPSを借りて設定。CentOSサーバ構築ホームページを見ながら、サーバとか

Solr管理URLとかにセキュリティを掛けて、こちらも素人ながら、意外とすんなり設定。

ホームページは、vpsサーバ相乗りさせるのではなく、別にさくらレンタルサーバを借りました。apacheの設定方法等を習得する必要がありませんし、vpsリソースapacheと分け

合う必要が無くなるので。ホームページhtmlファイルcssファイル等も調べながら設定し、画像も準備しました。

あと、構想を思いついたとき妄想していたサービス名の.comドメインは、すでに他者に取得されていたのですが、どうも使っている風にも見えなかったので、whoisで出てきたメール

ドレスに連絡して交渉し、幾ばくか払って買い取りました。

ようやく完成

結局、足かけ18か月。ようやく完成。

楽天市場家具を、幅x奥行x高さ(家具サイズ)で検索できる、楽天市場家具カテゴリ専門の検索エンジン

カグサイズ検索

http://kagusize.com

この商品数規模(データ収録約30万アイテム)で、1センチ単位家具サイズ指定検索が可能な手段は、商用サービスも含めて、ほかには存在しないと思います

kanzen21と違って、エロじゃないから華はないけどね。。。


カグサイズ検索提供する価値について

ちなみに冒頭で少し書いたきっかけですが、就職して独り暮らしを開始したときに、新しい家にピッタリサイズ家具が欲しかったのですが、これが楽天で探すのは至難の技でして。

楽天家具を探してみようと思った人には判っていただけると思うのですが、楽天では、価格では範囲指定やソートができても、サイズでは検索出来ないんです。

これは、楽天では、商品のサイズ情報は商品の自由記述欄に記載することになっているためで、商品ごとにサイズの記載方法がバラバラのため、検索事実上、不能となっています

家電製品とかに関しては、種類が少ないこともあり、メーカーホームページとかでサイズを確認した上で、商品型番で検索すればいいので、それほど問題にはならないのですが、家具

って、種類が非常に多く、型番もあったり無かったりで、家電のようにサイズを調べることができません。

しかも、サイズが非常に重要な商品です。なんて不便な!

・・・ということで、カグサイズでは、楽天の商品ページにいろいろな書式で書かれているサイズ情報を拾って解析して正規化し、範囲指定やソートして検索ができるようにしています

また、単に寸法サイズを拾うだけでは、梱包サイズとか引き出し内寸とかも引っ掛かってしまうので、それらは出来るだけ排除して、商品の外寸が優先して引っ掛かるよう、アルゴリズ

ムを調整しています

単位センチミリ)に関しても、商品ごとにバラバラ(単に単位だけでなく、商品説明のどこに"センチ"とか"ミリ"と記載しているかについてもバラバラです。)なので、サイズ表記

前後の状況をみて、正しいと思われる単位で拾うようにしています


その他

あと、変わった使い方としては、欲しい家具価格比較みたいなこともできます

家具は、同じ商品でも、店ごとに型番が違ったりすることがよくあり、簡単には価格比較が行いづらいジャンルの商品です。

しかし、型番は違っても、同じ商品なら原則、サイズは同じですから、欲しい商品とまったく同じサイズ検索をかけると、同等商品があるのかどうか比較しやすい・・・といった使い

方もできます

おわりに

と、そんな感じで、しがない事務職リーマン作ってみたニッチな用途の検索webサービスを、サービスインさせて頂きました。

一般に公開されていて、誰でもアクセスできる情報でも、ニーズが有りそうな切り口の条件で検索性を高めれば、新しい価値創造できるんじゃないかという実験です。

もしよろしければ、ぜひ、使ってみてくださいー。それでは!

----------

カグサイズ検索

http://kagusize.com

追記

アップ直前の変更により、最大サイズの指定がうまく働かなくなっていたため、修正をしました。ご指摘有難うございました。

2008-01-31

http://anond.hatelabo.jp/20080131182838

同意だよ。

初心者が本当に注意しなければいけないのは、スクリプト脆弱性よりもサーバーセキュリティ

PHPなら大抵どこのレンタルサーバーも利用可能なので殆ど問題がない。

初心者でもどんどん公開していいとおもう。

なにがいいって現段階においてはPHPは非常に多くの人に使われている。

だからもし見当違いなことをやっていたら注意してくれる人がいっぱいいる。

そして何よりも大きいのはサーバー運営業者などがノウハウを吸収しているということ。

PHPシステムコマンドなんかは大体止められているしRFIなんかの攻撃に対しても不正ファイルが埋め込まれたりすたら通報してくれるところもある。

初心者スクリプトを書くことだけに集中できるわけだ。

現段階のRubyでそれができるだろうか?

大手のレンタルサーバーでさえまだ設定があやふや。

そのままじゃ動かなかったりしている。

じゃぁ自前サーバーならいけるのかというと、正直初心者には無理なんじゃないの?

Mongrelあたりを入れて、あれ、これメモリ漏れてねぇ?とかそういう心配をしたり、24時間監視できるわけがない。

Ruby初心者に薦められる?

まだ「いいえ」なんじゃないの?

Rubyをちゃんとできる人や教えられる人はまだ少なすぎる。

PHPをぐだぐだ言うひとはちゃんとできるひとなのかな?

どうなのよ?

Matzだってサービスを組む人ではないだろう。

まあ異論はあるかもしれないが。。

あと、こっちは、一般的に同意をえられるとおもうんだけど、

スクリプトが垂れ流す脆弱性よりもroot権限のっとられたマシンの方が怖くね?

んでもって、遥かに有害だよね。


PHP脆弱性うんぬん言ってるけど、

そんなに言うならSQLインジェクションの穴のひとつでも見つけて報告してごらんよ。

SQLインジェクションなんて、DB接続ができるようなレベルになれば最近マニュアル本には当たり前に書いてあるじゃない。しかもこれは何もPHPに限った話しじゃないじゃない。

穴なんて時間の経過とともに増えるんだから、メンテナンスされてないサービスのほうが怖いわけですよ。

ローカル言語サーバー使ってそのままになってしまうほうが最悪なんじゃないかな。

もし、素人がぐだぐだにつくったPHPサービスとかで問題があるとすれば・・・

SQLインジェクションで中の情報漏れる(そんなサービス漏れて大切な情報登録するなよ)

メール送信系でヘッダー偽装でスパムの踏み台にされる(これは意外と多いかもしれないね)

・クローラーが他のサーバに負荷をかけまくる

まあどれもPHP”だから”というわけでもないよね。

97年頃にはperlだって掲示板アップローダーだって穴だらけだったじゃない。

coderedがでるまでiisで建ってたサーバーだって山ほどあった。

そのころにはSQLインジェクションに対応していないサイトは本当に簡単に見つけられた。

未知の脅威まで対応してコーディングなんてプロでも無理だよ。

初心者は主流からはいるのがいろんな意味でみんなのためじゃない。

今の主流はphpということでいいんじゃないの?

PHPは発展期

RonRは成長期(すくなくともあと1年ぐらいは)

perlは爛熟期

python黎明期

あとは・・・

.asp,.do,jsp,cfm ここらへんかな。

コールドフュージョンにはもうちょっと頑張ってほしかった。

pythonからColdFusionのにおいしてない・・・?

あと、なんかLLってあったっけ?

curlがなんかいまさらだけど脚光をあびるような予感がしている。

ところでさ、

PHPを批判しているような人はPHP6の仕様とかちゃんとフォローしてるのかね?

そもそも何かを作り上げることができる人というのは非常に少ない希少種なのに、

そこに入ろうとする前途ある人達モチベーションを使用言語がどうこうと、

挫こうとするのはなんか憤りを感じるよ。

Matzみたいな人がそれをやってどうするんだよとか、ちょっと思った。

まあ本人はもっと無邪気だったのかもしれないけど取り巻きがちょっと邪悪だよね。

2007-08-12

http://anond.hatelabo.jp/20070812230505

$ curl --head http://www.keishicho.metro.tokyo.jp/sikumi/pipo/pipo2/image/jikoshoukai.asf

HTTP/1.1 200 OK

Date: Sun, 12 Aug 2007 14:34:47 GMT

Server: Apache/2.0.46 (Red Hat)

Last-Modified: Tue, 17 Jul 2007 05:31:19 GMT

ETag: "d74055-236b-e31017c0"

Accept-Ranges: bytes

Content-Length: 9067

Content-Type: text/plain

MIME Typeが合ってない時かなぁ。asfファイルでtext/plainだとMac版のFireFoxは落ちるっぽい?

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん