オープンかつ無料で使えるプロセッサの命令セットである「RISC-V」（リスクファイブ）のソフトウェアエコシステム発展を推進する団体「RISE」（RISC-V Software Ecosystem）が、オープンソースプロジェクト向けにRISC-VプロセッサによるGitHub Actionsランナーを無料提供すると発表しました。
RISC-VプロセッサによるGitHub Actionsランナーを無料提供、オープンソースプロジェクトに。RISC-V普及促進団体「RISE」が発表 － Publickey
RISC-Vはカリフォルニア大学バークレイ校のコンピュータサイエンス科で、新しいプロセッサ命令セットを開発するためのプロジェクトとして始まりました。
RISC-VプロセッサによるGitHub Actionsランナーを無料提供、オープンソースプロジェクトに。RISC-V普及促進団体「RISE」が発表 － Publickey
現在ではRISC-V Internationalの下でオープンかつ無料で使えるプロセッサの命令セットとしてライセンスされています。
RISC-VプロセッサによるGitHub Actionsランナーを無料提供、オープンソースプロジェクトに。RISC-V普及促進団体「RISE」が発表 － Publickey
今回発表されたRISE RISC-Vランナーは、GitHub上のオープンソースプロジェクトを対象に、GitHub上でソフトウェアのビルド、テストなどを実行できるGitHub Actionsランナーを無償で提供するというものです。
RISC-VプロセッサによるGitHub Actionsランナーを無料提供、オープンソースプロジェクトに。RISC-V普及促進団体「RISE」が発表 － Publickey
RISE RISC-Vランナーは、実際には欧州に位置するクラウドプロバイダーであるScalewayが提供するベアメタルのRISC-Vサーバ上でLinux OSのUbuntuを用いて実行されるようになっています。
RISC-VプロセッサによるGitHub Actionsランナーを無料提供、オープンソースプロジェクトに。RISC-V普及促進団体「RISE」が発表 － Publickey
導入方法などはRISEが公開しているドキュメント「RISE RISC-V Runners」を参照してください。
RISC-VプロセッサによるGitHub Actionsランナーを無料提供、オープンソースプロジェクトに。RISC-V普及促進団体「RISE」が発表 － Publickey
⇧ で、「RISE RISC-V Runners」のリンクのページを確認すると、
⇧ とあるのだが、
⇧ 上記サイト様にありますように、「脆弱性」に対する対応が考慮されていない...
「GitHub」の公開している公式の「ブログ」の「情報」によると、
⇧ 上記で「Enforce SHA pinning」という「機能」がリリースされたらしく、
If you need more reliable versioning, you should use the SHA value associated with the version of the action. SHAs are immutable and therefore more reliable than tags or branches. However, this approach means you will not automatically receive updates for an action, including important bug fixes and security updates. You must use a commit's full SHA value, and not an abbreviated value. When selecting a SHA, you should verify it is from the action's repository and not a repository fork.
⇧ 上記のように、「action」の「バージョン」に対応する「SHA」の「値」を利用することを推奨とあるのだが、肝心の「SHA」の「値」の確認方法の記載が無い...
「stackoverflow」の「情報」によると、
⇧ 最初に、通常の「バージョン」の「タグ」で「GitHub Actions」の「ワークフロー」を実行して、「実行ログ」から確認する感じになるっぽい。
何と言うか、「脆弱性」の「情報」を共有されても「対応方法」について明確に共有されないのであれば、「脆弱性対応」が適切に完遂されない可能性があるからして、「リスク」は解消できないのであって、意味は無いと思うのよね...
ちなみに、
⇧ 上記サイト様にありますように、「自動化」が構築されているような環境において、「SHA」の値の更新に追従していくのは厳しそうではありそう...
Linuxのシンボリックリンク（symbolic link）はGitで管理されてしまうので気を付けよう
「スクリプト」は便利であることは間違いないのであるが、「利用者」が気にせずに済むように「隠蔽」されていないと、危険が伴うこと、あるあるですと。
正しい用法を把握していなくても、
フールプルーフ (英: fool proof) とは、安全工学における用語のひとつで、工業製品やシステムを設計する際、誤操作や誤設定などの間違った使い方をしても、少なくとも使用者や周囲にとって危険な動作をしないように、あるいはそもそも間違った使い方ができないように配慮する設計手法のこと。
英語では「壊したり間違えたりすることなく、誰でも簡単に使える」という意味を持つ、idiot-proofという言葉が使われることもある。またフールプルーフと同じ概念として、日本語のポカヨケを直訳したpoka-yokeが用いられることもある。
フールプルーフが目指す「誤用されない設計」とは、本質的に防御的な設計 (英: defensive design) となる。これは、「人間は往々にして間違いを犯すものである」という前提に立った考え方に基づいている。
特に生産現場では、ちょっとしたミスが人命にかかわる致命的な事故につながる可能性があることから、労働災害を防止するために、安全衛生の観点からも機器や環境のフールプルーフ化を推進することが望ましい。
⇧ 上記のような体制になっている場合は、
- 作業者の精神的負担の軽減
- 障害の発生リスクの抑制
といった感じで、「トライアンドエラー」をし易い雰囲気になるのだが、残念ながら、諸々の「メンテナンス」が追い付かず、往々にして「カオス」な「状況」になっているのが「現場」ですと...
話が脱線しましたが、表題の件。
ネットの情報を漁っていたところ、
rbenv で気づいた衝撃の事実・・・git はシンボリックリンクをコミット出来る。
⇧ 上記サイト様にありますように、「Git」は「Linux」環境の「シンボリックリンク（symbolic link）」を管理できてしまうのである...
そして、
⇧「Windows」環境での「Git」操作では、「情報」が欠落してしまうのである...
ちなみに、「Windows」環境の「Git」操作だと、「ファイル」の「権限」などの「情報」についても問題を起こすので、
⇧ 上記サイト様にありますように、「Windows」環境では「Git」の「設定」を追加しておく必要がありますと。
ちなみに、「カレントディレクトリ」配下に対して「シンボリックリンク（symbolic link）」が存在するかは、
find ./* -type l -ls
find . -type l -exec sh -c 'echo "$1 -> `readlink -f "$1"`"' _ {} \;
⇧ 上記で確認できる模様。
そして、
⇧ 上記サイト様にありますように、「シンボリックリンク（symbolic link）」が絡むと「削除」がややこしい感じになる模様。
「ChatGPT」氏に質問してみたところ、以下のようなパターンがあり得るとの回答が返ってきた。
📌 シンボリックリンク（symbolic link）が絡んできた場合の削除のパターン
| No | 処理前 | 処理 | 処理後 | コメント | |||||
|---|---|---|---|---|---|---|---|---|---|
| 実体 | リソースタイプ | シンボリックリンク | 実体への処理コマンド | シンボリックリンクへの処理コマンド | 実体 | リソースタイプ | シンボリックリンク | ||
| 1 | 存在 | ファイル | 正常リンク | rm target.txt | rm link.txt | 削除済み | ファイル | 削除済み | 正常削除 |
| 2 | 存在 | ファイル | 正常リンク | rm target.txt/（NG） | rm link.txt/（NG） | 存在 | ファイル | 存在 | エラーで何も削除されない |
| 3 | 存在 | ファイル | 壊れたリンク | rm target.txt | rm link.txt | 削除済み | ファイル | 削除済み | 正常削除 |
| 4 | 存在 | ファイル | 壊れたリンク | rm target.txt/（NG） | rm link.txt/（NG） | 存在 | ファイル | 存在 | エラーで何も削除されない |
| 5 | 存在 | ファイル | 削除済み | rm target.txt | なし | 削除済み | ファイル | 削除済み | 正常削除 |
| 6 | 存在 | ファイル | 削除済み | rm target.txt/（NG） | なし | 存在 | ファイル | 削除済み | エラーで実体は残る |
| 7 | 存在 | ディレクトリ | 正常リンク | rm -r target_dir | rm link_dir | 削除済み | ディレクトリ | 削除済み | 正常削除 |
| 8 | 存在 | ディレクトリ | 正常リンク | rm -r target_dir/ | rm link_dir/（危険） | 削除済み | ディレクトリ | 削除済み | リンク先実体が削除される可能性あり |
| 9 | 存在 | ディレクトリ | 壊れたリンク | rm -r target_dir | rm link_dir | 削除済み | ディレクトリ | 削除済み | 正常削除 |
| 10 | 存在 | ディレクトリ | 壊れたリンク | rm -r target_dir/ | rm link_dir/（危険） | 削除済み | ディレクトリ | 削除済み | 実体削除の可能性あり |
| 11 | 存在 | ディレクトリ | 削除済み | rm -r target_dir | なし | 削除済み | ディレクトリ | 削除済み | 正常削除 |
| 12 | 存在 | ディレクトリ | 削除済み | rm -r target_dir/ | なし | 削除済み | ディレクトリ | 削除済み | 正常削除 |
| 13 | 削除済み | ファイル | 正常リンク | なし | rm link.txt | 削除済み | ファイル | 削除済み | リンクのみ削除 |
| 14 | 削除済み | ファイル | 正常リンク | なし | rm link.txt/（NG） | 削除済み | ファイル | 存在 | エラーでリンク残る |
| 15 | 削除済み | ファイル | 壊れたリンク | なし | rm link.txt | 削除済み | ファイル | 削除済み | 正常削除 |
| 16 | 削除済み | ファイル | 壊れたリンク | なし | find -type l ! -exec test -e {} \; -delete | 削除済み | ファイル | 削除済み | 安全削除 |
| 17 | 削除済み | ファイル | 削除済み | なし | なし | 削除済み | ファイル | 削除済み | 操作不要 |
| 18 | 削除済み | ディレクトリ | 正常リンク | なし | rm link_dir | 削除済み | ディレクトリ | 削除済み | リンクのみ削除 |
| 19 | 削除済み | ディレクトリ | 正常リンク | なし | rm link_dir/（NG） | 削除済み | ディレクトリ | 存在 | エラーでリンク残る |
| 20 | 削除済み | ディレクトリ | 壊れたリンク | なし | rm link_dir | 削除済み | ディレクトリ | 削除済み | 正常削除 |
| 21 | 削除済み | ディレクトリ | 壊れたリンク | なし | find -type l ! -exec test -e {} \; -delete | 削除済み | ディレクトリ | 削除済み | 安全削除 |
| 22 | 削除済み | ディレクトリ | 削除済み | なし | なし | 削除済み | ディレクトリ | 削除済み | 操作不要 |
| 23 | 削除済み | ファイル/ディレクトリ | 削除済み | なし | なし | 削除済み | ファイル/ディレクトリ | 削除済み | 操作不要 |
| 24 | 削除済み | ファイル/ディレクトリ | 削除済み | なし | なし | 削除済み | ファイル/ディレクトリ | 削除済み | 操作不要 |
✅ 1. 基本原則
- シンボリックリンクは「ポインタ」 であり、リンク先が削除されてもリンク自体は独立して存在できます。
- 逆に 実体を先に削除すると、リンクは壊れたリンクになる だけで削除自体には問題ありません。
つまり、削除の順番による コマンドエラーは基本的に発生しません。
✅ 2. 削除の順番による違い
| 削除順 | 結果 | 注意点 |
|---|---|---|
| 実体 → リンク | リンクは壊れた状態で残る → その後 rm link で安全に削除可能 |
特に危険なし |
| リンク → 実体 | リンク削除後、実体を削除 → 正常に削除可能 | 特に危険なし |
💡 結論：削除の順番は基本的に気にしなくて大丈夫
✅ 3. 例外ケース
-
rm -r link_dir/のように末尾スラッシュ付きでディレクトリリンクを削除する場合-
リンク先の実体まで削除される危険がある
-
この場合は 順番が重要になることがある
-
安全に削除するなら リンクは
/なしで先に削除する
-
-
自動化スクリプトで
find -type l -deleteを使う場合-
壊れたリンクも含めて安全に削除可能
-
この場合も順番を気にする必要なし
-
要するに、「末尾スラッシュ付きのディレクトリリンク」だけ注意すれば、基本的には順番を気にせず削除できる ということです。
う～む...、「動作確認」できていないので、「幻覚（ハルシネーション）」を引き起こしているか確認できないのだが、「シンボリックリンク（symbolic link）」が絡むといろいろ考えることが増えて複雑になりそうね...
可能な限り、「イミュータブル（Immutable）」で「状態」を持たないようにしたいので、「スクリプト」の実行の際に利用される一時的な「データ」は「スクリプト」の処理の最後には、削除されるようにしておきたいですな...
とりあえず、「シンボリックリンク（symbolic link）」の作成が絡むような「スクリプト」の場合は、「スクリプト」の処理の終わりに、
- シンボリックリンク（symbolic link）のみ削除する
- シンボリックリンク（symbolic link）と実体の両方を削除する
- 削除しない
いずれの方針とするかは、決めておきたいところですかね...
実体についても、
- ディレクトリ
- ファイル
のいずれが対象となるのかもハッキリさせておきたいところですかね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
