日付も変わったし朝食にするか……

「PlayStation®5 “原神” ギフトパック」を7月17日（水）より数量限定・特別価格で発売！ – PlayStation.Blog 日本語
https://blog.ja.playstation.com/2024/06/05/20240605-ps5/

> 「PlayStation 5 “原神” ギフトパック」の発売を記念し、『原神』のキャラクターをモチーフにしたアバター10種（※）をプレゼントします。

気付かなかった…… (交換した)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

だめだ、 Step CA と Caddy の組み合わせだとどう足掻いても証明書更新のランダムな失敗が避けられない (しかもどちらを再起動しても直らなかったりする)

bad nonce とか antireplay エラーとか言われてるのだが、べつに Caddy 側で特別に設定した記憶はないから内蔵の ACME client で適切にハンドルされているはずでキャッシュ設定がおかしいとかはないはず

接続エラーの面でもローカルの resolver を明示的に指定した場合と暗黙にルータ経由で名前解決した場合のどちらでもエラーが出ることを確認しているので、ここのミスの線も薄い

result を resault と誤記する界隈があるのか #漫然英語

これもある種の hypercorrect みたいなものか？

オレオレ root CA の証明書をインストールしてあるのに CI が失敗すると思ったら、 git は独自で検証するようになっているらしく、 Woodpecker CI の agent 側で git config をうまいこと設定する必要が出てきた

ログからはわからないが、もしかして clone の段階からコンテナ内で実行されてたりする？ だとするとセットアップが数段面倒になるが…… (いやたぶんそんなことはないと信じたい)

Xanadu の話してる？

ザナドゥ計画 - Wikipedia
https://ja.wikipedia.org/wiki/%E3%82%B6%E3%83%8A%E3%83%89%E3%82%A5%E8%A8%88%E7%94%BB

ｵﾀｸﾑｰｳﾞﾒﾝﾄのせいで極論のストックだけが溜まっていくの、本当によくない (?)

もしかして: Woodpecker CI で custom root CA を使っている Forgejo から agent が git clone することはできない？

.gitconfig を注入できればいけるのだが、どうも無理そうで .netrc しか許してもらえなそう (その .netrc もどこから持ってきたやつたのか知らないけど……)

clone 段階で環境変数 GIT_SSL_CAINFO を設定できればそれもありといえばありだが……

原因自体はもうわかっていて、

* git サーバは custom root CA cert で HTTPS アクセスを受け入れている
* CI agent サーバは custom root CA cert をシステムにインストール済
* agent は docker コンテナを作成して内部で git clone しているので、 custom root CA cert を認知していない

という状態で、解決策として証明書をどうにか clone 用 container に突っ込むか (望み薄)、さもなくば環境変数とかで git に検証を無視させるか、というあたり

ただし環境変数を使うにしても、リポジトリ側のワークフロー定義に書くのは嫌なのでどうにか CI サーバ側の設定でどうにかならんか？ というのが今調べていること

plugin-git/docs.md at main · woodpecker-ci/plugin-git · GitHub
https://github.com/woodpecker-ci/plugin-git/blob/af152a724817400a3a7b6a548e206d1d92fdd73a/docs.md

clone を手書きできるから、そこで諸々の証明書関係の話をうまく突っ込めれば勝ち？

これもこれであまり気分は良くないが、まあ仕方ないか……

せめてホスト側に存在する証明書を clone コンテナに注入する設定を agent 側の設定でどうにかできませんかね

モジュール間で責任が適切に分配されていない感覚がかなり不愉快

secrets で証明書の URL を指定しておいてそれを custom-ssl-url に与えれば……と思ったけど HTTPS でその証明書を取得してくるのに証明書あるいは検証無視オプションが必要じゃん

完全に円満な解決を目指すなら、 LAN 内に private registry を立てたうえで諸々のコンテナ (debian とか rust とか) をオレオレ root CA 証明書を突っ込んだうえでビルドするという手があるのだが、普通にダルいんで嫌です

Add tools version of containers by Christiaan676 · Pull Request #122 · rust-lang/docker-rust
https://github.com/rust-lang/docker-rust/pull/122

これ欲しいけど望み薄だなぁと思っていたら見覚えのあるアイコンが出現して草

捜索対象になるワークフロー定義ファイルの名前を特殊にしてしまえば良いのかな

#myoldgear

