先日転職ドラフトの情報漏洩事故がありましたね。この事故に対する重大さの感覚がエンジニアと非エンジニアで(さらにいうならエンジニア間でもレベルによって)まるで違うように思えたので、ちょっと取り上げます。
先日転職ドラフトの情報漏洩事故がありましたね。この事故に対する重大さの感覚がエンジニアと非エンジニアで(さらにいうならエンジニア間でもレベルによって)まるで違うように思えたので、ちょっと取り上げます。
需要がどれだけあるかわかりませんが、使えたら使ってください。POSIX sedでもGNU sedでも動作します。
sed -r \ -e 's/%/%25/g' \ -e 's/\$/%24/g' -e 's/\(/%28/g' -e 's/\)/%29/g' -e 's/\*/%2A/g' -e 's/\+/%2B/g' -e 's/\//%2F/g' -e 's/\?/%3F/g' -e 's/\[/%5B/g' -e 's/\]/%5D/g' \ -e 's/!/%21/g' -e 's/#/%23/g' -e 's/&/%26/g' -e "s/'/%27/g" -e 's/,/%2C/g' -e 's/:/%3A/g' -e 's/;/%3B/g' -e 's/=/%3D/g' -e 's/@/%40/g' \ -e 's/ /+/g'
関数化すれば、シェルスクリプト内でパイプ的に使えるのでまあまあ便利かも?
function urlencode() {
sed -r \
-e 's/%/%25/g' \
-e 's/\$/%24/g' -e 's/\(/%28/g' -e 's/\)/%29/g' -e 's/\*/%2A/g' -e 's/\+/%2B/g' -e 's/\//%2F/g' -e 's/\?/%3F/g' -e 's/\[/%5B/g' -e 's/\]/%5D/g' \
-e 's/!/%21/g' -e 's/#/%23/g' -e 's/&/%26/g' -e "s/'/%27/g" -e 's/,/%2C/g' -e 's/:/%3A/g' -e 's/;/%3B/g' -e 's/=/%3D/g' -e 's/@/%40/g' \
-e 's/ /+/g'
}
echo "a*a + b*b != c*c" | urlencode
制御文字やASCII範囲外の文字には対応していないので限定的にしか使えませんが、場合によってはまあ使えるんじゃないかと思います。
ちゃんとしたものが必要なら、JavaScriptなりPHPなり専用の関数を備えた言語で書くのが確実です。
Web標準に新たなステータス「Baseline」が登場。変化し続けるWeb標準のうちWeb開発者が安心して使える機能群を示す。MDNドキュメントなどで表示開始
これは朗報。特に「Chromeだけで動けばいいや」ではなくて多くのブラウザーに対応したいサービスにとってはいい規定だと思います。
今までは、使いたい機能がCan I use...とかでどのブラウザに対応してるかを一々調べた上で独自の基準で採用するかどうかを決めていたと思いますが、今後は「Baselineに載っているかどうか」という簡単な基準を使えるようになるので、システムの発注側にとってもありがたい基準なのではないでしょうか。
「辞書に載っている単語を含めてはいけない」「120日ごとに新しくパスワードを設定すること」などバカげたパスワードのルールを持つサイトを集めた「Dumb Password Rules」
パスワードに関しては以前にもこのブログで書きましたが、こちらの記事では具体的なサイトも含めて公開されています。
以前のブログの内容と重複しているもの・いないものが色々ありますが、重複していないものだと定期的にパスワードの更新を要求されるのはイヤですね。どこかの研究で、「パスワードを定期的に更新するとかえって危険になる」というような内容を見たことがあります。詳しい内容は忘れましたが、定期的に更新するとどれが現在使っているものかわからなくなったり、覚えやすいパスワードを使うようになったりする・・・みたいな話だったかな。
あとはキーパッドによる入力を強要されるのもダルそう。キーロガーを警戒しているのかもしれませんが、ダルいだけでなくキーの順序がランダムなので入力ミスが多そう。そんな独自仕様を作るより、WebAuthnにでも対応してくれたほうがよっぽど安全なんですが。。。
説明がややこしくてなんのこっちゃという感じですが、ようするにどういう影響があるかというと
ということです。デジタル署名を使っていないとか、そもそもGnuPGを使ってないという場合は影響ありません。あとUbuntuのようにGentoo Linux以外を使っている人も影響ありません。
今まではパスフレーズが必要なときはpinentryがGNOME Keyringに入っているパスフレーズを参照して自動入力してくれたので手動では何も入力する必要がなかったんですが、つい最近から急に入力ダイアログが出始めました。
PAMの設定も問題なく、ログイン時に自動的にGNOME Keyringが解錠される設定はこれまでと変わっていません。
結論を書くと、Gentoo Linuxのpinentryパッケージがv1.2.1-r2でgnome-keyring
USEフラグをkeyringに改名したのが原因です。
対応は、インストール時に設定しているgnome-keyringフラグをkeyringにしてやればOK。
いや勝手なことすんなし。せめてeselect news readコマンドで注意喚起してくれ。
とりあえず、Gentoo Linuxユーザーで、2023年5月20日前後から急にGnuPGのパスフレーズプロンプトが表示されたというピンポイントな悩みの方がいたら本記事が役に立つかもしれません。
去る5月9日に関西Node学園 10時限目を開催しました。コロナ鍋で中々オフライン開催できなかったのですが、3年ぶりに開催することになりました。
個人的にはJSConf JP(旧Node学園祭)の運営のお手伝いをしていますが、地元の関西Node学園の運営にはほとんど関わっていませんでした。今回はちょっとだけお手伝い。
そしてついでに登壇もしてきました。話したネタはv19.7で追加されたSingle Executable Applications。以前にちょっとここでも触れました。
スライドはこちらです。以前のブログを書いた時から、仕組みをちょっとだけ調べました。
スライドに出てきた実装例はこちらにあります。好きに使ってください。