karubabuの日記

タイトルに解決と書いているものがあるけれど、別に付いていない物は解決していないというわけではないです。つまるところ記事を書いた後に解決してちょっと嬉しかったので付けました。

ebuild内でSRC_URIにgithubへリンクを持ってくるのなら取得したファイルの名前に注意する必要がある

タイトルの通りです。

どういうこと?

多分結構なebuildで、公式・非公式問わずに、

SRC_URI="https://github.com/${PN}/${PN}/archive/V${PV}.tar.gz -> ${P}.tar.gz"

-> ${P}.tar.gzの様に、名前が変更されて保存されるものが多い。
これがないと自身のDISTDIRにV${PV}.tar.gzの様な名前のファイルが保存されることになる。
これが大事なのでちゃんと名前を変更しようねという話(4敗)。

これの何が問題かと言うと、これを対策せずにうっかり名前が重複したファイルを保存したりする(つまりバージョンが一致する様なパッケージが複数現れる)とemerge時に問題が起きる。
多分以下の様なことが起きる。

  1. 対策されていないパッケージAをemergeする
  2. 対策されていなくかつパッケージAと同じバージョンであるパッケージBをemergeする
  3. パッケージAをemergeした時に保存される、パッケージAのtarボールをパッケージBのemergeで使おうとしてしまう(同じ名前のファイルなので)
  4. tarボールのチェックサムが一致しない、もしくはサイズが一致しないのでエラーが出る

おわり

この問題で出るエラーメッセージはこの問題が原因であるということに辿り着きにくいような内容なので、ここにメモしておくね
dev-embedded/cc65: fix SRC_URI. · karubabu/gentoo-overlay@f91d0cd · GitHub
問題を修正したコミット(これだけではない)

8月~9月のmikocon.comフォーラムへの侵害を調べた

趣味で割れフォーラムやハックファーラムを覗いたりしているものだ(WNPNMN)
その時に見付けた中国系割れフォーラムであるMikocon.comの話
こんなこと全然やったことがないので、"よく分かりませんでした。いかがでしたか?"になるだろうし、
間違っている部分も出ると思うので、そーゆーところは教えてくれー!

https://www.mikocon.com/thread-47863-1-1.html

何が起きたとされているのか

見出しの通り、本当に何が起きたのかは上記のスレッドに全て書いているわけではない。
というのも、フォーラム管理者が侵害によって設置されたスクリプトの中身を判断せずに消去したため。

上記の記事の雑な要約

8月20日に管理スタッフのアカウントが侵害される、これは管理スタッフの弱いパスワードが原因と考えている。
同日、悪意のあるスクリプト("0x."から始まるサイト)をフッターに設置される。

9月14日、このスレッドを立てたアドミンの一人が侵害に気が付き、悪意のあるスクリプトを撤去する。
しかし、スクリプトが何をしていたのかは把握していない。

よって定かではないが、8月20日~9月14日にログインしたユーザーはパスワードを侵害された可能性がある。
mikocon.com自体から何かが盗まれた等はない。(mikocon.com自体には何も置かれていないため)

このスレッドを立てたフォーラム管理者は、mikocon.comで常にNoscriptアドオンを使用している。
よって、私(このスレッドを書いたフォーラム管理者)に対してスクリプトが動いたとは思えない。

スクリプトは一体何をやっていたのか

確認されずにフォーラムから削除された悪意のあるスクリプトが何をやっていたのか調べた。
archive.orgに侵害された期間に保存されたデータがある。
https://web.archive.org/web/20200911041156/https://www.mikocon.com/forum.php
その中には、"0x."から始まるスクリプトが確かに存在している。
https://0x[.]ax/YbAQ
0x[.]axはxss[.]ptへのエイリアスで、これはXSSプラットフォーム。