そのあたり踏み込もうとすると、法律でやるとマズいから条例でふんわりとやっている暴力団排除とかがややこしいことになりそう

それとは別問題で、そもそも責任が制限されたからといって「やりたくてやっているわけではないとは限らない」のが西側の宗教由来の価値観のアレなところなので……

規制緩和に合わせたら合わせたで「{{ 任意の悪行 }}を支援し促進している！」とかキャンペーンを打たれるのは目に見えているので、やるならちゃんと責任だけでなく制限の権利まで規制しないといけない

これを workflow 定義ではなく CI システム側の設定でできれば良いのだが、可能かはよくわからん

なんか web UI ではなく master サーバの設定ファイル側でグローバル変数を定義する方法があったのでこうなった。本当はちゃんと verify したいがひとまず責任の切り方としてはギリギリ許容範囲。

思想としては、シンプルに「本質的にCI 環境に無関係な処理が workflow 定義に書かれるべきで、本質的に CI 環境に依存する/固有な処理は workflow 定義ではなく CI でやるべき」という話なのだが、これだけのことがなかなか難しい

なんというか「CI システム側の構成の自由度が高すぎると大変なので、何がなんでも (たとえ CI システム依存の項目でも！) リポジトリ側に持ってきて状態を減らすぞ」みたいな、先駆者実装に対する反動みたいなのが感じられる

某おじさんがアイコンの、あの……

草

まだ private registry に同名のオレオレイメージを用意する方が現実的そう (こちらは公式に方法が用意されている (といっても docker の daemon.json か何かを与えることができるというだけのようだが))

だいたい HTTPS サーバから検査対象のリポジトリを引っ張ってくるのに再現性もクソもあるかい、そんなもんは commit hash を見ればいい話であってわざわざ workflow 内に証明書を無視するだのクレデンシャルがどうだの書いてもしょうがないだろ

どーにも「なんちゃって宣言的/なんちゃって再現性/なんちゃってステートレス」みたいな感じがしていまひとつのめりこめない

(ところで: 証明書ブートストラップ問題については publicly accessible なサーバにオレオレ root CA cert を置いてその URI を使うという方法でも解決できる)

そうしたいかというと……まあ嫌ですが。いくら公開鍵といってもネットワーク外に露出したい理由は (他には) ない

clone 段階にコマンドを差し込めるのなら http で落としてきて署名検査なりハッシュサム検査なりすれば良いのだが、残念ながらそういうことをしたければ plugin を書けということらしく、嫌です！！！ (ダルい)

とりあえず issue だけ書いてみてもいいか

[Feature] Use custom SSL certificate from the direct value · Issue #163 · woodpecker-ci/plugin-git
https://github.com/woodpecker-ci/plugin-git/issues/163

とりあえず書くだけ書いたが。はてさて。

どうでもいいけど TLS の証明書を SSL certificate と書くことに抵抗があるマンです (といいつつ圧倒的思想を展開していくつもりもないので文脈に合わせた表記にするが)

進捗をしたいのに CI 設定をいつまでも弄っている (仕方ない……)

過去やっていたプロジェクトではローカルでテストを走らせていたが、ちょっと feature flag とか toolchain version とかで組み合わせを増やしたら実行時間が大変なことになり (それはそう)、さすがにこれは複数ホストに分散させにゃやってられんぞ……となった経験があるため

CPU72スレッドとメモリ384GBが火を吹くぜ！！！

まって、なんでアイドル状態なのにメモリ100GBも使ってるの

はいはいどうせﾄﾞｮｯｶｰのせい

いやほんまか？ なんかリークしてたりする？

めぼしいやつらはこれだけで、他は200MBいかない程度のが多い

これは…… “怪物” が潜んでいるぞ……

average にしてみたが、やっぱりメモリは恒常的に食っているらしい……何だ？

CSS だと限界がありそう。事前に8em とかで余白を作って揃えるくらいしかない？

JS でアダプティブにやるとグラフ更新で縦軸の範囲が変わると表示がガタガタ揺れる可能性もある。
と思ったけどそれは今の方式でもそうだからべつに悪くなりはしないか……

というかドラッグで拡大とかできるし普通にこれ CSS でなくスクリプトでやってるのだから、じゃあどうにかしてくれよという感想になってきた

とりあえず htop を入れて様子を見てみている

resident はそんな 75 GB いきそうな感じはしないが……

