what exactly does `wheel keygen` w/ `sign` do?
So I'm trying to be a good Python project owner for https://github.com/brettcannon/caniusepython3 so that means wanting to produce a universal wheel. While reading up on exactly what is needed I noticed there is `wheel keygen` which feeds `wheel sign`. But what exactly is the keygen producing? I'm assuming it's a private/public key but there is nothing about where those keys are stored, if I should keep them when I change machines, etc. And if this is PKI then I would assume I would want to get my public key signed by others in some web-of-trust to make sure that the signing is more than just a content hash. I do have a public/private GPG key from years ago when I tried to do the right thing and got it signed at PyCon, but once again the wheel docs don't say anything about GPG or reusing keys, etc. The wheel docs are so non-committal it makes it feel like that whatever `gpg keygen` produces is really not some performance shortcut and not really something to care about perpetuating the output of. So am I missing something or is `wheel keygen` just an optimization?
On Feb 21, 2014, at 2:11 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
So I'm trying to be a good Python project owner for https://github.com/brettcannon/caniusepython3 so that means wanting to produce a universal wheel. While reading up on exactly what is needed I noticed there is `wheel keygen` which feeds `wheel sign`.
But what exactly is the keygen producing? I'm assuming it's a private/public key but there is nothing about where those keys are stored, if I should keep them when I change machines, etc. And if this is PKI then I would assume I would want to get my public key signed by others in some web-of-trust to make sure that the signing is more than just a content hash. I do have a public/private GPG key from years ago when I tried to do the right thing and got it signed at PyCon, but once again the wheel docs don't say anything about GPG or reusing keys, etc. The wheel docs are so non-committal it makes it feel like that whatever `gpg keygen` produces is really not some performance shortcut and not really something to care about perpetuating the output of.
So am I missing something or is `wheel keygen` just an optimization? _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
In my opinion Wheel key signing is pointless. It has no trust model based with it and it’s Wheel specific. Right now there’s not a lot of benefit to signing but I would use the gpg signing that’s build into distutils. It’s generic and works across all file types. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Well, I'll at least use what twine supports. =) On Fri, Feb 21, 2014 at 2:17 PM, Donald Stufft <donald@stufft.io> wrote:
On Feb 21, 2014, at 2:11 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
So I'm trying to be a good Python project owner for https://github.com/brettcannon/caniusepython3 so that means wanting to produce a universal wheel. While reading up on exactly what is needed I noticed there is `wheel keygen` which feeds `wheel sign`.
But what exactly is the keygen producing? I'm assuming it's a private/public key but there is nothing about where those keys are stored, if I should keep them when I change machines, etc. And if this is PKI then I would assume I would want to get my public key signed by others in some web-of-trust to make sure that the signing is more than just a content hash. I do have a public/private GPG key from years ago when I tried to do the right thing and got it signed at PyCon, but once again the wheel docs don't say anything about GPG or reusing keys, etc. The wheel docs are so non-committal it makes it feel like that whatever `gpg keygen` produces is really not some performance shortcut and not really something to care about perpetuating the output of.
So am I missing something or is `wheel keygen` just an optimization? _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
In my opinion Wheel key signing is pointless. It has no trust model based with it and it’s Wheel specific. Right now there’s not a lot of benefit to signing but I would use the gpg signing that’s build into distutils. It’s generic and works across all file types.
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Twine just uses gpg like distutils upload does. It’ll even do the signing for you if you want. twine upload -s dist/* On Feb 21, 2014, at 3:02 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
Well, I'll at least use what twine supports. =)
On Fri, Feb 21, 2014 at 2:17 PM, Donald Stufft <donald@stufft.io> wrote:
On Feb 21, 2014, at 2:11 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
So I'm trying to be a good Python project owner for https://github.com/brettcannon/caniusepython3 so that means wanting to produce a universal wheel. While reading up on exactly what is needed I noticed there is `wheel keygen` which feeds `wheel sign`.
But what exactly is the keygen producing? I'm assuming it's a private/public key but there is nothing about where those keys are stored, if I should keep them when I change machines, etc. And if this is PKI then I would assume I would want to get my public key signed by others in some web-of-trust to make sure that the signing is more than just a content hash. I do have a public/private GPG key from years ago when I tried to do the right thing and got it signed at PyCon, but once again the wheel docs don't say anything about GPG or reusing keys, etc. The wheel docs are so non-committal it makes it feel like that whatever `gpg keygen` produces is really not some performance shortcut and not really something to care about perpetuating the output of.
So am I missing something or is `wheel keygen` just an optimization? _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
In my opinion Wheel key signing is pointless. It has no trust model based with it and it’s Wheel specific. Right now there’s not a lot of benefit to signing but I would use the gpg signing that’s build into distutils. It’s generic and works across all file types.
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Well, the docs gave the gpg command to use and made the good point that doing so meant not typing your GPG passphrase into a strange app. Anyway, https://pypi.python.org/pypi/caniusepython3 is now live and has both an sdist and universal wheel which are both signed with my creaky GPG key. On Fri, Feb 21, 2014 at 3:16 PM, Donald Stufft <donald@stufft.io> wrote:
Twine just uses gpg like distutils upload does. It’ll even do the signing for you if you want.
twine upload -s dist/*
On Feb 21, 2014, at 3:02 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
Well, I'll at least use what twine supports. =)
On Fri, Feb 21, 2014 at 2:17 PM, Donald Stufft <donald@stufft.io> wrote:
On Feb 21, 2014, at 2:11 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
So I'm trying to be a good Python project owner for https://github.com/brettcannon/caniusepython3 so that means wanting to produce a universal wheel. While reading up on exactly what is needed I noticed there is `wheel keygen` which feeds `wheel sign`.
But what exactly is the keygen producing? I'm assuming it's a private/public key but there is nothing about where those keys are stored, if I should keep them when I change machines, etc. And if this is PKI then I would assume I would want to get my public key signed by others in some web-of-trust to make sure that the signing is more than just a content hash. I do have a public/private GPG key from years ago when I tried to do the right thing and got it signed at PyCon, but once again the wheel docs don't say anything about GPG or reusing keys, etc. The wheel docs are so non-committal it makes it feel like that whatever `gpg keygen` produces is really not some performance shortcut and not really something to care about perpetuating the output of.
So am I missing something or is `wheel keygen` just an optimization? _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
In my opinion Wheel key signing is pointless. It has no trust model based with it and it’s Wheel specific. Right now there’s not a lot of benefit to signing but I would use the gpg signing that’s build into distutils. It’s generic and works across all file types.
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Woot On Fri, Feb 21, 2014 at 3:32 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
Well, the docs gave the gpg command to use and made the good point that doing so meant not typing your GPG passphrase into a strange app. Anyway, https://pypi.python.org/pypi/caniusepython3 is now live and has both an sdist and universal wheel which are both signed with my creaky GPG key.
On Fri, Feb 21, 2014 at 3:16 PM, Donald Stufft <donald@stufft.io> wrote:
Twine just uses gpg like distutils upload does. It'll even do the signing for you if you want.
twine upload -s dist/*
On Feb 21, 2014, at 3:02 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
Well, I'll at least use what twine supports. =)
On Fri, Feb 21, 2014 at 2:17 PM, Donald Stufft <donald@stufft.io> wrote:
On Feb 21, 2014, at 2:11 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
So I'm trying to be a good Python project owner for https://github.com/brettcannon/caniusepython3 so that means wanting to produce a universal wheel. While reading up on exactly what is needed I noticed there is `wheel keygen` which feeds `wheel sign`.
But what exactly is the keygen producing? I'm assuming it's a private/public key but there is nothing about where those keys are stored, if I should keep them when I change machines, etc. And if this is PKI then I would assume I would want to get my public key signed by others in some web-of-trust to make sure that the signing is more than just a content hash. I do have a public/private GPG key from years ago when I tried to do the right thing and got it signed at PyCon, but once again the wheel docs don't say anything about GPG or reusing keys, etc. The wheel docs are so non-committal it makes it feel like that whatever `gpg keygen` produces is really not some performance shortcut and not really something to care about perpetuating the output of.
So am I missing something or is `wheel keygen` just an optimization? _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
In my opinion Wheel key signing is pointless. It has no trust model based with it and it's Wheel specific. Right now there's not a lot of benefit to signing but I would use the gpg signing that's build into distutils. It's generic and works across all file types.
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Yea it does that too :) I was just being too lazy to type the docs out again :) On Feb 21, 2014, at 3:32 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
Well, the docs gave the gpg command to use and made the good point that doing so meant not typing your GPG passphrase into a strange app. Anyway, https://pypi.python.org/pypi/caniusepython3 is now live and has both an sdist and universal wheel which are both signed with my creaky GPG key.
On Fri, Feb 21, 2014 at 3:16 PM, Donald Stufft <donald@stufft.io> wrote: Twine just uses gpg like distutils upload does. It’ll even do the signing for you if you want.
twine upload -s dist/*
On Feb 21, 2014, at 3:02 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
Well, I'll at least use what twine supports. =)
On Fri, Feb 21, 2014 at 2:17 PM, Donald Stufft <donald@stufft.io> wrote:
On Feb 21, 2014, at 2:11 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
So I'm trying to be a good Python project owner for https://github.com/brettcannon/caniusepython3 so that means wanting to produce a universal wheel. While reading up on exactly what is needed I noticed there is `wheel keygen` which feeds `wheel sign`.
But what exactly is the keygen producing? I'm assuming it's a private/public key but there is nothing about where those keys are stored, if I should keep them when I change machines, etc. And if this is PKI then I would assume I would want to get my public key signed by others in some web-of-trust to make sure that the signing is more than just a content hash. I do have a public/private GPG key from years ago when I tried to do the right thing and got it signed at PyCon, but once again the wheel docs don't say anything about GPG or reusing keys, etc. The wheel docs are so non-committal it makes it feel like that whatever `gpg keygen` produces is really not some performance shortcut and not really something to care about perpetuating the output of.
So am I missing something or is `wheel keygen` just an optimization? _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
In my opinion Wheel key signing is pointless. It has no trust model based with it and it’s Wheel specific. Right now there’s not a lot of benefit to signing but I would use the gpg signing that’s build into distutils. It’s generic and works across all file types.
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Hey, I'm just glad that `twine upload dist/*` with the .asc files in that directory did the right thing. Something to mention if you ever decide to update the docs. On Fri, Feb 21, 2014 at 3:34 PM, Donald Stufft <donald@stufft.io> wrote:
Yea it does that too :) I was just being too lazy to type the docs out again :)
On Feb 21, 2014, at 3:32 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
Well, the docs gave the gpg command to use and made the good point that doing so meant not typing your GPG passphrase into a strange app. Anyway, https://pypi.python.org/pypi/caniusepython3 is now live and has both an sdist and universal wheel which are both signed with my creaky GPG key.
On Fri, Feb 21, 2014 at 3:16 PM, Donald Stufft <donald@stufft.io> wrote:
Twine just uses gpg like distutils upload does. It’ll even do the signing for you if you want.
twine upload -s dist/*
On Feb 21, 2014, at 3:02 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
Well, I'll at least use what twine supports. =)
On Fri, Feb 21, 2014 at 2:17 PM, Donald Stufft <donald@stufft.io> wrote:
On Feb 21, 2014, at 2:11 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
So I'm trying to be a good Python project owner for https://github.com/brettcannon/caniusepython3 so that means wanting to produce a universal wheel. While reading up on exactly what is needed I noticed there is `wheel keygen` which feeds `wheel sign`.
But what exactly is the keygen producing? I'm assuming it's a private/public key but there is nothing about where those keys are stored, if I should keep them when I change machines, etc. And if this is PKI then I would assume I would want to get my public key signed by others in some web-of-trust to make sure that the signing is more than just a content hash. I do have a public/private GPG key from years ago when I tried to do the right thing and got it signed at PyCon, but once again the wheel docs don't say anything about GPG or reusing keys, etc. The wheel docs are so non-committal it makes it feel like that whatever `gpg keygen` produces is really not some performance shortcut and not really something to care about perpetuating the output of.
So am I missing something or is `wheel keygen` just an optimization? _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
In my opinion Wheel key signing is pointless. It has no trust model based with it and it’s Wheel specific. Right now there’s not a lot of benefit to signing but I would use the gpg signing that’s build into distutils. It’s generic and works across all file types.
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Fri, Feb 21, 2014 at 2:17 PM, Donald Stufft <donald@stufft.io> wrote:
On Feb 21, 2014, at 2:11 PM, Brett Cannon <brett@yvrsfo.ca> wrote:
So I'm trying to be a good Python project owner for https://github.com/brettcannon/caniusepython3 so that means wanting to produce a universal wheel. While reading up on exactly what is needed I noticed there is `wheel keygen` which feeds `wheel sign`.
But what exactly is the keygen producing? I'm assuming it's a private/public key but there is nothing about where those keys are stored, if I should keep them when I change machines, etc. And if this is PKI then I would assume I would want to get my public key signed by others in some web-of-trust to make sure that the signing is more than just a content hash. I do have a public/private GPG key from years ago when I tried to do the right thing and got it signed at PyCon, but once again the wheel docs don't say anything about GPG or reusing keys, etc. The wheel docs are so non-committal it makes it feel like that whatever `gpg keygen` produces is really not some performance shortcut and not really something to care about perpetuating the output of.
So am I missing something or is `wheel keygen` just an optimization? _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
In my opinion Wheel key signing is pointless. It has no trust model based with it and it's Wheel specific. Right now there's not a lot of benefit to signing but I would use the gpg signing that's build into distutils. It's generic and works across all file types.
'wheel keygen' creates an Ed25519 key that is stored using the Python keyring library; the private key can end up in the system keychain on Mac, the Gnome keychain, or a json file in ~/.config depending on available bindings. The underlying idea was to give people a way to request a package signed by a literal key in the same way that you can request a download has a particular sha digest. But it wasn't developed further. Now we hope the 'tuf' project will be able to deliver useful package signing.
participants (3)
-
Brett Cannon -
Daniel Holth -
Donald Stufft