Security: dQuadrant/mithril

Security

SECURITY.md

Security Vulnerability Disclosure Policy

Introduction

The Mithril open source project is committed to ensuring the security of its software and the privacy of its users. We value the contributions of the security community in helping us identify and address vulnerabilities in our code. This Security Vulnerability Disclosure Policy outlines how security vulnerabilities should be reported and how we will respond to and remediate such reports.

Security Vulnerability Handling Process

Reporting a Vulnerability

If you discover a security vulnerability in Mithril, we encourage you to responsibly disclose it to us. To report a vulnerability, please use the private reporting form on GitHub to draft a new Security advisory.

Please include as much details as needed to clearly qualify the issue:

  • A description of the vulnerability and its potential impact.
  • Steps to reproduce the vulnerability.
  • The version of mithril-node package where the vulnerability exists.
  • Any relevant proof-of-concept or exploit code (if applicable).

Processing Vulnerability

  1. Acknowledgment: The team acknowledges the receipt of your report within 3 business days by commenting on the issue reporting it or replying to email.

  2. Validation: The team investigates the issue and either reject or validate the reported vulnerability.

    a. Rejection: If the team rejects the report, detailed explanations will be provided by email or commenting on the relevant issue and the latter will be made public and closed as Won't fix.

    b. Acceptance: If the team accepts the report, a CVE identifier will be requested through GitHub and a private fork opened to work on a fix to the issue

  3. Resolution: The team works to resolve the vulnerability in a timely manner. The timeline for resolution will depend on the complexity and severity of the vulnerability, but we will strive to address critical vulnerabilities as quickly as possible.

  4. Collaboration: While working on a fix, the team maintains open and transparent communication with the reporter throughout the process, providing updates on the status of the vulnerability and any steps taken to remediate it. In particular this means that the reporter will be asked to review any proposed fix and to advise on the timing for public disclosure.

  5. Fixing Issue: The team agrees on the fix, the announcement, and the release schedule with the reporter. If the reporter is not responsive in a reasonable time frame this should not block the team from moving to the next steps particularly in the face of a high impact or high severity issue.

    a. Mitigation: Depending on the severity and criticity of the issue, the team can decide to disclose the issue publicly in the absence of a fix if and only if a clear, simple, and effective mitigation plan is defined. This must include instructions for users and operators of the software, and a time horizon at which the issue will be properly fixed (eg. version number).

    b. Fix: When a fix is available and approved, it should be merged and made available as quickly as possible:

    • All commits to the private repository are squashed into a single commit whose description should not make any reference it relates to a security vulnerability
    • A new Pull Request is created with this single commit
    • This PR's review and merging is expedited as all the work as already been done

  6. Release: The team creates and publish a release that includes the fix

  7. Announcement: Concommitant to the release annoucement, the team announces the security vulnerability by making the GitHub issue public. This is the first point that any information regarding the vulnerability is made public.

    a. Credit: The team publicly acknowledges the contributions of the reporter once the vulnerability is resolved, subject to the reporter's preferences for attribution.

  8. Disagreements: In case of disagreements with the reporter on the fix, mitigation, timing, or announcement, the team has the final say.

Responsible Disclosure

We kindly request that reporters adhere to responsible disclosure practices, which include:

  • Do not disclose the vulnerability publicly: Please refrain from posting details of the vulnerability on public forums or social media until it has been resolved.
  • Do not exploit the vulnerability: Do not attempt to exploit the vulnerability to cause harm or gain unauthorized access to systems.
  • Work with us: Allow us a reasonable amount of time to investigate and address the vulnerability before publicly disclosing any details.

Legal Protections

We will not pursue legal action against individuals who report security vulnerabilities to us.

Contact Information

To report a security vulnerability, please use GitHub form.

Revision of Policy

This Security Vulnerability Disclosure Policy may be updated or revised as necessary. Please check the latest version of this policy on the Mithril repository.

Conclusion

The Mithril project greatly appreciates the assistance of the security community in helping us maintain the security of our software while upholding the highest standards of privacy. Together, we can work to identify and address vulnerabilities, ensuring a safer and more secure experience for all users.

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
Security: dQuadrant/mithril
Security

SECURITY.md

