home ホーム search 検索 -  login ログイン  | help ヘルプ

find 検索

1 - 10 / 1320    1  2  3  4  5  6  7  8  9  10   [>]  [>|][>|]
タイトル/名前 更新者 更新日
技術/"暗号技術入門"読書メモ msakamoto-sf 2020-09-05 10:37:18
日記/2019/05/06/減量終了、4/18時点の結果 msakamoto-sf 2019-05-06 10:47:11
技術/Security/OAuth msakamoto-sf 2019-05-03 00:38:45
日記/2019/03/31/AC7の攻略メモ msakamoto-sf 2019-03-31 20:53:15
技術/HTML/SVG参考メモ msakamoto-sf 2019-02-09 18:00:03
日記/2019/01/13/ソースコードの内面化 msakamoto-sf 2019-01-13 23:28:45
Java/JREをバンドルしたJavaのパッケージング、あるいはインストーラの作成(2019-01時点参考URLメモ) msakamoto-sf 2019-01-12 20:38:02
日記/2019/01/12/"HTTPS" Proxy (クライアントとプロキシの間もSSL使うタイプ) msakamoto-sf 2019-01-12 19:18:57
Java/diff(差分検出アルゴリズム)のJava実装調査メモ msakamoto-sf 2019-01-06 14:38:22
Java/Markdown処理系, asciidoc処理系のURLメモ msakamoto-sf 2019-01-05 14:09:04
ソート項目 / ソート順     1ページ 件ずつ表示

技術/"暗号技術入門"読書メモ  ↑

所有者: msakamoto-sf    作成日: 2011-01-13 12:10:08
カテゴリ: 読書 

"暗号技術入門"読書メモ。

非常に分かりやすい「入門書」で、おすすめです。
まず図が豊富で文章も簡潔丁寧。あまり詳細まで踏み込まず、基本コンセプトに絞って解説してくれているので概要を把握するにはもってこいです。
そしてなにより、「なぜこの技術が開発されたのか？」「他の技術とどう関連して使われているのか？」「どういう課題が発生するのか？」「その課題を克服するためにどういう技術が編み出されたのか？」という、技術の目的とその積み重ねを丁寧に追っていく点が素晴らしいです。

例えばPKIとは何かという疑問に対して、「PKIとは○○だよ」と教えてくれる資料はたくさんあります。
しかし、「なぜPKIが必要だったのか？PKIで克服しようとした課題はなんだったのか？PKIを導入しても解決できない課題はなにか？」という部分まで解説してくれるのが本書です。
さらに、それら要素技術がどのように組み合わされて実用化されているのか、PGPやSSLを例に応用例を分かりやすく示してくれています。

どの技術も、それまでの技術の積み重ね、「巨人の肩に乗った」成果ではあります。そしてこの本は、暗号技術に付いての積み重ねを分かりやすく俯瞰し、把握できるよう工夫されています。

個別の要素技術について調べていっても、どう繋がっているのか全体像が見えづらくてモヤモヤしている方に、特におすすめです。

(全て表示する)
プレーンテキスト形式でダウンロード
現在のバージョン : 2
更新者: msakamoto-sf
更新日: 2020-09-05 10:37:18
md5:2e1e0deb76de9dd57272f6228bb53309
sha1:b3da6726124756d33b373abee00c23ba0509f210

日記/2019/05/06/減量終了、4/18時点の結果  ↑

所有者: msakamoto-sf    作成日: 2019-05-06 10:27:43
カテゴリ:

日記/2018/12/31/減量折返しポイント通過中 + 2018年まとめ から引き続きやっていた減量だが、4/18に終了した。

2018-09-01 から始めたので、ほぼ8ヶ月に及ぶ結果、73kg台前半に到達した。BMI標準体重 71.3 kg には届かなかったが、+2kg程度なので許容範囲とする。

