パスワードを忘れた? アカウント作成

アカウントを作成して、スラドのモデレーションと日記の輪に参加しよう。

13641713 journal
日記

ko-zuの日記: ubuntu bionicに移行するもlxdのメモリリークがひどい 1

日記 by ko-zu

centos6で構築されていたadblockリゾルバをbionic+一部lxd上に移行してみた。
とりあえず動作はしているがlxd 3.0.1でのメモリリーク、一日数十MBってリリースしちゃダメだろうこれ……

と思ってlxdのgitみると開発者は4人だけ。プロダクトとして死にそうなのでステージング以外のvmはlxd無しで構築。ステージング環境としてはsnapshot楽で便利なんだけど。

13469151 story
バグ

iOS 11で「it」と入力できないバグ 68

ストーリー by hylom
It-can't-be-input 部門より
headless曰く、

iOS 11で「it」と入力できない問題が発生し、少なくとも数百人から苦情が出ているそうだ(Mac RumorsThe Register)。

問題はテキスト入力フィールドに「it」または「It」と入力し、スペースを入力すると「I.T」に変換されてしまうというものだ。QuickTypeの予測入力候補には「I.T」が提示されているが、候補をタップしなくても入力されてしまうという。問題は特定の環境でのみ発生するようで、Mac Rumorでは再現できなかったとのこと。

回避策としては予測入力の無効化やユーザー辞書に「it」を登録するなどの対策が考えられる。ただし、「is」が「I.S」に変換されるとの報告も11月初めに出ており、報告者はこれらの対策には効果がなかったと述べている。この報告者によれば、問題は10月初めから発生していたようだ。

iOS 11では単語「I」を正常に入力できない問題が発生し、iOS 11.1.1で修正されている。こちらの問題に対するAppleからのコメントは出ておらず、修正の対象にならなかったとみられる。

13414175 journal
日記

ko-zuの日記: DevFoxからアドオンが消えた

日記 by ko-zu

ついにWebExtension強制となった。
自分にとってのFireFoxを使う理由の9割が拡張機能なのでchromeか。
WebExtension拡張より類似のChrome拡張のほうが見つかる可能性が高いと思うのは自分だけかな?

13001030 story
お金

英国の新5ポンド紙幣に微量の獣脂が含まれることが判明し、反対運動が起こる 124 Screenshot-sm

ストーリー by headless
微量 部門より
9月に発行が始まった英国の新5ポンド紙幣に微量の獣脂が含まれていることが明らかになり、絶対菜食主義者などの間で反対運動が広がっている(The Registerの記事[1][2]VICEの記事The Guardianの記事CNN Moneyの記事)。

新5ポンド紙幣は樹脂製のポリマー紙幣で、現在の古くなった紙製の5ポンド紙幣を2017年5月までに置き換える計画だ。ポリマー紙幣は環境負荷が低く、高度な偽造防止が可能で丈夫といった利点が強調されているが、原料のポリマーペレットに微量の獣脂(tallow: 牛脂または羊脂)が含まれていることを英中央銀行が公表したことで、強い反発を受けることになる。

Change.orgでは、紙幣での獣脂使用中止を英中央銀行に求めるキャンペーンが実施されており、開始から5日で12万人を超える賛同者を集めている。この数は英国内での象牙市場廃止アナグマの殺処分中止動物虐待に対する量刑を重くするといった英政府および国会の請願サイトでの署名活動で集まった署名よりも多い。先日成立したInvestigatory Powers Act撤回を求める署名もようやく15万人を超えたところだ。英国人だけが署名できるこれらの署名活動と、Change.orgのキャンペーンは単純に比較できないが、注目度は高いようだ。
12968336 comment

ko-zuのコメント: Re:Firefox 49.0.2で4GB超えられました (スコア 1) 2

