/git-releasePublic

Security: gsnw/git-release

Security

SECURITY.md

Security Policy

Reporting a vulnerability

Please send a detailed mail to git-security@googlegroups.com to report vulnerabilities in Git.

Even when unsure whether the bug in question is an exploitable vulnerability, it is recommended to send the report to git-security@googlegroups.com (and obviously not to discuss the issue anywhere else).

Vulnerabilities are expected to be discussed only on that list, and not in public, until the official announcement on the Git mailing list on the release date.

Examples for details to include:

  • Ideally a short description (or a script) to demonstrate an exploit.
  • The affected platforms and scenarios (the vulnerability might only affect setups with case-sensitive file systems, for example).
  • The name and affiliation of the security researchers who are involved in the discovery, if any.
  • Whether the vulnerability has already been disclosed.
  • How long an embargo would be required to be safe.

Supported Versions

There are no official "Long Term Support" versions in Git. Instead, the maintenance track (i.e. the versions based on the most recently published feature release, also known as ".0" version) sees occasional updates with bug fixes.

Fixes to vulnerabilities are made for the maintenance track for the latest feature release and merged up to the in-development branches. The Git project makes no formal guarantee for any older maintenance tracks to receive updates. In practice, though, critical vulnerability fixes are applied not only to the most recent track, but to at least a couple more maintenance tracks.

This is typically done by making the fix on the oldest and still relevant maintenance track, and merging it upwards to newer and newer maintenance tracks.

For example, v2.24.1 was released to address a couple of CVEs, and at the same time v2.14.6, v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1, v2.22.2 and v2.23.1 were released.

There aren't any published security advisories

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
/git-releasePublic
Security: gsnw/git-release
Security

SECURITY.md

Security Policy
Reporting a vulnerability
Please send a detailed mail to git-security@googlegroups.com to
report vulnerabilities in Git.
Even when unsure whether the bug in question is an exploitable
vulnerability, it is recommended to send the report to
git-security@googlegroups.com (and obviously not to discuss the
issue anywhere else).
Vulnerabilities are expected to be discussed only on that
list, and not in public, until the official announcement on the
Git mailing list on the release date.
Examples for details to include:
  • Ideally a short description (or a script) to demonstrate an
exploit.
  • The affected platforms and scenarios (the vulnerability might
only affect setups with case-sensitive file systems, for
example).
  • The name and affiliation of the security researchers who are
involved in the discovery, if any.
  • Whether the vulnerability has already been disclosed.
  • How long an embargo would be required to be safe.
Supported Versions
There are no official "Long Term Support" versions in Git.
Instead, the maintenance track (i.e. the versions based on the
most recently published feature release, also known as ".0"
version) sees occasional updates with bug fixes.
Fixes to vulnerabilities are made for the maintenance track for
the latest feature release and merged up to the in-development
branches. The Git project makes no formal guarantee for any
older maintenance tracks to receive updates. In practice,
though, critical vulnerability fixes are applied not only to the
most recent track, but to at least a couple more maintenance
tracks.
This is typically done by making the fix on the oldest and still
relevant maintenance track, and merging it upwards to newer and
newer maintenance tracks.
For example, v2.24.1 was released to address a couple of
CVEs, and at the same time v2.14.6,
v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,
v2.22.2 and v2.23.1 were released.
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
/git-releasePublic
Security: gsnw/git-release
Security

SECURITY.md

Security Policy
Reporting a vulnerability
Please send a detailed mail to git-security@googlegroups.com to
report vulnerabilities in Git.
Even when unsure whether the bug in question is an exploitable
vulnerability, it is recommended to send the report to
git-security@googlegroups.com (and obviously not to discuss the
issue anywhere else).
Vulnerabilities are expected to be discussed only on that
list, and not in public, until the official announcement on the
Git mailing list on the release date.
Examples for details to include:
  • Ideally a short description (or a script) to demonstrate an
exploit.
  • The affected platforms and scenarios (the vulnerability might
only affect setups with case-sensitive file systems, for
example).
  • The name and affiliation of the security researchers who are
involved in the discovery, if any.
  • Whether the vulnerability has already been disclosed.
  • How long an embargo would be required to be safe.