6週間コースを5周したわけだが、当初計算上は 1周6週間で 4kg 減量できる見込みだった。
しかし実際にやってみたところ、後半は年末年始の行事や風邪でのお休みなどもあり、さらにトレーニング自体に体がなれてしまったらしく（トレーナー談）、1月後半～2月あたりは減量ペースが1周あたり2kg程度までかなり落ち込んだ時期もあった。
そこで、トレーナーからのアドバイスもあり有酸素運動（20分程度の早歩き）を追加してみたところ、どうにか1周あたり3kg程度の減量ペースまで回復できた。

ただし、BMI標準 + 2kg程度にもかかわらず体脂肪率は未だに30%をちょい切って29%程度。こちらが問題だ。
もともと筋肉がつきにくいのか、去年2周ほど回してみた筋肉増量系のトレーニングはほとんど効果が出なかった。
よって、やはり有酸素運動をメインに据えて、今後は体脂肪率を削っていくことに専念すべきかもしれない。

成人男性で健康的と言えるのは20%未満らしいのだが、うーん、そこまで削るとマラソンランナー的なガリガリ体型になるかもしれない・・・。とはいえ、せめて20%台を安定キープまで持っていきたい・・・。

GW連休で少しリバウンドもしてる。8ヶ月近く続けた食事制限の影響か、胃が小さくなった気もするので、食事量はあまり大食いに戻さず控えめ意識を続け、有酸素運動メインのトレーニングに挑戦してみたい。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-05-06 10:47:11
md5:1bb5f253514416ea05ebd634ef88e276
sha1:e81b32794adff55ed858347773b6b94c1b6d1354

技術/Security/OAuth  ↑

所有者: msakamoto-sf    作成日: 2012-04-16 00:23:54
カテゴリ: OAuth セキュリティ 

OAuth勉強用リンクメモ。

実装

OAuth 1.0 仕様, 参考資料

OAuth 2.0 及び関連RFC

JSONによる暗号処理関連:

アサーション, SAML, JWT との関連:

PKCE関連:

Proof of Posession (PoP: 所有証明)

OpenID Connect:

OAuth 2.0 参考資料

参考書籍