スクリプトは以下の通りにログイン情報やDB情報をaj2e[.]tkへ送信していた。

  • ログインしているのなら、ログアウトし、このスクリプトによって一度ログアウトした事を確認するcookieを追加する
  • ログインボタンをクリックしたタイミングで、入力されているユーザー名とパスワードを外部のサーバーへ送信する
  • エンターキーを押したタイミングで、入力されているユーザー名とパスワードを外部のサーバーへ送信する
  • メンバー専用画面(member.php)でログインした場合は、ユーザー名・パスワード・秘密の質問そして秘密の質問の答えを外部のサーバーへ送信する
    * ログインしているユーザーがフォーラム管理者(discuz_uid == 1)なら、admin管理画面からDBのインポートリクエストを行い、結果を外部のサーバーへ送信する
  • ログインしているユーザーがフォーラム管理者(discuz_uid == 1)なら、./admin.php?action=db&operation=importのページhtmlを外部のサーバへ送信する

所感

DBのインポートリクエストは、ぱっと見た感じだと何をするためなのか分からなかった。

  • エクスポートなら分かるのだけれど、インポートとは何が目的なんだろう…
  • インポートのfetchリクエストのbodyがnullなので、無をインポートしてDBを削除する目的の可能性はある えあいさんが調べてくれました。 ありがてー!

フォーラム管理者の"パスワードが漏れた"という発想は間違っていなかったが、実際には、ユーザーの秘密の質問やその答えも漏れている。
cookieを確認することでユーザーは自身が侵害されたかどうかを確認する方法が一応ある。

  • cookie一覧にdiscuz_01というクッキーで、"3.2"という値が格納されていれば高い確率で侵害されている
  • このクッキーがあっても、その後にログインしていなければ問題はない

xssプラットフォームが使われていたけれど、実際XSSが原因なのかは分からなかった。

  • スレッドを読む限りだと、分からない部分には"多分"や"可能性がある"と言っていて、そうでない部分は言い切っているので、管理スタッフのパスワードが弱くて破られたのは本当そうではある

これ以上調べると長くなりそうなので例のヤツを唱えて終わりにしましょう!
調べてみた所、割れプラットフォームは侵害後の対応もそれなりに雑ということが分かりました!
いかがでしたか?良い子の皆は割れを…しないようにしようね!

追記

passivetotalでaj2e.tkを調べた。
f:id:karubabu:20210119065136p:plain
侵害が起きる前である、8月20日前までこのドメインが使われていた形跡がある。 この52.229.135.210について調べると、advtekgroup.com.twというドメインが、侵害がフォーラム管理者に発見されて10日経った程度の頃にこのIPaddrで使われるようになっている。
f:id:karubabu:20210119065419p:plain

f:id:karubabu:20210119065839p:plain
advtekgroup.com.twの検索結果

さらに、advtekgroup.com.twのその後のIPaddrである158.247.200.199は、i.9bie.orgと一致する。これは先程の検索結果に出てきていた人のブログ。

f:id:karubabu:20210119070156p:plain
advtekgroup.com.twと同じip addrだったことのあるドメイン

teregramにアカウントを持つ@bakabieさんは、ブログによればinfosecにかなり造詣を持ち、RATの開発も行なっているようだ。

fcitx4からfcitx5に移行した

しました
どっかのoverlayにはfcitx5のebuildが既にあったのだけれど、折角なので自分でebuildを書いた
以下はよく分からなくてハマったところ

firefoxgimp上でnihongo ga utenai

つまり、gtk系のGUIでfcitx5が機能していないので、fcitx5-gtkが上手いことインストール出来ていない
でもQAnotice(なんかgentooのポリシーに違反している状態を、インストール時に教えてくれるやつ)は出ていない

imモジュールをgtk側に認識させる