virtual だった。というか Ryot おまえかーーーー！！！！！！

というか CoreDNS の VIRT 1256M も笑うんだが。マジで？

Frequently Asked Questions (FAQ) - The Go Programming Language
https://go.dev/doc/faq#Why_does_my_Go_process_use_so_much_virtual_memory

> Why does my Go process use so much virtual memory?

草、まあみんな疑問に思うわなw

さすがに VIRT をカウントしているのは変なので ZFS を疑ってみたが、ビンゴっぽい

ARC size 60 GB、なに？
いやまあ空きメモリなんだからいくら使おうがべつにいいだろという話はあるが……

あーはいはいはいわかったかも、 QEMU VM で動いている Proxmox Backup Server が 32 GB と 360 GB の zvol を使っているからたぶんそのせいだ

Proxmox VE Administration Guide
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_zfs_limit_memory_usage

> ZFS uses 50 % of the host memory for the Adaptive Replacement Cache (ARC) by default. For new installations starting with Proxmox VE 8.1, the ARC usage limit will be set to 10 % of the installed physical memory, clamped to a maximum of 16 GiB. This value is written to /etc/modprobe.d/zfs.conf.

はいはい、 nagisa は 7.x からアップグレードしたやつだから 最大 64 GB 使うわけね

……と思ったけど3ノードいずれも 8.1 より前に入れたやつだから /etc/modprobe.d/zfs.conf なかった……

世界が平和になった

CI job の中から agent の情報を得たいと思って ip a してみたが docker が NAT してて駄目だったw

なぜそんなことをしているかというと、 agent を1つしか用意していないのに2ステップが並列で実行されているように見えるため

Agent configuration | Woodpecker CI
https://woodpecker-ci.org/docs/administration/agent-config

> `WOODPECKER_MAX_WORKFLOWS` if not set, defaults to 1

とあるので、並列実行されるはずがないのだが……

ホストの /etc/hostname をマウントするのが早いか

うーんやっぱり2タスクが同時刻に開始かつ進行してるな…… (date と sleep 5 を突っ込んで確認した)

まあひとまず放置するか、気に入らないけど…… (複数ノード登録したら問題なくなるかもしれないし)

どうせコンテナなのでパフォーマンスは安定しない前提で使うべきだし

あーそうかそうか、これ agent で実行する workflow の数の指定であって複数の step が同時に走ることを拒む設定ではないのか！

うげ、 cargo って --release はあるのに --debug とか --release=false とかできないのか

空文字列を与えてもそれはそれでエラーになるし

${EMPTY_STRING} がどう展開されるか賭けじゃん

cargo test --doc が library target の存在しない場合にエラーで失敗することを知った。
めんどくさいな！

--workspace があるときは有効なワークスペース内に lib target があるか自分で確認する必要があるってことじゃん (なお “無意味な” Cargo.toml がある場合を考えると [lib] で grep するというのはあまりうまくない)

cargo metadata からどうにか引っ張ってこられるか？

@anatawa12 まさにそれでよさそうです。ありがとうございます！

このアカウントは、notestockで公開設定になっていません。

Profiles - The Cargo Book
https://doc.rust-lang.org/cargo/reference/profiles.html#profile-selection

> The `--release` flag is equivalent to `--profile=release`.

とはっきり書いてあったわ

--release に profile 選択以外の効果があったら困ると思っていたが、ないらしい。なら安心

cargo metadata --format-version 1 | grep ',"doctest":true,'
でいけそう

https://mastodon.cardina1.red/@lo48576/112871716610678321

ほーらちょっと組み合わせを用意しただけであっという間に36パターンできた (死)

白状すると、こんな感じのことを普通に GitLab だか GitHub だかのリポジトリでやらかして、 CI の無料分リソースをあっという間に食い尽くした経験があります (すまんかった)

神経質なオタクなので……

本格的にやる場合は、 feature flag の組み合わせがもっと派手になって、まず基本が

- (empty)
- default
- (all-features)
- alloc
- std
- serde
- serde,alloc
- serde,std

で、これに加えて (というか掛けて) 固有のフラグの設定をいくらか (reader, writer, tree, みたいな) という感じなので、まあ死にます。
features の組み合わせだけでも絞りまくるしかない