簡単な読書メモ(間違ってる可能性もあるので参考程度に)

  • フロント・チャネル / バック・チャネル : フロントがリソース所有者とブラウザを介したコミュニケーション。バック・チャネルはリソース所有者を介さない、ソフトウェアだけのコミュニケーション。
  • "Bearer" : この場合、小切手や手形の「持参人」としての意味っぽい。運ぶ人、運搬人、あるいは手紙の使者という意味も持つ。ニュアンス的には、「中身が何かは知らないけど、とりあえず重要な情報を持ってきた人」的な感じになると思う。
    • OAuth 2.0 における Bearer トークンのポイントとして、「クライアントはトークンの中身を解析しない/する必要が無い/できない」というのがある。認可サーバから発行されたトークンを、まさに「中身を知らずにとりあえず持参して運んできた人」がクライアント、という見立てっぽい。
  • クライアントは Bearer トークンの中身を知らなくても、保護対象のリソースサーバは知る必要がある場合もある。特に認可サーバとリソースサーバとで、認可した主体やスコープ、有効期限など細かくやり取りしたい場合。
    • → 認可サーバが発行するトークンの中身を、JSONを使って表現力を高め、さらに署名などの暗号技術を組み合わせることでセキュリティを確保する、そのためにJWS/JWTなどが活用される。
  • ただし Bearer トークンの中身にいろいろ詰め込みすぎると、トークンが漏洩したときの影響が大きくなる。リソースサーバが、アクセストークンをもとに認可サーバに対してトークンの詳細をリクエストする仕組みが「トークン・イントロスペクション」として策定された。
  • 構成時シークレット(Configuration Time Secret) : ソフトウェアを構成する際に組み込まれるシークレット。クライアントID/クライアント・シークレットなど。
  • 実行時シークレット(Runtime Secret) : ソフトウェア実行時に生成・取得されるシークレット。認可コードやアクセストークン/リフレッシュトークンなど。
  • 公開クライアント(Public Client) : クライアント内に構成時シークレットを持つことができない。ネイティブアプリやブラウザ内で完結するアプリケーションなど。これらにクライアントシークレットを埋め込んでも、解析されて容易に取り出されてしまい、秘密のままにできない。
    • 公開クライアントでの認可コード付与方式での認可コードとトークンのセキュリティを強化するために、PKCE(Proof Key for Code Exchange) が開発された。認可コード発行時と、アクセストークンへの交換時に、クライアントが生成したchallenge/verifier を認可サーバとやり取りすることで、認可コードの横取りを防ぐ。
  • 機密クライアント(Confidential Client) : 構成時シークレットを保持できる。Webアプリとしてのクライアントなど。
  • ネイティブアプリはコピーされて複数の場所で動くことから、クライアントシークレットを保持できず、クライアントの認証に難があった。
    • → 実行時にクライアントを動的に認可サーバに登録し、認可サーバ側でクライアントシークレットを発行・管理する仕組みが開発された。これはクライアントからの自己申告的な側面も強いように思われ、認証というよりは、同じクライアントIDに基づく複数のクライアントインスタンスを「識別」するためのもの、と考えたほうが良いかも。
  • OAuth が「認証」ではないのはなぜか？
    • そもそも OAuth におけるアクセストークンは、所有者が認可したあとは、所有者がいてもいなくても使える性質がある。grant type によってはそもそもシステム同士の認可だったりして所有者がいない場合すらある。
    • 認可サーバにおいて認可を下す瞬間に、所有者の認証が行われる保証は厳密には無い。システムによる自動作業の可能性もあるし、そこはブラックボックスであり OAuth の範囲外。
    • つまりアクセストークンがあること、イコール、そのアクセストークンに紐づく「誰か」が認証されたこと、という紐付けは OAuth 2.0 の範囲では取り扱っていない。
    • さらに言えば、アクセストークンのライフサイクルと、「認証」情報のライフサイクルが異なる。また、OAuth 2.0 の思想としてクライアント側はアクセストークンの中身を認知しないため、アクセストークンに認証情報を埋め込み認可サーバからクライアントに情報を伝えるのはできない。
    • → ここにおいて、認可サーバからクライアントに、「認証」イベントの発生と認証情報を伝えるための、アクセストークンとは別のライフサイクルを持ったトークンが必要とされる。これが OpenID Connect における IDトークンとなり、表現力とセキュリティを要求されることからJWTエコシステムの技術が使われている。
  • Bearer トークンはクライアントが中身を知らなくても良い反面、漏洩してしまった場合にクライアントとトークンを紐付けるのが難しい問題がある。（中身を知らなくても使える = 攻撃者の手に渡っても使える)
    • これを解決するために、鍵(公開鍵ペア)をトークンをペアにして、クライアント側でトークンと鍵による署名を追加し、保護対象リソース側で検証することによりクライアントとトークンを紐付けられるようにしたが「Proof of Posession : 所有証明」の仕組みっぽい。

全体的にOAuth 2.0を幹とした関連仕様/技術が広がっているが、その関連仕様はなぜ作られたのか、OAuth 2.0だけでは解決できないどのような問題を解決しようとしているのか、またそのためにどういう技術を使っているのか、というのが分かりやすく書かれているのが良かった。
また実際に動く簡易的なシステム一式をJavaScriptのサンプルコードで示し、OAuth 2.0や関連仕様のエッセンスをソースコードで解説してくれるのもユニークであり、またポイントを押さえた解説がありがたい。
おそらく原著の影響と思われるが文章がやや冗長なところはあるものの、2019年時点で OAuth およびそのエコシステムをここまで包括的に解説してくれる書籍は貴重。
今から始めると用語だけでも迷子になりそうな OAuth エコシステムの世界で、分かりやすく整理された道標を示してくれる一冊となっている。


プレーンテキスト形式でダウンロード
現在のバージョン : 2
更新者: msakamoto-sf
更新日: 2019-05-03 00:38:45
md5:88573ca2d8c3acbf00790a1861943126
sha1:93d25b15612aa321cf85e13411d7fa31da7dfdec