Supported Versions
There are no official "Long Term Support" versions in Git.
Instead, the maintenance track (i.e. the versions based on the
most recently published feature release, also known as ".0"
version) sees occasional updates with bug fixes.
Fixes to vulnerabilities are made for the maintenance track for
the latest feature release and merged up to the in-development
branches. The Git project makes no formal guarantee for any
older maintenance tracks to receive updates. In practice,
though, critical vulnerability fixes are applied not only to the
most recent track, but to at least a couple more maintenance
tracks.
This is typically done by making the fix on the oldest and still
relevant maintenance track, and merging it upwards to newer and
newer maintenance tracks.
For example, v2.24.1 was released to address a couple of
CVEs, and at the same time v2.14.6,
v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,
v2.22.2 and v2.23.1 were released.
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
/git-releasePublic
Security: gsnw/git-release
Security

SECURITY.md

Security Policy
Reporting a vulnerability
Please send a detailed mail to git-security@googlegroups.com to
report vulnerabilities in Git.
Even when unsure whether the bug in question is an exploitable
vulnerability, it is recommended to send the report to
git-security@googlegroups.com (and obviously not to discuss the
issue anywhere else).
Vulnerabilities are expected to be discussed only on that
list, and not in public, until the official announcement on the
Git mailing list on the release date.
Examples for details to include:
  • Ideally a short description (or a script) to demonstrate an
exploit.
  • The affected platforms and scenarios (the vulnerability might
only affect setups with case-sensitive file systems, for
example).
  • The name and affiliation of the security researchers who are
involved in the discovery, if any.
  • Whether the vulnerability has already been disclosed.
  • How long an embargo would be required to be safe.
Supported Versions
There are no official "Long Term Support" versions in Git.
Instead, the maintenance track (i.e. the versions based on the
most recently published feature release, also known as ".0"
version) sees occasional updates with bug fixes.
Fixes to vulnerabilities are made for the maintenance track for
the latest feature release and merged up to the in-development
branches. The Git project makes no formal guarantee for any
older maintenance tracks to receive updates. In practice,
though, critical vulnerability fixes are applied not only to the
most recent track, but to at least a couple more maintenance
tracks.
This is typically done by making the fix on the oldest and still
relevant maintenance track, and merging it upwards to newer and
newer maintenance tracks.
For example, v2.24.1 was released to address a couple of
CVEs, and at the same time v2.14.6,
v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,
v2.22.2 and v2.23.1 were released.
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
/git-releasePublic
Security: gsnw/git-release
Security

SECURITY.md

Security Policy
Reporting a vulnerability
Please send a detailed mail to git-security@googlegroups.com to
report vulnerabilities in Git.
Even when unsure whether the bug in question is an exploitable
vulnerability, it is recommended to send the report to
git-security@googlegroups.com (and obviously not to discuss the
issue anywhere else).
Vulnerabilities are expected to be discussed only on that
list, and not in public, until the official announcement on the
Git mailing list on the release date.
Examples for details to include:
  • Ideally a short description (or a script) to demonstrate an
exploit.
  • The affected platforms and scenarios (the vulnerability might
only affect setups with case-sensitive file systems, for
example).
  • The name and affiliation of the security researchers who are
involved in the discovery, if any.
  • Whether the vulnerability has already been disclosed.
  • How long an embargo would be required to be safe.
Supported Versions
There are no official "Long Term Support" versions in Git.
Instead, the maintenance track (i.e. the versions based on the
most recently published feature release, also known as ".0"
version) sees occasional updates with bug fixes.
Fixes to vulnerabilities are made for the maintenance track for
the latest feature release and merged up to the in-development
branches. The Git project makes no formal guarantee for any
older maintenance tracks to receive updates. In practice,
though, critical vulnerability fixes are applied not only to the
most recent track, but to at least a couple more maintenance
tracks.
This is typically done by making the fix on the oldest and still
relevant maintenance track, and merging it upwards to newer and
newer maintenance tracks.
For example, v2.24.1 was released to address a couple of
CVEs, and at the same time v2.14.6,
v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,
v2.22.2 and v2.23.1 were released.
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
/git-releasePublic
Security: gsnw/git-release
Security

SECURITY.md

Security Policy
Reporting a vulnerability
Please send a detailed mail to git-security@googlegroups.com to
report vulnerabilities in Git.
Even when unsure whether the bug in question is an exploitable
vulnerability, it is recommended to send the report to
git-security@googlegroups.com (and obviously not to discuss the
issue anywhere else).
Vulnerabilities are expected to be discussed only on that
list, and not in public, until the official announcement on the
Git mailing list on the release date.
Examples for details to include:
  • Ideally a short description (or a script) to demonstrate an
