春山 征吾のくけー

https://www.unixuser.org/~haruyama/blog/ に移転しました http://wiki.livedoor.jp/haruyama_seigo/d/FrontPage @haruyama タイトルが思いつかないときはそのときかかってた曲をタイトルにしています.


OpenSSH 6.5/6.5p1 がリリースされました.

2014/01/30, OpenSSH 6.5/6.5p1 がリリースされました.


Changes since OpenSSH 6.4
OpenSSH 6.4 からの変更点

This is a feature-focused release.


New features:


 * ssh(1), sshd(8): Add support for key exchange using elliptic-curve
   Diffie Hellman in Daniel Bernstein's Curve25519. This key exchange
   method is the default when both the client and server support it.

   ssh(1), sshd(8): Daniel Bernstein の Curve25519 による
   楕円曲線 Diffee Hellman を用いた鍵交換のサポートを加える.

 * ssh(1), sshd(8): Add support for Ed25519 as a public key type.
   Ed25519 is a elliptic curve signature scheme that offers
   better security than ECDSA and DSA and good performance. It may be
   used for both user and host keys.

   ssh(1), sshd(8): 公開鍵のタイプとして Ed25519 のサポートを加える.
   Ed25519 は 楕円曲線の署名方式で, ECDSA と DSA よりもよいセキュリティを
   提供する. またパフォーマンスもよい. ユーザ鍵にもホスト鍵にも利用できる.

 * Add a new private key format that uses a bcrypt KDF to better
   protect keys at rest. This format is used unconditionally for
   Ed25519 keys, but may be requested when generating or saving
   existing keys of other types via the -o ssh-keygen(1) option.
   We intend to make the new format the default in the near future.
   Details of the new format are in the PROTOCOL.key file.

   (オフライン攻撃から)鍵をよりよく保護するために bcrypt KDF を用いる
   新しい鍵フォーマットを加える. この形式は無条件に Ed25519 鍵に用いられる.
   ただし, ssh-keygen(1) の -o オプションによって, 鍵の生成時や
   他のタイプの既存の鍵の保存で要求できる. 近い将来この新しい形式を
   デフォルトにするつもりだ. 新しいフォーマットの詳細は,
   PROTOCOL.key ファイルにある.

 * ssh(1), sshd(8): Add a new transport cipher
   "chacha20-poly1305@openssh.com" that combines Daniel Bernstein's
   ChaCha20 stream cipher and Poly1305 MAC to build an authenticated
   encryption mode. Details are in the PROTOCOL.chacha20poly1305 file.

   ssh(1), sshd(8): 新しいトランスポート暗号 "chacha20-poly1305@openssh.com"
   を加える.  認証された暗号モードを作成するために Daniel Bernstein の
   ChaCha20 ストリーム暗号とPoly1305 MAC を組合せたものだ.
   詳細は PROTOCOL.chacha20poly1305 ファイルにある.

 * ssh(1), sshd(8): Refuse RSA keys from old proprietary clients and
   servers that use the obsolete RSA+MD5 signature scheme. It will
   still be possible to connect with these clients/servers but only
   DSA keys will be accepted, and OpenSSH will refuse connection
   entirely in a future release.

   ssh(1), sshd(8): 時代遅れの RSA+MD5 署名方式を用いる古い
   プロプリエタリなクライアントとサーバからの RSA 鍵を拒否する.
   これらのクライアント/サーバとの接続はまだ可能だが, DSA 鍵のみが
   受けつけられる. また, OpenSSH は近い将来接続を完全に拒否するだろう.

 * ssh(1), sshd(8): Refuse old proprietary clients and servers that
   use a weaker key exchange hash calculation.

   ssh(1), sshd(8): より弱い鍵交換ハッシュ計算をする古いプロプリエタリ

 * ssh(1): Increase the size of the Diffie-Hellman groups requested
   for each symmetric key size. New values from NIST Special
   Publication 800-57 with the upper limit specified by RFC4419.

   ssh(1): それぞれの対称鍵のサイズのために求められる
   複数の Diffee-Hellman 群のサイズを増やす.
   新しい値は NIST Special Publication 800-57 からの もので,
   RFC4419 で指定された上限がある.

 * ssh(1), ssh-agent(1): Support pkcs#11 tokes that only provide
   X.509 certs instead of raw public keys (requested as bz#1908).

   ssh(1), ssh-agent(1): 生の公開鍵の代わりに X.509 証明書を提供する
   場合にのみ pkcs#11 をサポートする (bz#1908 で依頼された).

 * ssh(1): Add a ssh_config(5) "Match" keyword that allows
   conditional configuration to be applied by matching on hostname,
   user and result of arbitrary commands.

   ssh(1): ssh_config(5) の "Match" キーワードで, ホスト名やユーザ

 * ssh(1): Add support for client-side hostname canonicalisation
   using a set of DNS suffixes and rules in ssh_config(5). This
   allows unqualified names to be canonicalised to fully-qualified
   domain names to eliminate ambiguity when looking up keys in
   known_hosts or checking host certificate names.

   ssh(1): ssh_config(5) の DNS 拡張子の集合とルールを用いた
   修飾されていない名前を 完全修飾パス名(FQDN)に正規化することで,
   known_hosts 中の鍵を検索する場合やホストの証明書名をチェックする際の

 * sftp-server(8): Add the ability to whitelist and/or blacklist sftp
   protocol requests by name.

   sftp-server(8): sftp プロトコル要求を名前でホワイトリスト化
   かつ/ないし ブラックリスト化する機能を加える.

 * sftp-server(8): Add a sftp "fsync@openssh.com" to support calling
   fsync(2) on an open file handle.

   sftp-server(8): open中のファイルハンドルに fsync(2) を呼び出すのを
   サポートする sftp の "fsync@openssh.com" を加える.

 * sshd(8): Add a ssh_config(5) PermitTTY to disallow TTY allocation,
   mirroring the longstanding no-pty authorized_keys option.

   sshd(8): TY の割り当てを 却下する PermitTTY を ssh_config(5) に 加える.
   昔からある no-pty authorized_keys のオプションの代わりになる.

 * ssh(1): Add a ssh_config ProxyUseFDPass option that supports the
   use of ProxyCommands that establish a connection and then pass a
   connected file descriptor back to ssh(1). This allows the
   ProxyCommand to exit rather than staying around to transfer data.

   ssh(1): ssh_config に ProxyUseFDPass 設定項目を加える.
   接続を確率し接続されたファイルデスクリプタを ssh(1) に戻す
   ProxyCommand の利用をサポートする.
   ProxyCommand が終了しても データの転送をし続けることが可能になる.



 * ssh(1), sshd(8): Fix potential stack exhaustion caused by nested

   ssh(1), sshd(8): ネストされた証明書による 潜在的なスタック枯渇を

 * ssh(1): bz#1211: make BindAddress work with UsePrivilegedPort.

   ssh(1): bz#1211: BindAddress が UsePrivilegedPort と共に動くようにする.

 * sftp(1): bz#2137: fix the progress meter for resumed transfer.

   sftp(1): bz#2137: 中断された転送でのプログレスメータを修正.

 * ssh-add(1): bz#2187: do not request smartcard PIN when removing
   keys from ssh-agent.

   ssh-add(1): bz#2187: ssh-agent から鍵を削除する際に スマートカードの
   PIN を要求しない.

 * sshd(8): bz#2139: fix re-exec fallback when original sshd binary
   cannot be executed.

   sshd(8): bz#2139: オリジナルの sshd バイナリが実行できない場合に

 * ssh-keygen(1): Make relative-specified certificate expiry times
   relative to current time and not the validity start time.

   ssh-keygen(1): 相対指定された証明書の有効期限を 妥当性検証の開始時間
   ではなく 現在時刻に対応させる.

 * sshd(8): bz#2161: fix AuthorizedKeysCommand inside a Match block.

   sshd(8): bz#2161: Match ブロック中の AuthorizedKeysCommand を修正.

 * sftp(1): bz#2129: symlinking a file would incorrectly canonicalise
   the target path.

   sftp(1): bz#2129: ファイルのシンボリックリックが

 * ssh-agent(1): bz#2175: fix a use-after-free in the PKCS#11 agent
   helper executable.

   ssh-agent(1): bz#2175: PKCS#11 エージェントヘルパの実行での

 * sshd(8): Improve logging of sessions to include the user name,
   remote host and port, the session type (shell, command, etc.) and
   allocated TTY (if any).

   sshd(8): ユーザ名やリモートホスト/ポート, セッションの種類
   (シェル, コマンド など), 割り当てられた TTY(あれば)を含む

 * sshd(8): bz#1297: tell the client (via a debug message) when
   their preferred listen address has been overridden by the
   server's GatewayPorts setting.

   sshd(8): bz#1297: サーバの GatewayPorts の設定によって
   クライアントが好む listen アドレスが上書きされた場合に
   (デバッグメッセージで) クライアントに通知する.

 * sshd(8): bz#2162: include report port in bad protocol banner

   sshd(8): bz#2162: 不正なプロトコルバナーメッセージ中で

 * sftp(1): bz#2163: fix memory leak in error path in do_readdir().

   sftp(1): bz#2163: do_readdir() でのエラーパスのメモリリークを修正.

 * sftp(1): bz#2171: don't leak file descriptor on error.

   sftp(1): bz#2171: エラー時にファイルデスクリプタをリークしない.

 * sshd(8): Include the local address and port in "Connection from
   ..." message (only shown at loglevel>=verbose)

   sshd(8): "Connection from .." メッセージで ローカルアドレスとポートも
   含める(loglevel>=verbose のときのみ表示)

Portable OpenSSH:

移植版 OpenSSH:

 * Please note that this is the last version of Portable OpenSSH that
   will support versions of OpenSSL prior to 0.9.6. Support (i.e.
   SSH_OLD_EVP) will be removed following the 6.5p1 release.

   注意: OpenSSL 0.9.6 より前のバージョンをサポートする最後の移植版
   OpenSSH になる. 6.5p1 以降のリリースでは サポート(SSH_OLD_EVP) は

 * Portable OpenSSH will attempt compile and link as a Position
   Independent Executable on Linux, OS X and OpenBSD on recent gcc-
   like compilers. Other platforms and older/other compilers may
   request this using the --with-pie configure flag.

   移植版 OpenSSH は, Linux や OS X, OpenBSD で 最近の gcc のような
   コンパイラを利用している場合に, Position Independent Executable として
   コンパイルしリンクしようとする. 他のプラットフォームや
   より古い/他のコンパイラでは, --with-pie configure フラグを作って

 * A number of other toolchain-related hardening options are used
   automatically if available, including -ftrapv to abort on signed
   integer overflow and options to write-protect dynamic linking
   information.  The use of these options may be disabled using the
   --without-hardening configure flag.

   利用可能であれば, 多数の toolchain 関係の堅牢化オプションが
   自動的に利用される. 符号付き整数オーバーフローで停止する -ftrapv
   や ダイナミックリンク情報を書き込み保護するオプションが含まれる.
   --without-hardening configure フラグで これらのオプションの利用を

 * If the toolchain supports it, one of the -fstack-protector-strong,
   -fstack-protector-all or -fstack-protector compilation flag are
   used to add guards to mitigate attacks based on stack overflows.
   The use of these options may be disabled using the
   --without-stackprotect configure option.

   toolchain がサポートしているならば, -fstack-protector-strong ないし
   -fstack-protector-all, -fstack-protector コンパイルフラグのうちの
   1つが, スタックオーバーフローに基づく攻撃を緩和するガードを
   --without-stackprotect configure フラグで これらのオプションの利用を

 * sshd(8): Add support for pre-authentication sandboxing using the
   Capsicum API introduced in FreeBSD 10.

   sshd(8): FreeBSD 10 で導入された Capsicum API を利用する

 * Switch to a ChaCha20-based arc4random() PRNG for platforms that do
   not provide their own.

   PRNG を提供しないプラットホームで ChaCha20 ベースの arc4random() PRNG

 * sshd(8): bz#2156: restore Linux oom_adj setting when handling
   SIGHUP to maintain behaviour over retart.

   sshd(8): bz#2156: リスタート時に振舞いを保持するために
   SIGHUP の処理時に Linux の oom_adj 設定を復元する.

 * sshd(8): bz#2032: use local username in krb5_kuserok check rather
   than full client name which may be of form user@REALM.

   sshd(8): bz#2032: krb5_kuserok で user@REALM のような形式の完全な

 * ssh(1), sshd(8): Test for both the presence of ECC NID numbers in
   OpenSSL and that they actually work. Fedora (at least) has
   NID_secp521r1 that doesn't work.

   ssh(1), sshd(8): OpenSSH の ECC NID ナンバーの存在とそれが実際に
   機能するかをテストする: (少なくとも) Fedora に動作しない
   NID_secp521r1 がある.

 * bz#2173: use pkg-config --libs to include correct -L location for

   bz#2173: libedit について 正しい -L の場所を含めるために pkg-config --libs


昨日 2013/03/20に突然 電話番号とかMACアドレスとか携帯の契約者idの単なるハッシュにとどめを刺したくなりました.

とりあえず 080[0-9]{8} 形式の電話番号のすべてについて,


なソート済みファイルを作りました. 全部で 4.2GB になりました.

手元の計算機で, 電話番号からハッシュ値の計算に数分, ソートに30分, 分割に数分といったところです.

2013/03/21 追記: ハッシュ値の頭文字で16分割し 625万行ずつのファイルにすると ソートせずに grep しても余裕でした. 時間も1億件やるのに8分台です. ちなみに単に1つのハッシュ値を照合するだけならファイルIOがないので総当たりで3分もかかりません. 春山 征吾のくけー : 電話番号とかMACアドレスとか携帯の契約者idの単なるハッシュにとどめを刺したい その2 - livedoor Blog(ブログ) で詳述してます.

unixuser であればlook(1) で高速に検索できます. 手元のDebian sid(x86_64, bsdmainutils 9.0.4)の look(1) は どうやら 1GB 以上のファイルを扱えないようなので, 2500万行ずつの4ファイルに分割しました. 1ファイルに対する検索は(エントリがあれば)2秒くらいで終わります.

ファイルをどこかで公開しようと思いましたが, 1GB(bzip -9 で圧縮しても 300MB以上になります)のファイルを置けて公開できるサービスがすぐにみつからなかったのでまだしていません.

電話番号には, 070 や 090, 固定電話がまだありますし, 表記としても ハイフン区切りあるなしがあります.

ハッシュ関数もMD5以外に多数あります. 汎用的にするにはもっと空間効率のよいデータ構造を利用したほうがよさそうです(レインボーテーブルなりなんなり).

とはいえ, ある1つのサブシステムで利用される表記やハッシュ関数は通常1つであり, 携帯の電話番号に限ってしまえばこの方法でも十分いけるでしょう.

2011/07/22 RFC 4819 セキュアシェル公開鍵サブシステム を翻訳

2011/07/22 RFC 4819 セキュアシェル公開鍵サブシステム を翻訳. Secure Shell (secsh) - Documents (secsh WG)に挙がっているRFCはすべて翻訳した.

「secure shell」でRFCを検索するとまだ訳していないものがあるので, 今後も翻訳を継続します.

2011/07/21 その3 自社ドメインではない採用サイト


これらのサイトでユーザはブラウザの鍵マーク(など)とドメイン名をチェックすることにより, 真の saiyo.jp や jposting.net に繋がっていることを知ることができる. しかし, 採用サイトの運営会社と表示されている企業が本当に契約しているかどうかを知ることができない.



  • 自社ドメインにページを作る
    • 自社ドメインであっても外部ASPの利用は可能だ(saiyo.jp などが対応しているかは知らない)
  • 独自の会員制度を持っていて応募者がサイトを信用することを期待してよい就活/転職サイトを利用する
    • リクナビやマイナビ, find-jobなど
    • 応募者は, 就活/転職サイトと契約し, 就活/転職サイトが善良にふくまう(表示している企業とまっとうに契約している)ことを期待する
      • saiyo.jp や jposting.net の場合はこのような契約は成立しない. 運営企業の名前はページには表示されていない.

すでに運用しており変更が難しい場合は, 自社ドメインのhttps のページで, これらのサイトがまっとうなものなことを保証する. httpsのページからリンクされていれば最低ラインはクリアしているとは思うが, 個人情報保護方針などを自社ドメインページでも(運営会社との関係を含めて)明示したほうがよいだろう.

2011/07/19 ScalaでSSHクライアントを書いてSSHプロトコルの解説を書いた

2011/07/19 ScalaでSSHクライアントを書いてSSHプロトコルの解説を書きました.

SSHクライアントといっても実用できるものではありません. トランスポートの確立, パスワード認証, リモートでのコマンドの実行のみができます. SSHプロトコルの理解の助けにはなるものができたと思います.

どちらも作ってからちゃんと見直していません. ツッコミは歓迎します. 特に Scalaでそこそこの規模のものを書いたのははじめてのなので, もっとよくできるところがあると思います.


主な理由は転職対策です. 現在も無職ですし就職できたとしてまた無職になることがあるでしょう. 求人への応募の際に自分を良く表現できているコードを提出したいと思い, SSHクライアントという題材を選びました.


現状のharuyama's Profile - GitHub は充実しているとはいいがたく整理もしておらず, このプログラムの作成前は求人への応募でコードの提出を求められた場合も昔のいま見るといまいちなものや小ネタを提出しなければなりませんでした(今回書いたのもあとで見ればいまいちだと思うでしょうけど).


SSHプロトコルの復習とScalaの勉強を独立に考えていました. ScalaのパーサコンビネータでSSHのメッセージのパースをするというのは楽しそうだなと思い, 2つを組合せて1つプログラムを作成することにしました.

とはいえ SSH クライアントを完全に作り込んでもユーザはいないし大変なだけなので, 教育用としてわりきって制限されたものを作ることにしました.

最初はblogでSSHプロトコルの解説を書こうと思っていましたが, wiki のほうがよいと思い wiki にしました.


転職先募集しています. 今日も不採用の通知が決ました. 能力は評価するが適当なポジションがない という理由です. 無職も3ヶ月目になっていますが, 焦らないで探していくつもりです. 転職用情報 - 春山征吾のWiki - livedoor Wiki(ウィキ) にいろいろな情報があります.

RFC4716 セキュアシェル (SSH) 公開鍵ファイル形式 も訳し終えたので公開しました.

2011/07/08 idcon #9 に行く / 自社idプラットフォームの必要性

2011/07/08 家で作業していた. これから idcon #9 に行く.

今回のテーマとは関係なさそうだが, 自社の会員と他者の情報を紐付けたい場合に, 会員idを別々の相手に渡してしまっているサービスは結構ある. ある意味ミニ携帯契約者id状態となっており, idによる名寄せの必要がある. よくある例は, 広告プラットフォームやゲームプラットフォームに自社会員idをそのまま渡してしまっている例だ.

最近はプラットフォーム側でOpenIDに対応している場合もあるが, 同じ自社OpenIDを別々の相手に渡していたら同じことだ.

このため, 多くのWeb系企業は自社のidプラットフォームを持たなければならない.


  • 取引先に渡す情報を暗号化
  • 取引ごとに一意なidを作る. このidからユーザを特定できない.
  • 取引先ごとにid変換を行なう
    • id-id表を持つ
    • idの範囲で衝突しないハッシュ関数を用いる.

2011/06/05 The Pelican Brief 読了 / 外部のフラット形式idの保存方法

前の記事 春山 征吾のくけー : 2011/06/04 サッカー / 他者との間で連携する際のid - livedoor Blog(ブログ) の末尾の記述を変更した. 自社idと他者に提供するidの変換について書き直した.

2011/06/05 The Pelican Brief 読了. 他の作品に比べて短めでその分最後だれなくてよかった.

前の記事では, 自社idを外部に提供する場合にどう名寄せを防ぐかについて書いた. 次は外部のフラット形式なidを自社で利用する場合のメモ.

携帯の契約者idなどプラットフォーム側のフラット形式なidをアプリに提供するプラットフォームが存在する. 携帯の契約者idによる名寄せが可能なことはよく知られている. ソーシャルアプリでも, プラットフォームのidとは独立したidをプラットフォームがアプリ側に提供することが名寄せ対策として必要だ.. がそうなっていないプラットフォームが存在するようだ.

もし, プラットフォームがフラット形式なidをアプリに提供してきたとき, そのidそのものをDBに保持しなくてもいいならば, idを変換してDBに保持すればDBの情報が漏洩した際の名寄せのリスクをなくせる.

このとき変換によって重複が発生すると問題なので, id空間に対して重複がないことを確認した鍵付きハッシュ(鍵がないとDBの情報だけで名寄せが可能, アプリごとに鍵を替える)か秘密鍵を捨てた公開鍵暗号(RSAなど)化のような重複のない一方向関数(完全ハッシュ関数)が必要となる(後者のアイディアは @ajiyoshi による).

idによる照合の際には, Webアプリ側で変換を施しDBのデータと照合する. これでDBの情報のみからは名寄せのリスクがなくなる.

2011/06/04 サッカー / 他者との間で連携する際のid

2011/06/04 文京区リーグ1部の試合. 2-3(1-1, 1-2)で敗戦. 私は前半だけ出場. いいプレーができなかったし失点にもからんでしまった. 後半の失点は不運もあったので敗戦は残念.


他者との間で連携する際のidについてメモ. あとで別のところでまとめるかも.

国民idの議論ではフラット方式とセクトラル方式で対立しているようだ. Webアプリケーションでは, フラット方式が多いのではないかと思う. たとえば, 自社の会員idをそのまま ASP(広告代理店)のWebAPIに渡している, など. 携帯電話の契約者idもフラット方式だ.

しかし, フラット方式には名寄せの危険がある. ASPの場合, 複数のASPに同じidを渡してしまうと, ASPから情報が漏れたら名寄せされてしまう. OpenID でも複数のサイトに同じ id を用いていると名寄せされる危険がある. 通常はユーザとしてはサイトAとサイトBでは同じOpenID提供者側のidで認証をしたくても, サイトAとサイトBで同じOpenIDである必要はない. OpenIDの例は以下になる.

example.org 側で同じid(会員)に紐づいているとしても, サイトA, サイトBからはOpenIDで名寄せをすることはできない. (もちろん, この場合でも属性情報による名寄せが可能かもしれない.)

崎村さんによると, US ICAM LoA1 認定を受けているところはそのような機能があるそうだ(まだ自分でちゃんと調べていない).

(以下2011/06/05夜に修正した)id提供者側は, 自社idと提供先ごとのidや情報に対して変換を行なう必要がある. OpenIDのように, OpenIDの一意性が必要でかつ自社id<->OpenIDの相互の変換が必要な場合は変換テーブルが必要だろう.

ASPに提供する情報のように自社idから複数の射影が存在してもよいならば, 共通鍵暗号による暗号化が利用できる. ASPに情報(idやマーケティング用の情報)を渡す際に暗号化し, ASPからの成果情報を復号して自社idを入手する. ただし, ASPに渡せる情報には文字数や文字種の制限がある. 暗号化では, 初期化ベクトルやナンスの分情報が増える. また, 英数文字しか使えないASPもあるので適当なエンコーディングが必要となる. ECナビではBase62(Base64ではない)変換を作成して一部で利用していた.

2011/06/03 また不採用 / 共有SSL

2011/06/03 月曜に面接したところから不採用通知. エージェントによると定着性がなさそうと判断されたとのこと. 理由なく定着することはないのでそのとおり. 会社が楽しくなくなっても楽しくしようと努力はするけどね.

ECナビの海の家 Beach House AJITO Special site の問合せページが, https://beachhouse-ajito.sakura.ne.jp/contact だ. これはよくない. ユーザがブラウザの鍵マークを確認して beachhouse-ajito.sakura.ne.jp とちゃんと繋がっていると確認しても, それがECナビが利用しているものかは確認できない. アルバイト採用の受付に利用しているので, https://ecnavi.co.jp/ 以下にページを設けるべきだ(既存のお問い合わせページでもよい).

サービスや技術関係ではない部署のサイトやページは外注まかせになることがあり, 特に管理/検査がおろそかになりがちだ. 本来は会社としてセキュリティ/品質管理をすべきだが, そういう体制ができてないところが多いだろう. ECナビ在職中は自分とは直接関係ない部分でも問題があったり変だと思うところは指摘していた(セキュリティ関係が主だがそうでないものも). セキュリティ以外の指摘については面倒な社員と思われていたと思う.

転職活動中なのでいろいろな会社の採用ページをみている. 採用ページも自社の技術者が関わってない場合が多いのだろう. いけてないページも多い. 技術者に入ってもらおうと思っているなら技術者から見てつっこみどころが少ないページを出してほしいなと思う.

2011/06/02 不採用 / 国民IDと一方向ハッシュ関数

2011/06/02 ebiseedで一緒になった方と昼食. 検索系の話をする. 先週面接した会社は不採用. 面接でしたECナビを辞めるまでの経緯を気にしていたし, 私のやりたいことと会社がやってほしいことがマッチしていないなというのは私も感じていたし相手も感じていたようなので妥当な結果だ.

面接ではECナビを辞める経緯を正直に話している. Twitterにも書いたが, 同じ事が同じ経緯で進んだらまた辞める. ただし, 同じ経緯にならないように次はさらに努力するつもり. そういうリスクがあると知った上で雇ってくれるところを探しています.

国民IDの議論で, 番号を一方向ハッシュ関数で変換したものは対象となるとかという議論があるようだ. 番号を単にハッシュ化しただけなら名寄せできるので是非対象としてもらいたい.

別の話だが, メールアドレスをmd5したら外に出してOKといってるやつらをどうにか潰さないといけない.

  • ライブドアブログ