Security: oxlime/cairo-zig

Security

docs/SECURITY.md

Security Guidelines

Introduction

Security is a top priority in the development of Ziggy STARKdust. This document outlines some security best practices that contributors should follow, as well as procedures for reporting security vulnerabilities.

Security Best Practices

Code Quality Rules

  • Understandable and Simplicity: Keep your code as simple and straightforward as possible.

  • Code Reviews: Every pull request must be reviewed by at least one other developer who is knowledgeable about the code and context.

  • Limited Scope: Minimize the accessibility of functions, classes, and variables by reducing their scope whenever possible.

  • Error Handling: Always check for error returns unless you are absolutely sure that the function cannot return an error.

  • Input Validation: Validate input from all untrusted data sources.

NASA's Power of Ten Rules

We adhere to the NASA Power of Ten Rules for safer code:

  1. Avoid complex flow constructs, such as goto and recursion.
  2. All loops must have a fixed upper bound and be provably terminable.
  3. Avoid dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper.
  5. Assert liberally to document internal assumptions and invariants.
  6. Minimize global and shared data.
  7. Use at least two runtime assertions per function.
  8. Data objects must be declared at the smallest possible level of scope.
  9. Check the return value of all non-void functions, or cast to void to indicate the result is useless.
  10. Limit the scope of data to the smallest possible lexical scope.

Vulnerability Reporting

Critical Vulnerabilities

For critical vulnerabilities, please do NOT open an issue. Instead, send an email directly to security@starkware.co.

Critical vulnerabilities include but are not limited to:

  • Code execution attacks
  • Privilege escalation
  • Data leaks

Non-Critical Vulnerabilities

For non-critical vulnerabilities, such as issues that are relevant but do not pose an immediate threat to the integrity of the system, you may open a GitHub issue in the ziggy-starkdust repository.

Conclusion

Adhering to these guidelines is essential for ensuring that Ziggy STARKdust remains a secure and reliable codebase. Your cooperation is greatly appreciated.

For any further questions, feel free to contact security@starkware.co.

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: oxlime/cairo-zig
Security

docs/SECURITY.md

Security Guidelines
Introduction
Security is a top priority in the development of Ziggy STARKdust. This document outlines some security best practices that contributors should follow, as well as procedures for reporting security vulnerabilities.
Security Best Practices
Code Quality Rules
  • Understandable and Simplicity: Keep your code as simple and straightforward as possible.
  • Code Reviews: Every pull request must be reviewed by at least one other developer who is knowledgeable about the code and context.
  • Limited Scope: Minimize the accessibility of functions, classes, and variables by reducing their scope whenever possible.
  • Error Handling: Always check for error returns unless you are absolutely sure that the function cannot return an error.
  • Input Validation: Validate input from all untrusted data sources.
NASA's Power of Ten Rules
We adhere to the NASA Power of Ten Rules for safer code:
  1. Avoid complex flow constructs, such as goto and recursion.
  2. All loops must have a fixed upper bound and be provably terminable.
  3. Avoid dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper.
  5. Assert liberally to document internal assumptions and invariants.
  6. Minimize global and shared data.
  7. Use at least two runtime assertions per function.
  8. Data objects must be declared at the smallest possible level of scope.
  9. Check the return value of all non-void functions, or cast to void to indicate the result is useless.
  10. Limit the scope of data to the smallest possible lexical scope.
Vulnerability Reporting
Critical Vulnerabilities
For critical vulnerabilities, please do NOT open an issue. Instead, send an email directly to security@starkware.co.
Critical vulnerabilities include but are not limited to:
  • Code execution attacks
  • Privilege escalation
  • Data leaks
Non-Critical Vulnerabilities
For non-critical vulnerabilities, such as issues that are relevant but do not pose an immediate threat to the integrity of the system, you may open a GitHub issue in the ziggy-starkdust repository.
Conclusion
Adhering to these guidelines is essential for ensuring that Ziggy STARKdust remains a secure and reliable codebase. Your cooperation is greatly appreciated.
For any further questions, feel free to contact security@starkware.co.
 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: oxlime/cairo-zig