Security Vulnerability Disclosure Policy
Introduction
The Mithril open source project is committed to ensuring the security of
its software and the privacy of its users. We value the contributions
of the security community in helping us identify and address
vulnerabilities in our code. This Security Vulnerability Disclosure
Policy outlines how security vulnerabilities should be reported and
how we will respond to and remediate such reports.
Security Vulnerability Handling Process
Reporting a Vulnerability
If you discover a security vulnerability in Mithril, we encourage you to
responsibly disclose it to us. To report a vulnerability, please use
the private reporting form on
GitHub
to draft a new Security advisory.
Please include as much details as needed to clearly qualify the issue:
  • A description of the vulnerability and its potential impact.
  • Steps to reproduce the vulnerability.
  • The version of mithril-node package where the vulnerability exists.
  • Any relevant proof-of-concept or exploit code (if applicable).
Processing Vulnerability
  1. Acknowledgment: The team acknowledges the receipt of your report
within 3 business days by commenting on the issue reporting it or replying to email.
  2. Validation: The team investigates the issue and either reject or validate the
reported vulnerability.
    a. Rejection: If the team rejects the report, detailed explanations will be provided by email or commenting on the relevant issue and the latter will be made public and closed as Won't fix.
    b. Acceptance: If the team accepts the report, a CVE identifier will be requested through GitHub and a private fork opened to work on a fix to the issue
  3. Resolution: The team works to resolve the vulnerability in a
timely manner. The timeline for resolution will depend on the
complexity and severity of the vulnerability, but we will strive to
address critical vulnerabilities as quickly as possible.
  4. Collaboration: While working on a fix, the team maintains open and transparent
communication with the reporter throughout the process, providing
updates on the status of the vulnerability and any steps taken to
remediate it. In particular this means that the reporter will be asked to review any proposed fix and to advise on the timing for public disclosure.
  5. Fixing Issue: The team agrees on the fix, the announcement, and the release schedule with the reporter. If the reporter is not responsive in a reasonable time frame this should not block the team from moving to the next steps particularly in the face of a high impact or high severity issue.
    a. Mitigation: Depending on the severity and criticity of the issue, the team can decide to disclose the issue publicly in the absence of a fix if and only if a clear, simple, and effective mitigation plan is defined. This must include instructions for users and operators of the software, and a time horizon at which the issue will be properly fixed (eg. version number).
    b. Fix: When a fix is available and approved, it should be merged and made available as quickly as possible:
    • All commits to the private repository are squashed into a single commit whose description should not make any reference it relates to a security vulnerability
    • A new Pull Request is created with this single commit
    • This PR's review and merging is expedited as all the work as already been done
  6. Release: The team creates and publish a release that includes the fix
  7. Announcement: Concommitant to the release annoucement, the team announces the security vulnerability by making the GitHub issue public. This is the first point that any information regarding the vulnerability is made public.
    a. Credit: The team publicly acknowledges the contributions of the
reporter once the vulnerability is resolved, subject to the
reporter's preferences for attribution.
  8. Disagreements: In case of disagreements with the reporter on the fix, mitigation, timing, or announcement, the team has the final say.
Responsible Disclosure
We kindly request that reporters adhere to responsible disclosure
practices, which include:
  • Do not disclose the vulnerability publicly: Please refrain from
posting details of the vulnerability on public forums or social
media until it has been resolved.
  • Do not exploit the vulnerability: Do not attempt to exploit the
vulnerability to cause harm or gain unauthorized access to systems.
  • Work with us: Allow us a reasonable amount of time to
investigate and address the vulnerability before publicly disclosing
any details.
Legal Protections
We will not pursue legal action against individuals who
report security vulnerabilities to us.
Contact Information
To report a security vulnerability, please use GitHub
form.
Revision of Policy
This Security Vulnerability Disclosure Policy may be updated or
revised as necessary. Please check the latest version of this policy
on the Mithril repository.
Conclusion
The Mithril project greatly appreciates the assistance of the security
community in helping us maintain the security of our software while
upholding the highest standards of privacy. Together, we can work to
identify and address vulnerabilities, ensuring a safer and more secure
experience for all users.
 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
Security: dQuadrant/mithril
Security

SECURITY.md

