Skip to content

Implement signed index support #308

Closed
#312
Closed
Implement signed index support#308
#312
Assignees
zooba
Labels
enhancementNew feature or request

Description

@zooba
zooba
opened on Apr 10, 2026

We want to be able to validate that at least our python.org index has not been tampered with, while not excluding other sources from providing their own index (e.g. by requiring that they have access to our certificates, or even their own).

My proposed approach:

  • add install.source_settings config that contains a mapping from source URL to additional settings
  • add settings for requires_signature, required_root_subject, required_publisher_subject, required_publisher_eku1. Also add these to the schema for feeds, though we won't be using them for the python.org feeds
  • set these settings by default for our default feed URL. Absent by default for custom feeds
  • when accessing a feed, we add .p7s to its URL to get a detached Authenticode signature
  • if the feed requires_signature and the signature file is missing, does not validate against the OS's certificate store, or does not match the other settings, we print a warning prompt before processing it. This prompt defaults to "no/abort", and if confirm=False then it always aborts
  • if the signature is valid, we print a prominent "validated" message, so that if it ever goes missing it should be fairly obvious to users that something has changed
  • if the feed has no settings, we parse it and look for its own requirements, then reprocess as above.
  • feeds without a requires_signature get a subtle warning - something like "skipping verification". This is to help discoverability of the feature for custom feed owners, without making it seem like an unverified feed is inherently problematic

The aim is to allow us to have secure default settings for the vast majority of our users, without turning the install manager into a proprietary downloader. We embed our certificate details in the client to make it more difficult for an attacker to remove the specification, but allow referencing them from the feed to allow downstreams to more easily enable their own checks. We require OS verification to handle certificate revocation, rather than trying to do it ourselves, but allow (optional) restricting the certificate to prevent an attacker switching the client's expectations. We use Authenticode rather than another mechanism because our code signing certificate is our best protected secret, and so the level of trust matches between the binaries we provide and our index.

And just to be clear, there is no evidence that anyone has attempted to hijack our index, and this issue is not motivated by any recent reports towards Python. It is motivated by our assessment of the ecosystem right now, and the fact that multiple recent supply chain attacks have targeted download pages and tools of popular software, and so (along with other procedural measures), we want to make sure that Python stays ahead of the attackers.

