Hatena::ブログ(Diary)

hnwの日記 このページをアンテナに追加 RSSフィード

[プロフィール]
 

2015年4月1日(水) PHP 5.4.0から無限大==無限大になってた このエントリーを含むブックマーク このエントリーのブックマークコメント

本日はエイプリルフールなので、嘘でも本当でも誰も困らないネタを紹介します。


内容としてはタイトルの通りで、浮動小数点数の無限大とマイナス無限大に関する==の挙動がPHP 5.3.xまでとPHP 5.4.0以降で変わっていたという話題です。


$ php-5.3.29 -r '$x=INF;var_dump($x, $x==$x);'
float(INF)
bool(false)
$ php-5.4.0 -r '$x=INF;var_dump($x, $x==$x);'
float(INF)
bool(true)

このように、PHP 5.4.0以降は INF == INF、-INF == -INF という挙動になりました。


僕は過去の記事「「===」がtrueを返し「==」がtrueを返さないサンプル」で、当時のPHPINF === INF なのに INF != INF となるのは違和感があるという風に書きました。これが自然な方向に修正されていたというわけです。やったね!

2015年3月8日(日) マルチブート環境の全OSで同じBluetoothデバイスを使う このエントリーを含むブックマーク このエントリーのブックマークコメント

マルチブート環境(デュアルブート・トリプルブートなど)でBluetoothデバイスを使う際の話題です。


Bluetoothデバイスを利用する際は通常「ペアリング」という作業が必要です。これは、初回接続時に128bitのリンクキーを発行して両者で共有し、通信相手のBDアドレスに紐付けておく仕組みです。これにより、次回接続時は同じリンクキーを使ってお互いを認証することができますから、面倒な手続きなしに利用することができます。


ところで、この仕組みはマルチブート環境ではうまく働きません。マルチブート環境ではそれぞれのOSが同じBluetoothアダプタを共有するため、Bluetoothデバイスからは各OSを区別できないのです。


もう少し具体的に説明します。マルチブート環境で1つのOSからデバイスをペアリングしたあとで別のOSを起動した状況を考えてみましょう。このとき、デバイス側から見るとペアリングが済んでいるはずのBDアドレスなのに、OS側ではペアリングしていないためリンクキーがわかりません。再ペアリングをすれば新たなリンクキーが発行されて接続できるようになりますが、今度は最初のOSがリンクキーを共有していない状況になってしまいます。別のOSを起動するたびに毎回ペアリングすれば使えるものの、これではせっかくのBluetoothの利便性が台無しです。


これを解決するには、OSの管理しているリンクキーの情報を書き換えてやるしかありません。本稿ではMacOSXWindowsLinuxのトリプルブート環境でリンクキーを揃える方法を紹介します。


この内容はApple Support Communitiesの「Dual pairing in OS X and Windows」がベースになっていますが、僕は正解にたどり着くのに苦労したのでまとめ直してみました。


Macのマルチブート環境

Macに他のOSインストールするということではBoot Campが有名ですね。本稿の情報はそうしたMacOSXWindowsデュアルブート環境でも活用できるかと思います。


ちなみに僕はBoot Campを使わずにMacBook Air(2010 Late)にMacOSX 10.9、Windows 7(32bit)、Ubuntu 14.04LTS(64bit)の3つをインストールしています*1。先日SSDを256GBに換装したので試しにインストールしてみたのですが、思ったより実用的だと感じています。


今回の作業で、これら3つのOSすべてで同じNexus5経由のBluetoothテザリングができるようになりました。

続きを読む

*1:興味がある方は「refind macbook」などのキーワードでググってください

トラックバック - http://d.hatena.ne.jp/hnw/20150308

2015年3月7日(土) 例示のためのMACアドレス このエントリーを含むブックマーク このエントリーのブックマークコメント

例として推奨されているドメイン名とIPアドレス - あどけない話」に、例示のためのドメイン名とIPアドレスが紹介されています。お役立ち情報ですね。


ところで、MACアドレスを例示したい場合はどうすればいいのでしょうか。答えがRFC7042に載っていたので紹介します。


48bit MACアドレスの場合

48bitというのは我々が普段見るスタイルのMACアドレスです。「2.1.2. EUI-48 Documentation Values」によれば、次のアドレス範囲が例示に利用できます。


  • ユニキャストアドレスの場合
    • 00-00-5E-00-53-00 から 00-00-5E-00-53-FF まで
  • マルチキャストアドレスの場合
    • 01-00-5E-90-10-00 から 01-00-5E-90-10-FF まで