exploit.
  • The affected platforms and scenarios (the vulnerability might
only affect setups with case-sensitive file systems, for
example).
  • The name and affiliation of the security researchers who are
involved in the discovery, if any.
  • Whether the vulnerability has already been disclosed.
  • How long an embargo would be required to be safe.
Supported Versions
There are no official "Long Term Support" versions in Git.
Instead, the maintenance track (i.e. the versions based on the
most recently published feature release, also known as ".0"
version) sees occasional updates with bug fixes.
Fixes to vulnerabilities are made for the maintenance track for
the latest feature release and merged up to the in-development
branches. The Git project makes no formal guarantee for any
older maintenance tracks to receive updates. In practice,
though, critical vulnerability fixes are applied not only to the
most recent track, but to at least a couple more maintenance
tracks.
This is typically done by making the fix on the oldest and still
relevant maintenance track, and merging it upwards to newer and
newer maintenance tracks.
For example, v2.24.1 was released to address a couple of
CVEs, and at the same time v2.14.6,
v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,
v2.22.2 and v2.23.1 were released.
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
/git-releasePublic
Security: gsnw/git-release
Security

SECURITY.md

Security Policy
Reporting a vulnerability
Please send a detailed mail to git-security@googlegroups.com to
report vulnerabilities in Git.
Even when unsure whether the bug in question is an exploitable
vulnerability, it is recommended to send the report to
git-security@googlegroups.com (and obviously not to discuss the
issue anywhere else).
Vulnerabilities are expected to be discussed only on that
list, and not in public, until the official announcement on the
Git mailing list on the release date.
Examples for details to include:
  • Ideally a short description (or a script) to demonstrate an
exploit.
  • The affected platforms and scenarios (the vulnerability might
only affect setups with case-sensitive file systems, for
example).
  • The name and affiliation of the security researchers who are
involved in the discovery, if any.
  • Whether the vulnerability has already been disclosed.
  • How long an embargo would be required to be safe.
Supported Versions
There are no official "Long Term Support" versions in Git.
Instead, the maintenance track (i.e. the versions based on the
most recently published feature release, also known as ".0"
version) sees occasional updates with bug fixes.
Fixes to vulnerabilities are made for the maintenance track for
the latest feature release and merged up to the in-development
branches. The Git project makes no formal guarantee for any
older maintenance tracks to receive updates. In practice,
though, critical vulnerability fixes are applied not only to the
most recent track, but to at least a couple more maintenance
tracks.
This is typically done by making the fix on the oldest and still
relevant maintenance track, and merging it upwards to newer and
newer maintenance tracks.
For example, v2.24.1 was released to address a couple of
CVEs, and at the same time v2.14.6,
v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,
v2.22.2 and v2.23.1 were released.
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
/git-releasePublic
Security: gsnw/git-release
Security

SECURITY.md

Security Policy
Reporting a vulnerability
Please send a detailed mail to git-security@googlegroups.com to
report vulnerabilities in Git.
Even when unsure whether the bug in question is an exploitable
vulnerability, it is recommended to send the report to
git-security@googlegroups.com (and obviously not to discuss the
issue anywhere else).
Vulnerabilities are expected to be discussed only on that
list, and not in public, until the official announcement on the
Git mailing list on the release date.
Examples for details to include:
  • Ideally a short description (or a script) to demonstrate an
exploit.
  • The affected platforms and scenarios (the vulnerability might
only affect setups with case-sensitive file systems, for
example).
  • The name and affiliation of the security researchers who are
involved in the discovery, if any.
  • Whether the vulnerability has already been disclosed.
  • How long an embargo would be required to be safe.
Supported Versions
There are no official "Long Term Support" versions in Git.
Instead, the maintenance track (i.e. the versions based on the
most recently published feature release, also known as ".0"
version) sees occasional updates with bug fixes.
Fixes to vulnerabilities are made for the maintenance track for
the latest feature release and merged up to the in-development
branches. The Git project makes no formal guarantee for any
older maintenance tracks to receive updates. In practice,
though, critical vulnerability fixes are applied not only to the
most recent track, but to at least a couple more maintenance
tracks.
This is typically done by making the fix on the oldest and still
relevant maintenance track, and merging it upwards to newer and
newer maintenance tracks.
For example, v2.24.1 was released to address a couple of
CVEs, and at the same time v2.14.6,
v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1,
v2.22.2 and v2.23.1 were released.
 There aren't any published security advisories