Security Vulnerability Disclosure Policy
Introduction
The Mithril open source project is committed to ensuring the security of
its software and the privacy of its users. We value the contributions
of the security community in helping us identify and address
vulnerabilities in our code. This Security Vulnerability Disclosure
Policy outlines how security vulnerabilities should be reported and
how we will respond to and remediate such reports.
Security Vulnerability Handling Process
Reporting a Vulnerability
If you discover a security vulnerability in Mithril, we encourage you to
responsibly disclose it to us. To report a vulnerability, please use
the private reporting form on
GitHub
to draft a new Security advisory.
Please include as much details as needed to clearly qualify the issue:
  • A description of the vulnerability and its potential impact.
  • Steps to reproduce the vulnerability.
  • The version of mithril-node package where the vulnerability exists.
  • Any relevant proof-of-concept or exploit code (if applicable).
Processing Vulnerability
  1. Acknowledgment: The team acknowledges the receipt of your report
within 3 business days by commenting on the issue reporting it or replying to email.
  2. Validation: The team investigates the issue and either reject or validate the
reported vulnerability.
    a. Rejection: If the team rejects the report, detailed explanations will be provided by email or commenting on the relevant issue and the latter will be made public and closed as Won't fix.
    b. Acceptance: If the team accepts the report, a CVE identifier will be requested through GitHub and a private fork opened to work on a fix to the issue
  3. Resolution: The team works to resolve the vulnerability in a
timely manner. The timeline for resolution will depend on the
complexity and severity of the vulnerability, but we will strive to
address critical vulnerabilities as quickly as possible.
  4. Collaboration: While working on a fix, the team maintains open and transparent
communication with the reporter throughout the process, providing
updates on the status of the vulnerability and any steps taken to
remediate it. In particular this means that the reporter will be asked to review any proposed fix and to advise on the timing for public disclosure.
  5. Fixing Issue: The team agrees on the fix, the announcement, and the release schedule with the reporter. If the reporter is not responsive in a reasonable time frame this should not block the team from moving to the next steps particularly in the face of a high impact or high severity issue.
    a. Mitigation: Depending on the severity and criticity of the issue, the team can decide to disclose the issue publicly in the absence of a fix if and only if a clear, simple, and effective mitigation plan is defined. This must include instructions for users and operators of the software, and a time horizon at which the issue will be properly fixed (eg. version number).
    b. Fix: When a fix is available and approved, it should be merged and made available as quickly as possible:
    • All commits to the private repository are squashed into a single commit whose description should not make any reference it relates to a security vulnerability
    • A new Pull Request is created with this single commit
    • This PR's review and merging is expedited as all the work as already been done
  6. Release: The team creates and publish a release that includes the fix
  7. Announcement: Concommitant to the release annoucement, the team announces the security vulnerability by making the GitHub issue public. This is the first point that any information regarding the vulnerability is made public.
    a. Credit: The team publicly acknowledges the contributions of the
reporter once the vulnerability is resolved, subject to the
reporter's preferences for attribution.
  8. Disagreements: In case of disagreements with the reporter on the fix, mitigation, timing, or announcement, the team has the final say.
Responsible Disclosure
We kindly request that reporters adhere to responsible disclosure
practices, which include:
  • Do not disclose the vulnerability publicly: Please refrain from
posting details of the vulnerability on public forums or social
media until it has been resolved.
  • Do not exploit the vulnerability: Do not attempt to exploit the
vulnerability to cause harm or gain unauthorized access to systems.
  • Work with us: Allow us a reasonable amount of time to
investigate and address the vulnerability before publicly disclosing
any details.
Legal Protections
We will not pursue legal action against individuals who
report security vulnerabilities to us.
Contact Information
To report a security vulnerability, please use GitHub
form.
Revision of Policy
This Security Vulnerability Disclosure Policy may be updated or
revised as necessary. Please check the latest version of this policy
on the Mithril repository.
Conclusion
The Mithril project greatly appreciates the assistance of the security
community in helping us maintain the security of our software while
upholding the highest standards of privacy. Together, we can work to
identify and address vulnerabilities, ensuring a safer and more secure
experience for all users.
 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
Security: dQuadrant/mithril
Security

SECURITY.md