by ko-zu (#3106655) ネタ元: Firefoxのメモリ消費量を増やす方法を求む

51.0a2 (2016-10-30) (64-bit)
タブを開きつづけると2GBまでは順調に増加。そこで増加ストップしてCPUを食いつづける。

マルチプロセスの合計は3GB超えているのと、瞬間的に2.3GBとか表示されるので32bitアドレスしてて確保不可というよりGC閾値かなにかの設定がよくないっぽいのだけど、mem関係のabout:configを見回しても初期値ばかり。なにが悪いのか……

ありがとうです。49に戻してみようかな

12967201 journal
日記

ko-zuの日記: Firefoxのメモリ消費量を増やす方法を求む 2

日記 by ko-zu

Firefox(少なくともwindows版 dev build)はx86_64でもメモリ消費を2GB以下に制限しようとしているらしい。この上限はいくら空きメモリがあっても変わらず、設定ファイル周りにそれらしい項目がない。

実装の中身を知っているわけではないけれど、挙動からすると32bit時代に書かれたメモリ管理実装に確保上限がハードコードされてしまっているのだろう。2GB以上のメモリ確保を必要とする処理、例えば複数ウィンドウを表示しようとすると、過剰にオブジェクト削除・再描写処理やGCなどのメモリ再配置が走っているようだ。
2GB弱消費している状態でCPUを1コア常時食いつぶすという現象がしばしば発生する。

表トピックのコメントが指摘してるのはこれじゃなかろうか?

12908769 comment

ko-zuのコメント: Re:パスワードの定期的変更 (スコア 1) 38

X秒毎定期変更論者『利用者がX+1秒後(!)に変更するまでの期間、利用者はずっとリスクにさらされていたわけだが、X+1秒毎定期変更論者にとって、このリスクは許容可能なのかね。』
帰納により0秒毎定期変更以外は4年毎定期変更も1000年毎定期変更も危険である。

というのは冗談として、これはリスクだけを見た相対的比較ではなくコスト対リスクの問題。ゼロか否かというだけなら定期的変更も漏洩発覚時の変更もどちらも効果はゼロではない。コストを含めた定量的比較が難しいから議論している。
また確率的な事象に対して事例が一つある、なんて主張するのは、当り番号がわかってからあの時くじに投票しておけば、と同じで意味が無い。

ところで定期変更の強制はパスワードの使い回しや脆弱化を助長しかねない。そのコストを必要論者はどのように許容しているのかな?

12906729 journal
日記

ko-zuの日記: DNS Amp

日記 by ko-zu

リゾルバのログにはそれっぽいのが見つからなかった。
クエリ自体あまり見えてないのでフィルタが効いてたのか単にオープンリゾルバスキャンしてるのが別組織なのか

12597276 submission
セキュリティ

同一の秘密鍵が異なる製品間で使われている問題

タレコミ by Anonymous Coward
あるAnonymous Coward 曰く、
多数のネットワーク機器などで、同一のHTTPS証明書や秘密鍵が使われているという(ITmedia)。オーストラリアのSEC Consultによる調査で明らかになったもの。

同じメーカー、製品ライン内だけでなく、複数のベンダー間で同じ証明書や鍵が使われているケースもあったそうだ。証明書や秘密鍵がユニークなものでない場合、中間者攻撃などに悪用される可能性がある。
12584258 story
セキュリティ

Gmail、暗号化されていない経路で受信したメールに警告を表示へ 43

ストーリー by hylom
メールの中身を第三者が見ることができるという常識はいつか変わるのか 部門より
あるAnonymous Coward 曰く、

Gmailが暗号化されていない経路で受け取ったメールについて、警告を表示するように変更するという(TechCrunchGoogle Online Security Blog)。

GoogleのTransparency Reportによると、TLSを使った暗号化経路を使ったメールはGmailからの発信で81%、受信で57%という割合だそうだ。また、ドメイン毎ではdocomo.ne.jpとezweb.ne.jp、softbank.jp、softbank.ne.jpのすべてと、rakuten.co.jpとyahoo.co.jpのほぼすべては暗号化されていない。

12550098 comment

ko-zuのコメント: Re:LINEの中の人は 「なりすまし」 が可能 (スコア 1) 46

問題なのは"簡単で効果的な"公開鍵の交換手段が無いことです。
まともな実装と信頼できる鍵交換手段さえあればリバースエンジニアリングで現代暗号の通信は盗聴できません。

12549885 comment

ko-zuのコメント: Re:LINEの中の人は 「なりすまし」 が可能 (スコア 2) 46

信頼されている認証局が公的に発行するのとLINEがLINEのために発行するのでは大違いです。

公的なCAも不正な証明書を発行すればなりすましできますが、それは現実的ではありません。CAがまがりなりにも信頼されているのは不正が技術的に可能・不可能ではなく、不正を第三者が検証できると考えられていることと、不正によって信頼を失ってブラウザベンダやユーザに失効させられるリスクを背負っているからです。

LINEがLINEの発行したIDに対してLINEのクライアントアプリでのみ検証可能な公的でない証明を与えるのでは意味がありません。またLINE以外による盗聴を防ぐだけであればエンドツーエンド暗号化は不要です。

12549796 comment

ko-zuのコメント: その鍵はどうやって検証したの? (スコア 1) 46

クライアント間で公開鍵をセキュアに受け渡しする必要があるわけですが、どうやって実装してるんですかね?
公開鍵の所有者確認をLINE側しかできないのであればメッセージだけ暗号化してもLINEが中間者になれるのは変わらないのですが。

12523190 comment

ko-zuのコメント: 4単語で強度は十分(ただし乱択が適切な場合に限る) (スコア 2) 47

英数+記号2で6ビットなので、パスワード認証に最低限必要と思われている8文字で2^48通り。
小さな辞書8192語としても2^13で、数万語の普通の辞書から乱択するかぎりは4つで9~10文字パスワードと同程度になりますね。認証なら十分の強度と思われます(もちろん暗号化には不十分)

ただこの乱択がやっかいで #2887064 みたいに『思いつきで4単語選ぶ』と誤解する人は少なからず出そうです。
同じパスフレーズ生成手法に関する以前のストーリー NSAでも破れないが、覚えやすいパスフレーズ でも指摘しましたが、数学的なランダム生成しないとかえって脆弱になってしまう可能性を排除できません。

typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

読み込み中...