Security

docs/SECURITY.md

Security Guidelines
Introduction
Security is a top priority in the development of Ziggy STARKdust. This document outlines some security best practices that contributors should follow, as well as procedures for reporting security vulnerabilities.
Security Best Practices
Code Quality Rules
  • Understandable and Simplicity: Keep your code as simple and straightforward as possible.
  • Code Reviews: Every pull request must be reviewed by at least one other developer who is knowledgeable about the code and context.
  • Limited Scope: Minimize the accessibility of functions, classes, and variables by reducing their scope whenever possible.
  • Error Handling: Always check for error returns unless you are absolutely sure that the function cannot return an error.
  • Input Validation: Validate input from all untrusted data sources.
NASA's Power of Ten Rules
We adhere to the NASA Power of Ten Rules for safer code:
  1. Avoid complex flow constructs, such as goto and recursion.
  2. All loops must have a fixed upper bound and be provably terminable.
  3. Avoid dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper.
  5. Assert liberally to document internal assumptions and invariants.
  6. Minimize global and shared data.
  7. Use at least two runtime assertions per function.
  8. Data objects must be declared at the smallest possible level of scope.
  9. Check the return value of all non-void functions, or cast to void to indicate the result is useless.
  10. Limit the scope of data to the smallest possible lexical scope.
Vulnerability Reporting
Critical Vulnerabilities
For critical vulnerabilities, please do NOT open an issue. Instead, send an email directly to security@starkware.co.
Critical vulnerabilities include but are not limited to:
  • Code execution attacks
  • Privilege escalation
  • Data leaks
Non-Critical Vulnerabilities
For non-critical vulnerabilities, such as issues that are relevant but do not pose an immediate threat to the integrity of the system, you may open a GitHub issue in the ziggy-starkdust repository.
Conclusion
Adhering to these guidelines is essential for ensuring that Ziggy STARKdust remains a secure and reliable codebase. Your cooperation is greatly appreciated.
For any further questions, feel free to contact security@starkware.co.
 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: oxlime/cairo-zig
Security

docs/SECURITY.md

Security Guidelines
Introduction
Security is a top priority in the development of Ziggy STARKdust. This document outlines some security best practices that contributors should follow, as well as procedures for reporting security vulnerabilities.
Security Best Practices
Code Quality Rules
  • Understandable and Simplicity: Keep your code as simple and straightforward as possible.
  • Code Reviews: Every pull request must be reviewed by at least one other developer who is knowledgeable about the code and context.
  • Limited Scope: Minimize the accessibility of functions, classes, and variables by reducing their scope whenever possible.
  • Error Handling: Always check for error returns unless you are absolutely sure that the function cannot return an error.
  • Input Validation: Validate input from all untrusted data sources.
NASA's Power of Ten Rules
We adhere to the NASA Power of Ten Rules for safer code:
  1. Avoid complex flow constructs, such as goto and recursion.
  2. All loops must have a fixed upper bound and be provably terminable.
  3. Avoid dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper.
  5. Assert liberally to document internal assumptions and invariants.
  6. Minimize global and shared data.
  7. Use at least two runtime assertions per function.
  8. Data objects must be declared at the smallest possible level of scope.
  9. Check the return value of all non-void functions, or cast to void to indicate the result is useless.
  10. Limit the scope of data to the smallest possible lexical scope.
Vulnerability Reporting
Critical Vulnerabilities
For critical vulnerabilities, please do NOT open an issue. Instead, send an email directly to security@starkware.co.
Critical vulnerabilities include but are not limited to:
  • Code execution attacks
  • Privilege escalation
  • Data leaks
Non-Critical Vulnerabilities
For non-critical vulnerabilities, such as issues that are relevant but do not pose an immediate threat to the integrity of the system, you may open a GitHub issue in the ziggy-starkdust repository.
Conclusion
Adhering to these guidelines is essential for ensuring that Ziggy STARKdust remains a secure and reliable codebase. Your cooperation is greatly appreciated.
For any further questions, feel free to contact security@starkware.co.
 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: oxlime/cairo-zig
