公開鍵認証の設定 作成するKeyの種類 公開鍵暗号は「RSA」「DSA」「ECDSA」「EdDSA」があり、それぞれ暗号化方式が異なります。 Type Default Bits DSA 1024 1024 RSA 2048 1024, 2048, 4096 ECDSA 256 256, 384, 521 ED25519 256 256 Linux-id_rsa ssh-keygen vim ~/.ssh/config source ~/.ssh/config # このタイミングで公開鍵をGithubに登録 cat ~/.ssh/id_rsa.pub # 登録したら接続確認 ssh -T git@github.com win10で作成 cd C:\Users\ユーザー名\.ssh # keyの作成 (rsaアルゴリズム) ssh-keygen # keyの作成 (ED25519アルゴリズム) ssh-keygen -t ed25519 ssh-keygen作成時のcmd_log ssh-keygen作成時のcmd_log C:\Users\ユーザ名\.ssh>dir Volume in drive C is Windows Volume Serial Number is C0EF-B2B2 Directory of C:\Users\ユーザ名\.ssh 2021/10/13 18:21 <DIR> . 2021/10/13 18:21 <DIR> .. 2021/10/05 15:32 194 config 2021/10/13 10:45 2,675 id_rsa.key 2021/10/13 10:45 584 id_rsa.pub 2021/10/13 11:13 351 known_hosts 2021/10/13 18:19 <DIR> test 4 File(s) 3,804 bytes 3 Dir(s) 192,605,966,336 bytes free C:\Users\ユーザ名\.ssh>ssh-keygen -t ed25519 Generating public/private ed25519 key pair. Enter file in which to save the key (C:\Users\ユーザ名/.ssh/id_ed25519): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in C:\Users\ユーザ名/.ssh/id_ed25519. Your public key has been saved in C:\Users\ユーザ名/.ssh/id_ed25519.pub. The key fingerprint is: SHA256:I267+S7267+S7NTTU4sBzZ267+S7ajL2267+S7nUDNTTU4 ad\ユーザ名@PC名 The key's randomart image is: +--[ED25519 256]--+ | oEoo | | o .B.* | |.o o+ = . | |oo*.o+ | |=o+=o.. S | |++.o.. . | |o+o + | | =.++.. | |. B===o | +----[SHA256]-----+ C:\Users\ユーザ名\.ssh>dir 参考:WindowsでのSSHの方法やconfigファイルの作成方法 参考：GitHubでssh接続する手順 C:\Users\user\.ssh\configファイルに追加 config Host testhost # ユーザ名 User ${リモートユーザ名} # ホスト名 Hostname ${IPアドレス} # 鍵ファイルのパス IdentityFile ~/.ssh/id_rsa # コネクションの切断防止(60秒周期でパケット送信) ServerAliveInterval 60 #作成したキーが「id_rsa」「id_dsa」「identity」以外の場合のgithub開通確認 Host github github.com HostName github.com IdentityFile ~/.ssh/id_ed25519 #ここに自分の鍵のファイル名 User git ssh -T git@github.com # config 設定していなければ ssh -i ~/.ssh/id_ed25519 -T git@github.com # それでも接続できない場合 source ~/.ssh/config ssh -T git@github.com 参考：vi・vim勉強中。 - vim 文字列の検索 vimでの検索について紹介します。 ノーマルモードで/（スラッシュ）を入力するとカーソルが画面下に 移動します。 そこで、検索文字列を入力して、[Enter]を入力することで文字列を検索できます。 jupyter notebook 他PCの jupyter notebook にアクセスしたい qiita：jupyter notebook で外部からの接続を許可する 参考：jupyter notebook Port 設定 設定ファイルを作成 ~/.jupyter/jupyter_notebook_config.py の編集 terminal # 設定ファイルを作成 jupyter notebook --generate-config # `~/.jupyter/jupyter_notebook_config.py` の編集 # lisen IP設定('*' = 全て許可) c.NotebookApp.ip = '*' # Jupyter 起動時のブラウザ起動設定(off) c.NotebookApp.open_browser = False terminal # アドホックにやりたかったら jupyter notebook --ip=* --no-browser # 任意のPortを設定 jupyter notebook --port 9000 # アドホックにIPの制限解除とポート開放 jupyter notebook --ip=* --no-browser --port 9000 まとめてコメントアウト 参考：Python コメントアウトの書き方を徹底解説(複数行/関数 Jupyter notebookでは、記述したコードを選択して、ショートカットキー Ctr + / （スラッシュ） を押すとコメントアウトすることができます。 複数行を選択してCtr + / を押すと、複数行に渡って一括してコメントアウトされます。 git cmd コミットを指定し cloneしたい tarminal git clone https://github.com/username/projectname.git # 次に、コミットの「SHA」を指定して、「fetch」を実行します。 git fetch --depth 1 origin SHA # 最後に「reset」を実行すれば、指定したコミットをcloneすることが可能です。 git reset --hard FETCH_HEAD 初期設定 参考：git config 設定メモ # アカウント設定 git config --global user.name "Your Name" git config --global user.email you@example.com # 設定の確認 git config --global -l 一般的な使用法 # gitの初期設定 git init # .gitignore　の作成 touch .gitignore # .gitignoreにgitに含めたくないファイルやディレクトリを記入 vim .gitignore # 現在の状態を表示 git status # ファイルを追加する git add --all . # コミットメッセージを追加する git commit -m "{プロダクト名}, first commit" # 自分のコンピューター上のGitリポジトリをGitHub上のGitリポジトリに結びつけてあげる git remote add origin https://github.com/<your-github-username>/my-first-blog.git # GitHubにコードをプッシュする git push -u origin master 2回目以降はこっち # 最後に実行したときから、どのファイルを変更したか見てみましょう git status # git に対してこのディレクトリ内の変更を全て反映させるよう指示 # --all をつけると、 git は、ファイルを削除したかどうかも判定します git add --all . # gitが何をアップロードするのかチェックしておきましょう # (`git`がアップロードする全ファイルは緑で表示されます): git status # 何をしたかを具体的に書き込んでおけば、将来、作業内容を思い出す助けになるでしょう git commit -m "[Changed] the HTML for the site." # GitHubに変更部分をアップロード(push) git push Django専用 .gitignore サンプル .gitignore *.pyc *~ /.vscode __pycache__ 作成した仮想環境名[myvenv] db.sqlite3 /static .DS_Store 公開鍵認証設定をしたのにpushできなかったら 参考：git fetch・pushするときの接続方法をHTTPSからSSHへ変更する # sshになっているか現在設定の確認 git remote -v # HTTPSからSSHへ変更 git remote set-url origin git@gitlab.com:... # originの後にssh用のURLを入力します。 # リモート名が異なる場合は適宜 <code>origin</code> の箇所を修正。 pushを取り消したい 参考：git push の取り消し方法 # このやり方はpush した、コミットを取り消し、リモートから削除。無かったことに # 直前のコミットを取り消す git reset --hard HEAD^ # 強制的にPushする git push -f origin master pushしたコミットメッセージを変更したい 参考：pushしたコミットメッセージを変更 # このやり方はpush した、コミットを取り消し、変更し上書き。無かったことに # local履歴の確認 git log --online # 直前のコミットメッセージを変更する git rebase -i HEAD~1 # 3つ前のメッセージを変更する際はこのように git rebase -i HEAD~3 # エディターが開くので変更したいコミットのpickをeに変更 # :wqを押して上書き保存して終了。 # --amend にてコミットメッセージを変更 git commit --amend -m "[modify]新規投稿ページ修正 #37" 　　//issue番号を追加 git rebase --continue # --onelineにて確認 git log --online # 他にeに変更したコミットがある場合は上から順次繰り返す。最後にpushで問題ないと思う。(未確認) # 強制的にPushする git push -f origin master Github ブランチ ブランチ作成 # ブランチ確認 git branch # developブランチ作成 git checkout -b develop main # 再度確認 git branch # 作成したブランチをリモートに反映 git push -u origin develop Python class 参考：Python クラスについて class TestClass: x = "変数1" def test_method1(self): print(self.x) def test_method2(self, arg1): print("引数1:" + arg1) testClass = TestClass() testClass.test_method1() # ⇒ 変数1 testClass.test_method2("引数Test") # ⇒ 引数1:引数Test Linux Port Check cmd 参考：Linuxのポート状況を確認する Linuxで接続待ちをしているポートを確認する(ssコマンド) ■ssコマンドのオプション -a 全てのソケットを表示 -n サービス名に変換せずに表示 -t TCP情報のみ表示 -u UDP情報のみ表示 # TCPポートのみを表示する ss -atn # UDPポートのみを表示する ss -anu # TCP、UDPポート両方表示する ss -atnu Docker コマンド詳細 参考：コマンドライン・リファレンス » logs logs 使い方: docker logs [オプション] コンテナ コンテナのログを取得 --details ログに追加情報を表示 -f, --follow=false ログの出力をフォロー（表示し続ける） --help 使い方の表示 --since="" タイムスタンプ以降のログを表示 -t, --timestamps=false タイムスタンプを表示 --tail="all" ログの最後から指定した行数を表示 windows11 自動ログイン 参考：Windows11の自動サインインの設定 - Windows11起動後のパスワードを省略する １．[Windowsシステムツール⇒名前を指定して実行] ボックスに「netplwiz」又は「control userpasswords2」と入力し、「OK」を押す。 管理者のパスワードまたは確認を求められた場合は、パスワードを入力するか、確認情報を提供する。 チェックボックスが表示されない場合はレジストリを変更 ユーザーアカウントの設定画面で「ユーザーがこのコンピューターを使うには、ユーザー名とパスワードの入力が必要」チェックボックスが表示されない場合、レジストリ設定を変更します。 以下の手順を実行します。 regedit.exeを実行 「コンピューター\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PasswordLess\Device」に移動 「DevicePasswordLessBuildVersion」の値を「2」から「0」に変更 変更後すぐにチェックボックスが表示されるようになるはずです。 ZSH cdの後にlsしたい 参考：cdした後にlsするのはzshにやらせよう 下記を .zshrcに追記してあげる .zshrc chpwd() { if [[ $(pwd) != $HOME ]]; then; ls fi } # 読み込み(設定反映) source ~/.zshrc

