Ken is hororo too...
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
Authorized Fetch、うちはサーバーの代表アクターだけは署名なしでも情報取れるようにしてあるけどよそはどうなんだろう
というか全アクターが署名なしだと情報取れない場合って、未知のサーバーとのやりとりでデッドロック起きるよね
まあ自動化されていて不特定多数が相手だと、どうしても PKI か TOFU (Trust On First Use) になっちゃうのか
たかが fetch のために challenge-response とか callback 的なことをするというのもダルいし (まずプロトコルでそう定められていないと実装間での通信も成立しない)
というかリクエスト投げたら認証なしでリクエスト投げ返してくれる系の実装、だいたい無関係なサーバへの攻撃とかに使われちゃったりする系のやつなので脆弱性チャンスだしちょっと……
このアカウントは、notestockで公開設定になっていません。
最初に見た相手がなりすましだった場合には、以後偽物を本物であるとして本物からの通信を拒絶してしまうようになるので、実際ちょっと軟弱
の投稿
library_yasu@misskey.io
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
<[T]>::len() とか str::len() が返す usize の上限って何か制限というか保証あったっけ……
<[u8]>::len() が usize::MAX を返すことって絶対にありえなくない？ と思ったところでハーバードアーキテクチャとかいうやつを思い出した (Rust が対応している/するつもりがあるかは知らん)
まあ null pointer と std::alloc::Layout::dangling() で返すアドレスの2つは予約済で実質的にアクセス不可能な領域なので、それを踏まえるとやっぱり usize::MAX が返ることは絶対にありえないと断言して良いと思うけど
"invalid subrange count" compiling `[(); 1 << 63]` with -g enabled · Issue #34127 · rust-lang/rust
https://github.com/rust-lang/rust/issues/34127
ワロてる、まあそうなるよな
C の RSIZE_MAX みたいな実用上の制限絶対あるし、突破するつもりがないなら言語や標準ライブラリの仕様として保証してくれると嬉しいのだが……はてさて。
NonOneUsize::new(slice.len() + 3).expect("length will be less than or equal to usize::MAX-3")
みたいなあほくさい expect を沢山書きたくないんだよなぁ
Missed optimization on value range of `slice::len` · Issue #67186 · rust-lang/rust
https://github.com/rust-lang/rust/issues/67186
ﾎ㍂
このアカウントは、notestockで公開設定になっていません。
from_raw_parts in std::slice - Rust
https://doc.rust-lang.org/1.71.1/std/slice/fn.from_raw_parts.html#safety
> The total size `len * mem::size_of::<T>()` of the slice must be no larger than `isize::MAX`. See the safety documentation of pointer::offset.
これだこれだ
pointer - Rust
https://doc.rust-lang.org/1.71.1/std/primitive.pointer.html#method.offset
> The compiler and standard library generally tries to ensure allocations never reach a size where an offset is a concern. For instance, `Vec` and `Box` ensure they never allocate more than `isize::MAX` bytes, so `vec.as_ptr().add(vec.len())` is always safe.
> (前略) As such, memory acquired directly from allocators or memory mapped files may be too large to handle with this function.
ははー、「<*const T>::offset() では扱えない (存在できないとは言ってない)」ということになっているのか
このアカウントは、notestockで公開設定になっていません。
Maximum slice length - Is this sound? - help - The Rust Programming Language Forum
https://users.rust-lang.org/t/maximum-slice-length-is-this-sound/91046
ﾝﾋｨ〜
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
でもそうじゃない人は年収高い人に優先的に吸収されていくだろうから、低く書いても選択肢の総数が (優れたものから) 減っていくだけだったりしません？
沢山引き続ければいつか当たるかもしれないガチャと、引く回数は少なく済むが碌な当たりのないガチャ、どちらが幸せか私にはわからんね。
ガチャをやめよう。
このアカウントは、notestockで公開設定になっていません。
NVMe (M.2) のことなら物理端子は共通だろうし遅い方に揃うだろうから心配なさそう
PCIe 端子そのものだと実効レーン数と規格バージョン以外にも物理端子の制約もあるので面倒 (x4 で動作する x16 端子のデバイスは x4 端子に挿せないなど)
x4 で動作するのに端子が x8 とか x16 になってるデバイス、勘弁してほしい
Maximum slice length - Is this sound? - help - The Rust Programming Language Forum
https://users.rust-lang.org/t/maximum-slice-length-is-this-sound/91046
ﾝﾋｨ〜
このアカウントは、notestockで公開設定になっていません。
Yongha KimさんはTwitterを使っています: 「C102参戦します。何よりも健康でお祭りを楽しんでください https://t.co/99dbaGT0yN」 / X
https://twitter.com/ysoya/status/1690170096386523136
キム・ヨンハ統括P！？
#threads に他人のいいねを覗く機能ができた。Mastodonにはない機能だし、欲しくもないやつだ…。気軽にいいねできなくなる。
fav は (投稿者に通知が飛ぶこと以外は) private なものにしたうえで、 collections 機能をちゃんと実装して (つまり togetter 的なやつを Mastodon 組込で用意して)、そのうえで「この collection に追加したやつは自動で fav する」みたいなオプションが生えてくると大満足という感じ
Mastodon が collections を扱えるようになるつもりがあるのかは知らんが
fediverse (AP) でﾌﾞﾘｭｽｷの招待コードを消化するのは無理があるやろ
同一消費期限のものを明日の昼 (昼とは言ってない) の分まで用意してあるので残念ながら……
フォークして編集して`cargo fmt`すると無関係の場所まで整形される状態のプロジェクト困る〜
これ本当に困る (仕方ないので git add -p であたたかみのある手動選択)
労役で clang のソースコード弄って clang-format かけたら私の弄らなかったあらゆる部分で差分が発生したときは、さすがに白目剥いた
NIC.IO - The Indian Ocean .IO Domain Registry and Network Information Centre - Rules for Domain Names
https://www.nic.io/rules.htm
> No .IO domain may be used, directly or indirectly, for any purpose that is sexual or pornographic or that is against the statutory laws of any Nation.
思いのほか強い条件だな
そもそも ccTLD は諸々リスクが高いので躊躇するし、ブランドとして使うドメインなら尚更のことよね……
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
winnow::combinator::eof が incomplete stream の末尾に対しても true を返すの、どうにも気に入らんな
/foo([^a-zA-Z0-9_]|$)/ みたいなマッチを入力 `foo` に対してかけるとき、 $ はマッチしたと見做すべきではなく Err(ErrMode::Incomplete(_)) を返すべきなので
無線LANルーターなど一部のネットワーク製品における 代替製品への切り替えのお願い - 最新情報 - セキュリティ情報｜ELECOM
https://www.elecom.co.jp/news/security/20230810-01/
なんとまあ
> 製品発売時には存在しなかった以下の脆弱性が判明いたしました。
この表現気になるな
どこかのアプデで追加されたという意味なのか、当時存在しなかった暗号攻撃手法みたいなのが今はあるという意味なのか、それ以外の何かなのか
PayPay の曲 (歌？) を聞いてみるくふぁくとりーのｴﾖｹﾞの PV かと思うやつじゃん
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ActivityPubサーバ大きさ調査を1ヶ月続けてきたところ、大きいサーバ(10万MAU超)ほど合計の人口の増減が大きいことがわかりました。グラフはそれぞれのサーバのMAUを1桁ずつに区切って合計したものの変遷です。ActivityPubに居つかない人ほど大きいサーバにアカウントを作る傾向があるのかな？今後も測定を続けていきますね。
下記のスクリプトで弊ぼっちを起点としてそれぞれのサーバのnodeinfoからMAUと知ってるサーバを教えてもらっています。単一スレッドで既知のサーバぜんぶの訪問に３日ほどかかります。
https://gist.github.com/zunda/f566e2bb85ca0616d351139363274ec5
このアカウントは、notestockで公開設定になっていません。
概念はわかっているが、“良い fuzzing test” とはどのようなものか確認する必要がある
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
訪問頻度の少ない場所に行くときは位置情報有効化して位置追跡アプリで GPS ログ残してる
えーとですね、サーバ監視の文脈で firing instances というのはデータセンターで火事が発生しているという意味ではなくてですね……
このアカウントは、notestockで公開設定になっていません。
