Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to handle a list of binary caches where some are signed and others aren't #1819

Closed
AmineChikhaoui opened this issue Jan 26, 2018 · 3 comments

Comments

@AmineChikhaoui
Copy link
Member

If I have a list of binary caches e.g s3://foo s3://bar and foo is signed while bar isn't.
It seems that right now if I have a require-sigs = true in my nix config, that will still try to check the signature for s3://bar paths which doesn't really make sense.

    /* Bail out early if this substituter lacks a valid
       signature. LocalStore::addToStore() also checks for this, but
       only after we've downloaded the path. */
    if (worker.store.requireSigs && !info->checkSignatures(worker.store, worker.store.publicKeys)) {
        printInfo(format("warning: substituter '%s' does not have a valid signature for path '%s'")
            % sub->getUri() % storePath);
        tryNext();
        return;
    }

Maybe a better approach would be to do signature validation per binary cache, i.e have some kind of mapping between binary cache/public key/require-sigs.

@copumpkin
Copy link
Member

I think that at some point (maybe only in the past) require-sigs was allowed on individual store URIs as well. @edolstra am I imagining that?

@edolstra
Copy link
Member

@copumpkin You may be thinking of signed-binary-caches, however it never actually supported individual URIs (it could only be * or an empty string).

@edolstra
Copy link
Member

@AmineChikhaoui Well, the model is that addToStore() doesn't know where a NAR comes from, so it cannot whilelist certain substituters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants