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

Make it possible to specify alternative certificate chains #142

Merged
merged 1 commit into from Oct 28, 2015

Conversation

Projects
None yet
2 participants
@GregBowyer
Copy link
Contributor

commented Oct 19, 2015

Twine is amazing in that it actually allows the end user to validate the
SSL when items are being uploaded to a specific pypi repository.

Unfortunately, this validation will only occur for the authorities that
are specified in certifi. This limits two important use cases for
internal and none standard pypi servers:

  1. There is no method to use an alternate certificate authority chain,
    such as, for instance, is presented from a custom CA root
  2. There is no method to use client certificates, which can be an
    alternative to username and password.

This commit seeks to redress this, by allowing both of these options to
be specified, with configuration that mirrors that of pip.

@GregBowyer GregBowyer force-pushed the GregBowyer:master branch from 206f329 to e549843 Oct 19, 2015

Make it possible to specify alternative certificate chains
Twine is amazing in that it actually allows the end user to validate the
SSL when items are being uploaded to a specific pypi repository.

Unfortunately, this validation will only occur for the authorities that
are specified in certifi. This limits two important use cases for
internal and none standard pypi servers:

1. There is no method to use an alternate certificate authority chain,
such as, for instance, is presented from a custom CA root

2. There is no method to use client certificates, which can be an
alternative to username and password.

This commit seeks to redress this, by allowing both of these options to
be specified, with configuration that mirrors that of pip.

@GregBowyer GregBowyer force-pushed the GregBowyer:master branch from e549843 to ece3711 Oct 19, 2015

@sigmavirus24

This comment has been minimized.

Copy link
Member

commented Oct 24, 2015

Hey @GregBowyer this is great. Can I make a request for a different way to structure this though?

The certificate root and client certificate information isn't really intrinsic to a Repository object. The Repository object just happens to manage a Session instance from requests. So, I think I'd rather see two methods added that handle this for us:

class Repository(object):
    # ...
    def set_certificate_authority(self, cacert):
        if cacert:
            self.session.verify = cacert

    def set_client_certificate(self, client_cert):
        if client_cert:
            self.session.cert = client_cert

And then have this used as

repository = Repository(config["repository"], username, password)
repository.set_certificate_authority(cacert)
repository.set_client_certificate(client_cert)

I'm anticipating that people are using (or will start using twine) as a library as well as a command-line utility. As such, I'd like Repository to be very clean as a public API.

sigmavirus24 added a commit to sigmavirus24/twine that referenced this pull request Oct 28, 2015

@sigmavirus24 sigmavirus24 merged commit ece3711 into pypa:master Oct 28, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@sigmavirus24 sigmavirus24 modified the milestone: next Oct 28, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.