Security Vulnerability Disclosure Policy
Introduction
The Mithril open source project is committed to ensuring the security of
its software and the privacy of its users. We value the contributions
of the security community in helping us identify and address
vulnerabilities in our code. This Security Vulnerability Disclosure
Policy outlines how security vulnerabilities should be reported and
how we will respond to and remediate such reports.
Security Vulnerability Handling Process
Reporting a Vulnerability
If you discover a security vulnerability in Mithril, we encourage you to
responsibly disclose it to us. To report a vulnerability, please use
the private reporting form on
GitHub
to draft a new Security advisory.
Please include as much details as needed to clearly qualify the issue:
  • A description of the vulnerability and its potential impact.
  • Steps to reproduce the vulnerability.
  • The version of mithril-node package where the vulnerability exists.
  • Any relevant proof-of-concept or exploit code (if applicable).
Processing Vulnerability
  1. Acknowledgment: The team acknowledges the receipt of your report
within 3 business days by commenting on the issue reporting it or replying to email.
  2. Validation: The team investigates the issue and either reject or validate the
reported vulnerability.
    a. Rejection: If the team rejects the report, detailed explanations will be provided by email or commenting on the relevant issue and the latter will be made public and closed as Won't fix.
    b. Acceptance: If the team accepts the report, a CVE identifier will be requested through GitHub and a private fork opened to work on a fix to the issue
  3. Resolution: The team works to resolve the vulnerability in a
timely manner. The timeline for resolution will depend on the
complexity and severity of the vulnerability, but we will strive to
address critical vulnerabilities as quickly as possible.
  4. Collaboration: While working on a fix, the team maintains open and transparent
communication with the reporter throughout the process, providing
updates on the status of the vulnerability and any steps taken to
remediate it. In particular this means that the reporter will be asked to review any proposed fix and to advise on the timing for public disclosure.
  5. Fixing Issue: The team agrees on the fix, the announcement, and the release schedule with the reporter. If the reporter is not responsive in a reasonable time frame this should not block the team from moving to the next steps particularly in the face of a high impact or high severity issue.
    a. Mitigation: Depending on the severity and criticity of the issue, the team can decide to disclose the issue publicly in the absence of a fix if and only if a clear, simple, and effective mitigation plan is defined. This must include instructions for users and operators of the software, and a time horizon at which the issue will be properly fixed (eg. version number).
    b. Fix: When a fix is available and approved, it should be merged and made available as quickly as possible:
    • All commits to the private repository are squashed into a single commit whose description should not make any reference it relates to a security vulnerability
    • A new Pull Request is created with this single commit
    • This PR's review and merging is expedited as all the work as already been done
  6. Release: The team creates and publish a release that includes the fix
  7. Announcement: Concommitant to the release annoucement, the team announces the security vulnerability by making the GitHub issue public. This is the first point that any information regarding the vulnerability is made public.
    a. Credit: The team publicly acknowledges the contributions of the
reporter once the vulnerability is resolved, subject to the
reporter's preferences for attribution.
  8. Disagreements: In case of disagreements with the reporter on the fix, mitigation, timing, or announcement, the team has the final say.
Responsible Disclosure
We kindly request that reporters adhere to responsible disclosure
practices, which include:
  • Do not disclose the vulnerability publicly: Please refrain from
posting details of the vulnerability on public forums or social
media until it has been resolved.
  • Do not exploit the vulnerability: Do not attempt to exploit the
vulnerability to cause harm or gain unauthorized access to systems.
  • Work with us: Allow us a reasonable amount of time to
investigate and address the vulnerability before publicly disclosing
any details.
Legal Protections
We will not pursue legal action against individuals who
report security vulnerabilities to us.
Contact Information
To report a security vulnerability, please use GitHub
form.
Revision of Policy
This Security Vulnerability Disclosure Policy may be updated or
revised as necessary. Please check the latest version of this policy
on the Mithril repository.
Conclusion
The Mithril project greatly appreciates the assistance of the security
community in helping us maintain the security of our software while
upholding the highest standards of privacy. Together, we can work to
identify and address vulnerabilities, ensuring a safer and more secure
experience for all users.
 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
Security: dQuadrant/mithril
Security