ひとつ考えられるのは型検査オンリーの検査 (cargo check / cargo clippy) とテスト実行を分離してテストは少数の組み合わせで済ます方法なのだが、これもこれで cargo check や cargo clippy が生成したキャッシュが cargo build を高速化するので、分離したらしたで実行時間が余計にかかることになりかねない

このアカウントは、notestockで公開設定になっていません。

117 (時報) じゃなくて 177 (天気予報) じゃねえか！

このアカウントは、notestockで公開設定になっていません。

さすがに驚いたわ

電話の3桁番号サービス | 電話商品・サービス | NTT東日本 Web116.jp
https://web116.jp/phone/telephone/

海上保安庁の 118 がなかなか覚えられない

存在は小学生の頃から知っているのに未だに覚えられない

このアカウントは、notestockで公開設定になっていません。

そうなんだ (海上事故だけに)

ｻｰｾﾝ

ミニPCは前面吸気背面排気にできて、ファンが静かで、ファンが埃を吸いまくってもメンテナンスが楽で、ファンの交換部品もあって、みたいな感じになってくれれば手を出したいのだが。オタクしか買わなそうだしないか……

おまえら 177 のことを 117 って言いすぎ！

時計合わせしようとして天気予報を聞いた老人は……老人はこの時間にはまだ寝てるか。 (失礼)

むしろお年寄りの方が朝が早いかもしれない (そういう話ではない)

ATUI （KAKUJITUNI）

このアカウントは、notestockで公開設定になっていません。

これアルファベット列を忘れたの！？ と思ったけど、良く考えなくても普通に社員証とか入構証みたいなやつのことだよな (社会性の欠如)

Mc (子供) の話をしているならマクドナルドとか？

マック (ゲール語) - Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%83%E3%82%AF_(%E3%82%B2%E3%83%BC%E3%83%AB%E8%AA%9E)

マッカーサーたしかに

https://www3.nhk.or.jp/news/html/20240718/k10014515831000.html

> 日本体操協会は栄光の歴史を汚す行為は決して許されず、スポーツにおける公正の精神とマナーを尊ばなければならないとして日本代表の選手や役員に対して行動規範を示しています。

ほーん

> この中では「国内・海外を含め法令を遵守し、違法行為は行わないことや、名誉と信用を損なうような行動や発言をしないこと」などを求めています。

せやな

> そして、喫煙については「日本代表チームとしての活動の場所においては、20歳以上であっても原則的に喫煙は禁止する」としたうえで、2016年度から数年かけて段階的に全面禁止とするとしています。

そうか？？？
これ「活動の場所」って競技の場所とかではなく選手としての行動中ずっとという意味だよね？

「喫煙は名誉と信用を損なう行動である」というのは公にするには問題ある思想ということにならないのかな (みんなが嫌っているからおkなのか？)

煙草でドーピング系のあれこれの誤検出が〜みたいな理由とかならわかるし、煙を他人に吸わせるなとかもわかるんだけど

原(っぱに太陽光発電パネルを敷き詰める)発(電所)

原(子を単結晶に適切に注入することで作成される特殊な素材を使った)発(電所)

正しい結果は不適切な動機や過程を正当化しないので……

このアカウントは、notestockで公開設定になっていません。

ChatGPT (Genuine Person Teacher)

すずしいよ (31.2℃)

べつに暑いのはもう仕方ないんだけど、冬頃に25℃で寒かったのはちょっと自分に恐怖した

https://mastodon.cardina1.red/@lo48576/112067598109533243

確認したら24℃だった。ならしゃーないか (?)

mkdir & cd を一発で済ます関数 (not 外部コマンド) `mcd` というのを作ってみたらかなり便利で常用しているのだが、あまりに常用しすぎてサーバでまで手癖で出てくる

サーバ上で直接作業するな、はい……

データベース (のスキーマ) の正規化みたいなやつ私は嫌いじゃないんだけど、ああいうのって “欲求” がないとダルいだけの苦行でしかなかったりするんだろうなと思うことはある

規格を読んでソースの粗探しをするのを楽しいと感じる適性があるかどうか、みたいなのに近いものを感じる

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

「C++ を持っていると全てが親指に見える」が本当に好きで好きでw

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

これで思い出したけど、確率とか場合の数とかで「同じと見做す」かどうかみたいなので混乱したことのある人って多そうだし、あの辺りを突破してきたかどうかと相関があったりするのかな