Security

docs/SECURITY.md

Security Guidelines
Introduction
Security is a top priority in the development of Ziggy STARKdust. This document outlines some security best practices that contributors should follow, as well as procedures for reporting security vulnerabilities.
Security Best Practices
Code Quality Rules
  • Understandable and Simplicity: Keep your code as simple and straightforward as possible.
  • Code Reviews: Every pull request must be reviewed by at least one other developer who is knowledgeable about the code and context.
  • Limited Scope: Minimize the accessibility of functions, classes, and variables by reducing their scope whenever possible.
  • Error Handling: Always check for error returns unless you are absolutely sure that the function cannot return an error.
  • Input Validation: Validate input from all untrusted data sources.
NASA's Power of Ten Rules
We adhere to the NASA Power of Ten Rules for safer code:
  1. Avoid complex flow constructs, such as goto and recursion.
  2. All loops must have a fixed upper bound and be provably terminable.
  3. Avoid dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper.
  5. Assert liberally to document internal assumptions and invariants.
  6. Minimize global and shared data.
  7. Use at least two runtime assertions per function.
  8. Data objects must be declared at the smallest possible level of scope.
  9. Check the return value of all non-void functions, or cast to void to indicate the result is useless.
  10. Limit the scope of data to the smallest possible lexical scope.
Vulnerability Reporting
Critical Vulnerabilities
For critical vulnerabilities, please do NOT open an issue. Instead, send an email directly to security@starkware.co.
Critical vulnerabilities include but are not limited to:
  • Code execution attacks
  • Privilege escalation
  • Data leaks
Non-Critical Vulnerabilities
For non-critical vulnerabilities, such as issues that are relevant but do not pose an immediate threat to the integrity of the system, you may open a GitHub issue in the ziggy-starkdust repository.
Conclusion
Adhering to these guidelines is essential for ensuring that Ziggy STARKdust remains a secure and reliable codebase. Your cooperation is greatly appreciated.
For any further questions, feel free to contact security@starkware.co.
 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: oxlime/cairo-zig
Security

docs/SECURITY.md

Security Guidelines
Introduction
Security is a top priority in the development of Ziggy STARKdust. This document outlines some security best practices that contributors should follow, as well as procedures for reporting security vulnerabilities.
Security Best Practices
Code Quality Rules
  • Understandable and Simplicity: Keep your code as simple and straightforward as possible.
  • Code Reviews: Every pull request must be reviewed by at least one other developer who is knowledgeable about the code and context.
  • Limited Scope: Minimize the accessibility of functions, classes, and variables by reducing their scope whenever possible.
  • Error Handling: Always check for error returns unless you are absolutely sure that the function cannot return an error.
  • Input Validation: Validate input from all untrusted data sources.
NASA's Power of Ten Rules
We adhere to the NASA Power of Ten Rules for safer code:
  1. Avoid complex flow constructs, such as goto and recursion.
  2. All loops must have a fixed upper bound and be provably terminable.
  3. Avoid dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper.
  5. Assert liberally to document internal assumptions and invariants.
  6. Minimize global and shared data.
  7. Use at least two runtime assertions per function.
  8. Data objects must be declared at the smallest possible level of scope.
  9. Check the return value of all non-void functions, or cast to void to indicate the result is useless.
  10. Limit the scope of data to the smallest possible lexical scope.
Vulnerability Reporting
Critical Vulnerabilities
For critical vulnerabilities, please do NOT open an issue. Instead, send an email directly to security@starkware.co.
Critical vulnerabilities include but are not limited to:
  • Code execution attacks
  • Privilege escalation
  • Data leaks
Non-Critical Vulnerabilities
For non-critical vulnerabilities, such as issues that are relevant but do not pose an immediate threat to the integrity of the system, you may open a GitHub issue in the ziggy-starkdust repository.
Conclusion
Adhering to these guidelines is essential for ensuring that Ziggy STARKdust remains a secure and reliable codebase. Your cooperation is greatly appreciated.
For any further questions, feel free to contact security@starkware.co.
 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: oxlime/cairo-zig
