トップ «前の日(10-23) 最新 次の日(10-25)» 追記

2004-10-24

_ 久しぶりに完全オフ

まー毎週ちゃんと休日はあるんですが、試験とか試験勉強とかなんだかんだでうまいこと身体を休めることができずにしばらくきてました。やっと完全休養日。たった一日。おいこら。

なんかいろいろやりたいことがあったような気がするんだけど、なんだったかもう思い出せないしやる気も起きない。

まーそんな日も必要だなってこった。なんか fink とか ports とか地味にアップデートしながらボー。

Tags: 日々

2006-10-24

_ emacs-w3m で referer は吐けないのか?

そんなにヘビーに使っているわけでもなかったので今まで w3m + Emacs で textarea を編集する際は普通に w3m から Emacs を起動して利用していたんだけど、ふと思い立って w3m-el を入れて全部 Emacs から作業するようにしてみた。

tDiary の CSRF 対策に引っかかって書いた内容全部飛ばしちまったorz

あとで分かったことだけど、どうも w3m から Emacs を起動するか、Emacs から w3m を起動するかの違いでしかないっぽいので、21.3.5 なら起動も速いし今まで通りの使い方でいいような気がしてきた。この方がマウスも普通に使えるし。

それより w3m.org がソースをそのまま吐いているのは何が起きているんだろうか。


ついでに以前 mule-ucs を組み込んで激重になった Debian 上の Emacs でも w3m-el なら快適だーと思っていたが、今度は textarea のレンダリングがおかしい。おうおうおう。そこが目的なんじゃい、emacs-w3m さんよぉ*1

ということで強権発動して、システムワイドでいきなり mule-ucs を読み込もうとする startup の elisp を外した。必要なときに自分で require することにして起動を軽くし、こっちも w3m から Emacs を起動する方式に変更。同時にあれこれ起動を重くする要素を見直して少しでも快適に作業できるようにしてみた。

結局、元通りってことなんだな。

※ tDiary の設定をいじればいいじゃんとも思うんだけど、まぁそもそも emacs-w3m の操作性がちょっと趣味に合わないので、無理に使わなくてもいいやと思ったのでした。そうこう言っててまたそっちに傾くかもしれないんだけど。

Tags: Emacs w3m

*1 たぶんバージョンがちょっと合ってないんだろな。


2007-10-24

_ WCLはもう一手間加えないとダメだな

しつこく Yahoo! Widgets の Widget Class Library ですが。

とりあえずライブラリの存在をチェックして include してグローバルな lib にオブジェクトを作ってやるなんつー単純な作業を毎回書くのはいやなので、それだけをやるコードを書いた。

ついでにどんなコンポーネントがあるのかだけでもライブラリ自身にリストアップしてもらおうと components(), subcomponents() を勝手に追加。(要はファイルシステムをなめて .js ファイルかディレクトリかチェックして配列を返すだけ。)

雰囲気がつかめてきて機嫌がよくなってくる。しかしその先へ行こうとサンプルを眺めてげんなり。

  • まず Yahoo.Controls.Theme コンストラクタに Theme の存在するパスを教えてやる(えぇっ!?)
    • しかもそのためには Yahoo.Controls クラスのリソースのパスを getResourcePath で取得したうえで、その中の Themes ディレクトリを指定する必要がある(マジっすか)
    • つまりこういうこと new Yahoo.Controls.Theme( lib.getResourcePath( 'Yahoo.Controls' ) + '/Themes' )
    • こんなのグローバルな lib を自分たちで汚してるんだし、オブジェクトの中で解決してくれよ
  • できたオブジェクトに theme 名を与える
  • 各コントロールのコンストラクタにはすべてこの theme オブジェクトを与える
  • 各コントロールのパラメータはできあがったオブジェクトに対して一つ一つ丁寧にセットしてやる
frmMain = new Yahoo.Controls.Form(theme);
frmMain.text = "Widget Class Library Control Sample";
frmMain.width = 350;
frmMain.height = 400;
...
lblPrompt1 = new Yahoo.Controls.Label(frmMain.theme);
lblPrompt1.autoSize = true;
lblPrompt1.left = 8;
...

以下コントロール分くり返し。

……。

いやぁ。自分で画像作らなくていいのはありがたいよ? ありがたいんだけど、なんでこんなめんどくさいんだよぅ。なーんつーかこう、バラバラな感じ。かといって粗結合で扱いやすいよ!とかでもない。あくまで縦横無尽に共依存。

どないやねん。どないやねーん。

なんかパラメータとかもさ、JSON でドーンとセットしたいじゃんよ。まぁそういうの書けばいいんだと思うけどさ。ぐるぐる回して setter があったらそれに放り込むようなやつ? まぁ自分に書けるかどうか分かんないけどさ*1。しかもこのライブラリの setter, getter の書き方って deprecated ですよ? orz

cf. Core JavaScript 1.5 Guide:Creating New Objects:Defining Getters and Setters - MDC

他にもリファレンスを眺めてみると obosolete なのに Widget Class Library のサンプルにはバンバン出てくる書き方とかあったりして、そういうのどうなのよ?とかね。気になるところがボロボロと出てきますね、これ。

たぶんその辺の気持ち悪さが解消されればめっちゃ便利になるんじゃないかと期待はしてるんだけどなぁ。自分で書かなきゃいけないんですかねぇ。WCL そのもののバージョンアップなんてそんなすぐにはないですよね…。

*1 setter 一覧とか getter 一覧て取れそうもないですなぁ。Ecmascript 4 ではできそうな気がするんだけど。