これらは先頭の40bitが固定されているので、使えるアドレスはそれぞれ256個です。NICやその他身近なネットワークデバイスにはユニキャストアドレスが割り当てられているはずですから、通常は前者のみが使えるということになるでしょう。


64bitのMACアドレスがどういう状況で使われるのか残念ながら僕は知りませんが、こちらも「2.2.3. EUI-64 Documentation Values」に記述があります。ご参考まで。


Bluetooth device address(BD_ADDR)とMACアドレスとの関係

Bluetoothでもデバイスごとにユニークな48bitのBluetooth device addressが割り振られており、これをMACアドレスと呼んでいる資料も多く見つかります。Bluetooth device addressもMACアドレスも上位24bitをベンダーごとに割り振っており、そのベンダーごとのIDも両者で一致しているようですから、非常に似ているのは間違いありません。


ただ、Bluetooth device addressがMACアドレスそのものなのか、また上のアドレスを例示に使っていいのかについてはわかりませんでした。詳しい方がいらしたら教えてください。


とはいえ、Bluetooth device addressの例示について言えば上のアドレスを使っておけば現実のデバイスと重複することは無い、ということは言えそうです。(00-00-5EがIANA所有になっているため)

トラックバック - http://d.hatena.ne.jp/hnw/20150307

2015年3月1日(日) CloudFlareのCNAME FlatteningをGitHub Pagesで使ってみた このエントリーを含むブックマーク このエントリーのブックマークコメント

(03/04 08:15 追記)今回のDNS設定変更でGitHub Pagesで提供しているCDNが使えるようになったことを追記しました。


今回はDNS方面の話題です。僕ははてなダイアリー以外にhttp://hnw.jp/という古めかしいサイトも管理しています。サイトの実体はGitHub Pagesで、これまでAWSのRoute 53でカスタムドメインの設定をしていました。


ところで、このサイトが2月の頭から1ヶ月ほど見えなくなっていました。原因は僕がGitHubからのメールを読み飛ばしており、DNS設定の変更を怠っていたためです。これに懲りて、今後DNS設定を二度といじらなくて済むようRoute 53からCloudFlareに引っ越してみました。その顛末を紹介します。


GitHub Pagesのカスタムドメイン設定

GitHub Pagesを普段使っていない人も多いと思いますので、まずは背景を紹介します。


GitHub PagesGitHubの提供する機能の一つで、GitHub上の各リポジトリhttp://hnw.github.io/hnw.jp/のようなURLを与え、特定のブランチをWebサイトとしてアクセスできるようにするものです(URL中のhnwがGitHubユーザー名、hnw.jpがリポジトリ名です)。WebサーバGitHubが提供してくれるので、gitの操作に慣れた人が静的コンテンツだけのサイトを手軽に作るにはもってこいのサービスだと言えるでしょう。


さらに、自分でドメインを持っていればGitHub PagesのURLを好きなホスト名に変更することもできます。「Setting up a custom domain with GitHub Pages」にも書いてある通り、リポジトリ上にホスト名を書いたファイルを追加した上でDNSのCNAMEレコードを設定すればカスタムドメインの設定ができます。


ただし、ホスト名として「zone apex」を使っている場合は設定方法が変わります。zone apexというのはドメイン名と同じホスト名のこと*1です。この場合RFCの制約から通常CNAMEを設定することができない*2ため、AレコードGitHubIPアドレスを直接指定するしかありません。


僕のサイトもzone apexだったため、Aレコードを設定していました。


zone apexでも放置運用したい

続きを読む

*1:正確には違いますけど説明用ということで…

*2RFC 1912 2.4にある「A CNAME record is not allowed to coexist with any other data」が根拠です

トラックバック - http://d.hatena.ne.jp/hnw/20150301

2015年1月31日(土) 江戸前セキュリティ勉強会でgithub.comの弱い鍵を探す話をしました このエントリーを含むブックマーク このエントリーのブックマークコメント

先週1/24(土)に江戸前セキュリティ勉強会で「偶然にも500万個のSSH公開鍵を手に入れた俺たちは」というタイトルでLT発表してきました。以下が発表資料です。



このプレゼン資料はLT用に圧縮して作ったので、わかりにくい部分があったかもしれません。そこで、Q&A形式で補足を書いてみました。


「最大公約数を求める攻撃はSSHユーザー鍵についても現実的脅威なのか?」

結論から言うと、SSHユーザー鍵に限れば脅威でないというのが個人的な考えです。

続きを読む

トラックバック - http://d.hatena.ne.jp/hnw/20150131
 
ページビュー
1419407