日記/2019/03/31/AC7の攻略メモ  ↑

所有者: msakamoto-sf    作成日: 2019-03-31 20:52:22
カテゴリ:

自分がAceCombat7(AC7)で、キャンペーンモードをクリアしたときの攻略メモを整理しました。

キャンペーンモードのストーリー内容・ネタバレなど含まれてますので注意してください。

https://docs.google.com/spreadsheets/d/1DoDbSsDh0MQbeBQPS7O9eXj_9dIJW6Wa-dF2QDdZv5Y/edit?usp=sharing


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-03-31 20:53:15
md5:a767e2e18394255ab7108a229393c033
sha1:5860e9aec66a7bc2cdeb0e7eda285f6c573880f3

技術/HTML/SVG参考メモ  ↑

所有者: msakamoto-sf    作成日: 2019-02-09 17:59:21
カテゴリ: HTML SVG 

参考資料

MDNのSVG資料:

入門記事:

SVG viewBox属性について：

実際に触ってみた時に遭遇したTIPS

塗りつぶしを透明なしにしたい:

  • fill="transparent"
<rect x="130" y="80" rx="10" ry="10" width="60" height="30" stroke="red" stroke-width="2" fill="transparent" />

塗りつぶしを半透明にしたい:

  • fillは塗りつぶしたい色を指定。
  • fill-opacity="0.5" など、小数点で透明度を指定。同様にstroke-opacityも設定できる。
  • 参考 :

SVG image 要素の注意点:

ブラウザ上でSVGを画像化したい:

JavaScriptライブラリ

Raphaelというのが老舗で、開発者が同じで Snap.svg というのが新たに作られたみたい。

比較記事:

2019年2月現在、確かに Snap.svg のプロジェクトは活発であるとは言えない。githubのTOPページで build failing が出たままで放置 + 最後のcommitが2017年というのが若干不安。
完成しているといえば完成しているのかもしれないが・・・。

仕事ではレガシーIEはもう使っていないこともあり、raphaelを使う必要性は今のところ感じられない。今後の仕事でも、レガシーIE(IE8-9)を相手にすることは無いだろう。

他のメジャーどころとしては、D3.jsなどはグラフやデータのビジュアライズに特化してる感じ。Two.js はWebGLやCanvasにも対応したシンプルな感じ。

raphael と Snap.svg の比較に疲れたら、SVG.js のほうが良いかもしれない。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-02-09 18:00:03
md5:821eeac53482f34fb8e75c462db8cd75
sha1:e3ed9772e1d211b113fc7ba1a549d8dcadd9ed6a

日記/2019/01/13/ソースコードの内面化  ↑

所有者: msakamoto-sf    作成日: 2019-01-13 22:47:37
カテゴリ:

この歳になってようやく気がついたが、数年に渡りほぼ自分一人でメンテナンスしているソースコードは、自分そのものだ。

自分の内面的な思考が染み付いていて、どこになにがあるか全て把握し、日々の生活（開発作業）が行われる、家であり寝室であり台所であり浴室でありトイレである。

そもそも会社からの帰り道やプライベートタイム、ましてやお風呂に入ってる間に思いついたり練ったアイデアが展開されているのだから、その点からも自分の内面・プライベートがそのまま延長されたテリトリーであり縄張りである。

そのためか、土足で上がってくるようなエンジニアを想定すると自分でも驚くほど攻撃的な感情が湧く。それは「俺の家で勝手に何してやがんだ！」という感情が最も近い。自分のモノであり、また自分そのものでもある家。それを主人に断りもなく勝手に上がり込んでこちらの流儀などお構いなしに散らかすような人間を想定すれば、怒りが湧いても当然といえる。

逆に、「他所様の家に上がらせてもらってる」という謙虚さが感じられる相手であれば許容できる。具体的には、相手の中の常識や流儀で家を使うのではなく、「お宅の流儀を学ばせてください、お宅ではどうやってますか？これはどう使っていいのですか？」と、こちらの流儀を聞いてくるような相手であれば信頼できる。