SECURITY.md

Security Vulnerability Disclosure Policy
Introduction
The Mithril open source project is committed to ensuring the security of
its software and the privacy of its users. We value the contributions
of the security community in helping us identify and address
vulnerabilities in our code. This Security Vulnerability Disclosure
Policy outlines how security vulnerabilities should be reported and
how we will respond to and remediate such reports.
Security Vulnerability Handling Process
Reporting a Vulnerability
If you discover a security vulnerability in Mithril, we encourage you to
responsibly disclose it to us. To report a vulnerability, please use
the private reporting form on
GitHub
to draft a new Security advisory.
Please include as much details as needed to clearly qualify the issue:
  • A description of the vulnerability and its potential impact.
  • Steps to reproduce the vulnerability.
  • The version of mithril-node package where the vulnerability exists.
  • Any relevant proof-of-concept or exploit code (if applicable).
Processing Vulnerability
  1. Acknowledgment: The team acknowledges the receipt of your report
within 3 business days by commenting on the issue reporting it or replying to email.
  2. Validation: The team investigates the issue and either reject or validate the
reported vulnerability.
    a. Rejection: If the team rejects the report, detailed explanations will be provided by email or commenting on the relevant issue and the latter will be made public and closed as Won't fix.
    b. Acceptance: If the team accepts the report, a CVE identifier will be requested through GitHub and a private fork opened to work on a fix to the issue
  3. Resolution: The team works to resolve the vulnerability in a
timely manner. The timeline for resolution will depend on the
complexity and severity of the vulnerability, but we will strive to
address critical vulnerabilities as quickly as possible.
  4. Collaboration: While working on a fix, the team maintains open and transparent
communication with the reporter throughout the process, providing
updates on the status of the vulnerability and any steps taken to
remediate it. In particular this means that the reporter will be asked to review any proposed fix and to advise on the timing for public disclosure.
  5. Fixing Issue: The team agrees on the fix, the announcement, and the release schedule with the reporter. If the reporter is not responsive in a reasonable time frame this should not block the team from moving to the next steps particularly in the face of a high impact or high severity issue.
    a. Mitigation: Depending on the severity and criticity of the issue, the team can decide to disclose the issue publicly in the absence of a fix if and only if a clear, simple, and effective mitigation plan is defined. This must include instructions for users and operators of the software, and a time horizon at which the issue will be properly fixed (eg. version number).
    b. Fix: When a fix is available and approved, it should be merged and made available as quickly as possible:
    • All commits to the private repository are squashed into a single commit whose description should not make any reference it relates to a security vulnerability
    • A new Pull Request is created with this single commit
    • This PR's review and merging is expedited as all the work as already been done
  6. Release: The team creates and publish a release that includes the fix
  7. Announcement: Concommitant to the release annoucement, the team announces the security vulnerability by making the GitHub issue public. This is the first point that any information regarding the vulnerability is made public.
    a. Credit: The team publicly acknowledges the contributions of the
reporter once the vulnerability is resolved, subject to the
reporter's preferences for attribution.
  8. Disagreements: In case of disagreements with the reporter on the fix, mitigation, timing, or announcement, the team has the final say.
Responsible Disclosure
We kindly request that reporters adhere to responsible disclosure
practices, which include:
  • Do not disclose the vulnerability publicly: Please refrain from
posting details of the vulnerability on public forums or social
media until it has been resolved.
  • Do not exploit the vulnerability: Do not attempt to exploit the
vulnerability to cause harm or gain unauthorized access to systems.
  • Work with us: Allow us a reasonable amount of time to
investigate and address the vulnerability before publicly disclosing
any details.
Legal Protections
We will not pursue legal action against individuals who
report security vulnerabilities to us.
Contact Information
To report a security vulnerability, please use GitHub
form.
Revision of Policy
This Security Vulnerability Disclosure Policy may be updated or
revised as necessary. Please check the latest version of this policy
on the Mithril repository.
Conclusion
The Mithril project greatly appreciates the assistance of the security
community in helping us maintain the security of our software while
upholding the highest standards of privacy. Together, we can work to
identify and address vulnerabilities, ensuring a safer and more secure
experience for all users.
 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
Security: dQuadrant/mithril
Security

