Add the --trusted option to upload and register commands

[glenfant]

This is explained in issue #387 and helps people who prefer to ignore CA cert issues and skip server certificate verifications.
Any comment is welcome.

Fixes #387.

[glenfant]

Hi, sorry to fix all this so late, but these are done.

[glenfant]

I don't understand this failure. @sigmavirus24 Can you please explain the required fix ?

[bhrutledge]

@glenfant From the link below, it looks like the failure is due to line length. I've made some suggestions to correct it.

https://travis-ci.org/pypa/twine/jobs/541750124#L235-L236

I got here by clicking the "Details" link in the "All checks have failed box" at the bottom of the PR, and then clicking on the "Linting code smells" failure.

[di]

FYI @glenfant you have merge conflicts here.

[glenfant]

Hi @bhrutledge all your comments are taken into account. Ready to merge !
Cheers.

[bhrutledge]

@glenfant Thanks for your continued work on this. However, this PR is now showing a bunch of changes that have already been merged. I don't know how that happened, or how to fix it, but I'm wary of merging this as-is.

If it were me, I'd probably close this PR, create a new branch off a fresh fetch of upstream/master, cherry-pick your changes, and submit a new PR. But there may be a better resolution.

[sigmavirus24]

git rebase would be the better solution. @glenfant let me know if you'd like instructions.

[bhrutledge]

Flagging this as needing changes before merging, namely git rebase.

[bhrutledge]

@glenfant Are you able to do the rebase? If not, a Twine maintainer can probably help and/or do it.

[bhrutledge]

@di has some concerns about this feature: #387 (comment).

[jaraco]

this PR is now showing a bunch of changes that have already been merged. I don't know how that happened

It looks like it may have been me. I didn't intentionally merge, but it looks like in add0aea, I merged in unrelated commits. The solution would be to cherrypick the correct commits without that merge commit. I can do that.

[jaraco]

On further consideration, and looking at the actual commits in glenfant:master, I don't see that commit in his commit history... but what I do see is f54ea50, which merges two heads that seem to be doing the same thing. It looks like a rebase was attempted, then merged with itself... and the way github is detecting the ancestry, it's comparing against the wrong basis.

Now I think the fix is to cherry-pick 8ee8bb2 onto 2da05c4 and then force-push that.

[jaraco]

I've fixed the repo history and resolved the conflicts with recent merges. Still, there's a pending concern about this change, so I'll wait for that to be resolved.

[jaraco]

I think I agree with the sentiments of di. I'd like for this feature to be an ugly hack and not a simple option. What if instead you had this script:

import twine.__main__


def disable_server_certificate_validation():
    "Allow twine to just trust the hosts"
    twine.repository.Repository.set_certificate_authority = lambda *args, **kwargs: None


def main():
    disable_server_certificate_validation()
    twine.__main__.main()

__name__ == '__main__' and main()

Call it twine-trusted and invoke that. We could consider supplying disable_server_certificate_validation with twine (so as to always match the API), but it still requires an ugly hack to invoke, providing the sufficient level of discouragement to make any user seriously consider using it.

[okainov]

Would be great to have it merged, thanks!

[jaraco]

I think the consensus on this issue is that the bypassing of the trusted mode can be readily handled by an intentionally-ugly workaround for environments that require it.

[agates4]

any change of opinion?

this would be a fantastic feature to have.

[sigmavirus24]

No