Security

docs/SECURITY.md

Security Guidelines
Introduction
Security is a top priority in the development of Ziggy STARKdust. This document outlines some security best practices that contributors should follow, as well as procedures for reporting security vulnerabilities.
Security Best Practices
Code Quality Rules
  • Understandable and Simplicity: Keep your code as simple and straightforward as possible.
  • Code Reviews: Every pull request must be reviewed by at least one other developer who is knowledgeable about the code and context.
  • Limited Scope: Minimize the accessibility of functions, classes, and variables by reducing their scope whenever possible.
  • Error Handling: Always check for error returns unless you are absolutely sure that the function cannot return an error.
  • Input Validation: Validate input from all untrusted data sources.
NASA's Power of Ten Rules
We adhere to the NASA Power of Ten Rules for safer code:
  1. Avoid complex flow constructs, such as goto and recursion.
  2. All loops must have a fixed upper bound and be provably terminable.
  3. Avoid dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper.
  5. Assert liberally to document internal assumptions and invariants.
  6. Minimize global and shared data.
  7. Use at least two runtime assertions per function.
  8. Data objects must be declared at the smallest possible level of scope.
  9. Check the return value of all non-void functions, or cast to void to indicate the result is useless.
  10. Limit the scope of data to the smallest possible lexical scope.
Vulnerability Reporting
Critical Vulnerabilities
For critical vulnerabilities, please do NOT open an issue. Instead, send an email directly to security@starkware.co.
Critical vulnerabilities include but are not limited to:
  • Code execution attacks
  • Privilege escalation
  • Data leaks
Non-Critical Vulnerabilities
For non-critical vulnerabilities, such as issues that are relevant but do not pose an immediate threat to the integrity of the system, you may open a GitHub issue in the ziggy-starkdust repository.
Conclusion
Adhering to these guidelines is essential for ensuring that Ziggy STARKdust remains a secure and reliable codebase. Your cooperation is greatly appreciated.
For any further questions, feel free to contact security@starkware.co.
 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: oxlime/cairo-zig
Security

docs/SECURITY.md

Security Guidelines
Introduction
Security is a top priority in the development of Ziggy STARKdust. This document outlines some security best practices that contributors should follow, as well as procedures for reporting security vulnerabilities.
Security Best Practices
Code Quality Rules
  • Understandable and Simplicity: Keep your code as simple and straightforward as possible.
  • Code Reviews: Every pull request must be reviewed by at least one other developer who is knowledgeable about the code and context.
  • Limited Scope: Minimize the accessibility of functions, classes, and variables by reducing their scope whenever possible.
  • Error Handling: Always check for error returns unless you are absolutely sure that the function cannot return an error.
  • Input Validation: Validate input from all untrusted data sources.
NASA's Power of Ten Rules
We adhere to the NASA Power of Ten Rules for safer code:
  1. Avoid complex flow constructs, such as goto and recursion.
  2. All loops must have a fixed upper bound and be provably terminable.
  3. Avoid dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper.
  5. Assert liberally to document internal assumptions and invariants.
  6. Minimize global and shared data.
  7. Use at least two runtime assertions per function.
  8. Data objects must be declared at the smallest possible level of scope.
  9. Check the return value of all non-void functions, or cast to void to indicate the result is useless.
  10. Limit the scope of data to the smallest possible lexical scope.
Vulnerability Reporting
Critical Vulnerabilities
For critical vulnerabilities, please do NOT open an issue. Instead, send an email directly to security@starkware.co.
Critical vulnerabilities include but are not limited to:
  • Code execution attacks
  • Privilege escalation
  • Data leaks
Non-Critical Vulnerabilities
For non-critical vulnerabilities, such as issues that are relevant but do not pose an immediate threat to the integrity of the system, you may open a GitHub issue in the ziggy-starkdust repository.
Conclusion
Adhering to these guidelines is essential for ensuring that Ziggy STARKdust remains a secure and reliable codebase. Your cooperation is greatly appreciated.
For any further questions, feel free to contact security@starkware.co.
 There aren't any published security advisories