SECURITY.md

Security Vulnerability Disclosure Policy
Introduction
The Mithril open source project is committed to ensuring the security of
its software and the privacy of its users. We value the contributions
of the security community in helping us identify and address
vulnerabilities in our code. This Security Vulnerability Disclosure
Policy outlines how security vulnerabilities should be reported and
how we will respond to and remediate such reports.
Security Vulnerability Handling Process
Reporting a Vulnerability
If you discover a security vulnerability in Mithril, we encourage you to
responsibly disclose it to us. To report a vulnerability, please use
the private reporting form on
GitHub
to draft a new Security advisory.
Please include as much details as needed to clearly qualify the issue:
  • A description of the vulnerability and its potential impact.
  • Steps to reproduce the vulnerability.
  • The version of mithril-node package where the vulnerability exists.
  • Any relevant proof-of-concept or exploit code (if applicable).
Processing Vulnerability
  1. Acknowledgment: The team acknowledges the receipt of your report
within 3 business days by commenting on the issue reporting it or replying to email.
  2. Validation: The team investigates the issue and either reject or validate the
reported vulnerability.
    a. Rejection: If the team rejects the report, detailed explanations will be provided by email or commenting on the relevant issue and the latter will be made public and closed as Won't fix.
    b. Acceptance: If the team accepts the report, a CVE identifier will be requested through GitHub and a private fork opened to work on a fix to the issue
  3. Resolution: The team works to resolve the vulnerability in a
timely manner. The timeline for resolution will depend on the
complexity and severity of the vulnerability, but we will strive to
address critical vulnerabilities as quickly as possible.
  4. Collaboration: While working on a fix, the team maintains open and transparent
communication with the reporter throughout the process, providing
updates on the status of the vulnerability and any steps taken to
remediate it. In particular this means that the reporter will be asked to review any proposed fix and to advise on the timing for public disclosure.
  5. Fixing Issue: The team agrees on the fix, the announcement, and the release schedule with the reporter. If the reporter is not responsive in a reasonable time frame this should not block the team from moving to the next steps particularly in the face of a high impact or high severity issue.
    a. Mitigation: Depending on the severity and criticity of the issue, the team can decide to disclose the issue publicly in the absence of a fix if and only if a clear, simple, and effective mitigation plan is defined. This must include instructions for users and operators of the software, and a time horizon at which the issue will be properly fixed (eg. version number).
    b. Fix: When a fix is available and approved, it should be merged and made available as quickly as possible:
    • All commits to the private repository are squashed into a single commit whose description should not make any reference it relates to a security vulnerability
    • A new Pull Request is created with this single commit
    • This PR's review and merging is expedited as all the work as already been done
  6. Release: The team creates and publish a release that includes the fix
  7. Announcement: Concommitant to the release annoucement, the team announces the security vulnerability by making the GitHub issue public. This is the first point that any information regarding the vulnerability is made public.
    a. Credit: The team publicly acknowledges the contributions of the
reporter once the vulnerability is resolved, subject to the
reporter's preferences for attribution.
  8. Disagreements: In case of disagreements with the reporter on the fix, mitigation, timing, or announcement, the team has the final say.
Responsible Disclosure
We kindly request that reporters adhere to responsible disclosure
practices, which include:
  • Do not disclose the vulnerability publicly: Please refrain from
posting details of the vulnerability on public forums or social
media until it has been resolved.
  • Do not exploit the vulnerability: Do not attempt to exploit the
vulnerability to cause harm or gain unauthorized access to systems.
  • Work with us: Allow us a reasonable amount of time to
investigate and address the vulnerability before publicly disclosing
any details.
Legal Protections
We will not pursue legal action against individuals who
report security vulnerabilities to us.
Contact Information
To report a security vulnerability, please use GitHub
form.
Revision of Policy
This Security Vulnerability Disclosure Policy may be updated or
revised as necessary. Please check the latest version of this policy
on the Mithril repository.
Conclusion
The Mithril project greatly appreciates the assistance of the security
community in helping us maintain the security of our software while
upholding the highest standards of privacy. Together, we can work to
identify and address vulnerabilities, ensuring a safer and more secure
experience for all users.
 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
Security: dQuadrant/mithril
Security