少なくとも、どうやら自分は、そう感じてしまうタイプらしい。

もちろん、特に仕事で開発しているものであれば、ソースコードは製品であり、自分そのものとして扱うわけにはいかない。
とはいってもなんだかんだの事情と歴史で、できる範囲で「自分色」は薄めてきたつもりではあるものの、フレームワークの手当が薄いとどうしても自分が作ったオレオレ流儀の部分が大きくなってきてしまう。

例えるなら、もともと売家として自分一人で建て始めた家だが、当面は自分一人しか住まないこともあり、自分が住みながら内装や部屋を増改築している間に、どうしても自分にとって居心地がいいように作ってしまったところが多い。

これをチーム開発に適合させるにはどうすればいいか？
自分一人の内面と濃密に結びついた、内面そのもの。これに入ってくるには、新しい人も相当なストレスというか居心地の悪さにさらされる可能性が高い。
扉の開け閉め、便器の蓋の開閉、トイレットペーパーのブランドや交換方法、台所での細かい道具の使い方、お作法、e.t.c...
それら全てに、それまでただ一人の住人であった自分の内面・価値観・判断基準が染み付いていて、まずはそれに従わないと、家に居させてもらえない。
あるいは、自分がその人を受け容れられなくなってしまう。

そうした感覚無く、「俺は私は」で自分の考えを自分の流儀で設計・コーディングしていくようなタイプはどうしても排斥したくなってしまう。

他者の意見は参考にするなり受け入れる方が良い。
だが、同時に家全体のメンテナンスや維持という責任がある。

家全体の設計の統一感・メンテナンスの容易性を実現するために、絶対に守るべきラインがあるし、絶対とは言わないけどなるべく守ってほしいラインがあるし、妥協できるラインもある。

重要なのは、そのラインが今の所、最初の住人であり数年に渡り家を建て増ししてきた自分の頭の中にしかない、ということかもしれない。

文書化するか、あるいはそれこそつきっきりでペアプログラミングするなりして、自分のお作法・判断基準のラインを徹底的に新しい入居者に叩き込むというのもありだろう。

それでも当面は家全体の責任を負うのが自分であれば、自分が100%納得するか、ある程度妥協できるソースコード以外は全てリジェクトする他ない。
作品というのはそういうものだろうし、今の所もっとも内面が反映され作品としての統一感を出しているのが自分であり、またぼちぼちユーザが使っている以上、自分が納得するか、納得の上で妥協するもの以外は出せない。
というか、出してしまうと、作品としての統一感が崩れてしまったり、結局のところ居住者にとってそこが永遠にストレスになってしまう。
そこだけルールが異なるのだ。

ソースコードは、機能を売るものではあるが、同時に開発者にとっては「棲家」だ。

必要なものがどこにあるか、どういうコンセプトで家具は配置されているか、どこにコンセントがあるか、あるいはどこにコンセントがあるように作られているか、天井の高さは、照明は、床の材質は、家具とのこすれは考えられているか、e.t.c...

これを整えようとすれば整えるほど、整えた人の内面や価値観、判断基準が色濃く生活空間に染み付いてしまう。
避けようが無いのかもしれない。
そのかわり、うまくマッチすれば居住者=開発者のパフォーマンスを最大限引き出すことができる。

とはいえ、全てが「オレ流儀」というわけでもない。
フレームワークを使っていればフレームワークの、ライブラリを使っていればライブラリの、あるいは使っている言語で一般的なスタイルの、それぞれの流儀がお互いに主張する。
それをうまくコーディネートするのも開発者の腕の見せどころだろう。
そういった外部が推奨する流儀やスタイルは、いわば「モジュール化」だ。
ある程度一般化されており、他の人も容易に馴染むことができる。
見慣れた玄関、見慣れた照明スイッチ、見慣れた便器、見慣れた水道蛇口、見慣れたガスコンロ。
別にその家の主に確認を取るまでもなく、自分の経験で問題なく使えるし、主もそれを許容している。だって主も同じように使ってるのだから。