$ fcitx5-diagnoseとかいうえらすぎる診断コマンドがあるのでそれを使う
適当に出力を読むと、Not Found fcitx5 im modules for gtk的な事が書いてある
これはつまり、fcitx5 のim moduleの存在をgtk側に知らせる類いのコマンドを、インストール時に呼び忘れているということらしい
ということで fcitx5-gtk内でgnome2-utilsにあるgnome2_query_immodules_gtkNの様なやつを、pkg_post{inst, rm}に呼ぶ
gnome2-utils.eclass – Gentoo Development Guide
gentoo-overlay/fcitx5-gtk-5.0.1.ebuild at master · karubabu/gentoo-overlay · GitHub

おわり

eclassってなんかいっぱいあって何を使えばよいのか全然わからんのよね
毎回、散々調べて遠回りし放題プラン(au by kddi)した後に"あ、これeclassを使うやつなのね…"という顔になる

fcitx5自体は使って見た感じ、fcitx4と全く遜色のない動きをしてくれるので最高だと思う
fcitx5-skkも問題なく動くので、fcitx4-skkで使っていた機能をこちらに移植すれば、fcitx4と同じskk環境に戻れそう
みんなもfcitx5-skkを使ってGNU/linuxSKK環境をなんとかしてくれー!

続 go製のプロジェクトのebulidを書く

go製のプロジェクトのebulidを書く - karubabuの日記

後はgo系のebuild classがやたら一杯あるのが謎だったね 結局golang-vcs-snapshotのみを使ったけれど、これでよかったのか、もっと相性の良いものがあったのか、全然わからん!

ここの話です

なにがあった

GitHub - imthaghost/scdl: SoundCloud music downloader 🎶
これのebuildを書こうと、前と同じ様にgolang-vcs-snapshotを使った書いたらビルドが通らなかった
詳しいエラーメッサゲはもう残っていないのだけれど、

is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt

