GitHub の公開鍵で暗号化する ghcrypt の処理内容 - こせきの技術日記
GitHub のユーザ名を指定してファイルを暗号化するツール ghcrypt を作った - こせきの技術日記 の続き。甘い物のことは忘れて、もうちょっとちゃんと書きます。 いくつかバージョンアップを行いました。暗号化はAESで行い、AES のパスフレーズを公開鍵で暗号化するようにしました。現在のバージョンは 0.5 です。 https://github.com/koseki/ghcrypt ghcrypt ファイル名 githubユーザ名(受信者) ghcrypt ファイル名.enc.tar githubユーザ名(送信者)で、暗号化・復号化を行います。 動作環境 OpenSSH の 5.6 以降が必須です。OpenSSL は 0.9.8 あたりで動作確認をしてます。 OpenSSH 形式の公開鍵を OpenSSL で使える PKCS#8 にエクスポートするために、 OpenSSH 5.6
GitHub に登録した SSH 公開鍵は全世界に公開されている | 774::Blog
意外と知らない人がいるようなのでブログに書いておきます。 GitHub のアドレスのあとに .keys を付けるとその人の SSH 公開鍵が表示される。 たとえば id774 さんの公開鍵であれば https://github.com/id774.keys を参照すれば良い。 ぜひ自分のアカウントで試してみて欲しい。 新規に用意するサーバーの ~/.ssh/authorized_keys に上記アドレスを wget したものを置いて適切なパーミッションを設定しておけばすぐに公開鍵認証ができるというわけである。 もうそろそろ公開鍵をメールで送ってくれとかいう文化が滅亡して GitHub から勝手に公開鍵を持っていくのが常識な世界になってほしい。
git による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
全てのクリエイターには「中田ヤスタカにとってのCAPSULE」が必要である
タイトルは大真面目です。煽ってすみません。解説します。 唐突ですが、プロとしてメディアコンテンツを作る仕事をしていると、しばし「自分が作りたいもの」と「仕事として作るべきもの」のギャップに葛藤する場面に遭遇します。自分の個人的な趣味趣向や興味関心と、世の中のニーズがマッチしない、ということです。「本当はヘヴィメタが好きなんだけど、それじゃ売れないから（仕方なく）J-POPの曲を作ろう」みたいなやつです。 こういうギャップは、音楽でも文章でも映像でもイラストでもファッションでもITでも、クリエイティブな仕事（とは何であるか、ここでは敢えて定義はしません）であればどんな分野でもあると思います。「自分が作りたいもの＝仕事として評価されるもの」という考えの人もいるかもしれませんが、多くの人は多分そうではないです。少なくとも、僕の場合は違います。 当然ですが、 クライアントのオーダーに応えるのがプロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