例えば、フレームワーク/ライブラリ/言語のお作法が 3 割で、残りが「オレ流儀」のクラス設計や命名規則などになってたとしよう。
そうなると、他の人が違和感なく作業できる領域が3割で、ほかは逐一、「オレ」にお伺いを立てて「この場合どうしてますか？」と聞かないと、「オレ」は機嫌を損ねてそいつを追い出そうとしてしまう。「オレのやり方を聞かずに、何勝手に自分で使おうとしてるんだ」と。

この状態ではチーム開発は覚束ない。
いくつか解決方法はあると思うが、個人的に挑戦するなら、フレームワーク/ライブラリ/言語のお作法を7割、いや8割程度まで高めて、残りを「オレ」の、流儀ではなくアイデアだけに絞り込む。

つまり「お作法」や「流儀」は可能な限り一般化されたモジュールを使うことにして、本当にコアの思考や言語化し辛い設計の勘所だけを属人性の塊として残す。
実際は「フレームワーク/ライブラリ/言語」が5割、「DDD/関数型プログラミング」などのパラダイム・哲学が3割、「コーディングスタイル・命名規則」が1割で、ここまでが全て一般的に受け容れられているものにして、「オレ流儀」じゃなくて「オレの思考」を残り1割に絞る。

こうすれば、他の人(= 新しい入居者)は「オレ」のお伺いを立てる気苦労がずっと減り、一般化されて学ぶ価値のあるフレームワークやライブラリ/言語/プログラミングパラダイム/コーディングスタイルなどを勉強してすばやく馴染むことができる。

そうなれば、家の増改築は「オレ」一人の仕事ではなくなり、近しいスタイルで力になってくれる戦力が増えるだろう。

気をつけなければならないのが、「オレの常識」を振りかざすのは良くないが、かといって作品等しての統一感を崩すのはもっと良くない、ということ。中長期的なメンテナンスビリティに影響が出てしまう。

理由を示すのが重要だろう。なぜ今はこんな「オレの常識」に従う必要があるのか。それは長期的にどう変わっていくのか。なぜ理不尽で不合理な「オレの常識」に従う必要があるのか。

それはひとえに、自分が売り物としての家のコンセプト・全体設計・品質に責任を負う以上、自分が納得できないものは絶対に入れられない。そうである以上、今は自分のこれまでの判断基準の積み重ねとしての「お作法」「流儀」を学び、まずはそれを真似ることに徹してほしい。
徐々に「オレ独自」の色を削っていく。そうすることで、お互いに納得度の高い仕事をできるようになる・・・多分・・・そうなるといいなぁ・・・。

このようなことをつらつら考えるに、やはり息の長いアプリケーションでは、ある程度大きなフレームワークの方が良いかもしれない。
フレームワークが小さいと、不足部分を手作りすることになり、そこで初期開発者の内面が色濃く出てしまう。
そうではなく、大きめのフレームワークを選択して、初期からフレームワークの流儀にうまく従うことで、初期開発者の内面の色付けを押さえて、入りやすいものにできるのかもしれない。

とはいっても、大きいフレームワークって結局そのフレームワークの開発者たちのお作法や流儀の塊なので、それを学んで適切に使いこなすのがまた一苦労なのだけれど・・・。

そんなことをつらつら風呂に入りながら考えていた。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-13 23:28:45
md5:6fe4e5542032f16f2b2542206d0d244d
sha1:ddbb2acc675befa77c834cc9e89c8dfb56b107a1

Java/JREをバンドルしたJavaのパッケージング、あるいはインストーラの作成(2019-01時点参考URLメモ)  ↑

所有者: msakamoto-sf    作成日: 2019-01-12 20:37:42
カテゴリ: Java 