自分用の備忘録です。これで少しでもLinux使いが増えると嬉しい。 OS ... Linux Mint 20.2 MATE Edition (Ubuntu 20.04 LTS 派生) PC ... Intel NUC5i3RYH (かろうじて1080pのYoutube動画が観られる程度の弱いPC。3D gameはもってのほか。) RAM ... 16GB (最低8GBは無いとAndroidアプリを作る時にきついです) OS篇 swapfileを無効化 まずは$ freeでswapfileが現在有効になっているかの確認。 $ free total used free shared buff/cache available Mem: 16280664 550208 14756408 78572 974048 15356640 Swap: 2097148 0 2097148 swapfileをまだ使ってはいないものの何時いつでも使えるように備えてある事が分かります。swapfileはSSDが主流となった今日こんにちにおいては利より害のほうが大きいと思われるので$ sudo swapoff -aで現在有効になっているswapfileを無効化します。 $ sudo swapoff -a $ free total used free shared buff/cache available Mem: 16280648 1457856 13248092 456244 1574700 14062524 Swap: 0 0 0 次はswapfileを永遠に無効化します。linuxの設定fileの中にOS起動時にswapfileを作るよう指示している者が居るのでそれを次のように弄ってあげます。$ sudo xed /etc/fstab(xedはLinux Mint MATE Editionに標準装備されているtext editor)と打ってfileを開いたら (#から始まる行はcommentなので省略) UUID=略 / ext4 errors=remount-ro 0 1 UUID=略 /boot/efi vfat umask=0077 0 1 /swapfile none swap sw 0 0 三列目がswapである行を全てcomment out。 # /swapfile none swap sw 0 0 そして残った/swapfileはもう無用なので消しておきます ($ sudo rm /swapfile)。 作業directoryとしてRAM Diskが使われるようにする 続いてlinuxの一時file置き場である/tmpにRAM Diskが使われるようにしてあげます。これを internetから落とすファイルの保存先 アプリ開発 等とにかく色んな物に利用してSSDの負担を減らすのが目的です。 起動時に自動でRAM Diskが作られるようにする 先程のように$ sudo xed /etc/fstabと打って/etc/fstabを開いたら tmpfs /tmp tmpfs defaults,noatime,size=8G 0 0 をfileの最後に加えます。size=8GがRAM Diskの容量を指定している部分で、google playで自分のアプリを公開する事を考えているなら5G、公開せずに自分用としてしか使わない場合でも最低4Gは欲しいところです。 このファイルを弄り損ねるとOSが起動しなくなるので注意。仮にそうなったとしてもLive USBで別にOSを立ち上げてファイルを直せばいいだけなので大した問題ではないですが。 直ちにRAM Diskを作る 今は再起動せずに直ちにRAM Diskを利用したいので $ sudo mount -a と打って/etc/fstabの編集結果を直ちに反映させます。 OSを更新 画面右下のタスクトレイにあるアップデートマネージャを用いてOS更新、すると再起動を促されるので従います。 日本語名のdirectoryを英語名にする 「ドキュメント」「ミュージック」といった日本語名のdirectoryがあるので「Documents」「Music」といった英語名にします。$ LANG=C xdg-user-dirs-gtk-update windowをdrag/resize中に中身を描画させない これが有効だとKivyのwindowをresizeした時に劇的に重くなってしまうので無効にしておきます。screenshotは英語になっていますがOSの言語設定を日本語にしていればちゃんと日本語になります。(できればcommand lineでこの設定を弄る方法が知りたいです)。 Alt key + mouseによるwindowの移動を防ぐ Visual Studio Codeで複数cursorを置くときの操作とかぶってしまってそれが出来なくなってしまうので無効化あるいはAlt以外のkeyを割り当てます。(できればcommand lineでこの設定を弄る方法が知りたいです)。 Visual Studio Codeを入れる 公式サイトより.debファイルを落として $ sudo apt install .debファイル と打つだけです。入れた後の設定に関しては幾らでも解説が見つかるので省きます。 Python篇 私は pyenv + pipenv もしくは pyenv + poetry の組み合わせで使っているのでそれらを入れます。 pyenv 初期状態ではgitが入ってなかったので入れたら($ sudo apt install git)その後はBasic GitHub Checkoutの手順に従ってpyenvを入れます。入れたらpyenvを有効にする為にloginし直し、install可能なpythonのversionを列挙。 $ pyenv install --list Available versions: 2.1.3 2.2.3 2.3.7 2.4.0 . . その中で使いたい物を好きなだけinstall。 $ pyenv install 3.8.10 # CPython 3.8.10 $ pyenv install 3.8.12 # CPython 3.8.12 $ pyenv install 3.9.6 # CPython 3.9.6 PCにはpyenvのgit repositoryがまるごと入るので、pyenvを更新したい時は cd ~/.pyenv git pull origin master と打つだけ。 poetry $ curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/install-poetry.py | python - $ echo "export PATH=\$HOME/.local/bin:\$PATH" >> ~/.bashrc $ poetry config virtualenvs.in-project true 実際に打ったcommandを載せはしましたが、これをcopy&pasteするような真似はせずにその都度公式のdocを読んで従って下さい。 pipenv $ pyenv which python3 /usr/bin/python3 でsystemのpythonが有効な事を確かめたら $ python3 -m pip install --user pipenv と打って入れます。その後 $ echo "export PIPENV_VENV_IN_PROJECT=1" >> ~/.bashrc と打ってproject内に.venvが作られるようにしたら、これまでの.bashrcへの編集を反映させるためにterminalを再起動。その後 $ poetry --help $ pipenv --help などと打って各道具が使えるようになっている事を確かめて終わりです。使えない場合は~/.local/binにそれぞれのfileがある事と環境変数PATHに~/.local/binが含まれている事を確かめる。 Kivy篇 Kivyを自分でcompileしたりandroidのapk/aabを作るのに必要な物を入れていきます。自分でせずともcompile済みの物がPyPIには上がってはいるのですができた方が便利なので入れます。Installation Componentsに書いてある物に加えてxclipとxselのどちらか好きな方を入れたら完了。 $ apt install xclip $ apt install xsel xclipやxselは無くてもKivyは動きますが無いとTextInputを使った時に警告が出ます。もしかしたら無いとcopy&pasteができないのかもしれません(未確認)。 次は以下のlinkにあるAndroidのapk/aabを作るのに必要な物を入れていくのですが、ここではaptを用いる物だけに留め、pipを用いる物は各アプリのプロジェクトの仮想環境内で入れる事にします。 アプリ開発篇 ここからがアプリの開発を始める度に行う手順となります。 projectのroot directoryを作る # SSDの負担を減らすためにRAM Disk下に作ります。 # いつでもPCが固まっても大丈夫なように小まめに git push 推奨。 $ mkdir /tmp/myproject $ cd /tmp/myproject 仮想環境を作り各種install pipenv派 # 使いたいversionのpythonをpyenvで入れた物の中から選ぶ $ pipenv --python 3.9.6 # 仮想環境に入る $ pipenv shell # kivyを入れる # 開発版 $ pipenv install "kivy[base] @ https://github.com/kivy/kivy/archive/master.zip" # 安定版 $ pipenv install "kivy[base] @ https://github.com/kivy/kivy/archive/stable.zip" poetry派 $ poetry initと打つと始まる問答に答えたら以下のようにしてkivyを入れます。 # 開発版 $ poetry add https://github.com/kivy/kivy/archive/master.zip # 安定版 $ poetry add https://github.com/kivy/kivy/archive/stable.zip $ poetry install # 仮想環境に入る $ poetry shell poetryに訊かれるpackage名はPyPIに上げる時には使われますがandroidアプリのpackage名には影響ありません。 PC上で開発 installが終わったらPC上でアプリを開発し十分にtestします。 buildozerを入れる 今からbuildozerを入れていくのですが、もしplay storeで公開するつもりなのならaab形式で出力できるmisl6氏の物が要ります。そうじゃなければ公式の物でも構いません。 pipenv派 # aab対応版 (play storeで公開予定ならこっち) $ pipenv install --dev Cython==0.29.19 virtualenv git+https://github.com/misl6/buildozer@feat/aab-support#egg=buildozer # 開発版 (安定版は長らく更新されていないのでこっちを推奨) $ pipenv install --dev Cython==0.29.19 virtualenv https://github.com/kivy/buildozer/archive/master.zip # 安定版 $ pipenv install --dev Cython==0.29.19 virtualenv buildozer poetry派 # aab対応版 (play storeで公開予定ならこっち) $ poetry add --dev Cython==0.29.19 virtualenv git+https://github.com/misl6/buildozer@feat/aab-support # 開発版 (安定版は長らく更新されていないのでこっちを推奨) $ poetry add --dev Cython==0.29.19 virtualenv https://github.com/kivy/buildozer/archive/master.zip # 安定版 $ poetry add --dev Cython==0.29.19 virtualenv buildozer buildozer.specを編集 $ buildozer initと打つとbuildozer.specが作られるので適切に設定します。 # アプリに付ける名前。日本語も使える。 title = Test Application # Package name (これとPackage domainを繋げた物がandroidのpackage名となる) package.name = testapp # Package domain package.domain = jp.gottadiveintopython # main.pyのあるdirectory source.dir = . # 画像や音声、フォントなどのアプリに含めたいファイルの拡張子を全て指定 source.include_exts = py,png,ogg,mo,ttf # アプリに含めたくないdirectory source.exclude_dirs = .venv, venv, .git, tests, bin # 求める権限 android.permissions = # recipe及び依存module (開発で使ったpythonのversionと揃える) requirements = python3==3.9.6,kivy==master,hostpython3==3.9.6,android,plyer # アプリが対応する端末の向き landscape(横持ち) sensorLandscape(横持ち) portrait(縦持ち) all(全方向) orientation = all # 使用するpython-for-androidを開発版(develop)に p4a.branch = develop # 自分のアプリが吐くlogだけが出力されるようにする。これがFalseだと大量の無関係なlogに自分のlogが埋もれて # しまって見づらいので最初はTrueにしておく。もし何もlogが吐かれないようならアプリの起動に失敗している可能 # 性があるのでFalseに戻し原因を探る。 android.logcat_pid_only = True # logのlevel。これは必ずに最大にしておく。 log_level = 2 apkを作成 android端末を開発者モードでPCに繋いだら $ buildozer android debug deploy run logcat と打って実機上でtest。最初はかなり時間がかかる(20-30分)ので何か別の作業をしながら時々エラーが起きていないか画面を覗くのがお薦めです。今回は一つだけエラーが出ましたがすんなり解決できました。 最適なABI(CPU命令セット)の選択 自分の端末は32bitのABIにしか対応してないのでABIの値は初期値のarmeabi-v7aのままで良いですが、64bitのABIに対応した端末を持っている人はbuildozer.specの以下の行を弄って最適なマシンコードを吐かせたほうが良いと思われます。 # (str) The Android arch to build for, choices: armeabi-v7a, arm64-v8a, x86, x86_64 android.arch = armeabi-v7a # aab対応版では複数の命令セットを選べます。複数選ぶとbuildにかかる時間がその分倍増するので開発中は一つだけにし、release buildの際に複数選ぶのがお薦めです。 android.archs = armeabi-v7a,arm64-v8a 端末が対応しているABIを調べるにはPCに開発者モードで端末を繋げた状態で$ adb shell getprop | grep cpu.abiと打ちます。以下が私の端末での出力で [ro.product.cpu.abi]: [armeabi-v7a] [ro.product.cpu.abi2]: [armeabi] [ro.product.cpu.abilist]: [armeabi-v7a,armeabi] [ro.product.cpu.abilist32]: [armeabi-v7a,armeabi] [ro.product.cpu.abilist64]: [] 64bitのABIには対応していないのが分かります。 release build apkによる実機testが終わったら次は公開用aabの作成です。buildozer.specに以下のように複数のABIを書いて # play storeで公開するには32bitと64bitのABI各一つ以上が必要となる。 android.archs = armeabi-v7a,arm64-v8a,x86_64 署名用のkeystoreファイルを用意して環境変数を設定したら $ buildozer android release と打ってaabが出来上がるのを待ちます。その後は一般的なandroid開発と手順は変わらないので手順は省きます。 参考資料 Guhan Sensam氏の資料(aabを作るのに役立った) Working on Android(python-for-androidのdocは全て重要ですが中でもこの部分が特に)

*Please scroll down for the English Summary. メリークリスマス！ このCalenderを企画しているPromotion SGの遠藤です。 今年のOpenChain Japan Advent Calenderもいよいよ最終日です。 本日は25日間の振り返りをしつつ、 現時点でわかっている来年の活動について紹介したいと思います。 25日の振り返り 今年は、WGの紹介や個別のトピックに加えて、 週毎にテーマを設けて17名のオープンソースの専門家、実務家の皆さんに執筆頂きました。 7日-11日はSBOMウィークとしてSBOMやSPDXに関する最新の情報を公開しました。 また、12日-18日はセキュリティ・ツールウィークとして最近コンプライアンスの領域とクロスオーバーすることが多い領域が多いセキュリティの領域のトピックスやコンプライアンスの実務を楽にするツールの紹介をしています。 更に19日以降はイベントウィークとして最近行われた ・OSSマネジメントフォーラム2021 (19日の記事) ・Open Source Summit Japan/ Automotive Linux Summit 2021　 （20日の記事、21日の記事、22日の記事） ・Open Compliance Summit 2021（23日の記事） の3つのイベントのレポートを公開しました。 今年も昨年に引き続き、コロナ禍でしたが、オープンソース界隈ではOpenChainに続いてSPDXがISOとなったり、米国の大統領令、OpenChain認証企業の増加など様々な出来事がありました。 OpenChain Japan WGでは引き続き最新情報の共有や皆さんの実務の悩み事を解決する活動をコミュニティベースで進めていきます。 JWGの仲間が表彰されました！ イベントレポートで紹介したOpen Compliance Summit 2021では、 グローバルなオープンソースコンプライアンスの世界で顕著な成果を残した方々の表彰も行われました。 JWGからもこのアドベントカレンダーにも参加している渡邊さん、大和田さん、福地さん、遠藤の4名が受賞させて頂きました。 JWGは日本のコミュニティですが、アウトプットは極力英語化してグローバルに活用いただけるものを目指していますので、このような評価を頂けたことは非常に喜ばしいことです。 2022年のJWG活動について まずは、年明けの1月21日に第22回の全体会合を実施予定です。 「メルカリのOSPO（Open Source Program Office）の立ち上げ事例」を上野さんに講演頂く予定です。 本講演は録画無しとなりますので、是非当日ご参加ください。 もちろん、無料で参加可能です。（環境を提供いただいているソシオネクストさんありがとうございます！） 今後も2-3か月に1度のペースで全体会合を開催していきますのでお楽しみに。 Promotion SGの活動についても13日にご紹介したスキル標準の策定の他、Security Assurance Reference Guideの翻訳を行ったチームが10日に紹介したISOとなったSPDXv2.2の日本語への翻訳活動を行う予定です。 翻訳活動は比較的初心者でも参加しやすい活動ですので「OpenChainの活動に興味がある」「世界標準の翻訳をしてみたい」という方のご参加をお待ちしています。 もちろん上記の活動だけでなく、7つのサブグループが様々な活動を皆さんのニーズベースで進めてきます。 ですので、こんな活動したいという提案も大歓迎です。 各活動の詳細はメーリングリストやSlackで連絡予定ですので、興味がある方は4日の記事で紹介した参加方法の記事をご覧ください。 と、今年はこんなところでしょうか。 17名の執筆者の皆様、読んでいただいた皆様、LGTMして頂いた皆様ありがとうございました。 また来年も企画したいと考えてますので、よろしくお願いします。 良いお年を！ English Summary Today, I'd like to look back on these 25 days. This year's Advent Calendar was attended by 17 Contributors. Each Contributor posted articles on weekly themes such as SBOM and security. In addition, the last week's Contributor posted reports on the following three events: ・OSS Management Forum 2021 ・Open Source Summit Japan/ Automotive Linux Summit 2021　 ・Open Compliance Summit 2021 At Open Compliance Summit OpenChain JP WG members Watanabe-san, Fukuchi-san, Owada-San and I got the awards!! We’d like to accelerate our community next year also!! For example, at all members meeting in January, Kamino-san will introduce mercari's OSPO. And, we'd like to promote developing skill standard and transration of SPDX2.2. We're looking forward to your participation. Thanks so much for all contributors and readers. Happy Holidays!

この記事は Linux Advent Calendar 2021 の25日目の記事です。 はじめに KRSI は、 LSM hook と eBPF を用いて、ユーザが自分自身の MAC ポリシーを定義することができるようになる仕組みである。具体的には、 LSM フック可能な場所に BPF プログラムをアタッチして、通信をブロックしたりすることが可能である。 さらに、この KRSI の開発過程で、セキュリティな人達以外に対しても KRSI の仕組みを汎用的に提供するために、 fmod_ret が導入された。 fmod_ret のフック対象は LSM フック箇所に限らず、エラーインジェクションが可能な関数にも広がっている。 今回は libbpf を用いて、その自由度の高さを体験していこうと思う。 なお、あまりにも神にも悪魔にもなれる機能なので、本投稿の疑似コードはそのままでは使えないよう抜粋した形で掲載する。 LSM フック わかりやすさのため、ありがちな例として指定プログラムのシグナル送信を制限してみる。具体的には、引数で指定されたプログラムが SIGKILL を発行していた場合に EPERM を返すサンプルを実装する。 ちなみに、CONFIG_LSM に bpf が入っていないと思うので、その場合は GRUB の設定ファイルを調整してほしい。 BPF 側の疑似コードとしては下記のようなイメージになる。 SEC("lsm/task_kill") int BPF_PROG(masked_signal, struct task_struct *p, struct kernel_siginfo *info, int sig, const struct cred *cred) { u64 pid_tgid = bpf_get_current_pid_tgid(); u32 tgid = pid_tgid >> 32; struct event *e; if (!is_targetted_comm()) { return 0; // Not targeted program } else { if (info->si_signo == SIGKILL) { e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0); if (e) { e->pid = tgid; e->killed_pid = p->pid; bpf_ringbuf_submit(e, 0); } } return -EPERM; } return 0; } それでは、シグナル制限のサンプルを起動して、別のプロンプトから sleep しているプロセスを kill してみよう。 $ ps aux | grep sleep | grep -v grep | awk '{ print "kill -9", $2 }' | bash bash: 1 行: kill: (4405) - 許可されていない操作です 実際に sleep プロセスを kill 出来なかったことがわかる。 上記の疑似コードを呼び出す側で、リングバッファの内容を表示するように実装しているので確認してみると、下記のように SIGKILL が送られた記録が残っていた。 Started SIGKILL: sent from 4911 to 4405 上記の結果から、 KRSI の導入によって eBPF を活用してプログラマブルにセキュリティ機能を実装できることがわかった。 fmod_ret 前述した通り、 fmod_ret のフック先は LSM フックに限定されてない。 そこで今回は write システムコールをフックして、あたかも書き込みに成功したかのように振る舞うサンプルを書いてみよう。 なお、fmod_ret に関しては CONFIG_LSM の設定は不要である。 BPF の疑似コードとしては下記のようなイメージになる。 int BPF_PROG(fake_write, struct pt_regs *regs) { struct event *e; if (!is_targetted_comm()) { return 0; } else { int fd = PT_REGS_PARM1(regs); size_t count = PT_REGS_PARM3(regs); if (fd > 2) { e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0); if (e) { e->fd = fd; e->count = count; bpf_ringbuf_submit(e, 0); } } return count; } } ユーザ空間から指定された読み取りサイズをそのまま戻り値として返すが、実際にはデータをファイルに書き込まないようにしている。 すなわち、本実装を応用すれば、アプリケーションには気づかれないまま任意の BPF コードを実行した後にアプリケーション側の処理を継続させることも出来てしまう。 次に、単純にファイルに書き込みをするサンプルコードを下記のように準備する。 #include <stdio.h> #include <stdlib.h> int main() { FILE *fp; fp = fopen("aiueo.log", "w"); if (fp == NULL) return EXIT_FAILURE; fprintf(fp, "%s\n", "aiueo"); fclose(fp); return EXIT_SUCCESS; } 上記のサンプル(test_write)を実行すると、通常は aiueo.log というファイルに aiueo が書き込まれる。 一方、 BPF のサンプルを起動後に、test_write を実行すると空の aiueo.log が作成されていることがわかる。 $ ./test_write $ cat aiueo.log 今回もリングバッファの内容を表示するように実装しているので確認してみると、戻り値としての 6 byte が記録されていることがわかる。 Started fd: 3, unwritten_count: 6 つまり、 test_write は 6 byte のデータが書き込まれたと信じたまま処理を正常終了させたことになる。 おわりに KRSI によって、容易にプログラマブルで軽量なセキュリティ基盤を構築する仕組みが提供された。 また、 fmod_ret はセキュリティだけでなくトレーシング等にも活用できそうだが、自由すぎることによる危険性の高さも合わせて実感することが出来た。 参考情報 BPF LSM (Updates + Progress) kernel.org

はじめに IBM CloudでOpenShiftクラスターを構築し、Windows10のWSL2のUbuntu環境にocコマンドおよびpodmanコマンドを導入して、CLIでOpenShiftにコンテナをデプロイできる環境を作りました。 IBM Cloudのアカウント後の手順になります。 https://cloud.ibm.com/registration IBM CloudにてOpenShiftクラスターを構築する手順 メニューから[OpenShift] - [クラスター]を選択する [OpenShiftクラスターの作成]をクリックする [手動セットアップ]を選択する OpenShiftのバージョンを選択する [このワーカー・プールの追加ライセンスを購入する]を選択する [クラッシック]を選択する [アジア太平洋][複数ゾーン][東京]を選択する ゾーンあたりのワーカー・ノードを１に選択する [作成]をクリックする (※この作成後、利用料金が発生しますのでご注意ください。） 以下のダイアログが表示される OpenShiftクラスターが作成される Windows10のWSL2のUbuntu環境にocコマンドとpodmanコマンドを導入する手順 ocコマンドの導入手順 以下のサイトからtar.gzファイルをダウンロードし、/usr/local/binディレクトリ配下に展開する https://console.redhat.com/openshift/downloads ※RedHatアカウントへのログインが必要です podmanコマンドの導入手順 以下のサイトから[Windows Subsystem for Linux (WSL) 2.0]の内容をもとに進める https://podman.io/getting-started/installation 以下のサイトの情報をもとに進める https://www.redhat.com/sysadmin/podman-windows-wsl2 $ . /etc/os-release $ sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" $ wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O Release.key $ sudo apt-key add - < Release.key $ sudo apt-get update -qq $ sudo apt-get -qq -y install podman $ sudo mkdir -p /etc/containers $ echo -e "[registries.search]\nregistries = ['docker.io', 'quay.io']" | sudo tee /etc/containers/registries.conf OpenShiftにコンテナをデプロイ 以上でIBM CloudでOpenShiftクラスターを構築し、Windows10のWSL2のUbuntu環境にocコマンドおよびpodmanコマンドを導入して、CLIでOpenShiftにコンテナをデプロイできる環境ができあがりました。 コンテナをデプロイする方法は後日別の記事を投稿予定です。 参考情報 Windows10のWSL2のUbuntu環境の構築方法は以下の記事を参考にしてください Windows10でWSL2をセットアップしてLinuxコマンドの勉強環境を作る方法

はじめに Windows版のPythonにはPythonランチャー(py.exe)というものが同梱されていて、思考停止で複数のバージョンをインストールしても簡単にバージョンを切り替えて実行することができます。 同じようなことをUnix環境でも出来ないかと情報を探していた所、以下のツールを見つけました。 導入 色々な方法がありますが、RustのパッケージマネージャーであるCargoを使った方法が一番楽そうです。Rust(Cargo)が導入されていれば以下のコマンドでインストールすることができます。 $ cargo install python-launcher 使う WindowsのPythonランチャーと同様に使用することができます。