2008-10-24

_ MacOSX の open を GNOME で

もうそのまんま gnome-open だった。

Twitter / UI: alias open='gnome-open' はあ ...

ただ alias って Emacs の Dired では解釈されないらしく、どうしても標準で入ってる open*1 の方が立ち上がっちゃって悲しい。

ちなみに OSX と同じく標準状態で PDF が手軽に作成できてるのは嬉しいんだけど、~/PDF/ に入るのはなんかもうちょっと分かりやすく GUI から設定できてもいいんじゃないかと思った。

Twitter / Takeru Naito: @wtnabe /etc/cups/cups-pdf ...

Tags: Linux

*1 全然ベツモノ

_ git で svn status のようなもの

git ls-files にいろいろオプションがある。

-m(--modified)
修正されているファイル。svn では M と出てくるやつ。
-o(--others)
管理対象外のファイル。svn では ? と出てくるやつ。--directory を付けると、丸ごと others なディレクトリは DIRECTORY/ までの表示になる。必要以上に出てこないのでうざくない。こっちがデフォルトの方が親切なような気もする。
-t
管理されているファイルの status が取れる。これこそが本当に svn status 相当。のはずなんだけど、見てる情報が違うらしく、上の二つの情報を合わせたものにはなぜかならない。どーもこの辺、git のマニュアルが不備なのか自分の理解が足りないのかよく分からんのだよな。

あと svn info 相当の情報も取り方がよく分からない。git remote -v でずいぶんあっさりした情報は取れるんだけどねぇ。

Tags: Git

2018-10-24

_ Cloud KMS + Cloud Storageの利用には大きく分けて3種類の方法があった

エンベロープ暗号化や秘密情報の扱いはそもそもそんなに得意じゃないので大間違いしている可能性があります。間違ってたら指摘お願いします。

※ Cloud KMSについては Key Management Serviceについて勘違いしていたこと - あーありがち(2018-10-21) に一部メモがあります。

まとめ

Cloud KMS + Cloud Storage の組み合わせには大きく分けて以下の3つの方法がある。

  1. Bucket のデフォルト暗号化キーを KMS Key にする
  2. Object 保存時に KMS Key Name をオプションで渡す
  3. 独自に KMS Key で暗号化して通常通り保存する

基本的に Cloud KMS のドキュメント上で説明されているのは 3 の方法。

1 と 2 の方法については Cloud KMS の API を enable にして KMS と Storage に同じアカウントでアクセスできるようにする必要がある。暗号化、複合は透過的に行われ、意図的に暗号化済みのデータを取得する方法はない。KMS Key が無効化されたら Object そのものにアクセスできなくなる。

Storageの自動機能の利用には注意が必要

上の 1, 2 は Storage + KMS という Google の提供する技で、これは簡単に言うと KMS Key Name の指定さえできていれば暗号化/複合処理は完全に Google におまかせになる、つまり自動で透過的に適用されるということ*1

この場合、Object のメタデータの一つに KMS Key Name が入るので、鍵とデータの組み合わせは気にする必要がない。

ただし、利用の際には以下のような制限が生まれる。

  • Bucket の Region と Key の Location の組み合わせには制限がある(例えば asia な Bucket に global な Key を組み合わせることはできない)
  • KMS と Storage の両方に同一のアカウントで認証を要求することになるので厳密なことを言うと権限がややルーズ
  • Key が無効化されたら Object にはメタデータ含めてアクセスできない(読み取りはできるが中身が分からない、ではなく、読み取りもできない。ただし Key Name は取得できる。)

特に Bucket レベルの制限はバツンと一律アクセスできなくなってしまうので、いろいろな利用方法の混ざった暗号化キーやシークレットに対しておおもとの KMS KEK Key で有効/無効を切り替えるといった使い方は難しそう。

となると、あくまで

  • KMS へのアクセスを外部に許可するわけではなく、管理が容易
  • シークレットの利用方法は同一
  • キーのローテーションはするが無効化は原則しない

以上のような運用に向いている気がする。

例えばマルチテナントのデータをテナントごとに暗号化するキーを分けたうえでその暗号化キーの暗号化に使う KEK がローテートされる、みたいな使い方をすると開発環境の準備も楽そうだし、よさそうに思える。*2

自前で暗号化する場合は自前で対応表に基づく自動化を行うべし

Storage の自動暗号化の恩恵に与らない場合、

  • KMS Key Name
  • 暗号化されたシークレット / DEK

の間を紐づける情報は Google Cloud のどこにも残らない。あくまで KMS Key とデータを呼び出したプログラムだったり紐づけて作業を行う作業者の頭の中だったり terminal の履歴の中だけに残るものとなる。

そこでおそらく基本的にはこのデータの暗号化/複合の処理はコードで閉じ込めてしまうわないと維持が難しくなってしまうので、まずは対応表とそれを利用した暗号化/複合処理のコードの準備が必要になる。

上に挙げた例の反対、

  • KMS へアクセスするユーザー(プログラム)の場所は様々
  • シークレットの利用方法が同一でない
  • キー単位で無効化するなどシークレットの利用を制御したい

といった要件が入る場合はこのような準備が必要と考えるのがよさそうだ。

*1 Bucket レベルの場合は指定はリソース ID になるが、同じこと。その場合はバージョンまで含めたリソース ID にならないように注意

*2 データの暗号化キーが KMS と自動連携する Storage で管理されるイメージ。キーは DB に入っていない方が安心な感じもする。