Footnotes

  1. The EKU is an identifying marker added by Azure Trusted Signing that lets us use their root certificate name and our EKU to validate ↩

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
     blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
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;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Implement signed index support · Issue #308 · python/pymanager · GitHub
    Skip to content
    Implement signed index support #308
    Closed
    #312
    Closed
    Implement signed index support#308
    #312
    Assignees
    zooba
    Labels
    enhancementNew feature or request
    Description
    @zooba
    zooba
    opened on Apr 10, 2026
    We want to be able to validate that at least our python.org index has not been tampered with, while not excluding other sources from providing their own index (e.g. by requiring that they have access to our certificates, or even their own).
    My proposed approach:
    • add install.source_settings config that contains a mapping from source URL to additional settings
    • add settings for requires_signature, required_root_subject, required_publisher_subject, required_publisher_eku1. Also add these to the schema for feeds, though we won't be using them for the python.org feeds
    • set these settings by default for our default feed URL. Absent by default for custom feeds
    • when accessing a feed, we add .p7s to its URL to get a detached Authenticode signature
    • if the feed requires_signature and the signature file is missing, does not validate against the OS's certificate store, or does not match the other settings, we print a warning prompt before processing it. This prompt defaults to "no/abort", and if confirm=False then it always aborts
    • if the signature is valid, we print a prominent "validated" message, so that if it ever goes missing it should be fairly obvious to users that something has changed
    • if the feed has no settings, we parse it and look for its own requirements, then reprocess as above.
    • feeds without a requires_signature get a subtle warning - something like "skipping verification". This is to help discoverability of the feature for custom feed owners, without making it seem like an unverified feed is inherently problematic
    The aim is to allow us to have secure default settings for the vast majority of our users, without turning the install manager into a proprietary downloader. We embed our certificate details in the client to make it more difficult for an attacker to remove the specification, but allow referencing them from the feed to allow downstreams to more easily enable their own checks. We require OS verification to handle certificate revocation, rather than trying to do it ourselves, but allow (optional) restricting the certificate to prevent an attacker switching the client's expectations. We use Authenticode rather than another mechanism because our code signing certificate is our best protected secret, and so the level of trust matches between the binaries we provide and our index.
    And just to be clear, there is no evidence that anyone has attempted to hijack our index, and this issue is not motivated by any recent reports towards Python. It is motivated by our assessment of the ecosystem right now, and the fact that multiple recent supply chain attacks have targeted download pages and tools of popular software, and so (along with other procedural measures), we want to make sure that Python stays ahead of the attackers.
    Footnotes
    1. The EKU is an identifying marker added by Azure Trusted Signing that lets us use their root certificate name and our EKU to validate ↩
    Metadata
    Metadata
    Assignees
    Labels
    enhancementNew feature or request
    Projects
    No projects
      Milestone
      No milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions
      
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Implement signed index support · Issue #308 · python/pymanager · GitHub
      Skip to content
      Implement signed index support #308
      Closed
      #312
      Closed
      Implement signed index support#308
      #312
      Assignees
      zooba
      Labels
      enhancementNew feature or request
      Description
      @zooba
      zooba
      opened on Apr 10, 2026
      We want to be able to validate that at least our python.org index has not been tampered with, while not excluding other sources from providing their own index (e.g. by requiring that they have access to our certificates, or even their own).
      My proposed approach:
      • add install.source_settings config that contains a mapping from source URL to additional settings
      • add settings for requires_signature, required_root_subject, required_publisher_subject, required_publisher_eku1. Also add these to the schema for feeds, though we won't be using them for the python.org feeds
      • set these settings by default for our default feed URL. Absent by default for custom feeds
      • when accessing a feed, we add .p7s to its URL to get a detached Authenticode signature
      • if the feed requires_signature and the signature file is missing, does not validate against the OS's certificate store, or does not match the other settings, we print a warning prompt before processing it. This prompt defaults to "no/abort", and if confirm=False then it always aborts
      • if the signature is valid, we print a prominent "validated" message, so that if it ever goes missing it should be fairly obvious to users that something has changed
      • if the feed has no settings, we parse it and look for its own requirements, then reprocess as above.
      • feeds without a requires_signature get a subtle warning - something like "skipping verification". This is to help discoverability of the feature for custom feed owners, without making it seem like an unverified feed is inherently problematic
      The aim is to allow us to have secure default settings for the vast majority of our users, without turning the install manager into a proprietary downloader. We embed our certificate details in the client to make it more difficult for an attacker to remove the specification, but allow referencing them from the feed to allow downstreams to more easily enable their own checks. We require OS verification to handle certificate revocation, rather than trying to do it ourselves, but allow (optional) restricting the certificate to prevent an attacker switching the client's expectations. We use Authenticode rather than another mechanism because our code signing certificate is our best protected secret, and so the level of trust matches between the binaries we provide and our index.
      And just to be clear, there is no evidence that anyone has attempted to hijack our index, and this issue is not motivated by any recent reports towards Python. It is motivated by our assessment of the ecosystem right now, and the fact that multiple recent supply chain attacks have targeted download pages and tools of popular software, and so (along with other procedural measures), we want to make sure that Python stays ahead of the attackers.
      Footnotes
      1. The EKU is an identifying marker added by Azure Trusted Signing that lets us use their root certificate name and our EKU to validate ↩
      Metadata
      Metadata
      Assignees
      Labels
      enhancementNew feature or request
      Projects
      No projects
        Milestone
        No milestone
        Relationships
        None yet
        Development
        No branches or pull requests
        Issue actions
        
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Implement signed index support · Issue #308 · python/pymanager · GitHub
        Skip to content
        Implement signed index support #308
        Closed
        #312
        Closed
        Implement signed index support#308
        #312
        Assignees
        zooba
        Labels
        enhancementNew feature or request
        Description
        @zooba
        zooba
        opened on Apr 10, 2026
        We want to be able to validate that at least our python.org index has not been tampered with, while not excluding other sources from providing their own index (e.g. by requiring that they have access to our certificates, or even their own).
        My proposed approach:
        • add install.source_settings config that contains a mapping from source URL to additional settings
        • add settings for requires_signature, required_root_subject, required_publisher_subject, required_publisher_eku1. Also add these to the schema for feeds, though we won't be using them for the python.org feeds
        • set these settings by default for our default feed URL. Absent by default for custom feeds
        • when accessing a feed, we add .p7s to its URL to get a detached Authenticode signature
        • if the feed requires_signature and the signature file is missing, does not validate against the OS's certificate store, or does not match the other settings, we print a warning prompt before processing it. This prompt defaults to "no/abort", and if confirm=False then it always aborts
        • if the signature is valid, we print a prominent "validated" message, so that if it ever goes missing it should be fairly obvious to users that something has changed
        • if the feed has no settings, we parse it and look for its own requirements, then reprocess as above.
        • feeds without a requires_signature get a subtle warning - something like "skipping verification". This is to help discoverability of the feature for custom feed owners, without making it seem like an unverified feed is inherently problematic
        The aim is to allow us to have secure default settings for the vast majority of our users, without turning the install manager into a proprietary downloader. We embed our certificate details in the client to make it more difficult for an attacker to remove the specification, but allow referencing them from the feed to allow downstreams to more easily enable their own checks. We require OS verification to handle certificate revocation, rather than trying to do it ourselves, but allow (optional) restricting the certificate to prevent an attacker switching the client's expectations. We use Authenticode rather than another mechanism because our code signing certificate is our best protected secret, and so the level of trust matches between the binaries we provide and our index.
        And just to be clear, there is no evidence that anyone has attempted to hijack our index, and this issue is not motivated by any recent reports towards Python. It is motivated by our assessment of the ecosystem right now, and the fact that multiple recent supply chain attacks have targeted download pages and tools of popular software, and so (along with other procedural measures), we want to make sure that Python stays ahead of the attackers.
        Footnotes
        1. The EKU is an identifying marker added by Azure Trusted Signing that lets us use their root certificate name and our EKU to validate ↩
        Metadata
        Metadata
        Assignees
        Labels
        enhancementNew feature or request
        Projects
        No projects
          Milestone
          No milestone
          Relationships
          None yet
          Development
          No branches or pull requests
          Issue actions
          
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Implement signed index support · Issue #308 · python/pymanager · GitHub
          Skip to content
          Implement signed index support #308
          Closed
          #312
          Closed
          Implement signed index support#308
          #312
          Assignees
          zooba
          Labels
          enhancementNew feature or request
          Description
          @zooba
          zooba
          opened on Apr 10, 2026
          We want to be able to validate that at least our python.org index has not been tampered with, while not excluding other sources from providing their own index (e.g. by requiring that they have access to our certificates, or even their own).
          My proposed approach:
          • add install.source_settings config that contains a mapping from source URL to additional settings
          • add settings for requires_signature, required_root_subject, required_publisher_subject, required_publisher_eku1. Also add these to the schema for feeds, though we won't be using them for the python.org feeds
          • set these settings by default for our default feed URL. Absent by default for custom feeds
          • when accessing a feed, we add .p7s to its URL to get a detached Authenticode signature
          • if the feed requires_signature and the signature file is missing, does not validate against the OS's certificate store, or does not match the other settings, we print a warning prompt before processing it. This prompt defaults to "no/abort", and if confirm=False then it always aborts
          • if the signature is valid, we print a prominent "validated" message, so that if it ever goes missing it should be fairly obvious to users that something has changed
          • if the feed has no settings, we parse it and look for its own requirements, then reprocess as above.
          • feeds without a requires_signature get a subtle warning - something like "skipping verification". This is to help discoverability of the feature for custom feed owners, without making it seem like an unverified feed is inherently problematic
          The aim is to allow us to have secure default settings for the vast majority of our users, without turning the install manager into a proprietary downloader. We embed our certificate details in the client to make it more difficult for an attacker to remove the specification, but allow referencing them from the feed to allow downstreams to more easily enable their own checks. We require OS verification to handle certificate revocation, rather than trying to do it ourselves, but allow (optional) restricting the certificate to prevent an attacker switching the client's expectations. We use Authenticode rather than another mechanism because our code signing certificate is our best protected secret, and so the level of trust matches between the binaries we provide and our index.
          And just to be clear, there is no evidence that anyone has attempted to hijack our index, and this issue is not motivated by any recent reports towards Python. It is motivated by our assessment of the ecosystem right now, and the fact that multiple recent supply chain attacks have targeted download pages and tools of popular software, and so (along with other procedural measures), we want to make sure that Python stays ahead of the attackers.
          Footnotes
          1. The EKU is an identifying marker added by Azure Trusted Signing that lets us use their root certificate name and our EKU to validate ↩
          Metadata
          Metadata
          Assignees
          Labels
          enhancementNew feature or request
          Projects
          No projects
            Milestone
            No milestone
            Relationships
            None yet
            Development
            No branches or pull requests
            Issue actions
            
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Implement signed index support · Issue #308 · python/pymanager · GitHub
            Skip to content
            Implement signed index support #308
            Closed
            #312
            Closed
            Implement signed index support#308
            #312
            Assignees
            zooba
            Labels
            enhancementNew feature or request
            Description
            @zooba
            zooba
            opened on Apr 10, 2026
            We want to be able to validate that at least our python.org index has not been tampered with, while not excluding other sources from providing their own index (e.g. by requiring that they have access to our certificates, or even their own).
            My proposed approach:
            • add install.source_settings config that contains a mapping from source URL to additional settings
            • add settings for requires_signature, required_root_subject, required_publisher_subject, required_publisher_eku1. Also add these to the schema for feeds, though we won't be using them for the python.org feeds
            • set these settings by default for our default feed URL. Absent by default for custom feeds
            • when accessing a feed, we add .p7s to its URL to get a detached Authenticode signature
            • if the feed requires_signature and the signature file is missing, does not validate against the OS's certificate store, or does not match the other settings, we print a warning prompt before processing it. This prompt defaults to "no/abort", and if confirm=False then it always aborts
            • if the signature is valid, we print a prominent "validated" message, so that if it ever goes missing it should be fairly obvious to users that something has changed
            • if the feed has no settings, we parse it and look for its own requirements, then reprocess as above.
            • feeds without a requires_signature get a subtle warning - something like "skipping verification". This is to help discoverability of the feature for custom feed owners, without making it seem like an unverified feed is inherently problematic
            The aim is to allow us to have secure default settings for the vast majority of our users, without turning the install manager into a proprietary downloader. We embed our certificate details in the client to make it more difficult for an attacker to remove the specification, but allow referencing them from the feed to allow downstreams to more easily enable their own checks. We require OS verification to handle certificate revocation, rather than trying to do it ourselves, but allow (optional) restricting the certificate to prevent an attacker switching the client's expectations. We use Authenticode rather than another mechanism because our code signing certificate is our best protected secret, and so the level of trust matches between the binaries we provide and our index.
            And just to be clear, there is no evidence that anyone has attempted to hijack our index, and this issue is not motivated by any recent reports towards Python. It is motivated by our assessment of the ecosystem right now, and the fact that multiple recent supply chain attacks have targeted download pages and tools of popular software, and so (along with other procedural measures), we want to make sure that Python stays ahead of the attackers.
            Footnotes
            1. The EKU is an identifying marker added by Azure Trusted Signing that lets us use their root certificate name and our EKU to validate ↩
            Metadata
            Metadata
            Assignees
            Labels
            enhancementNew feature or request
            Projects
            No projects
              Milestone
              No milestone
              Relationships
              None yet
              Development
              No branches or pull requests
              Issue actions
              
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Implement signed index support · Issue #308 · python/pymanager · GitHub
              Skip to content
              Implement signed index support #308
              Closed
              #312
              Closed
              Implement signed index support#308
              #312
              Assignees
              zooba
              Labels
              enhancementNew feature or request
              Description
              @zooba
              zooba
              opened on Apr 10, 2026
              We want to be able to validate that at least our python.org index has not been tampered with, while not excluding other sources from providing their own index (e.g. by requiring that they have access to our certificates, or even their own).
              My proposed approach:
              • add install.source_settings config that contains a mapping from source URL to additional settings
              • add settings for requires_signature, required_root_subject, required_publisher_subject, required_publisher_eku1. Also add these to the schema for feeds, though we won't be using them for the python.org feeds
              • set these settings by default for our default feed URL. Absent by default for custom feeds
              • when accessing a feed, we add .p7s to its URL to get a detached Authenticode signature
              • if the feed requires_signature and the signature file is missing, does not validate against the OS's certificate store, or does not match the other settings, we print a warning prompt before processing it. This prompt defaults to "no/abort", and if confirm=False then it always aborts
              • if the signature is valid, we print a prominent "validated" message, so that if it ever goes missing it should be fairly obvious to users that something has changed
              • if the feed has no settings, we parse it and look for its own requirements, then reprocess as above.
              • feeds without a requires_signature get a subtle warning - something like "skipping verification". This is to help discoverability of the feature for custom feed owners, without making it seem like an unverified feed is inherently problematic
              The aim is to allow us to have secure default settings for the vast majority of our users, without turning the install manager into a proprietary downloader. We embed our certificate details in the client to make it more difficult for an attacker to remove the specification, but allow referencing them from the feed to allow downstreams to more easily enable their own checks. We require OS verification to handle certificate revocation, rather than trying to do it ourselves, but allow (optional) restricting the certificate to prevent an attacker switching the client's expectations. We use Authenticode rather than another mechanism because our code signing certificate is our best protected secret, and so the level of trust matches between the binaries we provide and our index.
              And just to be clear, there is no evidence that anyone has attempted to hijack our index, and this issue is not motivated by any recent reports towards Python. It is motivated by our assessment of the ecosystem right now, and the fact that multiple recent supply chain attacks have targeted download pages and tools of popular software, and so (along with other procedural measures), we want to make sure that Python stays ahead of the attackers.
              Footnotes
              1. The EKU is an identifying marker added by Azure Trusted Signing that lets us use their root certificate name and our EKU to validate ↩
              Metadata
              Metadata
              Assignees
              Labels
              enhancementNew feature or request
              Projects
              No projects
                Milestone
                No milestone
                Relationships
                None yet
                Development
                No branches or pull requests
                Issue actions
                
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
Implement signed index support · Issue #308 · python/pymanager · GitHub
                Skip to content
                Implement signed index support #308
                Closed
                #312
                Closed
                Implement signed index support#308
                #312
                Assignees
                zooba
                Labels
                enhancementNew feature or request
                Description
                @zooba
                zooba
                opened on Apr 10, 2026
                We want to be able to validate that at least our python.org index has not been tampered with, while not excluding other sources from providing their own index (e.g. by requiring that they have access to our certificates, or even their own).
                My proposed approach:
                • add install.source_settings config that contains a mapping from source URL to additional settings
                • add settings for requires_signature, required_root_subject, required_publisher_subject, required_publisher_eku1. Also add these to the schema for feeds, though we won't be using them for the python.org feeds
                • set these settings by default for our default feed URL. Absent by default for custom feeds
                • when accessing a feed, we add .p7s to its URL to get a detached Authenticode signature
                • if the feed requires_signature and the signature file is missing, does not validate against the OS's certificate store, or does not match the other settings, we print a warning prompt before processing it. This prompt defaults to "no/abort", and if confirm=False then it always aborts
                • if the signature is valid, we print a prominent "validated" message, so that if it ever goes missing it should be fairly obvious to users that something has changed
                • if the feed has no settings, we parse it and look for its own requirements, then reprocess as above.
                • feeds without a requires_signature get a subtle warning - something like "skipping verification". This is to help discoverability of the feature for custom feed owners, without making it seem like an unverified feed is inherently problematic
                The aim is to allow us to have secure default settings for the vast majority of our users, without turning the install manager into a proprietary downloader. We embed our certificate details in the client to make it more difficult for an attacker to remove the specification, but allow referencing them from the feed to allow downstreams to more easily enable their own checks. We require OS verification to handle certificate revocation, rather than trying to do it ourselves, but allow (optional) restricting the certificate to prevent an attacker switching the client's expectations. We use Authenticode rather than another mechanism because our code signing certificate is our best protected secret, and so the level of trust matches between the binaries we provide and our index.
                And just to be clear, there is no evidence that anyone has attempted to hijack our index, and this issue is not motivated by any recent reports towards Python. It is motivated by our assessment of the ecosystem right now, and the fact that multiple recent supply chain attacks have targeted download pages and tools of popular software, and so (along with other procedural measures), we want to make sure that Python stays ahead of the attackers.
                Footnotes
                1. The EKU is an identifying marker added by Azure Trusted Signing that lets us use their root certificate name and our EKU to validate ↩
                Metadata
                Metadata
                Assignees
                Labels
                enhancementNew feature or request
                Projects
                No projects
                  Milestone
                  No milestone
                  Relationships
                  None yet
                  Development
                  No branches or pull requests
                  Issue actions