うん？ MinIO で mc admin service restart しても minio server のプロセス ID って変化しないのか。なんか特殊な graceful restart みたいなことしてそうだな

Upgrade a MinIO Deployment — MinIO Object Storage for Linux
https://min.io/docs/minio/linux/operations/install-deploy-manage/upgrade-minio-deployment.html

systemd とかでデーモン管理してるなら mc admin update でセルフアップデートと自前再起動をするのはやめておけと書いてあるのだが、そうは言ってもきみ apt リポジトリとか提供してくれてないから普通にアプデするのダルいじゃん……となっており、模索している

パーミッションの問題は symlink でどうとでもなるのだが、デーモン自身の再起動を systemd が関知しないというのが良いのか悪いのかよくわからん。
万が一プロセス ID が変わったときに systemd がわざわざ殺して restart しようとする挙動とかがあると面倒なので、たぶんその辺りがハマりどころなのだと思うが

systemd service を Type=oneshot と RemainAfterExit=yes にしたうえでスクリプトからデーモンを起動することでプロセスツリーから外すという手もあるのだが、それはそれで cgroup とかによる管理から外れてしまうので嫌

いや、よく見たらこれ systemctl-managed でも mc admin service restart してええぞと書いてあるな。謎が深まった

このアカウントは、notestockで公開設定になっていません。

ﾊｲﾔｰﾎｯｸｽ

いや、はっきり言わせてもらうと HTTP と HTTPS で別々のコンテントを提供するサービス側が全面的に “良くない” のでこれでブラウザを責めるのは普通によくないと思います

IPv4 と IPv6 で別々のコンテンツを提供するくらいおかしい。
そういうのが許されるのはひとえにテスト目的かネタだけや

まあ世の中にはそういう “暗黙の透過性” を崩そうとしてくる人はたまにいて、たとえば public DNS を使っているとアクセスさせてくれない web サイトとか…… (やめろ)

HTTP でコンテント (の内部実装) を変えて特別な対応をする合理的な理由、たとえば cookie とか CORS とかそういう系の話はありそう、だが、それはあくまで内部実装の話であって意図のレベルに踏み込むものではない

逆にさくらｲﾝﾀﾈｯﾂはこれどう思ってるんだろう

http のつもりで入力した**リンクが**勝手に https にされている状況というのが日常茶飯事だとこういう案内は有用だろうけど、そんなことあるか？
(ロケーションバーでの書き換えはアクセスという結果を伴うし、 http と入力したうえで https 失敗したらちゃんとフォールバックしがちなのでちょっと話が別)

識別せんでいい土管をわざわざ突き付けてくんなと思ったが、土管がアピールしてくるようではそれ以前の問題だった

「小さな親切、大きなお世話」ってやつ

えーと、メインのツールではなく $PATH が通っていなくともよいが実行可能ファイルではあるようなものを置くのは /usr/{,local/}libexec でよかったっけ

/usr/local/bin/minio を symlink にして、 minio:minio が writable なディレクトリにバイナリの実体を置こうとしているのだが、その置き場所を /opt/minio/bin とかにするか /usr/local/libexec/minio/minio とかにするかを悩んでいる

しかしまあ libexec 直下のディレクトリはだいたい owner が root か。 (sgid か何かのためか dbus-daemon-launch-helper は root:messagebus になっていたが)

/opt にします

*.sakura.ne.jp だとたぶん複数同時に指定しているかワイルドカード (ワイルドカードではなかった気がするけど)

ワイルドカードでしたw
サーセンw

SNI でコネクションぶった切るとかだと近年のブラウザは HTTP へのフォールバックしてくれるのかな

302 Found とかで HTTP に流したらリダイレクトループしたりする？ その場合はブラウザがバカというだけだが (まあブラウザのバグへの文句がサイト管理者に来たりするのもありそうな話ではある)

cookie を許可しなかったら表示されないページとかはだいぶマシで cookie を許可しなかったら無限にリダイレクトループするバカのサイトとかたまにある

もちろんログインが必要なサイトであれば許可リストに入れるのだが (あたりまえ)、ログインの過程で謎のドメインをヒストリに残さない形でいくつか経由したりして、その途中のドメインについて cookie 許可を出したり container tabs での isolation を無効化したりなどいろいろする必要があるのでだいぶカス

ヒストリに残らない場合は目押しの Esc でロード中止してドメインを確認して許可リストへ突っ込み…… (くそめんどい)

