連続体仮説: 2014

2014年12月18日木曜日

play framework 2で「ファイル名が長すぎます」と出た時の対処法

Play Framework 2.1 を使っていた時に次のようなエラーが出たことがあった。

$ play ~compile
...
[error] 
[error]      while compiling: myproject/target/scala-2.10/src_managed/main/views/html/signup.template.scala
[error]         during phase: jvm
[error]      library version: version 2.10.0
[error]     compiler version: version 2.10.0
[error]   reconstructed args: -encoding utf8 -bootclasspath ...
[error] 
[error]   last tree to typer: Literal(Constant(play.api.templates.Html))
[error]               symbol: null
[error]    symbol definition: null
[error]                  tpe: Class(classOf[play.api.templates.Html])
[error]        symbol owners: 
[error]       context owners: anonymous class anonfun$f$1 -> package html
[error] 
[error] == Enclosing template or block ==
...

[error] == Expanded type of tree ==
[error] 
[error] ConstantType(value = Constant(play.api.templates.Html))
[error] 
[error] uncaught exception during compilation: java.io.IOException
[error] ファイル名が長すぎます
[error] two errors found
[error] (compile:compile) Compilation failed
[error] Total time: 25 s, completed 2014/12/18 11:57:36
1. Waiting for source changes... (press enter to interrupt)

どうやら、playが自動生成するファイルのクラス名が長すぎて、scalaコンパイラの扱う長さを超えてしまっていることが原因らしい。しかしscalacに渡すコンパイラオプションを指定することによって長い名前を許容することができる。 play frameworkの場合はSBTを使っているので、project/Build.scalaをつぎのように変更した。


object ApplicationBuild extends Build {
  ...

  val main = play.Project(appName, appVersion, appDependencies).settings(
    scalacOptions ++= Seq("-Xmax-classfile-name", "140")
  )
}

参考: https://github.com/scala/pickling/issues/10#issuecomment-31318136

2014年11月14日金曜日

Scalaで Netty を使った WebSocket Client

JBossのNettyというライブラリを使えばWebSocketクライアントを実装できると聞いてJava製のサンプルコードがあったのでそれをScala化してみた。バージョンはわけあって3.9系だけど多分4系でも同様に動く。

オリジナルのJavaコード: https://github.com/netty/netty/tree/3.9.1/src/main/java/org/jboss/netty/example/http/websocketx/client

ついでにSBT化もしてみた。ディレクトリ構成はたったの3ファイル。sbt 'run ws://localhost/' で実行可能。

WebSocketClient.scala
WebSocketClientHandler.scala
build.sbt

WebSocketClient.scala WebSocketClientHandler.scala build.sbt 単純な構文リプレイスなのでScalaらしくはない。

2014年9月11日木曜日

LinuxでWindowsのGoogle Chrome対応ブラウザサービスを利用する

Linuxでウェブブラウザを利用していると、だいたいどのサービスもWindowsや他のOSと同様に利用できるが、たまに次のように表示され、利用できないことがある。

Google Chrome対応となっております。
下記OSにて利用可能なGoogle Chromeのみ対応しております。
* Windows Vista/7/8
* Mac OS X 10.6/10.7/10.8/10.9

多くの場合、LinuxのGoogle Chromeでも原理上動作はするが、運営側がテストをしていないということで、対応OS以外であればサービスを無効にするような処理が施されている。ウェブサービスでOSを判定するためには、多くの場合ブラウザのUser Agent情報を参照している。しかしこれは自分のブラウザが勝手に名乗っているだけで、偽装することが可能である。特にGoogle Chromeでは比較的簡単にUser Agentを偽装できる。その手順は次の通り

Google Chromeで利用したいページを開く
F12またはCtrl-Shift-i を押してDeveloper Toolsウィンドウを開く
右下の歯車アイコンをクリックしてSettingsを開く(画像参照)
右上の方のOverride User Agentにチェック(画像参照)
偽装したいブラウザ,OSを選択
ブラウザをリロード

以上でUser Agentを選択できるが、Windows版のGoogle Chromeはなぜか選択肢に入ってない。その場合はOthersを選択して次のUser Agentを直接指定すれば良い。

Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63 Safari/537.36

試した環境は次の通り

Ubuntu 12.04
Google Chrome 18.0.1025.162

2014年6月6日金曜日

OpenSSLのCCSに関する脆弱性