SECURITY.md

Security Vulnerability Disclosure Policy
Introduction
The Mithril open source project is committed to ensuring the security of
its software and the privacy of its users. We value the contributions
of the security community in helping us identify and address
vulnerabilities in our code. This Security Vulnerability Disclosure
Policy outlines how security vulnerabilities should be reported and
how we will respond to and remediate such reports.
Security Vulnerability Handling Process
Reporting a Vulnerability
If you discover a security vulnerability in Mithril, we encourage you to
responsibly disclose it to us. To report a vulnerability, please use
the private reporting form on
GitHub
to draft a new Security advisory.
Please include as much details as needed to clearly qualify the issue:
  • A description of the vulnerability and its potential impact.
  • Steps to reproduce the vulnerability.
  • The version of mithril-node package where the vulnerability exists.
  • Any relevant proof-of-concept or exploit code (if applicable).
Processing Vulnerability
  1. Acknowledgment: The team acknowledges the receipt of your report
within 3 business days by commenting on the issue reporting it or replying to email.
  2. Validation: The team investigates the issue and either reject or validate the
reported vulnerability.
    a. Rejection: If the team rejects the report, detailed explanations will be provided by email or commenting on the relevant issue and the latter will be made public and closed as Won't fix.
    b. Acceptance: If the team accepts the report, a CVE identifier will be requested through GitHub and a private fork opened to work on a fix to the issue
  3. Resolution: The team works to resolve the vulnerability in a
timely manner. The timeline for resolution will depend on the
complexity and severity of the vulnerability, but we will strive to
address critical vulnerabilities as quickly as possible.
  4. Collaboration: While working on a fix, the team maintains open and transparent
communication with the reporter throughout the process, providing
updates on the status of the vulnerability and any steps taken to
remediate it. In particular this means that the reporter will be asked to review any proposed fix and to advise on the timing for public disclosure.
  5. Fixing Issue: The team agrees on the fix, the announcement, and the release schedule with the reporter. If the reporter is not responsive in a reasonable time frame this should not block the team from moving to the next steps particularly in the face of a high impact or high severity issue.
    a. Mitigation: Depending on the severity and criticity of the issue, the team can decide to disclose the issue publicly in the absence of a fix if and only if a clear, simple, and effective mitigation plan is defined. This must include instructions for users and operators of the software, and a time horizon at which the issue will be properly fixed (eg. version number).
    b. Fix: When a fix is available and approved, it should be merged and made available as quickly as possible:
    • All commits to the private repository are squashed into a single commit whose description should not make any reference it relates to a security vulnerability
    • A new Pull Request is created with this single commit
    • This PR's review and merging is expedited as all the work as already been done
  6. Release: The team creates and publish a release that includes the fix
  7. Announcement: Concommitant to the release annoucement, the team announces the security vulnerability by making the GitHub issue public. This is the first point that any information regarding the vulnerability is made public.
    a. Credit: The team publicly acknowledges the contributions of the
reporter once the vulnerability is resolved, subject to the
reporter's preferences for attribution.
  8. Disagreements: In case of disagreements with the reporter on the fix, mitigation, timing, or announcement, the team has the final say.
Responsible Disclosure
We kindly request that reporters adhere to responsible disclosure
practices, which include:
  • Do not disclose the vulnerability publicly: Please refrain from
posting details of the vulnerability on public forums or social
media until it has been resolved.
  • Do not exploit the vulnerability: Do not attempt to exploit the
vulnerability to cause harm or gain unauthorized access to systems.
  • Work with us: Allow us a reasonable amount of time to
investigate and address the vulnerability before publicly disclosing
any details.
Legal Protections
We will not pursue legal action against individuals who
report security vulnerabilities to us.
Contact Information
To report a security vulnerability, please use GitHub
form.
Revision of Policy
This Security Vulnerability Disclosure Policy may be updated or
revised as necessary. Please check the latest version of this policy
on the Mithril repository.
Conclusion
The Mithril project greatly appreciates the assistance of the security
community in helping us maintain the security of our software while
upholding the highest standards of privacy. Together, we can work to
identify and address vulnerabilities, ensuring a safer and more secure
experience for all users.
 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
Security: dQuadrant/mithril
Security