㍂

安全率: >1.05 くらいありそう (?)

このアカウントは、notestockで公開設定になっていません。

よく見たら China と Hong Kong が分かれてるのもリプで指摘されてて草

まあ †一つの中国† は政治的可燃性高そうだし多少はね (?)

“北朝鮮” は二度出場してるし、政治的可燃性云々を心配する時期はとうに過ぎていそう (そういう問題ではない)

このアカウントは、notestockで公開設定になっていません。

知らん間に †素材† できてるじゃん……

あっやばい、前回の飯が何時だったか忘れた

たぶん9〜11時くらいです、そういうことにしておく

自動電源オフで落ちたｵｮｰｸﾏﾝを食後に利用再開していま稼働時間が 1:34:43 だから、だいたい 10:30 くらいに食べ終えた感じか

これがデジタルフォレンジック (ちがう)

デスクが 31.9℃ 52%RH なので、「暑くない……まだ暑くない……」と呟きならが手の平と足の裏と背中と鼻の下にダラダラ汗をかく人になっている

どうにか削って feature あたり8通り + オマケ(今のところ3) にまで抑えたが、まだ多いな……

どうにかもなにも beta toolchain で実行する組み合わせを減らしただけだが

cargo generate-lockfile - The Cargo Book
https://doc.rust-lang.org/cargo/commands/cargo-generate-lockfile.html

「依存をアップデートしない cargo update ってどうやるんだっけ……」などと支離滅裂な発言をしかけたが、 see also にちゃんとあったので一命をとりとめた

しかしまてよ、

> If the lockfile already exists, it will be rebuilt with the latest available version of every package.

これはどういうことだろう

Unstable Features - The Cargo Book
https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#direct-minimal-versions

-Zdirect-minimal-versions も気付いてなかった…… CI ではこっちの方が向いている？
(といいつつ indirect dependency が pub use で露出されていることも稀によくあるので、やっぱり -Zminimal-versions も必要ではある)

スクリプトで基本的に set -x しがちなのだが、たまに SOME_TEST && foo みたいな書き方をしたくなってもできないので困る (if-then-fi しないといけない)

(set +x ; SOME_TEST && foo) みたいなのも可能といえば可能だろうけど、かなり邪道な感じがする (本当にこれで問題ないかは確認してない)

しょーもないことでサブシェルを生やすな

ATRI はよ原作やらねば…… (←まだやってないの？)

夏休みのまとまった時間でやらなかったらもう一生やらないだろ

feat(resolver): `-Zdirect-minimal-versions` by epage · Pull Request #11688 · rust-lang/cargo · GitHub
https://github.com/rust-lang/cargo/pull/11688

Potential future work で "Remove `-Zminimal-versions`" とか言われてるんですが、マジで？

うーん？
Woodpecker 2.7.0 で普通の matrix 定義と include を混ぜると include 側しか認識されていないようなのだが……

べつに lint で警告が出ているわけでもなく。これ仕様か？

https://github.com/woodpecker-ci/woodpecker/blob/ef8e03396e0da0f72212ee834f77f381744d4646/pipeline/frontend/yaml/matrix/matrix.go#L47-L53

* `include` があったらそれだけ返す
* なければ matrix として使う

おいーーー

matrix with combinations AND includes · Issue #3992 · woodpecker-ci/woodpecker
https://github.com/woodpecker-ci/woodpecker/issues/3992

とりあえず feature request として起票

このアカウントは、notestockで公開設定になっていません。

過酷だが、これができなくて日本の GPKI は信頼を失ったからな

GPKIよ、おととい来やがれ！(タイトルで煽るスタイル) - yumetodoの旅とプログラミングとかの記録
https://yumetodo.hateblo.jp/entry/2018/02/28/232939

このアカウントは、notestockで公開設定になっていません。

とはいえ不利益 (偽物への信頼を植え付けられる) を被るのは何万とか何億とかのユーザだったりするわけで、まあ……

問題があるとすればそれは PKI という仕組みの問題ともいえるかも。
ただこのルールを緩和して PKI をどう代替するかといわれると……「ユーザにとってもっと信頼できない仕組みにしましょう！」としかならなくない？

べつに諸々の root CA 証明書バンドルのベンダーに認めてもらえずとも証明書を配布することはできるわけだしね。まあ落第した認証局を誰が信用するんだよとなるだろうけど。