以下、http://ccsinjection.lepidum.co.jp/ja.html より引用

[English]
最終更新日: Fri, 06 Jun 2014 01:29:36 +0900

CCS Injection Vulnerability

概要

OpenSSLのChangeCipherSpecメッセージの処理に欠陥が発見されました。
この脆弱性を悪用された場合、暗号通信の情報が漏えいする可能性があります。
サーバとクライアントの両方に影響があり、迅速な対応が求められます。
攻撃方法には充分な再現性があり、標的型攻撃等に利用される可能性は非常に高いと考えます。

対策
各ベンダから更新がリリースされると思われるので、それをインストールすることで対策できます。
（随時更新）

Ubuntu

Debian

FreeBSD

CentOS

Red Hat 5

Red Hat 6

原因
OpenSSLのChangeCipherSpecメッセージの処理に発見された欠陥により、第三者が通信に介在することが可能であることを確認しました。
そのためOpenSSLに第三者が知ることのできる弱い鍵を使用させることができます。
今回発見された脆弱性により、これにより修正前のバージョンのOpenSSLを使用して通信の保護を実施していたウェブの閲覧、電子メールの送受信、VPNといったソフトウェアには通信内容や認証情報などを詐取・改ざんされる危険性があります。

Q&A

どのバージョンが影響を受けますか?
以下のバージョンにバグが存在する。

1.0.1から1.0.1g

1.0.0から1.0.0l

0.9.8y以前の全て

以下のバージョンではバグが修正されている。

1.0.1h

1.0.0m

0.9.8za

どのような攻撃が行われる恐れがありますか?
クライアントとサーバがともにバグが存在するバージョンで、サーバがバージョン1.0.1以降の場合に、通信の盗聴・改ざんを行う攻撃が行われる恐れがあります。サーバだけがバグの存在するバージョンの場合は、クライアントの偽装を行う攻撃が行われる恐れがあります。

秘密鍵を再生成し、証明書を再発行する必要はありますか?
この脆弱性を悪用したとしても、秘密鍵を盗み出すことはできません。しかし、一度でもOpenSSLのSSL/TLSで保護された経路で秘密鍵を転送したことがある場合は慎重に考慮してください。

SSL/TLSのプロトコル設計の問題ですか?
いいえ。実装の問題です。

どのプロトコルが影響をうけますか?
SSL3.0, TLS1.0, TLS1.1, TLS1.2 のすべてが影響をうけます。

どの暗号アルゴリズムが影響を受けますか?
全ての暗号アルゴリズムが影響を受けます。

過去に攻撃を受けた形跡を確認することはできますか?
OpenSSLを使っていた場合は何の形跡も残らないため、おそらく確認することはできません。

IDS等で検知することは可能ですか?
通常と異なるタイミングで送信されるChangeCipherSpecパケットを検知するよう構成すれば、検知できると思われます。

どのようにして発見されましたか?
レピダムの菊池がCoqを用いたTLSの安全な実装の研究中に発見しました。

参照

CVE-2014-0224

CCS Injection 脆弱性の発見経緯（レピダムの技術者ブログ）

CERT/CC (USA)

CCS-InjectionのロゴはCC0で公開されます。SVGフォーマットでダウンロード

Lepidum Co. Ltd. Contact : press@lepidum.co.jp
Copyright © 2014 Lepidum Co. Ltd. All rights reserved.

2014年3月25日火曜日

Beamerでテーマによって Undefined control sequence. のようなエラーが出る問題

Beamerを使っていて、次のようなエラーが出て困ったことがありました。


! Undefined control sequence.
\trans@languagepath ->\languagename 
                                    ,English

色々調べてみると、自分の場合はMadridというテーマを使っていて、次の行を削除するとエラーが出なくなることがわかりました。


\usetheme{Madrid}

テーマを指定しなかったり、別のテーマの場合は通ったりしたので、不思議だったのですが、原因がわかりました。タイトル情報が無かったということでした。次の4行を追加し、エラーをなくすことが出来ました。


\title{タイトルタイトル}
\author{連続太郎}
\institute{株式会社連続体仮説}
\date{\today}

Madridというテーマでは各ページのした部分にタイトルや著者などの情報を表示しており、タイトル情報がきっと必須だったのでしょう。考えてみれば当然です。しかし、LaTeXって便利だけれどエラーメッセージがわかりにくいですね。