と出るしなんか駄目らしい
そんなこと言ったって前(https://karubabu.hateblo.jp/entry/2020/02/13/034634)はこれで出来てたじゃんね

どうすりゃいい

諦めてgolang様のeclassについて多少調べた
どうやら、基本的にはgo-moduleというクラスを使うこと考えて、go-muduleに適合しないソフトウエアはgolang-*クラスを使うべきらしい
go-module.eclass – Gentoo Development Guide

This eclass provides basic settings and functions needed by all software written in the go programming language that uses modules. If the software you are packaging has a file named go.mod in its top level directory, it uses modules and your ebuild should inherit this eclass. If it does not, your ebuild should use the golang-* eclasses.
If, besides go.mod, your software has a directory named vendor in its top level directory, the only thing you need to do is inherit the eclass. If there is no vendor directory, you need to also populate EGO_SUM and call go-module_set_globals as discussed below.

scdlはgo.modがtop level directoryにあるのでこのmoduleを使い、かつvendor directoryが無いのでEGO_SUMを作らないといけないらしい

どうした

go-moduleの説明通りに書いた
go.sumを内容をEGO_SUMの列挙フォーマットに合わせるのはcat go.sum | cut --fields=1-2 -d" " | sed -e 's:$:":' | sed -e 's:^:":' | xsel -ciとかやれば捗る
gentoo-overlay/scdl-2.0.2.ebuild at master · karubabu/gentoo-overlay · GitHub
完成したものがこれ

おわりに

golang製のソフトウエアも一枚岩ではないらしい
じゃあ前にやったdns-over-httpsはotp level directoryにgo.modがないプロジェクトだったんだなあ☺️と思って見に行ったら、普通にあった
GitHub - m13253/dns-over-https: High performance DNS over HTTPS client & server

どういうことなものなの??やっぱり分からん!

systemd-resolvedでNXDOMAINが返ってくるような名前解決を求めるとnetwork errorになる

解決しなかったので供養です
systmed-resolvedのDNSOverTLSが良い塩梅になったので( RFE: Certificate checking for Resolveds DNS over TLS feature · Issue #9397 · systemd/systemd · GitHub )
使おう!ー>うまくいかない(◞‸◟)というやつです

なにがあった

[Resolve]
DNSOverTLS=yes
DNSSEC=no
DNS=2606:4700:4700::1111#1dot1dot1dot1.cloudflare-dns.com 2606:4700:4700::1001#1dot1dot1dot1.cloudflare-dns.com  1.1.1.1#1dot1dot1dot1.cloudflare-dns.com

/etc/systemd/resolved.conf.d/dns_over_tls.confあたりに置いて、
systemctl start systmed-resolvedすると、
名前解決出来るものは問題ないのだけれど、名前解決が失敗するはずのものdrill sthoeusntahublablabla.com等を行うと、十数秒待たされた後にnetwork errorになる
(本当はエラーの文章をそのまま貼り付けた方が良いのだろうけれど、もうログを出せる状態でないし面倒なので適当)

どうした

LLMNRの無効

nss-resolve returns UNAVAIL for LLMNR resolution failures · Issue #14922 · systemd/systemd · GitHub
これかしら…と思ってLLMNRを無効にしたけれど、特に関係はなかった(◞‸◟)
LLMNRを無効にするには、global設定であるsystemd-resolved側からLLMNRを無効にするのと、
インターフェース毎の設定をsystmed-networkd側でやらないといけないので注意が必要だった
Bug #1777523 “Unable to set systemd/network settings from netpla...” : Bugs : netplan
具体的にはこれ

ログの確認

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

systemctl edit systemd-resolvedで加えてjournalctl -efu systemd-resolvedを実行し、
適当な名前解決をするコマンドdrill stohublablabla.comを叩いたログを見た
すると、
Connection failure for DNS TCP stream: Connection refused is:closed
Failed to invoke gnutls_handshake: Error in the push function.
の様なログが大量に流れているのが見えた
これらのログはTransaction 47045 for <photos-ugc.l.googleusercontent.com IN A> on scope dns on wlp0s20u2/* now complete with <attempts-max-reached> from none (unsigned).の様な、attempts-max-reachedという単語がログに出るのと共にログに出なくなっていた
このログは、名前解決に成功しても失敗しても発生していた
なので、名前解決成功時は成功した結果をよしなにして終了するけれど、名前解決失敗時はこのログに出ている作業の終了を待っているのでは…?という感じある
エラーの内容的にも、これらならnetwork errorとdrillの結果が表示されるのも分からないでもない

でもこれらのログでgithubのissueを検索しても、それっぽいのが見付けられなかった(◞‸◟)

おしり

万策付きたのでdnsmasq+dns-over-httpsの環境に戻しました
これの他には、DNSSECのvalidationを有効にすると結構な頻度で見れないサイトが出現する(www.ipa.go.jp等)的な話もあるのだけれど、
まあこれもどうすればよいのか分からんねという感じで終わってしまった
DNSSECのvalidationの問題に関しては、dnsmasq+dns-over-httpsな環境でdnsmasqのdnssec validationを有効にしても発生するので諦めみたいな不死もあるね
しかも、systmed-resolvedで見られなくなるサイトと、dnsmasq+dns-over-httpsで見られなくなるサイトは一緒ではないのでまた良くわからない

gcc10を使ってビルドするときに確認しないといけないやつ

そのままビルドし始めると結構なソフトウエアがビルドに失敗するやつ
Porting to GCC 10 - GNU Project - Free Software Foundation (FSF)

Gcc 10 porting notes/fno common - Gentoo Wiki
gentooは、リンク先に書かれている通りにビルドする時に環境変数を追加するのも良いけれど、
/etc-portage/env/${CATEGORY}/${P} なファイルにCFLAGS="${CFLAGS} -fcommon"と書いておけば勝手にgcc9の様な感じでビルドが通る

Porting to GCC 10. · karubabu/netplan@677a01a · GitHub
大分前にnetplanのgcc10対応のコードを書いたのだけれど、PRを送らずにそのまま別の人が対応のPRを送ったので供養しておくね
ランチパッドみたいな名前の場所にissueをクローズしにいくのが大儀だった

btrfsの圧縮アルゴリズムを変更する時に必要っぽいこと

つまるところ、全体の圧縮アルゴリズムを変更する時は、マウントオプションでアルゴリズムを設定してからbtrfs filesystem defragment -r -t5G .をやるのが良さそう

背景

LUKS の☝️にbtrfs を乗せて暗号化しつつ適当に圧縮かけて捗らせたいね、というのが趣旨
基本的に保存すること自体が目的のオキニの動画や画像やその他のファイルを、HDDに保存したいので、
書き込み速度やなんやらを全て無視して、読み込み速度がそれなりで圧縮効率が良さそうなbtrfsのzstdの15レベルを使って圧縮したい…

けれど、この作業を始めた当初はzstdというものを知らなかったので、とりあえずcompress=lzoを付けてHDDをマウントしてファイルをコピーし始めてしまった
勿論データを全て消してからcompress=zstd:15を付けてマウントしてやり直せば間違いはないのだけれど、
後から圧縮アルゴリズムをzstd:15に変更するにはどうすればええねんということを調べたり、そもそもその作業が成功しているかどうかを確認する方法はどうすれば良いのか調べた

謎ら

95割はCompression - btrfs Wikiここを読めばよいのだけれど、それでも何だか謎みあることが幾つかある。

  • btrfs filesystem defragment-cオプションはzstd:15の様なレベル指定を受け付けてくれない
  • btrfs filesystem defragment-cオプションはzlibらしいのだけれど(man btrfs-filesystemに書いてある)、This is independent of the mount options compress or compress-force, and using the option -c you can set the compression algorithm.の意味が分からない
  • 圧縮された後のファイルから、どの圧縮アルゴリズムが使われているのか判断出来無い
  • 計測の方法が分からない

わからんことだらけやんけ

やったこと

しっかり計測したことなんてないし、ここを詰めると絶対に面倒なやつなので計測は適当にやる
基本的に、dfコマンドを使ってどれだけ空き容量が空くかで上手くいっているのかどうかを判断した
dfbtrfs filesystem dfだと出力されるサイズが違うという話はあるのだけれど、まあ誤差でしょう

https://mstdn.maud.io/@babukaru/104629699414995825
これらが試行錯誤した結果なのだけれど、調べ方が行き当りばったりだし、後から見ると色々情報が抜けていて何を言っているのか分からんねえ
空き容量って何に対してやねん
でも面倒だし、このツイーヨした部分は重要ではないと勝手に私は思っているので、何か読み取りたい人はこのツイーヨからエスパーしてね

これらを試した後、rm -rf /mnt/encrypt_data/*;sync;umonut /mnt/encrypt_dataして(/mnt/encrypt_data は圧縮したいHDD)、
当初の目的だったzstd:15での圧縮をマウント時から指定して(compress-force=zstd:15)ファイルをコピーし直した結果、
btrfs filesystem df /mnt/encrypt_dataのサイズは、"マウントオプションでcompress-force=zstd:15を設定してbtrfs filesystem defragment -r -t5G /mnt/encrypt_dataしたもの"とほぼ等しくなった
このことから、少なくとも箇条書きした疑問点の2番目は、-cオプションを付けなければzlibになるというわけではなさそうだとは思う
よくよく考えてみれば当たり前ではあるのだけれど、自信はないみたいな感じだった

おわりに

分かったような分かっていないような
そもそも計測の仕方がガバガバなのでもう全てがガバガバで何の腹の足しにもなっていない感じがすごい
最終的にはzstd:15で圧縮されたことは間違いないだろうしまあ良いでしょう
最後の大事な話です
https://mstdn.plusminus.io/@mohemohe/104634297256629871
https://mastodon.cardina1.red/@lo48576/104634286070925741
https://mastodon.cardina1.red/@lo48576/104634289896653923
百里ある