Gitの認証情報を奪い取れるGit 2.26.0以下にある脆弱性についてYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
【セキュリティ ニュース】Gitに深刻な脆弱性、認証情報など取得されるおそれ（1ページ目 / 全1ページ）：Security NEXT
分散型バージョン管理システム「Git」に深刻な脆弱性が含まれていることがわかった。アップデートがリリースされている。 同システムの「credential helper」において改行を含む細工したURLを用いることで、Gitクライアントより認証情報を任意のホストに送信させることが可能となる脆弱性「CVE-2020-5260」が明らかとなったもの。 米国立標準技術研究所（NIST）の脆弱性データベース「NVD」による共通脆弱性評価システム「CVSSv3.1」のベーススコアは「9.3」で「クリティカル（Critical）」とレーティングされている。 脆弱性の判明を受けて、開発チームでは脆弱性へ対処した「同2.26.1」「同2.25.3」「同2.24.2」「同2.23.2」「同2.22.3」「同2.21.2」「同2.20.3」「同2.19.4」「同2.18.3」「同2.17.4」をリリース。また脆
git push `--force-with-lease`はいつも安全？ - Qiita
git push --force-with-leaseはgit push --forceと違って、他の人がpushしていたら良い感じにコケてくれるので安全、という話を聞き、さっそく使っています。 git push --force でなく git push --force-with-lease を使う - valid,invalid --force considered harmful; understanding git's --force-with-lease - Atlassian Developers ただ、ちょっとだけ注意しないとな、と思ったところがあるので書き残しておきます。 前提 git 2.6.4で確認 最後にfetchしたタイミングでの一致を保証する man git-pushを見るとこんな記述があります。 --force-with-lease alone, without
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
First commit が git rebase -i できない問題 → git rebase -i --root でできる - 納豆には卵を入れる派です。
git init してから一番最初のcommit内容を、2番目のcommitと一緒にまとめたい、と後で思った。 よーし、git rebase -i HEAD~~からのfixupで… $ git rebase -i HEAD~~ fatal: Needed a single revision invalid upstream head~~えっ・・・(ΦωΦ) 一番最初のcommitはgit rebase -i HEADほにゃららでは遡れないのか・・・一番最初のcommitはgit rebase -i できないのか・・・？— TAE ✅ (@ken_c_lo) April 21, 2013 @ken_c_lo それ方法あったら知りたいですねー。調べた限りでは無さそうなのもあって、自分でリポジトリ作る時はgit flow initを使って最初に空のInitial commitを作るようにしてます
Git Submodule Vulnerability Announced | The GitHub Blog
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Git - Git オブジェクトの置き換え
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
Gitのfetch/pullサブコマンドで--pruneオプションをデフォルトにする
Gitではbranch -aでリモート・リポジトリーも一覧できる。この一覧には既にリモートでは消されたリモート・リポジトリーも表示される。この一覧を更新するにはfetch --pruneを使うわけだが、いちいちそうするのは面倒くさい。どうやらfetch.pruneをtrueにするとデフォルトで--pruneを付けてfetch(及びpull)を実行してくれるようだ。 $ git config --global fetch.prune true $ git fetch From https://github.com/hail2u/example x [deleted] (none) -> origin/deleted-branch グローバルに設定して良い場合はこれで常に--prune付きでfetchとpullが実行されるようになる。この設定はプロジェクト・ローカルで特定のリモートに対してのみ
初めてGitHubリポジトリにpushしたらrejectedエラーになったときの対応メモ - Qiita
% git push origin master To https://github.com/xxxx/xxxxx.git ! [rejected] master -> master (fetch first) error: failed to push some refs to 'https://github.com/xxxx/xxxxx.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes
Emacsで現在見ている行を変更したPRを開けるようにした - $shibayu36->blog;
このコードどうしてこうなってるのかという経緯を知りたい時、git blameなどのコマンドを利用することが多い。しかし、git blameだとその行を変更したcommitが分かるだけであり、経緯が結局分からないということがよくある。 そういう時にその行を変更したPRを開けるようにしたいなーと思って、いろいろやったところ、Emacsで現在見ている行を変更したPRを開けるようになったのでメモ。 特定のコミットが含まれるPull Requestを開くには 前段階として、特定のコミットが含まれるPull Requestを開くということをやってみる。これは既にいろいろやっている人がいて Commit Hash から、該当 Pull Request を見つける方法 - Qiita How to find pull-request by a commit sha - Pitr.ch Gitベースのコード
gitでマージコミットが含まれるブランチをrebaseする - 作業ノート
確認したのは以下のバージョン。 $ git --version git version 1.7.12.4 例えば以下のように、マージコミットを含むブランチのコメントを編集したいとき。 $ git log --graph --pretty=format:'%h -%d %s' --abbrev-commit --date=relative * cd00264 - (HEAD, master) Merge branch 'branch-b' |\ | * 8f7b4c7 - add b.txt |/ * 521e66f - Merge branch 'branch-a' |\ | * f5622e4 - add a.txt |/ * 0d8bbff - new この状態でrebaseを行うときに $ git rebase -i HEAD~~ -iオプションだけでは pick f5622e4 a
まだ git push origin するときに current branch 名を入力して消耗しているの? - Qiita
毎回 BRANCH_NAME を指定する作業をしていると、日に何回も push する時は、とても多くの時間がかかってしまうことがあるかもしれません。 あと、タイトルは単に消耗しているの?って言いたかっただけです。 git push origin HEAD 下記を実行することで、カレントブランチ (git st で確認)の内容を origin に対して push できます。 詳しく git document によると1 git push origin HEAD A handy way to push the current branch to the same name on the remote カレントブランチを同じ名前でリモートに対して push する便利な方法です。 とあります。 同様の stackoverflow 2によると If you want to push a differ
git blameでプルリクエストの番号を表示する
GitHubでプルリクエスト前提の開発をしていると、git blameで「なぜ、このコードがこうなっているのか」調べる際に、commit idではなくプルリクエストの番号を表示してほしくなります。 というわけで書いたのが git-blame-pr.pl。 以下のような感じで表示されるので、調査がはかどります。 $ git-blame-pr.pl lib/core/request.c (中略) PR #446 PR #606 h2o_iovec_t h2o_get_redirect_method(h2o_iovec_t method, int status) PR #606 { PR #606 if (h2o_memis(method.base, method.len, H2O_STRLIT("POST")) && !(status == 307 || status == 308)) PR
GitHub - hotwatermorning/auto-git-diff: A vim plugin which shows git diff for Git Rebase Interactive
git rebase -iの時に役立つプラグイン - Qiita
はじめに 以前、と言っても結構前ですが、タイトルにあるようなgit rebase -iの時に役に立つVimプラグインというのを作ったので、それを紹介したいと思います。 動機 僕の所属している開発チームでは、バージョン管理システムにgitを使用しています。 gitは広く知られている通り、分散バージョン管理システムと呼ばれているものの一つです。その特徴と言っていいのかわからないですが、gitを利用すると、手元でのソースコードの変更を、細かい単位でローカルのリポジトリにどんどんコミットしておき、それを適当なタイミングでコミット履歴を改変して内容を整理してから、チームで共有しているリポジトリに状態を同期させるようなことができます。 git rebaseとは、そのようにコミット履歴を改変するときに使用するコマンドです。 git rebaseコマンド、特に-iというオプションを付けたものは、コミットの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Git」に複数の脆弱性、Windowsユーザーはとくに注意／修正版のv2.24.1などへ更新を
GitHub - jesseduffield/lazygit: simple terminal UI for git commands
「Git」に複数の脆弱性、修正版が公開 ～Microsoftは「Git for Windows」の更新を推奨／細工のあるレポジトリをサブモジュール込みでクローンすると任意のコードが実行される
git submoduleを今風な感じで削除する - Qiita
githubではdiffを見たくないけど手元では見たい - しるてく