SECURITY.md

Security Vulnerability Disclosure Policy
Introduction
The Mithril open source project is committed to ensuring the security of
its software and the privacy of its users. We value the contributions
of the security community in helping us identify and address
vulnerabilities in our code. This Security Vulnerability Disclosure
Policy outlines how security vulnerabilities should be reported and
how we will respond to and remediate such reports.
Security Vulnerability Handling Process
Reporting a Vulnerability
If you discover a security vulnerability in Mithril, we encourage you to
responsibly disclose it to us. To report a vulnerability, please use
the private reporting form on
GitHub
to draft a new Security advisory.
Please include as much details as needed to clearly qualify the issue:
  • A description of the vulnerability and its potential impact.
  • Steps to reproduce the vulnerability.
  • The version of mithril-node package where the vulnerability exists.
  • Any relevant proof-of-concept or exploit code (if applicable).
Processing Vulnerability
  1. Acknowledgment: The team acknowledges the receipt of your report
within 3 business days by commenting on the issue reporting it or replying to email.
  2. Validation: The team investigates the issue and either reject or validate the
reported vulnerability.
    a. Rejection: If the team rejects the report, detailed explanations will be provided by email or commenting on the relevant issue and the latter will be made public and closed as Won't fix.
    b. Acceptance: If the team accepts the report, a CVE identifier will be requested through GitHub and a private fork opened to work on a fix to the issue
  3. Resolution: The team works to resolve the vulnerability in a
timely manner. The timeline for resolution will depend on the
complexity and severity of the vulnerability, but we will strive to
address critical vulnerabilities as quickly as possible.
  4. Collaboration: While working on a fix, the team maintains open and transparent
communication with the reporter throughout the process, providing
updates on the status of the vulnerability and any steps taken to
remediate it. In particular this means that the reporter will be asked to review any proposed fix and to advise on the timing for public disclosure.
  5. Fixing Issue: The team agrees on the fix, the announcement, and the release schedule with the reporter. If the reporter is not responsive in a reasonable time frame this should not block the team from moving to the next steps particularly in the face of a high impact or high severity issue.
    a. Mitigation: Depending on the severity and criticity of the issue, the team can decide to disclose the issue publicly in the absence of a fix if and only if a clear, simple, and effective mitigation plan is defined. This must include instructions for users and operators of the software, and a time horizon at which the issue will be properly fixed (eg. version number).
    b. Fix: When a fix is available and approved, it should be merged and made available as quickly as possible:
    • All commits to the private repository are squashed into a single commit whose description should not make any reference it relates to a security vulnerability
    • A new Pull Request is created with this single commit
    • This PR's review and merging is expedited as all the work as already been done
  6. Release: The team creates and publish a release that includes the fix
  7. Announcement: Concommitant to the release annoucement, the team announces the security vulnerability by making the GitHub issue public. This is the first point that any information regarding the vulnerability is made public.
    a. Credit: The team publicly acknowledges the contributions of the
reporter once the vulnerability is resolved, subject to the
reporter's preferences for attribution.
  8. Disagreements: In case of disagreements with the reporter on the fix, mitigation, timing, or announcement, the team has the final say.
Responsible Disclosure
We kindly request that reporters adhere to responsible disclosure
practices, which include:
  • Do not disclose the vulnerability publicly: Please refrain from
posting details of the vulnerability on public forums or social
media until it has been resolved.
  • Do not exploit the vulnerability: Do not attempt to exploit the
vulnerability to cause harm or gain unauthorized access to systems.
  • Work with us: Allow us a reasonable amount of time to
investigate and address the vulnerability before publicly disclosing
any details.
Legal Protections
We will not pursue legal action against individuals who
report security vulnerabilities to us.
Contact Information
To report a security vulnerability, please use GitHub
form.
Revision of Policy
This Security Vulnerability Disclosure Policy may be updated or
revised as necessary. Please check the latest version of this policy
on the Mithril repository.
Conclusion
The Mithril project greatly appreciates the assistance of the security
community in helping us maintain the security of our software while
upholding the highest standards of privacy. Together, we can work to
identify and address vulnerabilities, ensuring a safer and more secure
experience for all users.
 There aren't any published security advisories