From techtonik at gmail.com Sat Nov 3 16:26:50 2012
From: techtonik at gmail.com (anatoly techtonik)
Date: Sat, 3 Nov 2012 18:26:50 +0300
Subject: [Catalog-sig] Traceback when removing SSH key
Message-ID: <CAPkN8xK9D881WobCOrjT0b4wAY4T4e-qx2GM70_SuQBZnZf5QA@mail.gmail.com>
I thought you'd be interested to know
Error processing form
Key processing failed. Please contact the administrator. Detail:
Traceback (most recent call last):
File "/data/pypi/sshkeys_update.py", line 4, in <module>
c = config.Config("config.ini")
File "/data/pypi/config.py", line 10, in __init__
self.database_name = c.get('database', 'name')
File "/usr/lib/python2.7/ConfigParser.py", line 607, in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'database'
Please, CC.
--
anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121103/be1baab2/attachment.html>
From techtonik at gmail.com Sat Nov 3 18:02:18 2012
From: techtonik at gmail.com (anatoly techtonik)
Date: Sat, 3 Nov 2012 20:02:18 +0300
Subject: [Catalog-sig] Still no easy way to secure upload packages to PyPI
Message-ID: <CAPkN8xLkLkdnfGi=H=HQ5mVqk-ZhM8szuLLe_jYJtw8pr5zt9w@mail.gmail.com>
CC: catalog-sig
`setup.py register` still fails when I specify secure
https://pypi.python.org/pypi URL
http://bugs.python.org/issue13615
It's also a very bad situation that PyPI encourages to use heavy
monkey-patching libraries like http://pypi.python.org/pypi/pypissh I
definitely don't want to have more problems with distutils with this
monkeypatching, neither seeing monkeypatching as an official practice.
--
anatoly t.
From pior at mtlpy.org Tue Nov 6 15:14:51 2012
From: pior at mtlpy.org (Pior Bastida)
Date: Tue, 6 Nov 2012 09:14:51 -0500
Subject: [Catalog-sig] Traceback when removing SSH key
In-Reply-To: <CAPkN8xK9D881WobCOrjT0b4wAY4T4e-qx2GM70_SuQBZnZf5QA@mail.gmail.com>
References: <CAPkN8xK9D881WobCOrjT0b4wAY4T4e-qx2GM70_SuQBZnZf5QA@mail.gmail.com>
Message-ID: <CAJA7-OekT8wyUkco1FWE21+mvtznHw4HR7KXCUUnAoMgvK9qTw@mail.gmail.com>
The same when I tried to import my ssh key.
On Sat, Nov 3, 2012 at 11:26 AM, anatoly techtonik <techtonik at gmail.com>wrote:
> I thought you'd be interested to know
>
> Error processing form
>
> Key processing failed. Please contact the administrator. Detail: Traceback (most recent call last):
> File "/data/pypi/sshkeys_update.py", line 4, in <module>
> c = config.Config("config.ini")
> File "/data/pypi/config.py", line 10, in __init__
> self.database_name = c.get('database', 'name')
> File "/usr/lib/python2.7/ConfigParser.py", line 607, in get
> raise NoSectionError(section)
> ConfigParser.NoSectionError: No section: 'database'
>
>
> Please, CC.
> --
> anatoly t.
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
>
--
Pior Bastida
pior at mtlpy.org
Org Montr?al-Python
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121106/9dbab05c/attachment.html>
From tseaver at palladion.com Mon Nov 12 20:06:00 2012
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 12 Nov 2012 14:06:00 -0500
Subject: [Catalog-sig] Any recent changes to the cheeshop infrastructure?
Message-ID: <k7rhcp$td9$1@ger.gmane.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sprinting today at PyConCA: we are seeing *super* slow installs today,
including taking many minutes (and failing) to install nose / coverage.
One sprint participant had heard a rumor that the Cheeseshop had "moved
into the cloud": we are wondering if our issue is somehow connected.
Thanks!
Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver at palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlChSJgACgkQ+gerLs4ltQ4xLwCaAuBDQV1HNq1Fn5h3+MVDDAIn
MDcAnizv7QQUVa+QCSvH5giZ3Cz7kz5G
=0nVB
-----END PGP SIGNATURE-----
From noah at coderanger.net Mon Nov 12 20:23:04 2012
From: noah at coderanger.net (Noah Kantrowitz)
Date: Mon, 12 Nov 2012 11:23:04 -0800
Subject: [Catalog-sig] Any recent changes to the cheeshop infrastructure?
In-Reply-To: <k7rhcp$td9$1@ger.gmane.org>
References: <k7rhcp$td9$1@ger.gmane.org>
Message-ID: <1BCC4C5F-BC03-4571-868D-1F97F6CDB681@coderanger.net>
Nothing recent, and the box looks fine. Currently pushing 60Mbit so perhaps it is something about the hotel wifi (proxy or bottleneck restrictions?)
The cloud bit is that it was moved to the PSF private cloud but that was quite a while ago.
--Noah
On Nov 12, 2012, at 11:06 AM, Tres Seaver wrote:
> Sprinting today at PyConCA: we are seeing *super* slow installs today,
> including taking many minutes (and failing) to install nose / coverage.
>
> One sprint participant had heard a rumor that the Cheeseshop had "moved
> into the cloud": we are wondering if our issue is somehow connected.
>
> Thanks!
>
>
> Tres.
> - --
> ===================================================================
> Tres Seaver +1 540-429-0999 tseaver at palladion.com
> Palladion Software "Excellence by Design" http://palladion.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121112/390d1a88/attachment.pgp>
From tseaver at palladion.com Mon Nov 12 21:24:15 2012
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 12 Nov 2012 15:24:15 -0500
Subject: [Catalog-sig] Any recent changes to the cheeshop infrastructure?
In-Reply-To: <1BCC4C5F-BC03-4571-868D-1F97F6CDB681@coderanger.net>
References: <k7rhcp$td9$1@ger.gmane.org>
<1BCC4C5F-BC03-4571-868D-1F97F6CDB681@coderanger.net>
Message-ID: <50A15AEF.2060605@palladion.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/12/2012 02:23 PM, Noah Kantrowitz wrote:
> Nothing recent, and the box looks fine. Currently pushing 60Mbit so
> perhaps it is something about the hotel wifi (proxy or bottleneck
> restrictions?)
Maybe so. It seems oddly local to PyPI, however (mail, IRC, web browsing
all seem fine).
> The cloud bit is that it was moved to the PSF private cloud but that
> was quite a while ago.
OK, thanks for the info. We'll battle on. :)
Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver at palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlChWu8ACgkQ+gerLs4ltQ7rIgCfd/mmydToqaS44EdCtOFLcl/A
ABwAmgMn+AOzH4zvXEPeORZ2OyJ2T/sa
=OPcX
-----END PGP SIGNATURE-----
From ncoghlan at gmail.com Tue Nov 13 03:04:33 2012
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 13 Nov 2012 12:04:33 +1000
Subject: [Catalog-sig] [Python-Dev] accept the wheel PEPs 425, 426, 427
In-Reply-To: <CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<CAPZV6o8=Uk5zn+f7kGCs6cFQnq50Nd46yOpu9FMwu4p6ctbE4A@mail.gmail.com>
<20121018211014.73d56057@pitrou.net>
<CAG8k2+6oALhohqOePU-yJYBA=Hr=FjqzGJJ1g5Ah3pjR+fCuGA@mail.gmail.com>
<CAPZV6o9nC+7CsOhvE5pyp_u_cKoaKhGzPJXNgFoTDqNkbkJZkg@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
Message-ID: <CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth <dholth at gmail.com> wrote:
> I think Metadata 1.3 is done. Who would like to czar?
>
(Apologies for the belated reply, it's been a busy few weeks)
I'm happy to be BDFL delegate for these. I'd like to see PEP 425 updated
with some additional rationale based on Ronald's comments later in this
thread, though.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121113/287b4dca/attachment.html>
From martin at v.loewis.de Tue Nov 13 07:21:42 2012
From: martin at v.loewis.de (martin at v.loewis.de)
Date: Tue, 13 Nov 2012 07:21:42 +0100
Subject: [Catalog-sig] Any recent changes to the cheeshop infrastructure?
In-Reply-To: <k7rhcp$td9$1@ger.gmane.org>
References: <k7rhcp$td9$1@ger.gmane.org>
Message-ID: <20121113072142.Horde.04ZlfcL8999Qoeb20joEQZA@webmail.df.eu>
Zitat von Tres Seaver <tseaver at palladion.com>:
> Sprinting today at PyConCA: we are seeing *super* slow installs today,
> including taking many minutes (and failing) to install nose / coverage.
>
> One sprint participant had heard a rumor that the Cheeseshop had "moved
> into the cloud": we are wondering if our issue is somehow connected.
These are rumors only, nothing has changed. If you notice such things,
please note the exact time (UTC) at which it happened for investigation.
Regards,
Martin
From martin at v.loewis.de Tue Nov 13 10:51:04 2012
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 13 Nov 2012 10:51:04 +0100
Subject: [Catalog-sig] [Python-Dev] accept the wheel PEPs 425, 426, 427
In-Reply-To: <CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<20121018211014.73d56057@pitrou.net>
<CAG8k2+6oALhohqOePU-yJYBA=Hr=FjqzGJJ1g5Ah3pjR+fCuGA@mail.gmail.com>
<CAPZV6o9nC+7CsOhvE5pyp_u_cKoaKhGzPJXNgFoTDqNkbkJZkg@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
Message-ID: <50A21808.8040909@v.loewis.de>
Am 13.11.12 03:04, schrieb Nick Coghlan:
> On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth <dholth at gmail.com
> <mailto:dholth at gmail.com>> wrote:
>
> I think Metadata 1.3 is done. Who would like to czar?
>
> (Apologies for the belated reply, it's been a busy few weeks)
>
> I'm happy to be BDFL delegate for these. I'd like to see PEP 425 updated
> with some additional rationale based on Ronald's comments later in this
> thread, though.
For the record, I'm still -1 on PEP 427, because of the signature issues.
The FAQ in the PEP is incorrect in claiming PGP or X.509 cannot
readily be used to verify the integrity of an archive - the whole
point of these technologies is to do exactly that.
The FAQ is entirely silent on why it is not using a more standard
signature algorithm such as ECDSA. It explains why it uses Ed25519,
but ignores that the very same rationale would apply to ECDSA as well;
plus that would be one of the standard JWS algorithms.
In addition, the FAQ claims that the format is designed to introduce
cryptopgraphy that is actually used, yet leaves the issue of key
distribution alone (except that pointing out that you can put them
into requires.txt - a file that doesn't seem to be specified anywhere).
Regards,
Martin
From mal at egenix.com Tue Nov 13 11:26:50 2012
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 13 Nov 2012 11:26:50 +0100
Subject: [Catalog-sig] [Python-Dev] accept the wheel PEPs 425, 426, 427
In-Reply-To: <50A21808.8040909@v.loewis.de>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<20121018211014.73d56057@pitrou.net>
<CAG8k2+6oALhohqOePU-yJYBA=Hr=FjqzGJJ1g5Ah3pjR+fCuGA@mail.gmail.com>
<CAPZV6o9nC+7CsOhvE5pyp_u_cKoaKhGzPJXNgFoTDqNkbkJZkg@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de>
Message-ID: <50A2206A.40804@egenix.com>
On 13.11.2012 10:51, "Martin v. L?wis" wrote:
> Am 13.11.12 03:04, schrieb Nick Coghlan:
>> On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth <dholth at gmail.com
>> <mailto:dholth at gmail.com>> wrote:
>>
>> I think Metadata 1.3 is done. Who would like to czar?
>>
>> (Apologies for the belated reply, it's been a busy few weeks)
>>
>> I'm happy to be BDFL delegate for these. I'd like to see PEP 425 updated
>> with some additional rationale based on Ronald's comments later in this
>> thread, though.
>
> For the record, I'm still -1 on PEP 427, because of the signature issues.
>
> The FAQ in the PEP is incorrect in claiming PGP or X.509 cannot
> readily be used to verify the integrity of an archive - the whole
> point of these technologies is to do exactly that.
>
> The FAQ is entirely silent on why it is not using a more standard
> signature algorithm such as ECDSA. It explains why it uses Ed25519,
> but ignores that the very same rationale would apply to ECDSA as well;
> plus that would be one of the standard JWS algorithms.
>
> In addition, the FAQ claims that the format is designed to introduce
> cryptopgraphy that is actually used, yet leaves the issue of key
> distribution alone (except that pointing out that you can put them
> into requires.txt - a file that doesn't seem to be specified anywhere).
I agree with Martin. If the point is to "to protect against cryptography
that is not used", then not using the de-facto standard in signing
open source distribution files, which today is PGP/GPG, misses that
point :-)
Note that signing such distribution files can be handled outside
of the wheel format PEP. It just way to complex and out of scope
for the wheel format itself. Also note that PGP/GPG and the other
signing tools work well on any distribution file. There's really no
need to build these into the format itself.
It's a good idea to check integrity, but that can be done using
hashes.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Nov 13 2012)
>>> Python Projects, Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
From dholth at gmail.com Tue Nov 13 16:00:26 2012
From: dholth at gmail.com (Daniel Holth)
Date: Tue, 13 Nov 2012 10:00:26 -0500
Subject: [Catalog-sig] [Distutils] [Python-Dev] accept the wheel PEPs
425, 426, 427
In-Reply-To: <50A2206A.40804@egenix.com>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<20121018211014.73d56057@pitrou.net>
<CAG8k2+6oALhohqOePU-yJYBA=Hr=FjqzGJJ1g5Ah3pjR+fCuGA@mail.gmail.com>
<CAPZV6o9nC+7CsOhvE5pyp_u_cKoaKhGzPJXNgFoTDqNkbkJZkg@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
Message-ID: <CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
On Tue, Nov 13, 2012 at 5:26 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 13.11.2012 10:51, "Martin v. L?wis" wrote:
> > Am 13.11.12 03:04, schrieb Nick Coghlan:
> >> On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth <dholth at gmail.com
> >> <mailto:dholth at gmail.com>> wrote:
> >>
> >> I think Metadata 1.3 is done. Who would like to czar?
> >>
> >> (Apologies for the belated reply, it's been a busy few weeks)
> >>
> >> I'm happy to be BDFL delegate for these. I'd like to see PEP 425 updated
> >> with some additional rationale based on Ronald's comments later in this
> >> thread, though.
> >
> > For the record, I'm still -1 on PEP 427, because of the signature issues.
> >
> > The FAQ in the PEP is incorrect in claiming PGP or X.509 cannot
> > readily be used to verify the integrity of an archive - the whole
> > point of these technologies is to do exactly that.
> >
> > The FAQ is entirely silent on why it is not using a more standard
> > signature algorithm such as ECDSA. It explains why it uses Ed25519,
> > but ignores that the very same rationale would apply to ECDSA as well;
> > plus that would be one of the standard JWS algorithms.
> >
> > In addition, the FAQ claims that the format is designed to introduce
> > cryptopgraphy that is actually used, yet leaves the issue of key
> > distribution alone (except that pointing out that you can put them
> > into requires.txt - a file that doesn't seem to be specified anywhere).
>
> I agree with Martin. If the point is to "to protect against cryptography
> that is not used", then not using the de-facto standard in signing
> open source distribution files, which today is PGP/GPG, misses that
> point :-)
>
> Note that signing such distribution files can be handled outside
> of the wheel format PEP. It just way to complex and out of scope
> for the wheel format itself. Also note that PGP/GPG and the other
> signing tools work well on any distribution file. There's really no
> need to build these into the format itself.
>
> It's a good idea to check integrity, but that can be done using
> hashes.
PGP-on-pypi is the very definition of cryptography that isn't used.
I'm willing to go ahead and move any mention of signing algorithms into a
separate PEP, leaving only the basic manifest hash vs. file contents
verification under the auspices of this PEP.
Is the rest of the wheel specification, explaining how packages are
actually produced and installed, clear?
I want to remove distutils from the standard library. If that happens then
we might want a secure way to install it from pypi. One way would be to
include the public key used to sign distutils in Python's own
signature-verifying bootstrap wheel installer, never mind whether it used
ECDSA or RSA or Ed25519. Do you have a better idea? TUF?
https://www.updateframework.com/wiki/SecuringPythonPackageManagement
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121113/9b99dd27/attachment.html>
From ronaldoussoren at mac.com Tue Nov 13 16:10:30 2012
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 13 Nov 2012 16:10:30 +0100
Subject: [Catalog-sig] [Python-Dev] [Distutils] accept the wheel PEPs
425, 426, 427
In-Reply-To: <CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<20121018211014.73d56057@pitrou.net>
<CAG8k2+6oALhohqOePU-yJYBA=Hr=FjqzGJJ1g5Ah3pjR+fCuGA@mail.gmail.com>
<CAPZV6o9nC+7CsOhvE5pyp_u_cKoaKhGzPJXNgFoTDqNkbkJZkg@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
Message-ID: <55555795-0D06-4358-B4CE-E6E5DBBCA296@mac.com>
On 13 Nov, 2012, at 16:00, Daniel Holth <dholth at gmail.com> wrote:
>
> I want to remove distutils from the standard library.
Why? Distutils may not be perfect, but is usable for basic packages. It could even be enhanced to support these peps and be even more useable, although patches for that would run into the self-imposed freeze of distutils development.
Ronald
From solipsis at pitrou.net Tue Nov 13 17:21:14 2012
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 13 Nov 2012 17:21:14 +0100
Subject: [Catalog-sig] [Python-Dev] [Distutils] accept the wheel PEPs
425, 426, 427
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
<55555795-0D06-4358-B4CE-E6E5DBBCA296@mac.com>
Message-ID: <20121113172114.40b0ca4a@pitrou.net>
Le Tue, 13 Nov 2012 16:10:30 +0100,
Ronald Oussoren <ronaldoussoren at mac.com> a ?crit :
>
> On 13 Nov, 2012, at 16:00, Daniel Holth <dholth at gmail.com> wrote:
> >
> > I want to remove distutils from the standard library.
>
> Why? Distutils may not be perfect, but is usable for basic packages.
> It could even be enhanced to support these peps and be even more
> useable, although patches for that would run into the self-imposed
> freeze of distutils development.
It wouldn't be totally unreasonable to start a project named
"distutils2" to build the next-generation distutils library.
Oops :-)
Antoine.
From dirkjan at ochtman.nl Tue Nov 13 16:04:50 2012
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Tue, 13 Nov 2012 16:04:50 +0100
Subject: [Catalog-sig] [Python-Dev] [Distutils] accept the wheel PEPs
425, 426, 427
In-Reply-To: <CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<20121018211014.73d56057@pitrou.net>
<CAG8k2+6oALhohqOePU-yJYBA=Hr=FjqzGJJ1g5Ah3pjR+fCuGA@mail.gmail.com>
<CAPZV6o9nC+7CsOhvE5pyp_u_cKoaKhGzPJXNgFoTDqNkbkJZkg@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
Message-ID: <CAKmKYaBS+xKO+Ht+jYPRe0HRJHjw3D0iO_SjGhRtdfc5D5YdLA@mail.gmail.com>
On Tue, Nov 13, 2012 at 4:00 PM, Daniel Holth <dholth at gmail.com> wrote:
> I'm willing to go ahead and move any mention of signing algorithms into a
> separate PEP, leaving only the basic manifest hash vs. file contents
> verification under the auspices of this PEP.
>From the discussion so far, that seems like the smart thing to do.
Cheers,
Dirkjan
From p.f.moore at gmail.com Tue Nov 13 11:39:52 2012
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 13 Nov 2012 10:39:52 +0000
Subject: [Catalog-sig] [Distutils] [Python-Dev] accept the wheel PEPs
425, 426, 427
In-Reply-To: <50A2206A.40804@egenix.com>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<20121018211014.73d56057@pitrou.net>
<CAG8k2+6oALhohqOePU-yJYBA=Hr=FjqzGJJ1g5Ah3pjR+fCuGA@mail.gmail.com>
<CAPZV6o9nC+7CsOhvE5pyp_u_cKoaKhGzPJXNgFoTDqNkbkJZkg@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
Message-ID: <CACac1F_ja5ZFCegEiGeXH2=np06_v0uzoX+hZnsFcAfP9WVrXQ@mail.gmail.com>
On 13 November 2012 10:26, M.-A. Lemburg <mal at egenix.com> wrote:
> I agree with Martin. If the point is to "to protect against cryptography
> that is not used", then not using the de-facto standard in signing
> open source distribution files, which today is PGP/GPG, misses that
> point :-)
>
I agree as well. For me, the main reason for cryptography not being used is
key distribution. Sure, I have a signed file, but without a key what's the
point? And if I'm creating a file, why sign it if I don't know how to
securely publish my key? So inventing a new signing infrastructure without
a key distribution process doesn't encourage me to use crypto at all...
> It's a good idea to check integrity, but that can be done using
> hashes.
>
+1 hashing is fine, and I don't have any problem with the hashing aspects
of the PEP.
Maybe the signing aspects could be deferred to a subsequent PEP, to be
thrashed out separately? I know Daniel has a strong interest in the signing
aspect, so I'm reluctant to suggest just dropping it, but I'd rather it not
be a showstopper for the rest of the current proposal.
Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121113/c3fbb4db/attachment-0001.html>
From martin at v.loewis.de Tue Nov 13 18:07:05 2012
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 13 Nov 2012 18:07:05 +0100
Subject: [Catalog-sig] [Python-Dev] accept the wheel PEPs 425, 426, 427
In-Reply-To: <50A2206A.40804@egenix.com>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<20121018211014.73d56057@pitrou.net>
<CAG8k2+6oALhohqOePU-yJYBA=Hr=FjqzGJJ1g5Ah3pjR+fCuGA@mail.gmail.com>
<CAPZV6o9nC+7CsOhvE5pyp_u_cKoaKhGzPJXNgFoTDqNkbkJZkg@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
Message-ID: <50A27E39.8080809@v.loewis.de>
Am 13.11.12 11:26, schrieb M.-A. Lemburg:
> Note that signing such distribution files can be handled outside
> of the wheel format PEP. It just way to complex and out of scope
> for the wheel format itself. Also note that PGP/GPG and the other
> signing tools work well on any distribution file. There's really no
> need to build these into the format itself.
And even if the desire is to include the signature in the distribution
(as is common for code-signing - you want the signature in the
executable, the jar file, etc), then it's still possible to include,
say, a PGP signature inside the file, which may well be a signature
to the manuscript, preserving the rest of the signing procedure.
Regards,
Martin
From martin at v.loewis.de Tue Nov 13 18:23:35 2012
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 13 Nov 2012 18:23:35 +0100
Subject: [Catalog-sig] [Distutils] [Python-Dev] accept the wheel PEPs
425, 426, 427
In-Reply-To: <CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<CAPZV6o9nC+7CsOhvE5pyp_u_cKoaKhGzPJXNgFoTDqNkbkJZkg@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
Message-ID: <50A28217.5060301@v.loewis.de>
> I want to remove distutils from the standard library. If that happens
> then we might want a secure way to install it from pypi. One way would
> be to include the public key used to sign distutils in Python's own
> signature-verifying bootstrap wheel installer, never mind whether it
> used ECDSA or RSA or Ed25519. Do you have a better idea? TUF?
> https://www.updateframework.com/wiki/SecuringPythonPackageManagement
It depends on the threat model - whose definition is key to any security
discussion.
I'd say that providing the CA certificate of the CA, and to use https
for downloading, should be enough.
Alternatively, if the threat is that somebody may have hacked PyPI,
then hard-code the hash (SHA-3 if you are paranoid) in the Python
distribution, and rely on downloading a specific version from PyPI.
OTOH, I'm -1 on removing the code from Python in a way that it may
come back through downloading. Instead, it is much easier to keep
it included.
Regards,
Martin
From dholth at gmail.com Tue Nov 13 18:41:22 2012
From: dholth at gmail.com (Daniel Holth)
Date: Tue, 13 Nov 2012 12:41:22 -0500
Subject: [Catalog-sig] [Distutils] [Python-Dev] accept the wheel PEPs
425, 426, 427
In-Reply-To: <50A28217.5060301@v.loewis.de>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<CAPZV6o9nC+7CsOhvE5pyp_u_cKoaKhGzPJXNgFoTDqNkbkJZkg@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
<50A28217.5060301@v.loewis.de>
Message-ID: <CAG8k2+4zSEPPjymYcOs9WGVEdRLfL66AJew-MQ9rppONzMWi=w@mail.gmail.com>
On Tue, Nov 13, 2012 at 12:23 PM, "Martin v. L?wis" <martin at v.loewis.de>wrote:
> I want to remove distutils from the standard library. If that happens
>> then we might want a secure way to install it from pypi. One way would
>> be to include the public key used to sign distutils in Python's own
>> signature-verifying bootstrap wheel installer, never mind whether it
>> used ECDSA or RSA or Ed25519. Do you have a better idea? TUF?
>> https://www.updateframework.**com/wiki/**SecuringPythonPackageManagemen**
>> t <https://www.updateframework.com/wiki/SecuringPythonPackageManagement>
>>
>
> It depends on the threat model - whose definition is key to any security
> discussion.
>
> I'd say that providing the CA certificate of the CA, and to use https
> for downloading, should be enough.
>
> Alternatively, if the threat is that somebody may have hacked PyPI,
> then hard-code the hash (SHA-3 if you are paranoid) in the Python
> distribution, and rely on downloading a specific version from PyPI.
>
> OTOH, I'm -1 on removing the code from Python in a way that it may
> come back through downloading. Instead, it is much easier to keep
> it included.
>
It is a long term goal. It would be more practical to discourage distutils
and encourage users to look elsewhere (Bento) for a beautifully designed
build system.
The short term goal is just to standardize a way to install packages
without having a build system, which is what wheel is for apart from the
practical goal of simply installing lxml in a reasonable amount of time.
I think Metadata 1.2 (PEP 426) is ready to be accepted. The compatibility
tags (PEP 425) need some additional text in the discussion section, any
contributors for https://bitbucket.org/dholth/pep425tags/ ? Wheel (PEP 427)
might mention that version 1.0 of the spec is only concerned with
losslessly representing existing (setuptools & distutils) packages without
trying to add too many new features apart from a standardized .egg
substitute.
distutils itself is not testable.
Daniel Holth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121113/d49b03e7/attachment.html>
From barry at python.org Tue Nov 13 21:43:30 2012
From: barry at python.org (Barry Warsaw)
Date: Tue, 13 Nov 2012 15:43:30 -0500
Subject: [Catalog-sig] [Distutils] [Python-Dev] accept the wheel PEPs
425, 426, 427
In-Reply-To: <CAG8k2+4zSEPPjymYcOs9WGVEdRLfL66AJew-MQ9rppONzMWi=w@mail.gmail.com>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
<50A28217.5060301@v.loewis.de>
<CAG8k2+4zSEPPjymYcOs9WGVEdRLfL66AJew-MQ9rppONzMWi=w@mail.gmail.com>
Message-ID: <20121113154330.0b1d0e2c@resist.wooz.org>
I'm just beginning to review these PEPs and the threads, with an OS vendor
packager's eye. Let me start with one small suggestion for PEP 425.
From the FAQ:
Q. Who will maintain the registry of abbreviated implementations?
A. New two-letter abbreviations can be requested on the python-dev mailing
list. As a rule of thumb, abbreviations are reserved for the current 4 most
prominent implementations.
I think the PEP should explicitly say that it will be the definitive keeper of
the abbreviations. The request can be made on python-dev, and once approved,
PEP 425 will be updated with the new abbreviation.
Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121113/43123fcd/attachment.pgp>
From ronaldoussoren at mac.com Wed Nov 14 08:23:43 2012
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 14 Nov 2012 08:23:43 +0100
Subject: [Catalog-sig] [Python-Dev] [Distutils] accept the wheel
PEPs 425, 426, 427
In-Reply-To: <20121113172114.40b0ca4a@pitrou.net>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
<55555795-0D06-4358-B4CE-E6E5DBBCA296@mac.com>
<20121113172114.40b0ca4a@pitrou.net>
Message-ID: <2A6F78E2-65CF-4925-8DE0-09EA570A7239@mac.com>
On 13 Nov, 2012, at 17:21, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le Tue, 13 Nov 2012 16:10:30 +0100,
> Ronald Oussoren <ronaldoussoren at mac.com> a ?crit :
>>
>> On 13 Nov, 2012, at 16:00, Daniel Holth <dholth at gmail.com> wrote:
>>>
>>> I want to remove distutils from the standard library.
>>
>> Why? Distutils may not be perfect, but is usable for basic packages.
>> It could even be enhanced to support these peps and be even more
>> useable, although patches for that would run into the self-imposed
>> freeze of distutils development.
>
> It wouldn't be totally unreasonable to start a project named
> "distutils2" to build the next-generation distutils library.
>
> Oops :-)
Or carefully enhance distutils itself. Rewriting distutils in one go seems
to be too ambitious with the limited resources available to do so.
Ronald
From dholth at gmail.com Wed Nov 14 13:04:57 2012
From: dholth at gmail.com (Daniel Holth)
Date: Wed, 14 Nov 2012 07:04:57 -0500
Subject: [Catalog-sig] [Distutils] [Python-Dev] accept the wheel
PEPs 425, 426, 427
In-Reply-To: <2A6F78E2-65CF-4925-8DE0-09EA570A7239@mac.com>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
<55555795-0D06-4358-B4CE-E6E5DBBCA296@mac.com>
<20121113172114.40b0ca4a@pitrou.net>
<2A6F78E2-65CF-4925-8DE0-09EA570A7239@mac.com>
Message-ID: <404A3CEE-7F9B-4611-B12C-E45BD780BDC8@gmail.com>
On Nov 14, 2012, at 2:23 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
> On 13 Nov, 2012, at 17:21, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
>> Le Tue, 13 Nov 2012 16:10:30 +0100,
>> Ronald Oussoren <ronaldoussoren at mac.com> a ?crit :
>>>
>>> On 13 Nov, 2012, at 16:00, Daniel Holth <dholth at gmail.com> wrote:
>>>>
>>>> I want to remove distutils from the standard library.
>>>
>>> Why? Distutils may not be perfect, but is usable for basic packages.
>>> It could even be enhanced to support these peps and be even more
>>> useable, although patches for that would run into the self-imposed
>>> freeze of distutils development.
>>
>> It wouldn't be totally unreasonable to start a project named
>> "distutils2" to build the next-generation distutils library.
>>
>> Oops :-)
>
> Or carefully enhance distutils itself. Rewriting distutils in one go seems
> to be too ambitious with the limited resources available to do so.
That has been tried already (setuptools, distribute, distutils2). Instead, try bento (http://cournape.github.com/Bento/).
Hilariously everyone I've showed it to is immediately put off by the indentation based syntax (who would use such a thing?) but the project has a few years of effort behind it and is well designed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121114/659c2e4c/attachment.html>
From p.f.moore at gmail.com Wed Nov 14 15:38:11 2012
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 14 Nov 2012 14:38:11 +0000
Subject: [Catalog-sig] [Distutils] [Python-Dev] accept the wheel PEPs
425, 426, 427
In-Reply-To: <404A3CEE-7F9B-4611-B12C-E45BD780BDC8@gmail.com>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
<55555795-0D06-4358-B4CE-E6E5DBBCA296@mac.com>
<20121113172114.40b0ca4a@pitrou.net>
<2A6F78E2-65CF-4925-8DE0-09EA570A7239@mac.com>
<404A3CEE-7F9B-4611-B12C-E45BD780BDC8@gmail.com>
Message-ID: <CACac1F9js9=R8Wk_+4sX+NEj6GVEUU-HbRQ7VfO5iKJcewtd=g@mail.gmail.com>
On 14 November 2012 12:04, Daniel Holth <dholth at gmail.com> wrote:
> That has been tried already (setuptools, distribute, distutils2). Instead,
> try bento (http://cournape.github.com/Bento/).
>
> Hilariously everyone I've showed it to is immediately put off by the
> indentation based syntax (who would use such a thing?) but the project has
> a few years of effort behind it and is well designed.
>
> Ironically, given the thread, it doesn't support the metadata PEPs, so
packages installed with bento aren't visible to pip, etc.
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121114/927aa213/attachment.html>
From dholth at gmail.com Wed Nov 14 16:17:23 2012
From: dholth at gmail.com (Daniel Holth)
Date: Wed, 14 Nov 2012 10:17:23 -0500
Subject: [Catalog-sig] [Distutils] [Python-Dev] accept the wheel PEPs
425, 426, 427
In-Reply-To: <CACac1F9js9=R8Wk_+4sX+NEj6GVEUU-HbRQ7VfO5iKJcewtd=g@mail.gmail.com>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
<55555795-0D06-4358-B4CE-E6E5DBBCA296@mac.com>
<20121113172114.40b0ca4a@pitrou.net>
<2A6F78E2-65CF-4925-8DE0-09EA570A7239@mac.com>
<404A3CEE-7F9B-4611-B12C-E45BD780BDC8@gmail.com>
<CACac1F9js9=R8Wk_+4sX+NEj6GVEUU-HbRQ7VfO5iKJcewtd=g@mail.gmail.com>
Message-ID: <CAG8k2+6iVW2GSnZkuS-r1f_TMPXAUg-LF+=V47kijG5T97p=WA@mail.gmail.com>
Well, you can build eggs with Bento, and I have a patch that allows it to
build wheels, in both cases it will produce pip-compatible metadata. The
Bento author has his own informed opinions about the way packaging should
work which do not necessarily include the packaging PEPs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121114/0ea1bae0/attachment.html>
From vinay_sajip at yahoo.co.uk Fri Nov 16 19:05:35 2012
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Fri, 16 Nov 2012 18:05:35 +0000 (UTC)
Subject: [Catalog-sig] [Distutils] accept the wheel PEPs 425, 426, 427
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
<55555795-0D06-4358-B4CE-E6E5DBBCA296@mac.com>
<20121113172114.40b0ca4a@pitrou.net>
<2A6F78E2-65CF-4925-8DE0-09EA570A7239@mac.com>
<404A3CEE-7F9B-4611-B12C-E45BD780BDC8@gmail.com>
<CACac1F9js9=R8Wk_+4sX+NEj6GVEUU-HbRQ7VfO5iKJcewtd=g@mail.gmail.com>
<CAG8k2+6iVW2GSnZkuS-r1f_TMPXAUg-LF+=V47kijG5T97p=WA@mail.gmail.com>
Message-ID: <loom.20121116T182317-742@post.gmane.org>
Daniel Holth <dholth <at> gmail.com> writes:
> The Bento author has his own informed opinions about the ?way packaging should
> work which do not necessarily include the packaging PEPs.
That's all well and good, but there needs to be a common infrastructure for
interoperability, which is what the PEPs are about. Bento has ploughed its own
furrow because of the difficulty of extending distutils. But packaging seems to
be an area when a particular approach can't succeed (other than in a niche)
without some level of consensus; setuptools, it seems, managed it because it was
number one in a field of one.
I've seen you being complementary about Bento's beautiful design, but I haven't
been able to find enough documentation about this design to allow me to make my
own assessment. I've looked at the documentation linked to from the GitHub home
of the project, which leads to http://bento.readthedocs.org - is that the most
current documentation?
I found myself generally in agreement with that documentation when it refers to
the drawbacks of distutils and "why Bento". However, details on the design
itself seem a little too light to make an assessment about "how Bento". For
example, I get the sense that Bento's main focus is on building packages rather
than installing them (which is fine, since that's the harder part, particularly
when you are working with complex packages like numpy and scipy). However, I
can't for example see how you would configure compiler options. Of course the
source is available and I've cloned it to have a look, but those kind of things
are in "bento/private" and "bento/backends" and it's not really clear what
public APIs might look like. Of course one of the problems with distutils was
under-documentation, leading to everything being regarded as "public API", and
we know where that's led. The heavy lifting in Bento seems to be in something
called "yaku", to which I see only passing references in the Bento
documentation and not much apart a README on the yaku GitHub page.
I'm probably being dense, so I'd be grateful if you'd share how you arrived at
your very positive assessment of the quality of Bento's design: was it by
grokking the source, or is there some documentation I've missed?
Just to be clear: I've nothing at all against Bento, I'm just trying to
understand how it's put together.
Regards,
Vinay Sajip
From dholth at gmail.com Fri Nov 16 19:30:49 2012
From: dholth at gmail.com (Daniel Holth)
Date: Fri, 16 Nov 2012 13:30:49 -0500
Subject: [Catalog-sig] [Distutils] accept the wheel PEPs 425, 426, 427
In-Reply-To: <loom.20121116T182317-742@post.gmane.org>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
<55555795-0D06-4358-B4CE-E6E5DBBCA296@mac.com>
<20121113172114.40b0ca4a@pitrou.net>
<2A6F78E2-65CF-4925-8DE0-09EA570A7239@mac.com>
<404A3CEE-7F9B-4611-B12C-E45BD780BDC8@gmail.com>
<CACac1F9js9=R8Wk_+4sX+NEj6GVEUU-HbRQ7VfO5iKJcewtd=g@mail.gmail.com>
<CAG8k2+6iVW2GSnZkuS-r1f_TMPXAUg-LF+=V47kijG5T97p=WA@mail.gmail.com>
<loom.20121116T182317-742@post.gmane.org>
Message-ID: <CAG8k2+4xWvkm7Np+q96AmdkG+rda+v2=PM37PmMWdJGdzWVqGw@mail.gmail.com>
On Fri, Nov 16, 2012 at 1:05 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk>wrote:
> Daniel Holth <dholth <at> gmail.com> writes:
>
> > The Bento author has his own informed opinions about the way packaging
> should
> > work which do not necessarily include the packaging PEPs.
>
> That's all well and good, but there needs to be a common infrastructure for
> interoperability, which is what the PEPs are about. Bento has ploughed its
> own
> furrow because of the difficulty of extending distutils. But packaging
> seems to
> be an area when a particular approach can't succeed (other than in a niche)
> without some level of consensus; setuptools, it seems, managed it because
> it was
> number one in a field of one.
>
> I've seen you being complementary about Bento's beautiful design, but I
> haven't
> been able to find enough documentation about this design to allow me to
> make my
> own assessment. I've looked at the documentation linked to from the GitHub
> home
> of the project, which leads to http://bento.readthedocs.org - is that the
> most
> current documentation?
>
> I found myself generally in agreement with that documentation when it
> refers to
> the drawbacks of distutils and "why Bento". However, details on the design
> itself seem a little too light to make an assessment about "how Bento". For
> example, I get the sense that Bento's main focus is on building packages
> rather
> than installing them (which is fine, since that's the harder part,
> particularly
> when you are working with complex packages like numpy and scipy). However,
> I
> can't for example see how you would configure compiler options. Of course
> the
> source is available and I've cloned it to have a look, but those kind of
> things
> are in "bento/private" and "bento/backends" and it's not really clear what
> public APIs might look like. Of course one of the problems with distutils
> was
> under-documentation, leading to everything being regarded as "public API",
> and
> we know where that's led. The heavy lifting in Bento seems to be in
> something
> called "yaku", to which I see only passing references in the Bento
> documentation and not much apart a README on the yaku GitHub page.
>
> I'm probably being dense, so I'd be grateful if you'd share how you
> arrived at
> your very positive assessment of the quality of Bento's design: was it by
> grokking the source, or is there some documentation I've missed?
>
> Just to be clear: I've nothing at all against Bento, I'm just trying to
> understand how it's put together.
He did say he will support the PEPs when they are done. IIUC David would
prefer, for example, a more rpm-like design with an actual database of
installed packages rather than files scattered everywhere. In the meantime
it's fairly easy to support eggs and wininst and sdist and wheel.
My informed opinion comes from writing a build_wheel command for Bento at
https://github.com/dholth/Bento/commit/66c457685009de46f2d36a6e016e498ab783ceeb
It was much easier than writing bdist_wheel for setuptools because the
Bento code is much cleaner and the different phases of build / compile /
install / etc. are nicely separated.
The setuptools bdist_wheel has to grab the install command and overwrite
all the install_* properties to get the paths right. It has to run in the
same process. I should probably mention that all the inconvenience is due
to the underlying distutils design; setuptools makes bdist_wheel possible
because it has a plugin architecture.
The Bento build_wheel declares a dependency between itself and the build
command. When you run build_wheel the build command and all of its
dependencies run, writing internal Bento metadata about the build to disk.
After build has run, build_wheel does not have to touch the other commands.
It just reads the internal metadata and creates the archive.
yaku is one way Bento can build C extensions. Bento can also use waf or
distutils' own compiler abstraction.
One potential deal breaker: David uses \ in his code. You will have to get
over it if you want to use Bento. :-)
Daniel Holth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121116/04792498/attachment.html>
From donald.stufft at gmail.com Fri Nov 16 19:33:57 2012
From: donald.stufft at gmail.com (Donald Stufft)
Date: Fri, 16 Nov 2012 13:33:57 -0500
Subject: [Catalog-sig] [Distutils] accept the wheel PEPs 425, 426, 427
In-Reply-To: <CAG8k2+4xWvkm7Np+q96AmdkG+rda+v2=PM37PmMWdJGdzWVqGw@mail.gmail.com>
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
<55555795-0D06-4358-B4CE-E6E5DBBCA296@mac.com>
<20121113172114.40b0ca4a@pitrou.net>
<2A6F78E2-65CF-4925-8DE0-09EA570A7239@mac.com>
<404A3CEE-7F9B-4611-B12C-E45BD780BDC8@gmail.com>
<CACac1F9js9=R8Wk_+4sX+NEj6GVEUU-HbRQ7VfO5iKJcewtd=g@mail.gmail.com>
<CAG8k2+6iVW2GSnZkuS-r1f_TMPXAUg-LF+=V47kijG5T97p=WA@mail.gmail.com>
<loom.20121116T182317-742@post.gmane.org>
<CAG8k2+4xWvkm7Np+q96AmdkG+rda+v2=PM37PmMWdJGdzWVqGw@mail.gmail.com>
Message-ID: <9620A77DDFA34CD2889233F592E7331D@gmail.com>
On Friday, November 16, 2012 at 1:30 PM, Daniel Holth wrote:
> One potential deal breaker: David uses \ in his code. You will have to get over it if you want to use Bento. :-)
>
Bento's imports always make my head spin D: I'm not smart enough to process them by scanning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121116/9a23ca32/attachment.html>
From vinay_sajip at yahoo.co.uk Fri Nov 16 19:46:59 2012
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Fri, 16 Nov 2012 18:46:59 +0000 (UTC)
Subject: [Catalog-sig] [Distutils] accept the wheel PEPs 425, 426, 427
References: <CAG8k2+5CjZ48tjGSoykhu_30Ui5jx0eFuQNqEK3hiD_MyEFcvA@mail.gmail.com>
<CAG8k2+7krh3R5_C0Emn3mb1sy+072iUKCRS6X0N4VdwkJr27SA@mail.gmail.com>
<CAG8k2+5YLwk1RGG2CqDnMQkijvPJJYHCO0SwEoJKVkak2vpTDw@mail.gmail.com>
<87k3un5fwh.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+6Ck+zACr6eAOZGAShWWtFeVyqcWy=vTLG-PojvsZ+TZA@mail.gmail.com>
<87a9vh694r.fsf@uwakimon.sk.tsukuba.ac.jp>
<CAG8k2+4WAqNxd7pZ=h==WHvSq=f8UrizzUWPV70-rAC6bwQ_Cg@mail.gmail.com>
<87626457t6.fsf@uwakimon.sk.tsukuba.ac.jp>
<CADiSq7fgsz49X4X09L4QJPA+Gft17K1SmAUpwbnjKMj-4Hu34w@mail.gmail.com>
<CAG8k2+68O-uca_k_=n9FiyDNo7DSNkg3nECCza_nVt9L4_LT2A@mail.gmail.com>
<CAG8k2+6dtWoy5_dX2gVVQwyrt7d3X3pZxz-ZioELGMMoqMkTZA@mail.gmail.com>
<CADiSq7e7xxyoiZZNtJeH8Vafw5vG+EWDh3SC7htC916FaCrOhw@mail.gmail.com>
<50A21808.8040909@v.loewis.de> <50A2206A.40804@egenix.com>
<CAG8k2+5uBpq7FO99QbH4yvt-MLXSAH3uoDfjxTttUHe3CqsdWQ@mail.gmail.com>
<55555795-0D06-4358-B4CE-E6E5DBBCA296@mac.com>
<20121113172114.40b0ca4a@pitrou.net>
<2A6F78E2-65CF-4925-8DE0-09EA570A7239@mac.com>
<404A3CEE-7F9B-4611-B12C-E45BD780BDC8@gmail.com>
<CACac1F9js9=R8Wk_+4sX+NEj6GVEUU-HbRQ7VfO5iKJcewtd=g@mail.gmail.com>
<CAG8k2+6iVW2GSnZkuS-r1f_TMPXAUg-LF+=V47kijG5T97p=WA@mail.gmail.com>
<loom.20121116T182317-742@post.gmane.org>
<CAG8k2+4xWvkm7Np+q96AmdkG+rda+v2=PM37PmMWdJGdzWVqGw@mail.gmail.com>
Message-ID: <loom.20121116T193410-398@post.gmane.org>
Daniel Holth <dholth <at> gmail.com> writes:
> My informed opinion comes from writing a build_wheel command for Bento
> It was much easier than writing bdist_wheel for setuptools because the Bento
> code is much cleaner and the different phases of build / compile / install /
> etc. are nicely separated.
What documentation did you have to help you? Or did you just copy an existing
command as a template and change it to one that built wheels?
> The Bento build_wheel declares a dependency between itself and the build
> command. When you run build_wheel the build command and all of its
> dependencies run, writing internal Bento metadata about the build to disk.
That certainly sounds saner than the distutils dance.
> After build has run, build_wheel does not have to touch the other commands.
> It just reads the internal metadata and creates the archive.
Is that documented? Is it the "build manifest" mentioned in the "Design notes"
part of the documentation?
> yaku is one way Bento can build C extensions. Bento can also use waf or
> distutils' own compiler abstraction.
Well, yaku seems something of a black box, and I'm not sure how that's a good
thing.
> One potential deal breaker: David uses \ in his code. You will have to get
> over it if you want to use Bento.
Well, the Bento documentation itself refers to its "weak documentation" and
"mediocre code quality" - while I don't think David needs to be quite so
self-deprecatory, I would definitely agree about the documentation :-)
I'm not currently planning to use Bento - my interest at present is just to see
if it might conceivably be a potential client of distlib.
Regards,
Vinay Sajip
From tarek at ziade.org Sat Nov 17 16:11:36 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 17 Nov 2012 16:11:36 +0100
Subject: [Catalog-sig] Any recent changes to the cheeshop infrastructure?
In-Reply-To: <50A15AEF.2060605@palladion.com>
References: <k7rhcp$td9$1@ger.gmane.org>
<1BCC4C5F-BC03-4571-868D-1F97F6CDB681@coderanger.net>
<50A15AEF.2060605@palladion.com>
Message-ID: <50A7A928.3000907@ziade.org>
On 11/12/12 9:24 PM, Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/12/2012 02:23 PM, Noah Kantrowitz wrote:
>> Nothing recent, and the box looks fine. Currently pushing 60Mbit so
>> perhaps it is something about the hotel wifi (proxy or bottleneck
>> restrictions?)
> Maybe so. It seems oddly local to PyPI, however (mail, IRC, web browsing
> all seem fine).
>
>> The cloud bit is that it was moved to the PSF private cloud but that
>> was quite a while ago.
> OK, thanks for the info. We'll battle on. :)
FWIW everytime I had slow installs on Nose or Docutils, it was because
of some links external to PyPI
the installer followed.
To check if this is the problem, you can use
--allow-hosts=pypi.python.org in easy_install
>
>
> Tres.
> - --
> ===================================================================
> Tres Seaver +1 540-429-0999 tseaver at palladion.com
> Palladion Software "Excellence by Design" http://palladion.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlChWu8ACgkQ+gerLs4ltQ7rIgCfd/mmydToqaS44EdCtOFLcl/A
> ABwAmgMn+AOzH4zvXEPeORZ2OyJ2T/sa
> =OPcX
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
From tarek at ziade.org Mon Nov 19 19:37:11 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 19 Nov 2012 19:37:11 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
Message-ID: <50AA7C57.8050805@ziade.org>
Hey
I am currently writing a small script to verify that the gpg signature
is correct when the --sign option
is used with the Distutils upload command, and I was wondering why we
don't publish the public key
alongside the .asc file.
Right now, unless I missed something, to verify a signature the user has
to manually get the public key before she
can control the tarball.
Wouldn't it make sense to modify the upload command and add a .pubkey
file alongside the archive file
and the .asc file on PyPI ? (since we don't have a notion of team/users
etc.)
Cheers
Tarek
From dholth at gmail.com Mon Nov 19 19:43:47 2012
From: dholth at gmail.com (Daniel Holth)
Date: Mon, 19 Nov 2012 13:43:47 -0500
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <50AA7C57.8050805@ziade.org>
References: <50AA7C57.8050805@ziade.org>
Message-ID: <CAG8k2+6S544hOdTcfaimosEPVSKKOZrCf3qAhp4U5324vY658g@mail.gmail.com>
If pypi would also sign the public key, and possibly the metadata for a
particular release, that feature could be pretty cool.
On Mon, Nov 19, 2012 at 1:37 PM, Tarek Ziad? <tarek at ziade.org> wrote:
> Hey
>
>
> I am currently writing a small script to verify that the gpg signature is
> correct when the --sign option
> is used with the Distutils upload command, and I was wondering why we
> don't publish the public key
> alongside the .asc file.
>
> Right now, unless I missed something, to verify a signature the user has
> to manually get the public key before she
> can control the tarball.
>
> Wouldn't it make sense to modify the upload command and add a .pubkey file
> alongside the archive file
> and the .asc file on PyPI ? (since we don't have a notion of team/users
> etc.)
>
> Cheers
> Tarek
> ______________________________**_________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/**mailman/listinfo/catalog-sig<http://mail.python.org/mailman/listinfo/catalog-sig>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121119/26a8a763/attachment.html>
From tarek at ziade.org Mon Nov 19 19:45:51 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 19 Nov 2012 19:45:51 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <CAG8k2+6S544hOdTcfaimosEPVSKKOZrCf3qAhp4U5324vY658g@mail.gmail.com>
References: <50AA7C57.8050805@ziade.org>
<CAG8k2+6S544hOdTcfaimosEPVSKKOZrCf3qAhp4U5324vY658g@mail.gmail.com>
Message-ID: <50AA7E5F.1060504@ziade.org>
On 11/19/12 7:43 PM, Daniel Holth wrote:
> If pypi would also sign the public key, and possibly the metadata for
> a particular release, that feature could be pretty cool.
why pip ?
>
>
> On Mon, Nov 19, 2012 at 1:37 PM, Tarek Ziad? <tarek at ziade.org
> <mailto:tarek at ziade.org>> wrote:
>
> Hey
>
>
> I am currently writing a small script to verify that the gpg
> signature is correct when the --sign option
> is used with the Distutils upload command, and I was wondering why
> we don't publish the public key
> alongside the .asc file.
>
> Right now, unless I missed something, to verify a signature the
> user has to manually get the public key before she
> can control the tarball.
>
> Wouldn't it make sense to modify the upload command and add a
> .pubkey file alongside the archive file
> and the .asc file on PyPI ? (since we don't have a notion of
> team/users etc.)
>
> Cheers
> Tarek
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org <mailto:Catalog-SIG at python.org>
> http://mail.python.org/mailman/listinfo/catalog-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121119/7c602d0e/attachment.html>
From mal at egenix.com Mon Nov 19 19:55:08 2012
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 19 Nov 2012 19:55:08 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <50AA7C57.8050805@ziade.org>
References: <50AA7C57.8050805@ziade.org>
Message-ID: <50AA808C.6060904@egenix.com>
On 19.11.2012 19:37, Tarek Ziad? wrote:
> Hey
>
>
> I am currently writing a small script to verify that the gpg signature is correct when the --sign
> option
> is used with the Distutils upload command, and I was wondering why we don't publish the public key
> alongside the .asc file.
>
> Right now, unless I missed something, to verify a signature the user has to manually get the public
> key before she
> can control the tarball.
>
> Wouldn't it make sense to modify the upload command and add a .pubkey file alongside the archive file
> and the .asc file on PyPI ? (since we don't have a notion of team/users etc.)
Doesn't that cause problems when revoking a public key ?
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Nov 19 2012)
>>> Python Projects, Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
From dholth at gmail.com Mon Nov 19 20:03:08 2012
From: dholth at gmail.com (Daniel Holth)
Date: Mon, 19 Nov 2012 14:03:08 -0500
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <50AA7E5F.1060504@ziade.org>
References: <50AA7C57.8050805@ziade.org>
<CAG8k2+6S544hOdTcfaimosEPVSKKOZrCf3qAhp4U5324vY658g@mail.gmail.com>
<50AA7E5F.1060504@ziade.org>
Message-ID: <CAG8k2+7qjUJPqzF-fjN8Tv7wuzGsX5keMGwa_0zf=JzPnugqpA@mail.gmail.com>
On Mon, Nov 19, 2012 at 1:45 PM, Tarek Ziad? <tarek at ziade.org> wrote:
> On 11/19/12 7:43 PM, Daniel Holth wrote:
>
> If pypi would also sign the public key, and possibly the metadata for a
> particular release, that feature could be pretty cool.
>
>
> why pip ?
>
It's the premier Python package manager.
PyPI would sign the publisher's keys so that you could trust them without
having to worry about the connection. You could mirror the expected keys
this way.
Key revocation is an unrelated issue. A revoked key is still revoked even
if you can download a version of it that is not marked as revoked.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121119/236698b5/attachment-0001.html>
From tarek at ziade.org Mon Nov 19 22:31:23 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 19 Nov 2012 22:31:23 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <CAG8k2+7qjUJPqzF-fjN8Tv7wuzGsX5keMGwa_0zf=JzPnugqpA@mail.gmail.com>
References: <50AA7C57.8050805@ziade.org>
<CAG8k2+6S544hOdTcfaimosEPVSKKOZrCf3qAhp4U5324vY658g@mail.gmail.com>
<50AA7E5F.1060504@ziade.org>
<CAG8k2+7qjUJPqzF-fjN8Tv7wuzGsX5keMGwa_0zf=JzPnugqpA@mail.gmail.com>
Message-ID: <50AAA52B.80809@ziade.org>
On 11/19/12 8:03 PM, Daniel Holth wrote:
> On Mon, Nov 19, 2012 at 1:45 PM, Tarek Ziad? <tarek at ziade.org
> <mailto:tarek at ziade.org>> wrote:
>
> On 11/19/12 7:43 PM, Daniel Holth wrote:
>> If pypi would also sign the public key, and possibly the metadata
>> for a particular release, that feature could be pretty cool.
>
> why pip ?
>
>
> It's the premier Python package manager.
>
> PyPI would sign the publisher's keys so that you could trust them
> without having to worry about the connection. You could mirror the
> expected keys this way.
>
> Key revocation is an unrelated issue. A revoked key is still revoked
> even if you can download a version of it that is not marked as revoked.
But you don't upload packages on Pypi using Pip - since it's just the
installer - So I don't get the workflow
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121119/214c9b09/attachment.html>
From tarek at ziade.org Mon Nov 19 22:34:31 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 19 Nov 2012 22:34:31 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <50AA808C.6060904@egenix.com>
References: <50AA7C57.8050805@ziade.org> <50AA808C.6060904@egenix.com>
Message-ID: <50AAA5E7.8010604@ziade.org>
On 11/19/12 7:55 PM, M.-A. Lemburg wrote:
> On 19.11.2012 19:37, Tarek Ziad? wrote:
>> Hey
>>
>>
>> I am currently writing a small script to verify that the gpg signature is correct when the --sign
>> option
>> is used with the Distutils upload command, and I was wondering why we don't publish the public key
>> alongside the .asc file.
>>
>> Right now, unless I missed something, to verify a signature the user has to manually get the public
>> key before she
>> can control the tarball.
>>
>> Wouldn't it make sense to modify the upload command and add a .pubkey file alongside the archive file
>> and the .asc file on PyPI ? (since we don't have a notion of team/users etc.)
> Doesn't that cause problems when revoking a public key ?
>
That problem still exists as things are today at PyPI -if you sign a
package you get an .asc file uploaded and
you need to tell people where is your public key.
If you change your key, the asc file is not valid anymore.
I am not sure what would be the best way to do this: maybe we should
allow people to update the asc files ?
From dholth at gmail.com Mon Nov 19 22:43:17 2012
From: dholth at gmail.com (Daniel Holth)
Date: Mon, 19 Nov 2012 16:43:17 -0500
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <50AAA5E7.8010604@ziade.org>
References: <50AA7C57.8050805@ziade.org> <50AA808C.6060904@egenix.com>
<50AAA5E7.8010604@ziade.org>
Message-ID: <CAG8k2+6h+CJgNB=ELv9H90-ExSgCJ-fDrX8fgDF6eqDSp8b17g@mail.gmail.com>
On Mon, Nov 19, 2012 at 4:34 PM, Tarek Ziad? <tarek at ziade.org> wrote:
> On 11/19/12 7:55 PM, M.-A. Lemburg wrote:
>
>> On 19.11.2012 19:37, Tarek Ziad? wrote:
>>
>>> Hey
>>>
>>>
>>> I am currently writing a small script to verify that the gpg signature
>>> is correct when the --sign
>>> option
>>> is used with the Distutils upload command, and I was wondering why we
>>> don't publish the public key
>>> alongside the .asc file.
>>>
>>> Right now, unless I missed something, to verify a signature the user has
>>> to manually get the public
>>> key before she
>>> can control the tarball.
>>>
>>> Wouldn't it make sense to modify the upload command and add a .pubkey
>>> file alongside the archive file
>>> and the .asc file on PyPI ? (since we don't have a notion of team/users
>>> etc.)
>>>
>> Doesn't that cause problems when revoking a public key ?
>>
>> That problem still exists as things are today at PyPI -if you sign a
> package you get an .asc file uploaded and
> you need to tell people where is your public key.
>
> If you change your key, the asc file is not valid anymore.
>
> I am not sure what would be the best way to do this: maybe we should allow
> people to update the asc files ?
>
You should consider reading up on the design of TUF: The Update Framework (
https://www.updateframework.com/). They have designed a security system for
Python packages.
One solution to the key revocation problem is to have two signatures, a
timestamp from PyPI along with a signature from the publisher. The package
is only valid if it has a valid publisher signature along with a timestamp
that is within the validity period of the publisher's signing key.
In other words, if I publish a package in October but revoke my public key
in November, the package is still valid because PyPI asserts it was signed
before the key was revoked.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121119/577414cd/attachment.html>
From tarek at ziade.org Mon Nov 19 22:44:50 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 19 Nov 2012 22:44:50 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <CAG8k2+7tmmm6BQiE7Cxgo5a5_BHncAWtjJfBt9Yt9X_tGRSA4A@mail.gmail.com>
References: <50AA7C57.8050805@ziade.org>
<CAG8k2+6S544hOdTcfaimosEPVSKKOZrCf3qAhp4U5324vY658g@mail.gmail.com>
<50AA7E5F.1060504@ziade.org>
<CAG8k2+7qjUJPqzF-fjN8Tv7wuzGsX5keMGwa_0zf=JzPnugqpA@mail.gmail.com>
<50AAA52B.80809@ziade.org>
<CAG8k2+7tmmm6BQiE7Cxgo5a5_BHncAWtjJfBt9Yt9X_tGRSA4A@mail.gmail.com>
Message-ID: <50AAA852.1010203@ziade.org>
On 11/19/12 10:37 PM, Daniel Holth wrote:
> You misread my first message, I only suggested that PyPI would sign
> the public keys.
oh right, sorry
PyPI already signs each release for the mirrors (see PEP 381) - so it
sounds feasible
>
>
> On Mon, Nov 19, 2012 at 4:31 PM, Tarek Ziad? <tarek at ziade.org
> <mailto:tarek at ziade.org>> wrote:
>
> On 11/19/12 8:03 PM, Daniel Holth wrote:
>> On Mon, Nov 19, 2012 at 1:45 PM, Tarek Ziad? <tarek at ziade.org
>> <mailto:tarek at ziade.org>> wrote:
>>
>> On 11/19/12 7:43 PM, Daniel Holth wrote:
>>> If pypi would also sign the public key, and possibly the
>>> metadata for a particular release, that feature could be
>>> pretty cool.
>>
>> why pip ?
>>
>>
>> It's the premier Python package manager.
>>
>> PyPI would sign the publisher's keys so that you could trust them
>> without having to worry about the connection. You could mirror
>> the expected keys this way.
>>
>> Key revocation is an unrelated issue. A revoked key is still
>> revoked even if you can download a version of it that is not
>> marked as revoked.
>
> But you don't upload packages on Pypi using Pip - since it's just
> the installer - So I don't get the workflow
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121119/e89875cf/attachment-0001.html>
From dholth at gmail.com Mon Nov 19 23:01:58 2012
From: dholth at gmail.com (Daniel Holth)
Date: Mon, 19 Nov 2012 17:01:58 -0500
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <50AAA852.1010203@ziade.org>
References: <50AA7C57.8050805@ziade.org>
<CAG8k2+6S544hOdTcfaimosEPVSKKOZrCf3qAhp4U5324vY658g@mail.gmail.com>
<50AA7E5F.1060504@ziade.org>
<CAG8k2+7qjUJPqzF-fjN8Tv7wuzGsX5keMGwa_0zf=JzPnugqpA@mail.gmail.com>
<50AAA52B.80809@ziade.org>
<CAG8k2+7tmmm6BQiE7Cxgo5a5_BHncAWtjJfBt9Yt9X_tGRSA4A@mail.gmail.com>
<50AAA852.1010203@ziade.org>
Message-ID: <CAG8k2+6cnKuOXSrohZx5PoZ=205eYhm_poNF-ueXhxPAGkYscQ@mail.gmail.com>
Unfortunately the whole signed mirror system falls down because it relies
on md5 hashes (http://www.kb.cert.org/vuls/id/836068) although the signing
key seems to be long enough. What would it take to get SHA-2 (or 3) added?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121119/d6331413/attachment.html>
From tarek at ziade.org Mon Nov 19 23:03:50 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 19 Nov 2012 23:03:50 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <CAG8k2+6cnKuOXSrohZx5PoZ=205eYhm_poNF-ueXhxPAGkYscQ@mail.gmail.com>
References: <50AA7C57.8050805@ziade.org>
<CAG8k2+6S544hOdTcfaimosEPVSKKOZrCf3qAhp4U5324vY658g@mail.gmail.com>
<50AA7E5F.1060504@ziade.org>
<CAG8k2+7qjUJPqzF-fjN8Tv7wuzGsX5keMGwa_0zf=JzPnugqpA@mail.gmail.com>
<50AAA52B.80809@ziade.org>
<CAG8k2+7tmmm6BQiE7Cxgo5a5_BHncAWtjJfBt9Yt9X_tGRSA4A@mail.gmail.com>
<50AAA852.1010203@ziade.org>
<CAG8k2+6cnKuOXSrohZx5PoZ=205eYhm_poNF-ueXhxPAGkYscQ@mail.gmail.com>
Message-ID: <50AAACC6.1070204@ziade.org>
On 11/19/12 11:01 PM, Daniel Holth wrote:
> Unfortunately the whole signed mirror system falls down because it
> relies on md5 hashes (http://www.kb.cert.org/vuls/id/836068) although
> the signing key seems to be long enough. What would it take to get
> SHA-2 (or 3) added?
No, the mirroring protocol use SHA
http://www.python.org/dev/peps/pep-0381/#mirror-authenticity
The md5 hash is only a crc-check added in the tarball url
From dholth at gmail.com Mon Nov 19 23:06:17 2012
From: dholth at gmail.com (Daniel Holth)
Date: Mon, 19 Nov 2012 17:06:17 -0500
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <50AAACC6.1070204@ziade.org>
References: <50AA7C57.8050805@ziade.org>
<CAG8k2+6S544hOdTcfaimosEPVSKKOZrCf3qAhp4U5324vY658g@mail.gmail.com>
<50AA7E5F.1060504@ziade.org>
<CAG8k2+7qjUJPqzF-fjN8Tv7wuzGsX5keMGwa_0zf=JzPnugqpA@mail.gmail.com>
<50AAA52B.80809@ziade.org>
<CAG8k2+7tmmm6BQiE7Cxgo5a5_BHncAWtjJfBt9Yt9X_tGRSA4A@mail.gmail.com>
<50AAA852.1010203@ziade.org>
<CAG8k2+6cnKuOXSrohZx5PoZ=205eYhm_poNF-ueXhxPAGkYscQ@mail.gmail.com>
<50AAACC6.1070204@ziade.org>
Message-ID: <CAG8k2+6NTRgKowxNJPtjaYWCvHerWzOkfKMrQtapV-=o7vGz0w@mail.gmail.com>
On Mon, Nov 19, 2012 at 5:03 PM, Tarek Ziad? <tarek at ziade.org> wrote:
> On 11/19/12 11:01 PM, Daniel Holth wrote:
>
>> Unfortunately the whole signed mirror system falls down because it relies
>> on md5 hashes (http://www.kb.cert.org/vuls/**id/836068<http://www.kb.cert.org/vuls/id/836068>)
>> although the signing key seems to be long enough. What would it take to get
>> SHA-2 (or 3) added?
>>
> No, the mirroring protocol use SHA http://www.python.org/dev/**
> peps/pep-0381/#mirror-**authenticity<http://www.python.org/dev/peps/pep-0381/#mirror-authenticity>
>
> The md5 hash is only a crc-check added in the tarball url
>
The last step is just a bit outdated, that's all. To me it would seem quite
harmless to change it to SHA-256 or better.
1. download the /simple page, and compute its SHA-1 hash
2. compute the DSA signature of that hash
3. download the corresponding /serversig, and compare it (byte-for-byte)
with the value computed in step 2.
4. compute and verify (against the /simple page) the MD-5 hashes of all
files they download from the mirror.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121119/a175d104/attachment.html>
From donald.stufft at gmail.com Mon Nov 19 23:10:09 2012
From: donald.stufft at gmail.com (Donald Stufft)
Date: Mon, 19 Nov 2012 17:10:09 -0500
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <CAG8k2+6h+CJgNB=ELv9H90-ExSgCJ-fDrX8fgDF6eqDSp8b17g@mail.gmail.com>
References: <50AA7C57.8050805@ziade.org> <50AA808C.6060904@egenix.com>
<50AAA5E7.8010604@ziade.org>
<CAG8k2+6h+CJgNB=ELv9H90-ExSgCJ-fDrX8fgDF6eqDSp8b17g@mail.gmail.com>
Message-ID: <014C2278177A42C0A4397B38646731F6@gmail.com>
If you're going to build out the infrastructure for this it needs the ability for someone to
immediately (or within a very short timeframe) revoke their key. There is little value
in revoking a key (which could indicate that the original key was compromised) if
the unrevoked key is going to remain valid for a significant amount of time.
On Monday, November 19, 2012 at 4:43 PM, Daniel Holth wrote:
> On Mon, Nov 19, 2012 at 4:34 PM, Tarek Ziad? <tarek at ziade.org (mailto:tarek at ziade.org)> wrote:
> > On 11/19/12 7:55 PM, M.-A. Lemburg wrote:
> > > On 19.11.2012 19:37, Tarek Ziad? wrote:
> > > > Hey
> > > >
> > > >
> > > > I am currently writing a small script to verify that the gpg signature is correct when the --sign
> > > > option
> > > > is used with the Distutils upload command, and I was wondering why we don't publish the public key
> > > > alongside the .asc file.
> > > >
> > > > Right now, unless I missed something, to verify a signature the user has to manually get the public
> > > > key before she
> > > > can control the tarball.
> > > >
> > > > Wouldn't it make sense to modify the upload command and add a .pubkey file alongside the archive file
> > > > and the .asc file on PyPI ? (since we don't have a notion of team/users etc.)
> > > Doesn't that cause problems when revoking a public key ?
> > >
> > That problem still exists as things are today at PyPI -if you sign a package you get an .asc file uploaded and
> > you need to tell people where is your public key.
> >
> > If you change your key, the asc file is not valid anymore.
> >
> > I am not sure what would be the best way to do this: maybe we should allow people to update the asc files ?
>
> You should consider reading up on the design of TUF: The Update Framework (https://www.updateframework.com/). They have designed a security system for Python packages.
>
> One solution to the key revocation problem is to have two signatures, a timestamp from PyPI along with a signature from the publisher. The package is only valid if it has a valid publisher signature along with a timestamp that is within the validity period of the publisher's signing key.
>
> In other words, if I publish a package in October but revoke my public key in November, the package is still valid because PyPI asserts it was signed before the key was revoked.
>
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org (mailto:Catalog-SIG at python.org)
> http://mail.python.org/mailman/listinfo/catalog-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121119/c39e0451/attachment.html>
From martin at v.loewis.de Mon Nov 19 23:40:03 2012
From: martin at v.loewis.de (martin at v.loewis.de)
Date: Mon, 19 Nov 2012 23:40:03 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <CAG8k2+6cnKuOXSrohZx5PoZ=205eYhm_poNF-ueXhxPAGkYscQ@mail.gmail.com>
References: <50AA7C57.8050805@ziade.org>
<CAG8k2+6S544hOdTcfaimosEPVSKKOZrCf3qAhp4U5324vY658g@mail.gmail.com>
<50AA7E5F.1060504@ziade.org>
<CAG8k2+7qjUJPqzF-fjN8Tv7wuzGsX5keMGwa_0zf=JzPnugqpA@mail.gmail.com>
<50AAA52B.80809@ziade.org>
<CAG8k2+7tmmm6BQiE7Cxgo5a5_BHncAWtjJfBt9Yt9X_tGRSA4A@mail.gmail.com>
<50AAA852.1010203@ziade.org>
<CAG8k2+6cnKuOXSrohZx5PoZ=205eYhm_poNF-ueXhxPAGkYscQ@mail.gmail.com>
Message-ID: <20121119234003.Horde.u_mYdNjz9kRQqrVDPdRmRlA@webmail.df.eu>
Zitat von Daniel Holth <dholth at gmail.com>:
> Unfortunately the whole signed mirror system falls down because it relies
> on md5 hashes (http://www.kb.cert.org/vuls/id/836068) although the signing
> key seems to be long enough.
You are misinterpreting the vulnerability. It does not apply to the
way in which md5 is used in PyPI.
So in no way the system "falls down".
Regards,
Martin
From dholth at gmail.com Mon Nov 19 23:53:46 2012
From: dholth at gmail.com (Daniel Holth)
Date: Mon, 19 Nov 2012 17:53:46 -0500
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <20121119234003.Horde.u_mYdNjz9kRQqrVDPdRmRlA@webmail.df.eu>
References: <50AA7C57.8050805@ziade.org>
<CAG8k2+6S544hOdTcfaimosEPVSKKOZrCf3qAhp4U5324vY658g@mail.gmail.com>
<50AA7E5F.1060504@ziade.org>
<CAG8k2+7qjUJPqzF-fjN8Tv7wuzGsX5keMGwa_0zf=JzPnugqpA@mail.gmail.com>
<50AAA52B.80809@ziade.org>
<CAG8k2+7tmmm6BQiE7Cxgo5a5_BHncAWtjJfBt9Yt9X_tGRSA4A@mail.gmail.com>
<50AAA852.1010203@ziade.org>
<CAG8k2+6cnKuOXSrohZx5PoZ=205eYhm_poNF-ueXhxPAGkYscQ@mail.gmail.com>
<20121119234003.Horde.u_mYdNjz9kRQqrVDPdRmRlA@webmail.df.eu>
Message-ID: <C40C8368-83B6-429B-98B1-9189EDC1DC76@gmail.com>
On Nov 19, 2012, at 5:40 PM, martin at v.loewis.de wrote:
>
> Zitat von Daniel Holth <dholth at gmail.com>:
>
>> Unfortunately the whole signed mirror system falls down because it relies
>> on md5 hashes (http://www.kb.cert.org/vuls/id/836068) although the signing
>> key seems to be long enough.
>
> You are misinterpreting the vulnerability. It does not apply to the
> way in which md5 is used in PyPI.
>
> So in no way the system "falls down".
>
> Regards,
> Martin
I can't create two colliding uploads, uploading the first (harmless version) to pypi and then tricking someone into mirroring the second (harmful) version? The system is not designed to protect the uploaded contents at all?
Perhaps it doesn't fall down for some reason, but the cert recommendation is:
Do not use the MD5 algorithm
Software developers, Certification Authorities, website owners, and users should avoid using the MD5 algorithm in any capacity. As previous research has demonstrated, it should be considered cryptographically broken and unsuitable for further use.
So why not start using sha256? The site would appear more modern, and at the very least people like me would stop complaining about it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121119/fdf897a0/attachment.html>
From martin at v.loewis.de Tue Nov 20 00:08:02 2012
From: martin at v.loewis.de (martin at v.loewis.de)
Date: Tue, 20 Nov 2012 00:08:02 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <C40C8368-83B6-429B-98B1-9189EDC1DC76@gmail.com>
References: <50AA7C57.8050805@ziade.org>
<CAG8k2+6S544hOdTcfaimosEPVSKKOZrCf3qAhp4U5324vY658g@mail.gmail.com>
<50AA7E5F.1060504@ziade.org>
<CAG8k2+7qjUJPqzF-fjN8Tv7wuzGsX5keMGwa_0zf=JzPnugqpA@mail.gmail.com>
<50AAA52B.80809@ziade.org>
<CAG8k2+7tmmm6BQiE7Cxgo5a5_BHncAWtjJfBt9Yt9X_tGRSA4A@mail.gmail.com>
<50AAA852.1010203@ziade.org>
<CAG8k2+6cnKuOXSrohZx5PoZ=205eYhm_poNF-ueXhxPAGkYscQ@mail.gmail.com>
<20121119234003.Horde.u_mYdNjz9kRQqrVDPdRmRlA@webmail.df.eu>
<C40C8368-83B6-429B-98B1-9189EDC1DC76@gmail.com>
Message-ID: <20121120000802.Horde.w2CxEdjz9kRQqrvSr-3mfOA@webmail.df.eu>
Zitat von Daniel Holth <dholth at gmail.com>:
> I can't create two colliding uploads, uploading the first (harmless
> version) to pypi and then tricking someone into mirroring the second
> (harmful) version? The system is not designed to protect the
> uploaded contents at all?
It *is* designed to protect the uploaded contents, but not against the
uploader. Instead, it protects against some mirror operator replacing
a mirrored file, or some attacker taking over a mirror.
If you assume that the package author is malicious, adding SHA hashes
would not help at all. The package author can just upload a new version,
and get it mirrored to all copies (including the master), and nothing
in the mirroring protocol prevents that new version from containing
a trojan horse. All hashes would be intact and fine, and the mirror
be consistent with the master.
> So why not start using sha256?
It's not that simple. Backwards compatibility needs to be considered.
Feel free to write specifications and patches.
And please stop making FUD claims.
Regards,
Martin
From donald.stufft at gmail.com Tue Nov 20 00:10:04 2012
From: donald.stufft at gmail.com (Donald Stufft)
Date: Mon, 19 Nov 2012 18:10:04 -0500
Subject: [Catalog-sig] [Distutils] zc.buildout 2.0.0a4 released
In-Reply-To: <k8edm2$p9b$1@ger.gmane.org>
References: <CAPDm-FimWaeWmaQ3Rw6CqjWmnx9Z_za+11skJp7WmoT=zW-faw@mail.gmail.com>
<CAPDm-FiZF4Wi7Uir58p9cFj55mSgRnuuxEUrx1V5GK545Wooug@mail.gmail.com>
<k8ea0j$pev$1@ger.gmane.org>
<CAPDm-Fh6aEA3yHaHXbvdqOjKL6d1gBbH8QTXTEUggFeJkqcG7g@mail.gmail.com>
<k8eb7b$4fo$1@ger.gmane.org>
<CAPDm-FjxNhsB=HamT0XjKjh3tJr_DF8ArrzYNWK=KnFv00D6-w@mail.gmail.com>
<k8edm2$p9b$1@ger.gmane.org>
Message-ID: <BC2159A35EA549E3B77D423F94C9B582@gmail.com>
On Monday, November 19, 2012 at 6:00 PM, Alex Clark wrote:
>
> Ugh, sorry. I wonder if we can get Richard Jones or Martin von L?wis to
> modify PyPI such that "hiding" really means hiding (CC'ing
> catalog-sig). I also wonder if that is the right thing to do.
> Personally, I'd be OK with having to use find-links (or something like
> it) to test the alpha e.g.:
>
>
> $ pip install -f http://path/to/buildout.zip zc.buildout
>
>
> Actually what would be ideal (I think), if it were possible, is:
>
> - Upload sdist
> - Hide release
> - pip install zc.buildout installs latest unhidden release
> - pip install zc.buildout==2.0.0a4 installs 2.0.0a4.
>
> But that may be nonsensical? unless perhaps pip and easy_install were
> to check a different index if/when an exact version spec is given. :-/
>
>
pip does do something differently when an exact version is given.
It looks at:
1. '(index_url)s/%(project_name)s/%(version)s'
2. '(index_url)s/%(project_name)s'
3. '(index_url)s'
It stops on the first page it finds. Crate.io uses this in order to allow
packages to never get deleted, but deleted packages only install
if you've pinned exactly to that version. I don't know if Buildout
or easy_install do anything similar as I don't use them.
>
>
> Alex
>
>
>
>
> >
> > Jim
>
>
> --
> Alex Clark ? https://www.gittip.com/aclark4life/
>
>
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG at python.org (mailto:Distutils-SIG at python.org)
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121119/6fa976c5/attachment.html>
From dholth at gmail.com Tue Nov 20 00:14:28 2012
From: dholth at gmail.com (Daniel Holth)
Date: Mon, 19 Nov 2012 18:14:28 -0500
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <20121120000802.Horde.w2CxEdjz9kRQqrvSr-3mfOA@webmail.df.eu>
References: <50AA7C57.8050805@ziade.org>
<CAG8k2+6S544hOdTcfaimosEPVSKKOZrCf3qAhp4U5324vY658g@mail.gmail.com>
<50AA7E5F.1060504@ziade.org>
<CAG8k2+7qjUJPqzF-fjN8Tv7wuzGsX5keMGwa_0zf=JzPnugqpA@mail.gmail.com>
<50AAA52B.80809@ziade.org>
<CAG8k2+7tmmm6BQiE7Cxgo5a5_BHncAWtjJfBt9Yt9X_tGRSA4A@mail.gmail.com>
<50AAA852.1010203@ziade.org>
<CAG8k2+6cnKuOXSrohZx5PoZ=205eYhm_poNF-ueXhxPAGkYscQ@mail.gmail.com>
<20121119234003.Horde.u_mYdNjz9kRQqrVDPdRmRlA@webmail.df.eu>
<C40C8368-83B6-429B-98B1-9189EDC1DC76@gmail.com>
<20121120000802.Horde.w2CxEdjz9kRQqrvSr-3mfOA@webmail.df.eu>
Message-ID: <C5430AD1-C97D-4E4A-ADAC-17FBB8D374AF@gmail.com>
On Nov 19, 2012, at 6:08 PM, martin at v.loewis.de wrote:
>
> Zitat von Daniel Holth <dholth at gmail.com>:
>
>> I can't create two colliding uploads, uploading the first (harmless version) to pypi and then tricking someone into mirroring the second (harmful) version? The system is not designed to protect the uploaded contents at all?
>
> It *is* designed to protect the uploaded contents, but not against the
> uploader. Instead, it protects against some mirror operator replacing
> a mirrored file, or some attacker taking over a mirror.
>
> If you assume that the package author is malicious, adding SHA hashes
> would not help at all. The package author can just upload a new version,
> and get it mirrored to all copies (including the master), and nothing
> in the mirroring protocol prevents that new version from containing
> a trojan horse. All hashes would be intact and fine, and the mirror
> be consistent with the master.
>
>> So why not start using sha256?
>
> It's not that simple. Backwards compatibility needs to be considered.
> Feel free to write specifications and patches.
>
> And please stop making FUD claims.
>
> Regards,
> Martin
Ok. We aren't protecting against the uploader. My real complaint is only that md5 hasn't been a recommended primitive since 1998.
I will see about that patch. Pip at least understands #sha256=...
From jim at zope.com Tue Nov 20 00:19:01 2012
From: jim at zope.com (Jim Fulton)
Date: Mon, 19 Nov 2012 18:19:01 -0500
Subject: [Catalog-sig] [Distutils] zc.buildout 2.0.0a4 released
In-Reply-To: <k8edm2$p9b$1@ger.gmane.org>
References: <CAPDm-FimWaeWmaQ3Rw6CqjWmnx9Z_za+11skJp7WmoT=zW-faw@mail.gmail.com>
<CAPDm-FiZF4Wi7Uir58p9cFj55mSgRnuuxEUrx1V5GK545Wooug@mail.gmail.com>
<k8ea0j$pev$1@ger.gmane.org>
<CAPDm-Fh6aEA3yHaHXbvdqOjKL6d1gBbH8QTXTEUggFeJkqcG7g@mail.gmail.com>
<k8eb7b$4fo$1@ger.gmane.org>
<CAPDm-FjxNhsB=HamT0XjKjh3tJr_DF8ArrzYNWK=KnFv00D6-w@mail.gmail.com>
<k8edm2$p9b$1@ger.gmane.org>
Message-ID: <CAPDm-Fi1UWqEfvJ7XwiMFtgHL6T+sHL0uNKB+5vknPnH7+a-Xg@mail.gmail.com>
On Mon, Nov 19, 2012 at 6:00 PM, Alex Clark <aclark at aclark.net> wrote:
> Ugh, sorry. I wonder if we can get Richard Jones or Martin von L?wis to
> modify PyPI such that "hiding" really means hiding (CC'ing catalog-sig).
That would be very bad. Old releases are often hidden.
> I
> also wonder if that is the right thing to do.
It's not.
> Personally, I'd be OK with
> having to use find-links (or something like it) to test the alpha e.g.:
>
>
> $ pip install -f http://path/to/buildout.zip zc.buildout
pip install https://github.com/downloads/buildout/buildout/zc.buildout-2.0.0a4.tar.gz
> Actually what would be ideal (I think), if it were possible, is:
>
> - Upload sdist
> - Hide release
> - pip install zc.buildout installs latest unhidden release
> - pip install zc.buildout==2.0.0a4 installs 2.0.0a4.
>
> But that may be nonsensical? unless perhaps pip and easy_install were to
> check a different index if/when an exact version spec is given. :-/
What would be ideal would be for pip and easy_install to only install
non-final releases if asked to. Or at least provide an option to
prefer final releases. Buildout has had a prefer-final option for
years. In an upcoming buildout 2 alpha, this will become the default.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://zo.pe/Kqm
From mal at egenix.com Tue Nov 20 09:41:03 2012
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 20 Nov 2012 09:41:03 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <50AAA5E7.8010604@ziade.org>
References: <50AA7C57.8050805@ziade.org> <50AA808C.6060904@egenix.com>
<50AAA5E7.8010604@ziade.org>
Message-ID: <50AB421F.7070000@egenix.com>
On 19.11.2012 22:34, Tarek Ziad? wrote:
> On 11/19/12 7:55 PM, M.-A. Lemburg wrote:
>> On 19.11.2012 19:37, Tarek Ziad? wrote:
>>> Hey
>>>
>>>
>>> I am currently writing a small script to verify that the gpg signature is correct when the --sign
>>> option
>>> is used with the Distutils upload command, and I was wondering why we don't publish the public key
>>> alongside the .asc file.
>>>
>>> Right now, unless I missed something, to verify a signature the user has to manually get the public
>>> key before she
>>> can control the tarball.
>>>
>>> Wouldn't it make sense to modify the upload command and add a .pubkey file alongside the archive
>>> file
>>> and the .asc file on PyPI ? (since we don't have a notion of team/users etc.)
>>
>> Doesn't that cause problems when revoking a public key ?
>>
> That problem still exists as things are today at PyPI -if you sign a package you get an .asc file
> uploaded and
> you need to tell people where is your public key.
>
> If you change your key, the asc file is not valid anymore.
>
> I am not sure what would be the best way to do this: maybe we should allow people to update the asc
> files ?
There are two things to consider when revoking a key (e.g. because
it got compromised):
1. You need to tell users that the key is revoked
2. You need to be able to resign packages that had been signed using
the revoked key.
For the first requirement, I think PyPI should not try to create a
new PKI, but instead rely on the existing public key servers that
PGP and GPG both know how to work with. Key revocation is part of
this infrastructure, along with many other features that we don't
really want to duplicate in PyPI :-)
For the second requirement, updating the .asc file would be
a solution. Alternatively, the packagers could check the revocation
date and then still allow packages to be installed which were signed
before the revocation happened.
Note that the second requirement may also be needed for expired
keys - unless packagers choose to ignore such expiration, and
accept packages that were signed with a then valid key. This is
how Windows treats expired certificates on installers.
For both methods involving checking the packaging time, you do
need to use a timestamp server to make things waterproof
(see e.g.
http://stackoverflow.com/questions/2872105/alternative-timestamping-services-for-authenticode).
Aside: These discussions appear a bit academic to me, since
the signatures only add a small bit of extra security to the
whole setup (protection against tampering with the distribution
files on the PyPI server and an extra password entry on the
uploader's side), while making the system a lot more complex.
Apart from the academic challenge, I wonder whether it's worth
the trouble :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Nov 20 2012)
>>> Python Projects, Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
From martin at v.loewis.de Tue Nov 20 13:49:57 2012
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 20 Nov 2012 13:49:57 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <50AA7C57.8050805@ziade.org>
References: <50AA7C57.8050805@ziade.org>
Message-ID: <50AB7C75.9050503@v.loewis.de>
Am 19.11.12 19:37, schrieb Tarek Ziad?:
> Wouldn't it make sense to modify the upload command and add a .pubkey
> file alongside the archive file
> and the .asc file on PyPI ? (since we don't have a notion of team/users
> etc.)
Each user is supposed to provide his PGP key ID. For those that did, we
could fetch them from the key server. OTOH, users can also fetch them
themselves.
In PGP, keys should really be on the key servers, rather than having
distributed copies, since they get updated (e.g. when counter-signed
or revoked).
Regards,
Martin
From tarek at ziade.org Tue Nov 20 13:54:24 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 20 Nov 2012 13:54:24 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <50AB7C75.9050503@v.loewis.de>
References: <50AA7C57.8050805@ziade.org> <50AB7C75.9050503@v.loewis.de>
Message-ID: <50AB7D80.3060400@ziade.org>
On 11/20/12 1:49 PM, "Martin v. L?wis" wrote:
> Am 19.11.12 19:37, schrieb Tarek Ziad?:
>> Wouldn't it make sense to modify the upload command and add a .pubkey
>> file alongside the archive file
>> and the .asc file on PyPI ? (since we don't have a notion of team/users
>> etc.)
>
> Each user is supposed to provide his PGP key ID. For those that did, we
> could fetch them from the key server.
In some projects we have several owners and maintainers, so I am not sure
how we can decide which key to use. The initial owner ?
Maybe we'd need to add a project <> key relation that's set by default
to the initial owner's key, but could be change afterwards.
But as other said, if we start to add those features, we are going to
hit all
the PKI issues - like the need to be able to revoke keys etc.
> OTOH, users can also fetch them
> themselves.
>
> In PGP, keys should really be on the key servers, rather than having
> distributed copies, since they get updated (e.g. when counter-signed
> or revoked).
This sounds more robust. I will investigate and see if I can come up
with a set of good practice here.
>
> Regards,
> Martin
>
>
From tarek at ziade.org Tue Nov 20 13:56:26 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 20 Nov 2012 13:56:26 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <50AB7D80.3060400@ziade.org>
References: <50AA7C57.8050805@ziade.org> <50AB7C75.9050503@v.loewis.de>
<50AB7D80.3060400@ziade.org>
Message-ID: <50AB7DFA.3040402@ziade.org>
On 11/20/12 1:54 PM, Tarek Ziad? wrote:
> On 11/20/12 1:49 PM, "Martin v. L?wis" wrote:
>> Am 19.11.12 19:37, schrieb Tarek Ziad?:
>>> Wouldn't it make sense to modify the upload command and add a .pubkey
>>> file alongside the archive file
>>> and the .asc file on PyPI ? (since we don't have a notion of
>>> team/users
>>> etc.)
>>
>> Each user is supposed to provide his PGP key ID. For those that did, we
>> could fetch them from the key server.
>
> In some projects we have several owners and maintainers, so I am not sure
> how we can decide which key to use. The initial owner ?
>
> Maybe we'd need to add a project <> key relation that's set by default
> to the initial owner's key, but could be change afterwards.
>
oh scratch this. each upload has a uploader associated so we can use this.
From donald.stufft at gmail.com Tue Nov 20 18:49:25 2012
From: donald.stufft at gmail.com (Donald Stufft)
Date: Tue, 20 Nov 2012 12:49:25 -0500
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <50AB421F.7070000@egenix.com>
References: <50AA7C57.8050805@ziade.org> <50AA808C.6060904@egenix.com>
<50AAA5E7.8010604@ziade.org> <50AB421F.7070000@egenix.com>
Message-ID: <4B1C8BBFE9D94E10A906615C01B8E9F9@gmail.com>
On Tuesday, November 20, 2012 at 3:41 AM, M.-A. Lemburg wrote:
> For the second requirement, updating the .asc file would be
> a solution. Alternatively, the packagers could check the revocation
> date and then still allow packages to be installed which were signed
> before the revocation happened.
No, if a key is revoked it can no longer be used. I may discover that
my key has been compromised months after it was actually compromised
I would then revoke it. I have no idea if the person who (in the hypothetical)
signed any packages with my key, or for how long they've been doing so.
Once a key is revoked you must not trust it for anything.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121120/5505058e/attachment.html>
From mal at egenix.com Tue Nov 20 20:17:33 2012
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 20 Nov 2012 20:17:33 +0100
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <4B1C8BBFE9D94E10A906615C01B8E9F9@gmail.com>
References: <50AA7C57.8050805@ziade.org> <50AA808C.6060904@egenix.com>
<50AAA5E7.8010604@ziade.org> <50AB421F.7070000@egenix.com>
<4B1C8BBFE9D94E10A906615C01B8E9F9@gmail.com>
Message-ID: <50ABD74D.5080103@egenix.com>
Donald Stufft wrote:
> On Tuesday, November 20, 2012 at 3:41 AM, M.-A. Lemburg wrote:
>> For the second requirement, updating the .asc file would be
>> a solution. Alternatively, the packagers could check the revocation
>> date and then still allow packages to be installed which were signed
>> before the revocation happened.
>
> No, if a key is revoked it can no longer be used. I may discover that
> my key has been compromised months after it was actually compromised
> I would then revoke it. I have no idea if the person who (in the hypothetical)
> signed any packages with my key, or for how long they've been doing so.
>
> Once a key is revoked you must not trust it for anything.
Good point, even though that makes it very difficult to deal with
the validity of signatures on older packages - the package author
may no longer be in possession of the needed bits to sign those
packages again or do a re-upload.
Hmm, perhaps just signing the hash value is good enough. Those
would be stored on PyPI and remain accessible.
I wonder how systems like Debian or the various RPM-based ones
deal with the problem.
--
Marc-Andre Lemburg
eGenix.com Professional Python Services directly from the Source
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
From donald.stufft at gmail.com Tue Nov 20 20:31:55 2012
From: donald.stufft at gmail.com (Donald Stufft)
Date: Tue, 20 Nov 2012 14:31:55 -0500
Subject: [Catalog-sig] getting the public key when --sign is used
In-Reply-To: <50ABD74D.5080103@egenix.com>
References: <50AA7C57.8050805@ziade.org> <50AA808C.6060904@egenix.com>
<50AAA5E7.8010604@ziade.org> <50AB421F.7070000@egenix.com>
<4B1C8BBFE9D94E10A906615C01B8E9F9@gmail.com>
<50ABD74D.5080103@egenix.com>
Message-ID: <62DDE1F42331489AA2320D9BE7C97A1C@gmail.com>
On Tuesday, November 20, 2012 at 2:17 PM, M.-A. Lemburg wrote:
> I wonder how systems like Debian or the various RPM-based ones
> deal with the problem.
OS packages are a little different since they use one key to sign
the entire repository. They tend to use a rolling key so that they
can expire keys overtime without having to deal with forcing everyone
to find out how to get a key over insecure means.
If they needed to revoke a key there should be other keys that
can sign the package, and if they needed to revoke all the keys
then they'd need to start over for the original trust distribution. I'm
not aware if they have any contingencies in place for "need to fix
the entire trust database".
Since there are fewer keys they can also make better assertions
about how secure those keys are. Since every author has a key
it's important to be able to revoke them because the chances
of any one individual author needing to do so is larger than that
of Debian.
As a side note, this type of system also needs to know who
is allowed to sign for what particular package names. This data
must be communicated securely, and it must require authorization
from the existing keys to confirm the additional (or allow the user
to force it to override). This cannot simply be a flag in PyPI.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121120/9e273c4c/attachment-0001.html>
From noel at vwci.com Fri Nov 23 17:56:31 2012
From: noel at vwci.com (Noel Morgan)
Date: Fri, 23 Nov 2012 10:56:31 -0600
Subject: [Catalog-sig] classifiers
Message-ID: <CCD506DF.15C55B%noel@vwci.com>
Hi,
I have two frameworks and one implementation that I would like categories
for if possible, so I can upload my complete and working projects.
Framework :: Pyll
Framework :: TelephonyPy
Framework :: TelephonyPy :: FreePyBX
Also, Pymp was taken, but looks like a name squatter, do these ever get
free'd up for real projects? If so, please make Framework :: Pymp instead
of Pyll.
I have cti and other python libs I want to release, so would they best be
in: "Topic :: Communications :: Telephony?"
VoIP telephony or even SIP might be better.
Thanks!
Noel
From holger.krekel at gmail.com Fri Nov 30 10:05:14 2012
From: holger.krekel at gmail.com (Holger Krekel)
Date: Fri, 30 Nov 2012 10:05:14 +0100
Subject: [Catalog-sig] current repo of pypi
Message-ID: <CAPJJ-pKdPm0o+5Sfx_yAmAt-Ni7gQD+59+R=_hQ5oQoBuGbd+Q@mail.gmail.com>
Hello,
The http://wiki.python.org/moin/CheeseShopDev page mentioned that the repo
is undergoing migration. Is there some (even intermediate) url which i
could pull today?
thanks,
holger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121130/a8797510/attachment.html>
From mal at egenix.com Fri Nov 30 10:11:38 2012
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 30 Nov 2012 10:11:38 +0100
Subject: [Catalog-sig] current repo of pypi
In-Reply-To: <CAPJJ-pKdPm0o+5Sfx_yAmAt-Ni7gQD+59+R=_hQ5oQoBuGbd+Q@mail.gmail.com>
References: <CAPJJ-pKdPm0o+5Sfx_yAmAt-Ni7gQD+59+R=_hQ5oQoBuGbd+Q@mail.gmail.com>
Message-ID: <50B8784A.8010106@egenix.com>
On 30.11.2012 10:05, Holger Krekel wrote:
> Hello,
>
> The http://wiki.python.org/moin/CheeseShopDev page mentioned that the repo
> is undergoing migration. Is there some (even intermediate) url which i
> could pull today?
AFAIK, this is still the current repo:
https://bitbucket.org/loewis/pypi
There was a discussion to get it moved to the PSF bitbucket
account:
http://python.6.n6.nabble.com/PyPI-code-now-on-bitbucket-td4622130.html
but this doesn't appear to have happened yet:
https://bitbucket.org/PSF
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Nov 30 2012)
>>> Python Projects, Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
2012-11-28: Released eGenix mx Base 3.2.5 ... http://egenix.com/go36
2013-01-22: Python Meeting Duesseldorf ... 53 days to go
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/