定義ファイルを KDL ではなく Lisp (Ketos) で書けるようにする by kb10uy · Pull Request #8 · kb10uy/declavatar
https://github.com/kb10uy/declavatar/pull/8
あんまり正気じゃない PR が生えた
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
定義ファイルを KDL ではなく Lisp (Ketos) で書けるようにする by kb10uy · Pull Request #8 · kb10uy/declavatar
https://github.com/kb10uy/declavatar/pull/8
あんまり正気じゃない PR が生えた
curl -sSL 'https://''hub.turnkeylinux.org/api/backup/archive/?turnkey_version='"$PROFILE" | jq --raw-output .archive_content | sed -e 's:_:/:g' -e 's:-:+:g' | base64 -d >"$PROFILE".tgz
declavatar に declavalidate、すき
パラメータを declavariable とでも名付けそうな勢いがある (?)
設定ファイルの拡張子は declisp とか (???)
エディタの検出に考慮して .decl.lisp にしたけどそれ考えなければ本当に declisp にしたかった(？？？)
VScode に built-in で modeline がないのはよくないと思いますの
validate されてほしいという話？ たとえば識別子とか型名を変えたとき置いていかれては困るみたいな
そうそう、$x:ident だと存在しない識別子を書ける……のはいいとして LSP で置換したときに stringify! の中身が置き換わらないみたいなのがある
マクロ中での何事かを考えるなら、たとえば
#[inline(always)]
fn ensure_type<T>(){}
とかを crate local で用意しといて、マクロ中で
ensure_type::<$T>();
を適当な場所に置くことで型であることを確信するみたいな手はなくもない
式を置けないならどこかに where $T: Into<$T> を付けるとかでも良いかも
どちらかというと match arm とか match 式ごとマクロで生やすのが正解なのではという気はしないでもない (できるかは知らん)
stringify_type! マクロの実装例
```
pub(crate) const fn ensure_type<T>(s: &str) -> &str {
s
}
macro_rules! stringify_type {
($t:ident) => {
ensure_type::<$t>(stringify!($t))
};
}
```
必要に応じて $($t:tt)* と $($t)* みたいにしてもろて
token tree だと stringify 時の空白の入れどころとかが安定しなそうだし (rust バージョンを跨ぐと変化する可能性がある)、あまり外部データとのやりとりとかには使うべきではなさそう
He told that he'd already written the cells...
このアカウントは、notestockで公開設定になっていません。
potato.immo というドメインを打つたびに、我ながら良いドメインを取ったなぁという良い気持ちになる
爆発事故の能代ロケット試験棟 修理は困難 解体し当面更地に｜NHK 秋田県のニュース
https://www3.nhk.or.jp/lnews/akita/20231128/6010019734.html
> このため、ＪＡＸＡは、試験棟の損傷が激しく修理は不可能だとして、建物を解体して当面、更地にすることを決めました。
> 「国内ではここにしかない実験設備だったので残念だ。固体ロケット以外の実験はできるので、当面はそれを秋田県の活性化につなげていきたい」
えぇ……
まだフロッピー1枚に収まるサイズ
『スーパーマリオ64』にて、チックタックロックのスター取得について新ルート開拓される。確かに爆速だが、見た目は奇妙 - AUTOMATON
https://automaton-media.com/articles/newsjp/20231128-273661/
TurnKey Linux、ほとんど放置する分にはまあまあ便利だったけど、マイグレーションがクッッッソダルいな……となっています、マジでどうするか
雑に docker on qemu に乗り替えるというのも割と現実的な選択肢に見えてきている
TurnKey Linux のマイグレーションがどうダルいかというと、
* TurnKey Hub を使わないと標準のバックアッププロファイルが使えない
* TurnKey Hub を使うには AWS アカウントの登録が必須 (スキップ不可)
* TurnKey Hub を迂回してバックアッププロファイルを落としてきても使うためのセットアップがダルそう
* 標準のバックアッププロファイルがいろいろ余計なもの (旧バージョンから引き継ぐ必要のなさそうなもの) までまとめてバックアップしてそう (動作未確認なので不明)
* 手動でやろうにもファイルが散らばっており、 confconsole を通して設定したファイルすらまとまっていない
* confconsole --nointeractive --plugin=... のようにして半自動再セットアップすればどうかと思ったが、 plugin の指定方法に関するドキュメントがどこにもないうえ python スクリプトが実行時エラー (TypeError: object of type 'filter' has no len()) を出す
17.2 から 18.0 とかなのでまだ頑張ってみようかなという気持ちにもなるが、マイナーバージョンアップのことなど考えたくもないし、正直この方法はもう駄目だったとして諦める方が良いのではないかという方に傾きつつある
どうせ Webmin とか使ってなかったし、 ansible か何かで最低限必要なものだけゴリゴリ弄るでも良さそうな気がしてきている
ただその一方で、 docker compose を使ったセットアップですら十分ダルかったのに、 lxc 上にほぼ生で web アプリを乗せるのがいかほどダルいかを考えると、今から気が滅入る
* docker on qemu VM: /var/lib/docker が最悪。 hub の rate limit が (普通は問題ないと思うが) 懸案事項。 docker compose を使っても十分ダルい。 docker の IPv6 対応はあまりにも最悪。
* docker on LXC: FS の権限はじめ多数の落とし穴がある。 /var/lib/docker 他の懸念も健在。
* LXC & ansible: 手間としては生で立ててるのとおそらくほとんど同じ。 docker compose よりも数倍ダルそう。
とりあえずこのタイミングで TurnKey Linux のダルさに気付けたのは悪くない
そんなに急いで乗り替えずとも良いというのはあるかもしれん (実際アプリの方はこまめにｱﾋﾟﾃﾞしている) が、それはそれとして、やっぱり bullseye から bookworm に乗り替えられるものなら乗り替えたいという気持ちはまあまあ強い
僕みたいな老害には、パスキーが多要素認証だという主張を理解できないのであった。サービス側で確認するのはパスキーに登録されてる鍵対だけに見える。
パスキー認証の誤解を解く：企業のセキュリティを変える未来の鍵・パスキー - クラウド Watch[Sponsored] https://cloud.watch.impress.co.jp/docs/topic/special/1546577.html
「パスキー」って一体何だ？ パスワード不要の世界がやってくる（3/4 ページ） - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2301/23/news086_3.html
> パスキーでは、ユーザー登録時や生体認証設定時に、ユーザーIDとURLがひも付いた形で“キー”に当たる、「マルチデバイス対応FIDO認証資格情報」（マルチデバイスFIDOクレデンシャル）を端末の安全な領域に保管する。実際のログイン時には、ユーザーIDを入力するか、表示される選択肢からIDを選ぶとFIDOクレデンシャルが要求されるので、生体認証でそれを取り出せばログインできる。
> パスワードを入力することもなく、そもそもパスワードが存在しないので漏えいすることもない。FIDOクレデンシャルはURLとユーザーIDにひも付いた形で保管されているので、見た目が似ていてもURLが異なる偽サイトだと生体認証が求められず、ログインはできないのでフィッシング攻撃にも強い。
これが本質？
この記事を読んだ感じだと、
* 生体認証や PIN などによって、中間鍵を取り出す時点で一度認証をかける (ここで knowledge factor や identity factor を使う)
* 中間鍵を端末にセキュアに保存し、それを端末-サービス間での認証に使う (ここで possession factor を使う)
* これらの2つを合わせれば2要素の認証になる
みたいな感じの二段構成でやっているように見える
とはいえ中間鍵 (multi-device FIDO credentials) を迂闊にクラウドで共有すると最初の1要素が死ぬことになるし、そこはちゃんと E2E 暗号化とかでどうにかやる必要があって、そこで誰を信用する必要があるかというと認証器ベンダーですかね。
たとえばｽﾏﾋｮなら、ｽﾏﾋｮのハードウェアベンダーとOS (クラウド同期システム含む) ベンダー。
ホワイトペーパー：マルチデバイス対応FIDO認証資格情報 - FIDO Alliance
https://fidoalliance.org/white-paper-multi-device-fido-credentials-jp/?lang=ja
> これらのマルチデバイス対応 FIDO 認証資格情報については、ユーザーが必要とする場所でクレデンシャル（認証資格情報）が利用できることを担保するのは OS プラットフォームの責務であるということです。
端末へのセキュアな保存、生体認証とかによる認証、ネットワーク経由での同期、その辺りが OS の仕事ってことよね。
> （FIDO 認証資格情報がマルチデバイス対応資格情報である場合、一部の企業は製品の実装において FIDO 認証資格情報を「パスキー」と呼んでいます。）
パスキーとは multi-device FIDO credentials のことであると。
> パスワードマネージャがパスワードに対して行うのと同様に、基盤となる OS プラットフォームは、FIDO 認証資格情報に属する暗号鍵をデバイス間で「同期」させます。
まあセキュアな保存が anti-tamper とかを含むと考えると、 OS レイヤーでやれということになるよね。
> つまり、ユーザーの同期された資格情報のセキュリティと可用性は、基盤となる OS プラットフォーム（Google、Apple、Microsoft など）のオンラインアカウントの認証メカニズムのセキュリティと、すべての（古い）デバイスが失われたときにアクセスを復活させるためのセキュリティ方法に依存することになります。
たぶんオタク的にはここはポイントで、同期プラットフォーム側での悪意や breach によってセキュリティが破られる可能性があると。
実際 Google か何かのクレデンシャル同期通信の実装がかなり粗雑だった的な話あった気がするし、能力を信頼するにしても倫理についての信用がどうなのかというのもあるし、ここは不安に思う人はいそう
https://defcon.social/@mysk/110262313275622023
これだ。 Google Authenticator が (HTTPS 越しとはいえ) 同期サーバに可読な形で 2FA secrets を送信しているという話。つまり client-to-client の E2E 暗号化をしておらず、 Google が悪用できる形でクレデンシャルが同期されている。
で、 FIDO の話に戻ると、
> これは、例えば AAL3 を必要とするユースケースの基準を必ずしも満たしていないかもしれませんが、パスワードと比較するとセキュリティのレベルは大きく向上しています。前述の各プラットフォームは、高度なリスク分析を適用し、認証時に暗黙的または明示的な第二要素を使用し、これによって多くのユーザーに AAL2 相当の保護を与えています。
リスクではあるが皆が好き勝手パスワード認証システムを用意した挙句ユーザがよわよわパスワードを設定するよりは遥かにマシだよね、というある意味では妥協を前提にした現実的な改善案であるというニュアンスが読み取れる。
> このように、世の中のあらゆるサービスが独自のパスワードベースの認証システムで自活することから、プラットフォームの認証メカニズムの高いセキュリティに依拠することへのシフトによって、インターネットの過度なパスワードへの依存を大規模に有意義に削減することができるのです。
よわよわな可能性のあるオレオレパスワードベース認証が乱立するよりは、ちゃんとした実装への依存が集中する方がセキュリティレベルは上がるよね、と。
ユーザよりはクラウドベンダーの方が信用できるので弱点をそちら側に移していきましょう、という空気を感じるな。ｸｿﾃﾞｶﾃｯｸへの反抗心のあるオタクとしては思うところがないでもない。少なくともセキュリティ意識の弱い人々を対象に考えた施策としては効果的であろうことは認めざるを得ないけど。
sshクライアント側で私有鍵がパスフレーズで暗号化されていたかあるいは私有鍵がパスフレーズなしで保管されているのかを、sshd側が知ることができないように、パスキーで認証に利用する私有鍵を取り出すのにPINか生体識別が必要だったのかをサービス側が検証することができないように見えちゃうんよね。
パスキーのシークレット（レジデントな鍵対）がネットワーク経由で同期されて同期に利用しているアカウントといっしょに取られちゃう問題は、TitanやYubiKeyなどのセキリティキーを使うように†気をつける†ことである程度回避できるだろうとは思っています。でもこれまではセキリティキーは第2要素としてしか扱われてなかったんじゃないかな…。どうしてパスキーになった途端複数要素になるのかな…。
これも結局さっきの FIDO の文書で「OSプラットフォームが責任持つやで〜」とされていたように、端末・OS・同期サービスのベンダーが sane な実装をするという前提で作られた仕組み (つまりそういったベンダーを信用することを込みのシステム) であるという説明になる気がする
別の表現をするなら、信頼できるプラットフォームを用いて passkey を準備することはユーザの責務である、と
ｺﾞｯｺﾞﾖやｱｯﾎﾟﾖを信用していいという前提でなら、たしかに「安全なパスワードを安全に管理する」よりは「信頼できるプラットフォームで同期する」の方がハードルは低いかもしれない (ｱﾝﾁｸｿﾃﾞｶﾃｯｸのオタクはお呼びでないです！)
セキュリティキーをパスキー認証に使うと一発で通るように見えるのは端末自体に possession 以外のロックがかかっている前提で透過的に 一段目はすでに通ってるみたいなイメージなんかな
このアカウントは、notestockで公開設定になっていません。
諦めて TurnKey Linux を毎度セットアップしなおして、 file copy と db backup/restore でどうにか済ますというのが現実的かなという気がしてきた。
だからこそ confconsole 操作の自動化をしたかったのだが…… plugin 指定マジでどうやればいいんだ
Yubico とか AgileBit と同等のレベルで Apple や Google や Microsoft に対してクレデンシャルストアとしての機能について信用を置けるかというと……みたいなところか
というより、 security key は要件としての anti tamper だけでなく、実際にオフラインで保管されるという性質を込みで信用できるトークンなんだけど、 passkey の同期プラットフォームは本質的にオフラインたりえないので “悪用されないという要件” だけあったところでオフライン保管相当の信頼を得ることは絶対に不可能、というところに不可避な差異がある
このアカウントは、notestockで公開設定になっていません。
指紋認証については明確に identity factor で、登録済端末のみという制約は possession factor なのでそこは普通に二要素認証として良いと思うのだが、 PIN というやつの扱いが厄介なんだよなぁ
PIN ってやつは possession factor を補完するものでしかなくて knowledge factor としてカウントするには些か無理があるのではないか、という悩みがある
possession というのを現実に「肌身離さず、他人に一切触れさせず」という形で実現するのが困難なので (たとえば睡眠中は所有デバイスであっても指紋認証を通されるおそれはある)、そこを誤魔化して穴を潰すための PIN であって独立した knowledge factor ほどの強さのある認証には該当しない、という考え方がある
ちなみに最近の Android は電源長押しメニューに「ロックダウン」というのがあると思いますが、これは「生体認証を無効化して PIN 入力等を必須とするロック」の機能で、まさに睡眠中の悪意あるアンロック試行を阻止するためのものです
β公開された1Passwordのパスキー対応について調べてみた - r-weblife
https://ritou.hatenablog.com/entry/2023/06/19/155439
https://twitter.com/1Password/status/1669841412291022850
> Our users verify themselves when unlocking 1Password. We surmise this to be sufficient user verification for authenticating our users to Relying Parties.
というわけで、端末なりパスワードマネージャなりのロックを解除できた時点で possession 以外の要素での認証ができていると考える、というのは合ってそう (少なくとも 1Password はそういう思想っぽい) >https://mstdn.maud.io/@kb10uy/111489799033069047
なおお仕事デスクトップは今日もXを起動したとたんディスプレイを失ったのでルータからDHCPクライアントを探してsshしてshutdownしています。known_hostsがどんどん育つw
mDNS を使って ${hostname}.local とかで名前解決できるようになるので、 DHCP で動的アドレスをもらっているデスクトップやラップトップに SSH 接続するときなどに便利
このアカウントは、notestockで公開設定になっていません。
デスクトップとかでは DHCP 使ってるけど、一応ルータ側で割り当てるアドレスを固定しているのでそこまで不自由したことはないし、ルータ側で DHCP クライアント情報を確認できるのでそっちでもどうにかなる
むしろ DHCP サーバから見えないぶん固定 IP アドレス設定で見失ったサーバとかの方が致命傷になりやすくて、そっちはもう nmap とか arp を for 文とかでぐるぐる回すなどしたりする
nmap -p139 --script smb-protocols ${addr}
で SMB サーバが対応しているプロトコルバージョンを確認できるという豆知識を思い出した
ローカルに CoreDNS 立ててからは諸々のローカルなコンテナやサーバに全部名前を割り当てられるようになったのでだいぶ楽できている
https://mastodon.cardina1.red/@lo48576/111368117311755158
GNUの頭(エティエンヌ・スバサ画) - GNUプロジェクト - フリーソフトウェアファウンデーション
https://www.gnu.org/graphics/agnuhead.html
ふと思い立って「ganyu gnu」とか「ganyu/Linux」とかで画像検索したが、GNU アイコンを甘雨の頭に挿げ替えたネタ画像などは発見できなかった
Initihooks - System initialization, configuration and preseeding | TurnKey GNU/Linux
https://www.turnkeylinux.org/docs/inithooks
もしかして私が欲しかった情報これか！
mcookie コマンド知らなんだ…… (まあ自分で直接使うこともないだろうし忘れていいや)
Portal: Revolution - Trailer - YouTube
https://www.youtube.com/watch?v=cXczxIIvXJ0
> Portal: Revolution is a free to play mod for Portal 2. This fully featured original campaign plays before Portal 2 in the dead and decaying Enrichment Center.
ほう！！ #Portal
2ヶ月ほど前から異音がしていたサーバのケースファンをついに交換した
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
“引用” ではないから元ネタの権利者に利用拒否されたり利益の折半を要求されたら断れないしな
このアカウントは、notestockで公開設定になっていません。
「24時間テレビ」寄付金も…日本テレビ系列局の元幹部が1100万円超を着服 28日付で懲戒解雇｜FNNプライムオンライン
https://www.fnn.jp/articles/-/621855
にっこりしてる
このアカウントは、notestockで公開設定になっていません。
[B! スポーツ] 日大アメフト部が廃部へ 学内会議で決定 部員の違法薬物事件で：朝日新聞デジタル https://b.hatena.ne.jp/entry/s/www.asahi.com/articles/ASRCX7W83RCXUTQP01W.html
これ、真面目な部員がかわいそう的な事言ってる人がそこそこ居るけど、全国ニュースに長期間とりあげられるような大きな不祥事が無かった組織ならあれだけど、タックル事件があった上で入ってる時点でそもそも判断がおかしい(事件の重要性よりも部員としてのキャリア肩書きを優先してる)ので、同情の余地なんて無いと思う＞＜
ジャニーズや宝塚は、アンテナが低ければ「週刊紙が騒いでるだけかもしれない」なんて発想になる可能性もなくもないと言えなくもない(それもかなりおかしいとオレンジは思うけど＞＜)けど、日大タックル問題は大きく報道されてたし国会でもそれなりの扱いされてたじゃん？＞＜
あれを見ててタックルだけが問題だった(ので部の指導者をすげ替えれば問題解決)って判断するのおかしいでしょ＞＜
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
侮蔑的かどうかをさておいて、特定ドメインでちゃんと定義された意味を持っている語を雑なレッテルに使うのは良くないという気持ちはあるので、本来は (自分のみを形容するための用法であっても) 脳死とか言うのはよろしくないとは思うんだけどねぇ
一方で、攻撃的に使うのでなければジャーゴンというかｵﾀｸ語彙として敢えて文脈を外して使うことも日常の営みではあり、その範疇にあると言われるとまあそうかなぁという気もするし
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
https://twitter.com/sm_hn/status/1729449613999186336
折りたたみスマホを持つ人の割合は40%！大きな画面とステータス感が魅力【フォルダブル購入動向調査】 - 読売新聞オンライン／まとめ読み／プレスリリース PRTIMES
https://web.archive.org/web/20231128155638/https://yab.yomiuri.co.jp/adv/feature/release/detail/000000038000084641.html
元記事消されてたけど、これか
右腕をまっすぐ伸ばして真上に向けると肩が痛む、まさか30代になる前に10n肩発症なのか……！？
ラジオ体操第1の最初の1動作で痛みを感じる体になろうとは
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
飲酒の有無に限らないけど、集会で一部メンバーだけが顕著な追加費用を発生させるようなとき、自然と「じゃあ追加費用分は恩恵を受けたメンバーだけで割るか」とならないような集団だったらあまり深く付き合わない方が良くない？ という感じはする
べつに全メンバーが「そんなの誤差！w」で済ますようなことならそれでいいんだけど、そこの合意が取れてない場合に遺憾なく吝嗇を発揮してしまうような人に気持ちよく交際費をかけられるかというだけの話
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
（埼玉）さいたま市緑区東浦和６丁目で声かけ １１月２９日夕方 | 2023/11/29 - 日本不審者情報センター https://nordot.app/1102578039549575966?c=134733695793120758
（実行者の特徴：年配男性、カーキ色上衣、ベージュ色ズボン）
■実行者の言動や状況
・女子生徒に声をかけた。
・「飛行機飛んでいるね、あの星は何だろうね」
https://git.sr.ht/~omasanori/sj3
TLI（BSD由来のソケットAPIとは別のネットワークAPI。System V系のUNIXで使われていた。）対応コードの削除や @uaa によるコンパイラの警告対応を2.0.95としてリリースした。 #SJ3 #InputMethod
TLIについては以下のページで触れられている。