背景：

  • Java11でpublic JREが無くなる。このため、JREをインストールしておいてもらえば、あとは実行可能jarファイル渡してダブルクリックするだけでOS側の拡張子連携によりJavaプロセス起動、という方式が採用しづらくなる。
    • public JREが無いということは、OS側に拡張子 .jar をjavaコマンドで実行する連携設定をインストーラ一発で入れられないということ、と理解して上の文章を書いてる。
    • 参考 : Java 11ではPublic JREが本当になくなりました - AOEの日記
  • JDK8までは javapackager というコマンドで、Inno Setup などサードパーティ製のインストーラ生成ツールと連携し、JREバンドルしたパッケージングが可能だった（っぽい）。
  • Java11から、JREバンドルして、exeか何かダブルクリックするだけで実行できる配布方式どうすりゃええねん・・・。

この辺の、2015年・・・Java8が出る前後くらいの時代の、方式やツール類が比較的よくまとめられてるのが以下：

とはいえ2019年になりJava8がEOL、Java11がLTSとなった今、javapackagerに頼ることは(少なくともFXアプリを作るのでなければ)厳しい。

一応、Java11にポーティングされたjavapackagerが単体であるにはあるらしく、それを使ったビルド方法の解説記事もあるが・・・ちと厳しいかなぁ・・・。

仕事柄触ってる有名どころのJavaアプリ + インストーラとしては、PortSwigger の Burp Suite がある。これ、インストーラのEXEが提供されてて、インストールするとjarとjreがバンドルされてて、OSのアプリ一覧(Windowsならスタートメニュー)にも登録され、簡単に起動できる。

Burp Suite の場合、INSTALL4J という商用製品を使ってるらしい。C:\Program Files\BurpSuiteCommunity\.install4j というフォルダができてて、そこにいろいろ入ってた。

良さそうではあるが、有償なのが敷居が高い・・・。製品というわけでもなく、社内でちょっと使う程度のツールでどこまで金を出せるか・・・。あと、OSS作りたいとか。

もちろんJava開発陣も javapackager が無くなったことは気にしてるらしく、以下のJEP 343でjavapackagerと同等で、もうちょっとシンプルなパッケージングツール作りたいね、という話は進んでるらしい。

が、さすがにこれのリリースを待つのは気が長すぎる、現状の範囲内でJava8～Java11の移行期を乗り切れる無償の、できればOSSフレンドリなツールはないか？
→とりあえず見つかったのが以下。

Win7環境とちょっと古い記事になるが、実際に3種類試した人が記事書いてくれてた：

ただ、上記記事では JSmooth と exewrap が若干微妙なところがあるらしい。起動後しばらくしてマウスカーソルが砂時計になったり(JSmooth)、jvm.dllがロードできない(exewrap)など。

以下はexewrapを使って配布パッケージを作ってみた人の記事。ここでは問題なさそう。

ざっとググった主観だが、利用者と実績が一番多いのは Launch4j に思える。StackOverflowでの質疑応答も多いっぽい。
また、exewrapはWin専用だが、Launch4j はMacも対応している(要 Xcode)。
Launch4jはJREバンドルも対応してるようなので、最も無難な選択肢に思える。

Launch4jを使った記事の参考:

また、Java9でのモジュール導入により、Java11にもなれば jdeps + jlink で必要なモジュールのみでJREの容量を削減できらしい。これも Launch4j と組み合わせられると嬉しいかも。

機会があれば、Launch4jちょっと触ってみたい。GUIだけなら単体で動かせるようだが、Mavenプラグイン経由となるとどうもMinGWが必要っぽいのでそのあたりの差異も試してみたい。

以上。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-12 20:38:02
md5:f53106e41c8f4d192e2e28142bc40720
sha1:9c4250dc422b27efc23da248692cd65bac6f0a39

日記/2019/01/12/"HTTPS" Proxy (クライアントとプロキシの間もSSL使うタイプ)  ↑

所有者: msakamoto-sf    作成日: 2019-01-12 19:02:02
カテゴリ: HTTP Proxy SSL/TLS 

昔からのHTTPプロキシでは、HTTPSの場合、最初にクライアントからプロキシに HTTP (= 平文) でCONNECTメソッドのリクエストを送り、プロキシではHTTPSに接続を切り替えてUpgradeレスポンスを返す。

