On Jan 2, 2015, at 3:21 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 2 January 2015 at 16:38, Donald Stufft don...@stufft.io
mailto:don...@stufft.io wrote:
On Jan 2, 2015, at 1:33 AM, Nick Coghlan ncogh...@gmail.com
mailto:ncogh...@gmail.com wrote:
That's the part I meant - the
On Jan 2, 2015, at 7:45 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 2 January 2015 at 11:21, Donald Stufft don...@stufft.io wrote:
To be clear, there is zero delay in being able to publish a new project, the
delay is between moving from a new project being validated by an online key
to an
On 2 January 2015 at 11:21, Donald Stufft don...@stufft.io wrote:
To be clear, there is zero delay in being able to publish a new project, the
delay is between moving from a new project being validated by an online key
to an offline key.
OK, got it.
Although on the terminology front, I don't
On 2 January 2015 at 16:38, Donald Stufft don...@stufft.io wrote:
On Jan 2, 2015, at 1:33 AM, Nick Coghlan ncogh...@gmail.com wrote:
That's the part I meant - the signing of developer keys to delegate trust
to them without needing to trust the integrity of the online PyPI service.
Hence
On Jan 2, 2015, at 6:04 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 2 January 2015 at 06:38, Donald Stufft don...@stufft.io wrote:
Developer keys get signed by offline keys controlled by I’m guessing either
myself or Richard or both.
One thought here. The issue being discussed here
On 2 January 2015 at 06:38, Donald Stufft don...@stufft.io wrote:
Developer keys get signed by offline keys controlled by I’m guessing either
myself or Richard or both.
One thought here. The issue being discussed here seems mainly to be
that it's hard to manage signing of developer keys. That's
On 2 January 2015 at 18:57, Donald Stufft don...@stufft.io wrote:
I have concerns about the actual feasibility of doing such a thing, some
of which are similar to my concerns with doing non-mandatory PEP 480.
* If uploading to a verifier service is optional then a significant
portion of
On 3 January 2015 at 00:25, Donald Stufft don...@stufft.io wrote:
On Dec 10, 2014, at 10:16 PM, Vladimir Diaz vladimir.v.d...@gmail.com
wrote:
Hello everyone,
I am a research programmer at the NYU School of Engineering. My
colleagues (Trishank Kuppusamy and Justin Cappos) and I are
On Dec 10, 2014, at 10:16 PM, Vladimir Diaz vladimir.v.d...@gmail.com wrote:
Hello everyone,
I am a research programmer at the NYU School of Engineering. My colleagues
(Trishank Kuppusamy and Justin Cappos) and I are requesting community
feedback on our proposal, Surviving a
On 2 January 2015 at 14:25, Donald Stufft don...@stufft.io wrote:
I’m going through the PEPs again, and I think that evaluating these PEPs is
more complicated by the fact that there is two of them, I agree that
splitting
up the two PEPs was the right thing to do though. What do you think about
On 3 January 2015 at 01:31, Paul Moore p.f.mo...@gmail.com wrote:
On 2 January 2015 at 14:25, Donald Stufft don...@stufft.io wrote:
Either way though, I suggest focus on PEP 458 (with an eye towards not
making any decisions which will require changes on the client side to
implement
PEP
On Jan 2, 2015, at 10:51 AM, Nick Coghlan ncogh...@gmail.com wrote:
Getting them to manage additional keys, and get them signed and registered
appropriately, and then supplying them is going to be a similar amount of
work, and the purpose is far more cryptic and confusing. My proposal is
On Jan 2, 2015, at 9:55 AM, Nick Coghlan ncogh...@gmail.com wrote:
I just don't personally have any major open questions for PEP 458 - while I'm
aware there are some significant technical details to be resolved in terms of
exactly what gets signed, and how the implementation will work in
Thanks for the great feedback - Nick, Donald, Paul, and Richard (off-list).
I am totally fine with focusing on PEP 458 and applying the final coat of
paint on this document.
There's a lot of background documentation and technical details excluded
from the PEPs (to avoid turning the PEP into a
On 2 January 2015 at 16:14, Vladimir Diaz vladimir.v.d...@gmail.com wrote:
There's a lot of background documentation and technical details excluded
from the PEPs (to avoid turning the PEP into a 15+ page behemoth), but I do
agree that we should explicitly cover some of these implementation
On 3 January 2015 at 02:12, Donald Stufft don...@stufft.io wrote:
On Jan 2, 2015, at 10:51 AM, Nick Coghlan ncogh...@gmail.com wrote:
Getting them to manage additional keys, and get them signed and registered
appropriately, and then supplying them is going to be a similar amount of
work,
I prefer pulling the TUF PEPs (available on hg.python.org) into
github.com/pypa.
Please add Justin, Linda, Trishank, and myself as collaborators:
https://github.com/vladimir-v-diaz
https://github.com/dachshund
https://github.com/JustinCappos
https://github.com/lvigdor
P.S. Donald helped
On 3 January 2015 at 02:26, Donald Stufft don...@stufft.io wrote:
On Jan 2, 2015, at 11:14 AM, Vladimir Diaz vladimir.v.d...@gmail.com
wrote:
Thanks for the great feedback - Nick, Donald, Paul, and Richard (off-list).
I am totally fine with focusing on PEP 458 and applying the final coat
On Jan 2, 2015, at 11:14 AM, Vladimir Diaz vladimir.v.d...@gmail.com wrote:
Thanks for the great feedback - Nick, Donald, Paul, and Richard (off-list).
I am totally fine with focusing on PEP 458 and applying the final coat of
paint on this document.
There's a lot of background
On Jan 2, 2015, at 11:47 AM, Vladimir Diaz vladimir.v.d...@gmail.com wrote:
I prefer pulling the TUF PEPs (available on hg.python.org
http://hg.python.org/) into github.com/pypa http://github.com/pypa.
Please add Justin, Linda, Trishank, and myself as collaborators:
On Wed, Dec 31, 2014 at 2:51 PM, Donald Stufft don...@stufft.io wrote:
On Dec 31, 2014, at 11:08 AM, Vladimir Diaz vladimir.v.d...@gmail.com
wrote:
On Wed, Dec 31, 2014 at 2:26 AM, Donald Stufft don...@stufft.io wrote:
On Dec 10, 2014, at 10:16 PM, Vladimir Diaz
On 1 January 2015 at 05:51, Donald Stufft don...@stufft.io wrote:
So here is my problem. I’m completely on board with the developer signing
for the distribution files. I think that makes total sense. However I worry
that requiring the developer to sign for what is essentially the
“installer”
On Jan 2, 2015, at 1:33 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 2 January 2015 at 16:13, Donald Stufft don...@stufft.io
mailto:don...@stufft.io wrote:
On Jan 2, 2015, at 12:57 AM, Nick Coghlan ncogh...@gmail.com
mailto:ncogh...@gmail.com wrote:
To raise the cost of a
On 2 January 2015 at 16:13, Donald Stufft don...@stufft.io wrote:
On Jan 2, 2015, at 12:57 AM, Nick Coghlan ncogh...@gmail.com wrote:
To raise the cost of a compromise through distributed signing authority,
we have to solve the trust management problem - getting developer keys out
to end
On Jan 2, 2015, at 12:57 AM, Nick Coghlan ncogh...@gmail.com wrote:
To raise the cost of a compromise through distributed signing authority, we
have to solve the trust management problem - getting developer keys out to
end users in a way that doesn't involve trusting the central PyPI
In the PEP 458 world, package authors are not required to do anything.
On Wed, Dec 31, 2014 at 11:54 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 31 December 2014 at 16:08, Vladimir Diaz vladimir.v.d...@gmail.com
wrote:
Let me know exactly what needs to change in the PEPs to make everything
On Dec 31, 2014, at 1:04 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 31 December 2014 at 17:43, Vladimir Diaz vladimir.v.d...@gmail.com wrote:
PEP 480 includes a section that discusses a potential approach to packages
signed by package authors:
On 31 December 2014 at 18:42, Donald Stufft don...@stufft.io wrote:
Just to speak to these two points. The purpose behind having a developer
sign some files is that you can verify that those files were signed by
the person holding the private key belonging to that developer.
[...]
Thanks for
On Dec 31, 2014, at 2:05 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 31 December 2014 at 18:42, Donald Stufft don...@stufft.io wrote:
Just to speak to these two points. The purpose behind having a developer
sign some files is that you can verify that those files were signed by
the person
On Dec 31, 2014, at 11:08 AM, Vladimir Diaz vladimir.v.d...@gmail.com wrote:
On Wed, Dec 31, 2014 at 2:26 AM, Donald Stufft don...@stufft.io
mailto:don...@stufft.io wrote:
On Dec 10, 2014, at 10:16 PM, Vladimir Diaz vladimir.v.d...@gmail.com
mailto:vladimir.v.d...@gmail.com
On 23 December 2014 at 04:15, Vladimir Diaz vladimir.v.d...@gmail.com
wrote:
On Mon, Dec 22, 2014 at 11:30 AM, Nick Coghlan ncogh...@gmail.com wrote:
From my perspective, the split into two PEPs meant most of the areas I
have doubts about have been moved to the end-to-end security model in
On Dec 30, 2014, at 9:29 PM, Richard Jones rich...@python.org wrote:
Thanks for the clarification, guys.
Donald, I'm not sure what you mean by a compromise of the CDN for
*uploading*”.
PyPI trusts the CDN to give it the correct bits, without a signature from the
author that is being
Thanks for the clarification, guys.
Donald, I'm not sure what you mean by a compromise of the CDN for
*uploading*.
On Wed Dec 31 2014 at 1:21:18 PM Donald Stufft don...@stufft.io wrote:
On Dec 30, 2014, at 8:24 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 23 December 2014 at 04:15,
On 31 December 2014 at 12:32, Donald Stufft don...@stufft.io wrote:
PyPI trusts the CDN to give it the correct bits, without a signature from
the author that is being verified uploading just relies on TLS again. The
other PEP should close that gap though I believe.
I'm actually not sure what
Now that I think about it, I'm almost certain that Donald and I have had
the hey, what about an upload.pypi.python.org conversation in the past,
as a way around issues involving the CDN :)
Still a good idea, in my opinion.
Richard
On Wed Dec 31 2014 at 3:01:53 PM Nick Coghlan
On Dec 10, 2014, at 10:16 PM, Vladimir Diaz vladimir.v.d...@gmail.com wrote:
Hello everyone,
I am a research programmer at the NYU School of Engineering. My colleagues
(Trishank Kuppusamy and Justin Cappos) and I are requesting community
feedback on our proposal, Surviving a
On Dec 22, 2014, at 1:15 PM, Vladimir Diaz vladimir.v.d...@gmail.com wrote:
On Mon, Dec 22, 2014 at 11:30 AM, Nick Coghlan ncogh...@gmail.com
mailto:ncogh...@gmail.com wrote:
On 23 December 2014 at 01:46, Vladimir Diaz vladimir.v.d...@gmail.com
mailto:vladimir.v.d...@gmail.com wrote:
::ping::
Has anyone in the community gotten a chance to review PEP 458 and/or PEP
480? Community feedback would be appreciated.
Thanks,
Vlad
On Wed, Dec 10, 2014 at 10:16 PM, Vladimir Diaz vladimir.v.d...@gmail.com
wrote:
Hello everyone,
I am a research programmer at the NYU School of
On 23 December 2014 at 01:46, Vladimir Diaz vladimir.v.d...@gmail.com
wrote:
::ping::
Has anyone in the community gotten a chance to review PEP 458 and/or PEP
480? Community feedback would be appreciated.
Sorry about that Vladimir - I think the main PyPA devs have been focused on
getting
On Mon, Dec 22, 2014 at 11:30 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 23 December 2014 at 01:46, Vladimir Diaz vladimir.v.d...@gmail.com
wrote:
::ping::
Has anyone in the community gotten a chance to review PEP 458 and/or PEP
480? Community feedback would be appreciated.
Sorry
Hello everyone,
I am a research programmer at the NYU School of Engineering. My colleagues
(Trishank Kuppusamy and Justin Cappos) and I are requesting community
feedback on our proposal, Surviving a Compromise of PyPI. The two-stage
proposal can be reviewed online at:
PEP 458
41 matches
Mail list logo
