パスキー導入の背景
こんばんは、Replay.fm第61回です。
こんばんは。
はい、今、今週土曜日に撮ってるんですけど、その原因となったのが、僕の風邪で火曜から延期してもらったんですけど、
火曜、炊飯金、4日?4日頂いたのに感知してないんで、とても低い。
まことに、まことに。
ガラガラ声で。
厳しいな、って厳しいよ。
はい、まあまあまあ。
機嫌悪くないよっていうエキスキーズ。
この機嫌悪くないよってエキスキーズすごい大事だと思ってるんだよね、個人的に。
仕事でもちゃんと結構意識的に言ってるんだけど、風邪引いてると。
なんかオンラインだと、分かんないじゃん。
なんかね、エンジニアマネージャーの仕事だっけな。
本で読んで確かに思ったのが、風邪の話じゃなくて、どうしても人間だから機嫌が悪いとか、
たまたまめっちゃ忙しい時にワンワンが入ってきたとか、
そういう時にエキスキーズするのすごい大事だよみたいな、向こう相手は何があったか知らないわけだから、
自分に対して何かがあって不満層に見えた時に、いらん、誤解を生むし、
オンラインだとなおさらそれが顕著になるから、みたいな。
確かに。
俺もなんかの本で読んだな、似たような話。
ハイアウトマネージメントかな、なんだろう。
上長部下の関係だと多分なお大事だけど、別に同僚とか一緒に仕事する時も同じだよなって気はしてて、
結構それ以来意識してるわ。
えらいね。
はい、機嫌悪くないし。
私は常にご機嫌ダメだよ。
それをその一番最初働く時に言っとくといいかもね。
機嫌が悪いという概念がないんで、どんなに怒ってそうでも機嫌いいっすっていう、そういうことでしょ。
知らんけど。
まあまあ、大抵の物事は機嫌がいいの半純に収まるよ。知らんけど。
そうか。
まあその辺の差し掛けも人それぞれやん。
知らんけど。
まあ難しいよね。
まあやりますか。
やります。
今日はね、先週もそうだった気がするけど、記事少なめですね。
教則。教則の。
教則。
若干語弊があるけど。
若干語弊がある。語弊しかない。
語弊。記事の数はいつも通りですけど。
僕らのね、なんか、僕ら、しかも僕なのかな。僕がなんか結構だいぶ、その2週目に入りつつある感があるから、そのおかげ感はあるね、個人的に。
はい、じゃあ1記事目は、メルカリのエンジニアリングブログの記事ですね。
内容のサマリーはちゃんと書いてないんです。書いてない。あれか。NotionやIKEAじゃないのに書いてないんですけど。
悟空マンさんの記事ですよ、ちなみに。
ああ、我らが1回ゲストに来ていただいた、気になる方は読んでいただけばって感じなんですけど。
そうですね、まあ、ご存じの方はご存じだと思いますけど、メルカリではパスキーログインっていうのが結構早めからサポートされてるし。
いやー、早めではないな。
早めではないんだ。
ああ、パスキー。早めではないな、でも。
でもなんか推進協会的なやつに会員ではあるよね。
アーリーアダプター的な速さでは別になかった。
ああ、そういうことか。
はい、じゃあちょっとそこは、すみません。失礼しましたって感じなんですけど。
パスキー導入してて、そのパスキーを一部導入とか既存のログイン方法と併用する形で導入してきてたけど、
それをフィッシングレジスタントっていうタイトルにも書いてある通り、
パスキーを設定してあるんだけど、IDパスワードログイン、OTPの2FAログインとかが残ってると、
結局そこはフィッシングのリスクとしては残るよっていうのがずっと課題としちゃったんだけど、
そこのリスクをつぶし込むために、とうとうパスキーを設定した人はフィッシングレジスタントでない認証方法は廃止していくっていうところに
舵を切り始めてますよっていうところの、超雑句言うとその辺の話かなっていうところですね。
アカウントリカバリの課題
なので、この前って言っても半年ぐらい前のかな、コックマンさんと話してから、
結構サービス的にはかなり一歩踏み出した感があって、すごいいいよねっていうところと、
あとはそうですね、個別読んで印象深いなと思ったのは、
フィッシングレジスタントでない認証方法をつぶしたってなったときに、
じゃあパスキーなくして積んだらどうするのかみたいな部分が。
アカウントリカバリのところがね、結局ボトニックになるというか、ウィークエストリンクになりがち。
そこに対してはいろいろ試行錯誤した結果、あれかな。
引用にはしてないけど、手動で連絡して復旧か。
手動で連絡して個別に復旧するか、またそのマイナンバーカードを登録しておくことで、
そのマイナンバーカードの証明ができれば復旧できるっていうのが、
これはすでに実装されてるのかな、ちょっと手元で試してないんだけど、
実装されてるんだよね、きっと。
なんでそれが投入されたっていうので、
結構今まで見たマイナンバーカードの活用の仕方で、
なんかとても有意義な使い方のうちの一つだなって個人的には考え深いというか。
これさ、別に俺が何したってわけでもないんだけど、いいよね。
めちゃくちゃいいね。
早く出ないかなーってずっと待ってた。
紹介できる日が来たこと、結構。
元仲の人だから知ってるってことだよね。
そう、辞める前から。
これできたらよくねって話をしてて、めっちゃいいですねっていう話をした記憶がある。
またパスキー登録のさせ方みたいなやつとかもいくつかやってるんだけど。
物によってはかえって悪用されちゃったりみたいなところがあって、
最終的にはステータス機能とトヨタリストを活用するっていうところ。
メルカリ使った方はわかると思うんですけど、
例えば出品して購入されて発送待ちみたいな状態になると、
発送するっていうタスクが自分のタスクなんで、
やることリストみたいなのに乗っかるんですけど、
多分そこにパスキー登録してねってのが入ってる。
登録するまで残るんだろうね。
僕は元々登録しちゃってたんで出たことないんですけど、
それが一番効果的っていうところが、なるほどなーという感じですね。
このかえって悪用されちゃったりがね、やっぱ難しいんだよな。
これ、ちゃんと狙われるんだね。
そうそう、意図的に選別はやっぱできなくて。
むずいよ、難しいな。
あと言って一番いい、何て言ったらいいんだろうな、速急タイミング。
そうだね。
他の会社も結構このモデル採用してるところ多いなと思うんだけど、
要はパスワードとSMSOTPでログインした直後にパスキーの登録を。
よく見るね。
よく見るパターンだと思うんだけど、
あんまり問題になってないのかどうなのか、どうなんだろう。
メルカリほど狙われてるところっていうのがそもそもそんなにない。
マイクロソフトとかどうなってるんだろうね。
うながす。いやー、パッと出てこねえな。たまに見るよね。
あるいはなんか、何て言ったらいいんだろうな、
サポートする要素として怪しさ判定みたいなのがそこに一緒に入ってて、
そこが一定の敷地クリアしたら速急するとか、
そういうところかな。
その辺の精度がめっちゃ良ければ、これは問題にならない。
そもそもパスキー導入してここまで割と仮定を洗いざるに書いてくれてる記事を
そんなに見かけたことはそもそもない気がして。
やられてるけど出せない。
結果フィッシングヘッドですかみたいな。
そういう意味でもこういう記事はすごいありがたいというか、
各社のこういう記事が普通に読みたいなって気がするな。
いやー、でもいいっすね。
とてもいい。
パスキー導入。
いろいろ課題はあったり、炎上なのかよくわかんない。
課題的とかもあったりするけど、ちゃんと進んでて偉いなって感じがしますね。
いやー、こういうリアルなところをやれるっていうのはこういう会社のいいところですね。
そうだね。
規模感も決して小さくないから、そこに対してできてるっていうのもすごく大きな成果だよね。
小規模なサービスでやりましたとは全然話が違うというか、
下手した売り上げへこむような、かえってへこむような取り組みでもある中で
きちんとやりきりつつあるっていうのは素晴らしいですね。
いやー、見習っていきたいですね。
次。
個人情報保護法の見直し
正々堰かける個人情報保護法、改正動向から読み解く実務の行方。
法律事務所リアクトのセコさんのスピーカーデックのスライドですね。
読みました。
読んだんで、結構全部説明しようと思うと時間かかるんで、
サラッと概要なんですけど、大きく分けて、
一つ目の話は、たぶん個人情報保護法を詳しい人にとっては復習なのかなと思いながら、
僕は知らなかったので読んだんですけど、個人情報保護法の見直しの話がまずあって、
見直し自体は個人情報保護法が施行されてから3年後に見直しが始まりますっていうサイクルになってて、
3年後に見直しが始まるんで、その見直しにかかる時間っていうのは、
その回ごとに結構2日の長さというか感じなんで、
今までの改正タイミングとかを見るときちんと定期的に改正されてきたわけじゃないけど、
そういうサイクルになってるよって中で、
直近じゃいつ次見直しが始まるかでいうと、ちょうど始まってますよっていうのが今なのかな。
2023年か。
2023年に施行されてるから、2026年に見直しが始まりつつある。
2022年に施行されてるから、今年見直しが始まってる話か。
その見直しの内容に関して、その中でCCIに絡みそうなものをピックして紹介してくれてるっていうスライドで、
主に3つ紹介していて、1つは同意規制の話。
同意規制の話は何かっていうと、個人情報を収集するときには、個人情報の持ち主の同意が基本的には必要ですよと。
何を取得するのかっていうのと、それをどう使うのかっていう部分の同意が劣るっていうのが基本的にはすごくざっくりと必須になってるんだけど、
見直しの検討会みたいなところの内容で、CCI開発文脈における個人情報の利用に関しては、
一番本人同意なしでいいっていうふうに整理できるんじゃないかみたいな論点があって、
何かっていうと、例えばCCIだと、ここは多分異役というかある種の推測ではあるんですけど、
個人情報を含む何か、行動履歴みたいなものをバーって学習したときに、
個人情報保護法の見直し
行動履歴がまるっと出力されるかっていうと、必ずしもそうじゃないよねみたいな部分があって、
そういう一定の条件が成り立つコンテキストにおいては、同意を得なくていいんじゃないかみたいな話かな。
これ法律の話怖いんで、ちょっと見直しながら読みますけど。
あとは統計作成か。統計作成。こういう傾向があるみたいなところには個人情報、
原理書入り得ないよねみたいな部分は、同意なしでいいんじゃないかみたいな話かな。
だからAI開発だけじゃなくて、AI開発とかみたいな話ですね。が一つ目。
スライド貼っつけてるんですけど、この辺はちょっと時間なくて。
P82か。P82、83、84か。
今までは基本的には取得時に同意した項目に関してしか個人情報っていうのを活用できなかったので、
たぶん今年皆さんも見に思えなかったと思うんですけど、利用契約更新、プライバシー更新しましたみたいなメールの通知が結構ポコポコきて、
差分見るとAI学習に使うんだろうなみたいな内容が追加されてるみたいなのがちょこちょこあると思うんですけど、
そういうことをしないと今の個人情報保護法だと、取得済みの個人情報とか行動履歴をAI開発に使うっていうのは難しい。
なぜなら取得時にそういう理由で同意を取ってないかっていう部分があるんだけど、
そのあたりがこの辺、この同意規制の部分で少し規制が緩まると、明示的にこれはそれに使いたいですっていう。
同意を取ってなくても一定の条件下においては使えるようになるかもっていうのが1個目の同意規制の話です。
委託先の監督と実態
2つ目が委託先の監督ですごくざっくり言い訳すると、委託先監督っていうのは、
例えば弊社の個人情報、当然、ちょっと弊社ややこしいな。
うちはちょっとややこしい。
そうだね。
なんかECサイトやってる事業者がいて、配送のために住所、氏名を取得してみたいなときに、
それを外部のCRMのSaaSに預けるみたいになったときに、
その預け方次第ではあるんですけど、一定の条件になると採択って形になって、
個人情報を採択してる先に対してはきちんと監督をしなきゃいけないよねっていうのが、
現状のちょうざっくり言うとやらなきゃいけないことなんだけど、
それがすごく言い訳すると、現実問題めっちゃ厳しくないですかっていうのが論点としてある。
見直しの部分の一時操作の表現としては、
委託先の管理等を通じた適正な個人データ等の取扱いの確保が困難な場合があることから、
個人データ等の取扱いの適正性を確保する能力など、
個人情報の取扱いに係る実態を踏まえて、疑問を負うべきもののあり方を検討していくことが望ましいみたいな。
個人的にはこの実態みたいな部分が大事な気はしてて、
この瀬子さんのスライドでもあるんだけど、
ビッグテック、GoogleとかオープンAIとかみんな大抵使ってるよねとか、
SaaS利用も増えてるよねみたいなところで、
SaaSを使うっていうのは委託として整理することが多いんだけど、
そこに個人データが入るんだったら、委託先の監督っていうのが必要になるか、
じゃあアマトのSaaS使ってて、うちは10個のSaaSに個人情報、
法的整理で言うとこの個人情報を採択してますとなる、委託してますとなると、
その10個に対して監督が必要なんだけど、監督っていうのが今何をさしてるかっていうと、
3つの項目か、委託先の選定みたいな部分をちゃんとしましょうねとか、
委託契約の締結とか、個人情報がどう取り扱われてるかっていうのを把握してください、
これは定期的に完走しましょうとかそういう話なんだけど、
じゃあ海外のいろんな国のSaaS使ってる中でそれを全部やり切るの無理じゃないっていう、
そもそも例えば個別の委託契約なんて結んでくれないよねみたいな、
そういうものが現実としてはあるあるになっていて、
パワーバランスの観点から十分な監督ができないみたいなのもスライドで書いてあって、
なので実態としてはなかなか厳しいと、
また日本の法律に合わせて海外の事業所とかだといろいろ情報開示してくれないみたいな部分も全然あるよねみたいな部分があって、
その辺を実態に合わせて緩める余地はあるかもしれないところと、
あとこれ僕は知らなくて持ち帰って勉強しようと思ってるんですけど、
海外だとDBAっていうものが結構ウェブ上で公開されてることが多いらしくて、
2個あるんだけど、データプロセッシングアグリメント、
個人情報をどう扱ってるかみたいな部分だと思うんですけど、
それを参照することである程度チェックすることができるって部分があって、
日本の法律でももしかしたらこういうものをサービス提供者側は出してねっていうふうにして、
利用する側は個別に監査するというよりかはそれをちゃんとチェックしてねっていう意味はあり得るのかもっていうのが、
漏えいと対応の基準
セコさんの試験として書かれてるって感じですね。
最後の漏えいと対応みたいな部分に関しては、
今の法律だと当然公的な個人情報に当たるものが、
例えば専権認証で漏えいしたら個人情報保護委員会に報告するみたいなそういう義務とかがあったりするけど、
今の立ちつけだと、
なんでしょうね。
漏れてもクリティカルじゃないとサービス事業者目線は言えるんだけど、
法的には個人情報っていうものが漏れたときにも一定の義務が発生するようにという部分に対して、
モットーソースの表現としては、
本人への通知が行われなくても本人の権利利益の保護にかける恐れが少ないものに関しては、
本人通知を要しない、必須にしないっていうのが検討として上がってるっていう話ですね。
いやー、これはでもなんかさ、
分かるけど基準が難しいよなと思っていて。
分かるけど基準が難しいね。
そこの基準作りがどうなるかって感じなんだろうね。
セコさんの例とかであると実害が、まあでも具体的な例はないか。
まあでもあると思うのかな。
単独で特定の個人を識別できず、かつ厳しさが低い場合とか、漏えいの恐れは否定できないが現実的な危険性が低い場合。
これはそうだね。
目質や既存が生じた漏えい等に上がりとするが、ユーザーへの影響がほとんどない場合。
これもそうだね。
だから後ろ2つはそうなのか。
後ろ2つっていうのは。
おめでとう108ページね。
108ページ。はいはいはい。
そうだね。
うん。
単独で特定の個人を識別できずっていうのは。
誰が主語なんだろうな。
まあね、そうだね。誰が主語の部分は確かにそうだし。
そうだね。
今だとレコードにユニークIDみたいなのも、外に出て外に人がそれから個人に辿ることはできないかもしれないけど、
そのサービス事業者の社員だったら辿れる状態にあるんだったら個人情報っていう話とかは。
何かと何かな。どっか他のところで漏えいしたものとの合わせ技で結果的に特定できちゃいましたとか普通にありえそうだなと思うし。
まあ確かにね。
確かに。
漏えいしたデータ単独で特定の個人を識別できないって、じゃあ何を持って生きれるのみたいな。
厳しいの部分は何だか、結構ある程度世の中一般で同意が得られるようなものっていうのはラインを引けそうだけどね。
もしかこれ本人通知の話だから、個人情報保護委員会には報告するけど、そこでジャッジが下るとかもあり得るのかな。
そうすると何か、そこのジャッジを待ってると本人通知が遅れるよね。
それはそうね。今のスループットがわかんないから何とも言えないけど、そこは何か現実どうするのって話はあるかもね。
具体例として挙げられてるのは、例えばユーザー登録情報と利用履歴情報のテーブルがあったとして、利用履歴情報を単独の場合だとどうなのか。
そうだね。そこに氏名とか住所とか何も入ってなくてもユーザーIDで紐づけられてそこから氏名たどれるんだったら、個人情報ですよっていうのが今の。
報告通知が必要だよねっていうのがあるけど、実際これがどうなんだろうねっていうのが多分あれなのかな。発表の中では振れられてた。
そうかもね。そうだね。一緒に購入履歴。一緒に購入履歴とかはスライドの表現だと赤信号というか、多分比較的厳な情報だよねっていう表現だと思うけど。
アプリケーション上の機械的なログは黄色信号というか。購入履歴と比べたら厳じゃないよみたいな。
そんなところを紹介されてたって感じですね。また最後に情報収集の話で、個人情報保護委員会のツイッターフォローするといい、Xフォローするといいよとか。
いろいろ書いたって。氏名って感じですね。
良かった。勉強になりましたって感じですね。
勉強になりました。バツとポツポツい。ザーッと眺めてた。
ソフトエンジニアと近しいというか、普通にプロダクトの知識をちゃんと持ってるのがすごいね、セコさんは。
いろんなところに入って、実物を見てるっていうのも。
なるほどね、確かにね。いいね。
一方で法律周りのキャッチアップも大変なんだろうなというのをしみじみ思った。
かなりピックしてくれてる気がしてて、このスライド。検討会みたいなやつの内容から。
そしてエンジニアリング界隈以上に結構。
文章も難しいしな。
議論自体が難しいだろうなと思うし。
そうだね。37ページとか文字多すぎて全部読まなかったんだ。
個人予報。
保護委員会のたぶんスライドかなんかの。あ、PDFか。
大変だよ。はい、そんな感じです。
じゃあ次。
どうしようかな。
ワンパスワードのマスターパスワード扱い回すべき理由。
ジャックさんのブログですね。
なんかジャックさんなぜか11月からワンパスワードアドベントカレンダーをやっていて、
それの2日目の記事なんですけど。
ありなかったんだね。
これ、そういうこと?60日やるってこと?
そういうことだと思ってたけど。
あるいは年末はまた別のアドベントカレンダーやる。
なるほどね。
何かっていうとワンパスワードの、
ワンパスワード使ったことない人向けに説明すると、
ワンパスワードってパスワードマネージャーですけど、
ワンパスワードにログインするときにマスターパスワード、IDとマスターパスワードの2つが必要で、
ただ初回ログイン時にはそれに合わせてシークレットキーっていうのが必要なんで、
ワンパスワードの管理
基本的には3要素揃わないと新規ログインできないっていう仕組みになってるんですけど、
そのマスターパスワードの部分を複数のワンパスワードのIDを持ってる場合は使い回すべきっていうのが、
ワンパスワードからも推奨されてるし、
その理由みたいなのをJacksonの目線で解説してくれてるって話ですね。
理屈としては、よくあるユースケース、僕も実際そうなんですけど、
個人のワンパスワードアカウントと会社がワンパスワードを同意して、
会社のワンパスワードアカウントがあるってなったときに、
マスターパスワードを2つ管理しなきゃいけない要素ですよねってなって、
その状態で例えば個人のマスターパスワードは覚えてるとしましょう、自分で覚えてるとして、
じゃあ会社のほうどうするかってなったときに、選択肢としてはいくつかあって、
別のにする場合は別のやつにして覚えるとか、
別のやつにするんだけどそれを個人のワンパスワードに入れておくとか、
いろいろあるんだけど、何にしてもその2つ、
それなりにガバガバすぎないマスターパスワードを複数覚えるっていうのは結構、
自分の記憶力に依存して忘れてしまうっていうリスクがあるよねっていう部分とか、
また2つだったらいいけど、
なるほどなと思ったのはフリーランスで業務委託で何社か契約してて、
何社分かのテナントがあるってなると、
その数だけマスターパスワード作って間違えることなく覚えるっていうのは結構きついよねっていう話があるし、
じゃあ覚えるの大変だから個人のワンパスに全部のマスターパスワードを入れておこうってなっちゃうと、
個人のやつ1個侵害されたときにちょっとシークレットキーがあるかどうかしらなんですけど、
横展開されちゃうよねみたいな部分があるんで、
その辺を加味してマスターパスワードは統一しましょうっていうのが公式でも推奨されてると。
GitHubのルールセットとコードオーナー
もう1つはパスワードの使いまして基本的にバッドプラクティスだよねっていう前提があるけど、
何で推奨してるしOKなのかっていう部分で言うと、
最初に言ったIDとマスターパスワードの他にシークレットキーっていうかなり長めの文字列があるんで、
基本的にそれが漏れなければマスターパスワードバレても侵害されないですよって話があるし、
このシークレットキー自体はワンパス側が発行するやつなんで、
全アカウントで基本的には違う値になってるから、それをちゃんと管理しましょうっていう部分がプラクティスとしては推奨されてるって感じですね。
これ理屈としてはわかるって感じなんですけど、公式で推奨してるの全然知らなかったんで。
あんまふわっとやりがちなんだけど、ワンパスに限らずだけど、
使い始めたときに公式のプラクティス、使い方ガイドみたいなのちゃんと読むの大事だなっていうのをしみじみ思い直しつつ、
理屈もわかると思いつつっていう感じですね。
はい。前のアカウントに避難来るねみたいなところとちょっとつながるというか、
どこをどう管理しとけば詰んでしまわないかって話と、
まだバランス感というか、現実的に運用できるところのバランス感みたいなところかなっていう感じですね。
うん、まあ確かにね。
なんか結構シークレットキーがあるのってワンパス側だけな気がするんだけど。
あー、そうなんだ。
ラストパスもビットワーでもないんだよね。
へー。
リパーとかがどうなるかがわかんないなと。
なんでワンパス側だけこういうのがあるのかなってずっと思ってたんだけど、結構納得したかも。
確かにね。複数IDを、だから逆に言うとラストパスとかビットワーでもあれかのかな、
一つのIDで複数のオルグに所属できるみたいなデザインになったりするのかな、もしかして。
いや、わからん。わかんねえ。わかんねえ。仕事で使ったことないな、どっちも。
なんかそうだったらまあ、でもそれはそれでさ、結局一つアカウントシンクリするやつ一気に終わりだから、
さすがにそうじゃない気もするけど。
そうだね、はい。
なんかこのアドベントカレンダー、ワンパス割とねほりはほり書いてるんで、
ワンパス詳しくない方は結構おすすめです。
あとワンパスを仕事で運用しなきゃいけない人とか、まあ僕はそのうちの一人なんですけど、
まあ僕というか僕らというか。
実際こういうときどうするの?売れられてそうなタイトルだけ眺めてて。
そうだね、なんか抑えるべきポイントを順々に抑えてるって感じがするね。
記事の分量もすごくちょうどいいし、まあアドベントカレンダーっていうのもありますけど。
じゃあ次、最後ですか、今日。
Required review by specific teams now available in rulesets.
GitHubのチェンジログですね。
これなんか地味にカミアムアップデートじゃないと思ってたんだけど、どうなんすか?
まあ、チェンジログの内容を解説すると、
そっからかな、まず。
GitHubのルールセットプッシュじゃないかな、ブランチルールセットかな。
ブランチだと思うね。
ブランチルールセットに対して、
プルリクを必須にするとか、アプローブ1個以上必須にするとかの条件の中の1つに、
このパスはこのチームからのアプローブを必須にするっていうのが設定できるようになりましたよっていうアップデートですね。
このパスはもそうだけどさ、
でもそっか、このパスだけか、このブランチは別に今までのコードオンラインでもいけるのか。
ブランチルールセット。
ブランチごとに変えたいんだったら、ブランチルールセット複数作ればいいんじゃないかな。
だから、ちょっと勘違いしてたな。
本当?
なるほどね。
そう、なので、その記事中としてはコードオーナーと何が違うねっていう話。
コードオーナーでもパスベースでチーム設定して、
で、RequireReviewFromコードオーナーにすれば同じことできるじゃんって話なんだけど、
なんか記事の内容説明としては、
コードオーナーは必ずしもレビューするときに目を通す人を定義したいんじゃなくて、
コードの持ち主を定義したいってことがあって、
だからコードの持ち主と、
目的がね。
そうそう、レビュー時の必須者は別にしたいっていうときに、
これが使えるよってことが書いてあるって感じですね。
で、ぱっと見良さそうと思ったけど、
なぜ僕はこれを読みたい記事に入れなかったかというと、
具体的にいつ使うんだっけっていうのが思いつかなくて。
そうだね。
あと、Cって大きな違いがあるとしたら、
EvaluateModeで回せるかどうかだよね。
それはでも、もともとのブランチルリセットでもいけるのか。
いけるね。
パスなんだよな。あくまでパスがどうなのっていう。
そうだな。
コードな、
これ使ったらさ、
ごめん、なんでもないわ。
いや、むずいな。
既存との差分、本当にパスだけだから結構。
Cって思いついたのは、
例えば、GitHubのワークプロファイルでメンテナンスする、
人はコードオーナーで定義するけど、
セキュリティレビューは必須にしたいみたいなときに、
セキュリティチームで、
だから同時にかけるっていうのもできるよね。
コードオーナーはレビューを必須にしてるし、
セキュリティチームはコードオーナーじゃないけど、
レビューを必須にするって文脈で、
ブランチルリセットをかけちゃうとかできるかも。
でも結構分かりづらい気がするんだよな。
どこで何が効いてるのか分かんなくなるよね。
移行の困難さ
そうそうそう。かなり上手にやらないと、
コードオーナーはファイル見ればいいけど、
ルールセットは一定の権限がないと中身見れないし、
編集はアドミニストしかできないから、
テロン管理とかしてればいいけど、
まだ使いたい場面に遭遇を見つけてない。
あとはワークプロファイルの編集には、
常にセキュリティチームのレビューが必要みたいなのを、
オリジナリゼーションワイドでポリシー化できるとかは、
技術の中でも言われてるけど。
確かにな。
それは、確かオルグワイドはでかいね。
そっかそっか。
確かにね。
確かに。
使える場面はあるんだろうな。
ディスカッションログみたいなコミュニティ。
なんかでもちょっとむずいな。
いつ使いたいのっていうのが難しいのは、
確かにその通りだな。
コードオーナーズの設定の意味がさ、
コードオーナーズを何に使ってるかしらでもあるかもね。
リタブー禁制の機能だと、
多分レビューに指定するぐらいなんだけど、
そのコードオーナーズのファイルを元に、
いろんな自動化を組んでますみたいになった時に、
レビュー必須にしたくないけど、
その自動化を組むためにコードオーナーズを書かなきゃいけないみたいな。
別で定義するのは二重管理になるか嫌みたいな。
人とかにとっては結構いいかもね。
でもさ、これ移行するの結構大変だなと思って、
仮に移行したいってなったらさ、
なんだろうな。
一旦はブランチプロテクションの設定、
ブランチプロテクションなり、
ブランチルールセットの設定で、
まずブランチプロテクションを使って、
クラシックブランチプロテクションを使ってる場合は、
ブランチルールセットにまず移行します。
ブランチルールセットの設定で、
コードオーナーのレビューを必須にしてるよっていうやつを、
それを外して、
確かにめんどくさいね。めんどくせえわ。
パスごとにさ。
気泡が、コピペできないでしょ。
これ多分。だってレビューは選んで、
そうだよね。
コードオーナーファイルからインポートができてほしいな。
そうだね。
既存のやつを結構、
ちょっとこれ見てみよう。
複数、一つのブランチルールセットで流石に複数
いんのかな。
リクアやアプリケーションフォーマージで、
リクアフォーマージ、アプリケーションフォーマージと、
これだ、プレビュー。
パスキーの未来
でも複数設定できるよね。
今個人のやつ見てるんでチームがないですけど。
なるほどね。
でも確かにインポートさせてくれないと、
既存のやつでかいコードファイルを写すのはしんどいね。
そうだね。
このコミュニティページ後で見てみようかな。
プレビューだから次元になるかまだまだわかんないですけど。
でも面白いと思う。
いい使い方待ってます。
出てくるのかな。
まずクラシックブランチルールセット、
ブランチプロテクション使ってる人が移行からですね。
残ってるね。
移行すりゃいいんだけど、エリアで引っ越すしかないよね。
2年後ぐらいにまだ残ってそうなんだよな。
だいぶニュアンス変わってきてる。
2年後はさ、さすがにGitHub側がクローズしそうな気がするけど。
でも2年前クラシックトークン消したそうな顔してて、
今全く消える気配ない。
消すってことは多分ないと思ってて、
新規作成を止めるとかそういうやり方しかできないんじゃないかな。
影響範囲がでかすぎると思う。
ほぼずつやってるリポジトリのやつとかどうするのとかあると思うし、
新規作成止めて既存の勝手にマイグレーションするよってナンスを1年前にして、
壊されたくなかったら自分でやれみたいな。
とかなんかな。
クラシックトークンはほっときゃ勝手に消えると思うから、
エクスパイアしないトークン以外は割とできそうな気がするけど。
まあまあまあ、時が来たら対応するだけでは。
あといろんな多分機能がもうルールセットにしか入らなくなってるから、
それでちょっとずつサイレントに意向を促してるという話はあるね。
カンファレンスの季節
今回のやつも使いたかったらルールセットにするしかないし、
この週か来週かは分かんなくて、
セキュリティじゃないんで多分取り上げないけど、
コパイロットをルールのバイパスに設定できるみたいな、
個人的にはめちゃくちゃカミアップがあったんですけど、
それも普通従来のやつだと多分無理なんで。
みなさんルールセットに移行してください。
僕らも頑張りましょう。
頑張りましょう。
今日はそんな感じですか?
いいですね。
セックスさんいいっすね。
あと2週間後にアドベントが出るんですよ。
あとなんかやっぱし、今週…
ん?
何かな。
決めなきゃ。
準備しなきゃな。
もう間に合わんな。
今日ぐらいからやんないと。
ちょっと頑張ろう。
あと今日明日で多分、
なんかカンファレンスラッシュだからいいスライドが出てくるかもしんないね。
もう出てたよね、確かに。
うん。
ヤプシのなんか、
ペパオブのやつとかちょっと見てないけど、
良さそうっていうのを同僚がスラックに投稿してて、
追ってた。
ヤプシ、ビトコンJPも今日ですね。
あともう1個ぐらいなんかあった気がする。
JSかTypeScriptか忘れたけど。
カンファレンスの季節でもあるということで。
ヤプシ福岡か。
だからペパオブなんだ。
はい。
じゃあそんな感じで、
ガラガラな音でお送りしましたが、
来週は…
いやでも3日後なんだよな。
習ってなかったらすいません。
次はきっと健康なノートでお送りするんで、
よろしくお願いします。
はい、直してください。
え、なんかすごい。
あ、待って待って。
いや、これいいや。
なんでもない。
また次回。
はい、次回のお楽しみに。
どんな記事あんのかなと思ったら、
うわーっと思って。
いや、これいいな。
まあいいや、はい。
はい。
また次回。
3日後のお楽しみということで。
はい。
じゃあそんな感じで、
はい、皆さんお休みなさい。
お休みなさい。