ただ、これだと少なくともHostが平文でネットワーク上を流れてしまう。

2019年1月時点のFirefox, Chrome, curl 7.52.0 以降では、ブラウザ/クライアントから、最初からHTTPSでプロキシにリクエストする "HTTPS" タイプのプロキシがサポートされている。

Firefox:

Chrome:

curl 7.52.0 以降

IE/Edge/Safari/Android/iOSでの対応状況は不明。

以前から SwitchyOmega や FoxyProxy など Chrome/Firefox用のプロキシ切り替え拡張で、プロキシの設定画面でschemaの他にタイプとして HTTP/HTTPS/SOCKS4/SOCKS5 あたりが選べるようになってて、「HTTPとSOCKSはわかるけど、HTTPSってなんじゃらほい・・・？」と不思議に思ってたのが、どうやらこれらしい。

どういう仕組で動いてるかは試したわけじゃないので確証は無いが、Chrome側の上記URLで、簡単に試すために通常のHTTPプロキシとして動作してるSquidに対してstunnelでSSLトンネリングしかければ、HTTPSでプロキシできるらしい。ということは Squid のCONNECT -> Upgrade の流れがそのままHTTPS(というかSSL)になっただけと思われる。SquidとしてはUpgrade返したあとは中の通信は素通しになるので、まぁ最初からHTTPSなら、Squid側としてはなんら変わることが無いのだろう。

Squid自体も https_port あたりの設定値でネイティブに HTTPS プロキシをサポートしているようなので、それで試しても良いかもしれない。

これ、httpスキーマについてもHTTPS プロキシで通せるのかな？ クライアント <> プロキシ間はHTTPSで、プロキシ <> ディスティネーションサーバ間はHTTPになるイメージだけど。
もしそれも可能なら、プロキシの利用者を制限するためにプロキシ認証を使いたいけどプロキシ認証の通信経路は暗号化したいときに最適かもしれない。

最大の難点は対応ブラウザやクライアントが限られること。とはいえ、Chrome/Firefoxで現時点で普通に動くので、一般ユーザ向けであれば採用しやすいかもしれない。アプリ間通信に使うのはcurl以外の対応状況が不明なので厳しいかな？

あと、「これで通信先を完全に隠せる」かというと、そうは行かない気もする。多分 ブラウザ -> プロキシへの最初のHTTPSで、今なら普通にSNIを送るのではなかろうか？そうなると TLS Client Hello パケットの中に平分で最終ディスティネーションのホスト名がSNI拡張フィールドに含まれるため、盗聴されていればどこに接続しようとしているのか、までは見えてしまう。

以上、メモ。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-12 19:18:57
md5:084bc75cb01979ff141ab43c828abef7
sha1:700531ad45fdcc4b6f1078dc98b6483ebc4967f3

Java/diff(差分検出アルゴリズム)のJava実装調査メモ  ↑

所有者: msakamoto-sf    作成日: 2019-01-06 14:37:50
カテゴリ: Java 

see : https://gist.github.com/msakamoto-sf/a42cc2c02d780d95a6af5413a739ded1


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-06 14:38:22
md5:6e9bf1171e05162403329ba4e00ff721
sha1:f484bc02353c4635299ab4520cfff3ec17afe69a

Java/Markdown処理系, asciidoc処理系のURLメモ  ↑

所有者: msakamoto-sf    作成日: 2019-01-05 14:08:21
カテゴリ: Java MarkDown 

Java実装のMarkdownパーサライブラリのURLメモ。

Markdownの仕様 : 2018年にもなると、CommonMark と GFM (Github Flavourd Markdown) がメジャー？

Java実装ライブラリ：

Markdownではないが、Asciidoctorも良さげ。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-05 14:09:04
md5:82ccd9e22243bcb9dda6f89cd437846c
sha1:9895cc67f7cc51c2d0a6af6e18ec5e0748dfe8ec