ko-zuのコメント: ハッシュなのか暗号化なのか区別して (スコア 1) 75
不可逆なハッシュだけ保持しているのを暗号化と(間違って)呼んでいるのか、鍵があれば管理者が復号できる可逆な暗号化なのか。
記事にするなら区別して確認してほしいところ。
こちらは、ko-zuさんのユーザページですよ。 アナウンス:スラドとOSDNは受け入れ先を募集中です。
不可逆なハッシュだけ保持しているのを暗号化と(間違って)呼んでいるのか、鍵があれば管理者が復号できる可逆な暗号化なのか。
記事にするなら区別して確認してほしいところ。
saltは万一のハッシュ漏洩時に簡単にレインボーテーブルが作られない・使われないように、ハッシュ関数自体をユーザーごとにわずかに変える(塩を振って味付けする)ためものなので、平文で保存され、最悪漏洩しても構わないものです。
あるsaltのハッシュからパスを推定できたとしても、同じパスの他のユーザはsaltが違うので特定できません。
centos6で構築されていたadblockリゾルバをbionic+一部lxd上に移行してみた。
とりあえず動作はしているがlxd 3.0.1でのメモリリーク、一日数十MBってリリースしちゃダメだろうこれ……
と思ってlxdのgitみると開発者は4人だけ。プロダクトとして死にそうなのでステージング以外のvmはlxd無しで構築。ステージング環境としてはsnapshot楽で便利なんだけど。
ついにWebExtension強制となった。
自分にとってのFireFoxを使う理由の9割が拡張機能なのでchromeか。
WebExtension拡張より類似のChrome拡張のほうが見つかる可能性が高いと思うのは自分だけかな?
51.0a2 (2016-10-30) (64-bit)
タブを開きつづけると2GBまでは順調に増加。そこで増加ストップしてCPUを食いつづける。
マルチプロセスの合計は3GB超えているのと、瞬間的に2.3GBとか表示されるので32bitアドレスしてて確保不可というよりGC閾値かなにかの設定がよくないっぽいのだけど、mem関係のabout:configを見回しても初期値ばかり。なにが悪いのか……
ありがとうです。49に戻してみようかな
Firefox(少なくともwindows版 dev build)はx86_64でもメモリ消費を2GB以下に制限しようとしているらしい。この上限はいくら空きメモリがあっても変わらず、設定ファイル周りにそれらしい項目がない。
実装の中身を知っているわけではないけれど、挙動からすると32bit時代に書かれたメモリ管理実装に確保上限がハードコードされてしまっているのだろう。2GB以上のメモリ確保を必要とする処理、例えば複数ウィンドウを表示しようとすると、過剰にオブジェクト削除・再描写処理やGCなどのメモリ再配置が走っているようだ。
2GB弱消費している状態でCPUを1コア常時食いつぶすという現象がしばしば発生する。
表トピックのコメントが指摘してるのはこれじゃなかろうか?
X秒毎定期変更論者『利用者がX+1秒後(!)に変更するまでの期間、利用者はずっとリスクにさらされていたわけだが、X+1秒毎定期変更論者にとって、このリスクは許容可能なのかね。』
帰納により0秒毎定期変更以外は4年毎定期変更も1000年毎定期変更も危険である。
というのは冗談として、これはリスクだけを見た相対的比較ではなくコスト対リスクの問題。ゼロか否かというだけなら定期的変更も漏洩発覚時の変更もどちらも効果はゼロではない。コストを含めた定量的比較が難しいから議論している。
また確率的な事象に対して事例が一つある、なんて主張するのは、当り番号がわかってからあの時くじに投票しておけば、と同じで意味が無い。
ところで定期変更の強制はパスワードの使い回しや脆弱化を助長しかねない。そのコストを必要論者はどのように許容しているのかな?
リゾルバのログにはそれっぽいのが見つからなかった。
クエリ自体あまり見えてないのでフィルタが効いてたのか単にオープンリゾルバスキャンしてるのが別組織なのか
血圧の低下とか謳うのって法的に大丈夫なのだろうか?
多数のネットワーク機器などで、同一のHTTPS証明書や秘密鍵が使われているという(ITmedia)。オーストラリアのSEC Consultによる調査で明らかになったもの。
同じメーカー、製品ライン内だけでなく、複数のベンダー間で同じ証明書や鍵が使われているケースもあったそうだ。証明書や秘密鍵がユニークなものでない場合、中間者攻撃などに悪用される可能性がある。
物事のやり方は一つではない -- Perlな人