From exarkun at divmod.com Tue Oct 11 03:49:13 2005 From: exarkun at divmod.com (Jp Calderone) Date: Mon, 10 Oct 2005 21:49:13 -0400 Subject: [Catalog-sig] Problems registering with PyPI In-Reply-To: 0 Message-ID: <20051011014913.3914.1561009094.divmod.quotient.26580@ohm> Today I tried to upload a package to PyPI today. I didn't meet with success. When I tried to use `python setup.py register', I received this output: Server response (400): Invalid classifier "('Intended Audience :: Developers', 'Programming Language :: Python', 'Development Status :: 2 - Pre-Alpha', 'Topic :: Utilities')" I pass a tuple of strings as the classifiers argument to setup. What should I be doing instead? Is this documented anywhere? Next I tried to upload the package information via the web interface. I received this response: Error processing form Missing required field "name" The PKG-INFO file I uploaded is the one `python setup.py sdist' spat out. Among the fields present in it is "Name: package". What went wrong here? I didn't try re-entering all my metainfo in the form on the website, so I can't say if that works or not. Jp From ben at groovie.org Thu Oct 13 21:07:04 2005 From: ben at groovie.org (Ben Bangert) Date: Thu, 13 Oct 2005 12:07:04 -0700 Subject: [Catalog-sig] Policies for packages where the author is unavailable Message-ID: <213C2458-4C30-48E1-A552-29E76B0DB60C@groovie.org> Several packages out there, including Python Paste, and several I'm working on have dependencies on a Python package called WSGI Utils. Unfortunately WSGI Utils is not packaged for setuptools and the Cheese Shop, nor have I been able to contact the author about having it added. The name also needs to be changed to WSGIUtils as the space appears to cause problems. What is the policy for having packages adapted to setuptools, and put on Cheese Shop in absence of official registration from the package author? In the case of WSGI Utils, the license appears to be a BSD license so I see no license restrictions preventing the redistribution from Cheese Shop. It would be nice if there was some policy in place for people to be 'maintainers' of a CheeseShop package in the case the author is either not interested or unavailable to do this themself. Thanks, Ben From ianb at colorstudy.com Sat Oct 22 21:20:51 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Sat, 22 Oct 2005 14:20:51 -0500 Subject: [Catalog-sig] Policies for packages where the author is unavailable In-Reply-To: <213C2458-4C30-48E1-A552-29E76B0DB60C@groovie.org> References: <213C2458-4C30-48E1-A552-29E76B0DB60C@groovie.org> Message-ID: <435A9113.9030502@colorstudy.com> Ben Bangert wrote: > Several packages out there, including Python Paste, and several I'm > working on have dependencies on a Python package called WSGI Utils. > Unfortunately WSGI Utils is not packaged for setuptools and the > Cheese Shop, nor have I been able to contact the author about having > it added. The name also needs to be changed to WSGIUtils as the space > appears to cause problems. Colin has applied some changes I've sent to him, but I haven't heard back on a couple things I've sent him since then. Oh well, it happens to all of us at times. > What is the policy for having packages adapted to setuptools, and put > on Cheese Shop in absence of official registration from the package > author? Since I don't notice any responses to this, I suppose that means there's no policy. I think I've brought this up before, for the same kind of reasons -- inaccuracies in entries (usually URLs), abandoned entries, or missing entries. Anyway, you can have multiple people with ownership (or at least admin access) on an entry. So I think it's okay to set up an entry (which in this case would point to your own package, probably with a version number that somehow distinguished it from the version it was [lightly] forked from). > In the case of WSGI Utils, the license appears to be a BSD license so > I see no license restrictions preventing the redistribution from > Cheese Shop. It would be nice if there was some policy in place for > people to be 'maintainers' of a CheeseShop package in the case the > author is either not interested or unavailable to do this themself. I say just go for it -- since there's no entry there's no problem at this point. Also, send Colin a note about it, and an offer to add him as an owner for the entry (I don't think you can set up an account on his behalf, so you can't actually add him as an owner until he has his own account). Then he can unfork whenever he feels like it, as is his prerogative. In the case of an abandoned entry, it's more complicated; you either have to create a new entry (with a new name), or there has to be some process to take over the entry. I would generally say that an entry should only be taken over if the author or owner of the entry is entirely missing for some time -- any other condition would be considered a fork (and should have a new name). -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From pje at telecommunity.com Sun Oct 23 07:08:10 2005 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 23 Oct 2005 01:08:10 -0400 Subject: [Catalog-sig] How to verify cheeseshop signatures? Message-ID: <5.1.1.6.0.20051023010305.01f9ff30@mail.telecommunity.com> Does anybody know how to verify cheeseshop signatures? I was just trying: gpg --verify roundup-0.9.0b1.tar.gz.asc roundup-0.9.0b1.tar.gz which results in: gpg: Signature made Fri Oct 7 01:39:29 2005 EDT using DSA key ID 41C6E930 gpg: Can't check signature: public key not found This seems to imply that to check a signature, you have to have the author's public key, and there's no way offered to get it via the cheese shop. Or is it looking for *my* public key for some reason? Or am I just confused about how this thing is supposed to work? From exarkun at divmod.com Sun Oct 23 08:55:56 2005 From: exarkun at divmod.com (Jp Calderone) Date: Sun, 23 Oct 2005 02:55:56 -0400 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <5.1.1.6.0.20051023010305.01f9ff30@mail.telecommunity.com> Message-ID: <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> On Sun, 23 Oct 2005 01:08:10 -0400, "Phillip J. Eby" wrote: >Does anybody know how to verify cheeseshop signatures? I was just trying: > > gpg --verify roundup-0.9.0b1.tar.gz.asc roundup-0.9.0b1.tar.gz > >which results in: > >gpg: Signature made Fri Oct 7 01:39:29 2005 EDT using DSA key ID 41C6E930 >gpg: Can't check signature: public key not found > >This seems to imply that to check a signature, you have to have the >author's public key, and there's no way offered to get it via the cheese shop. > >Or is it looking for *my* public key for some reason? Or am I just >confused about how this thing is supposed to work? > The required key is indicated in the message. You just need to retrieve it: gpg --import 41C6E930 Re-running --verify should now work. Jp From martin at v.loewis.de Sun Oct 23 13:54:23 2005 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 23 Oct 2005 13:54:23 +0200 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> References: <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> Message-ID: <435B79EF.5040900@v.loewis.de> Jp Calderone wrote: > The required key is indicated in the message. You just need to retrieve it: > > gpg --import 41C6E930 > > Re-running --verify should now work. Partially, yes: it will verify that the signature was made by the public key with that key ID. That doesn't mean you know for sure that the person you assume to be behind the key really is the "owner" of the key. For that, you would actually have to validate the public key, e.g. by looking at the signatures on the public key, and checking whether you recognize them, and whether you believe they would only sign keys for people they have verified in person. This is nothing cheeseshop could help with: the web of trust really is between people, not between technology. Regards, Martin From pje at telecommunity.com Sun Oct 23 18:02:17 2005 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 23 Oct 2005 12:02:17 -0400 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <435B79EF.5040900@v.loewis.de> References: <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> Message-ID: <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> >Jp Calderone wrote: > > The required key is indicated in the message. You just need to > retrieve it: > > > > gpg --import 41C6E930 > > > > Re-running --verify should now work. It doesn't. I get "gpg: can't open `41C6E930': No such file or directory". At 01:54 PM 10/23/2005 +0200, Martin v. L?wis wrote: >Partially, yes: it will verify that the signature was made by the public >key with that key ID. That doesn't mean you know for sure that the >person you assume to be behind the key really is the "owner" of the key. > >For that, you would actually have to validate the public key, e.g. by >looking at the signatures on the public key, and checking whether you >recognize them, and whether you believe they would only sign keys for >people they have verified in person. > >This is nothing cheeseshop could help with: the web of trust really is >between people, not between technology. So, from a practical perspective, the current signature implementation is of no use whatsoever to the vast majority of cheeseshop users. It seems like it would make more sense to use a format that includes a certificate signature chain (as with Ruby Gems). Having to manually track the keys of individual authors sort of goes against the whole point. From exarkun at divmod.com Sun Oct 23 18:28:31 2005 From: exarkun at divmod.com (Jp Calderone) Date: Sun, 23 Oct 2005 12:28:31 -0400 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> Message-ID: <20051023162831.27584.602406230.divmod.quotient.3045@ohm> On Sun, 23 Oct 2005 12:02:17 -0400, "Phillip J. Eby" wrote: > >>Jp Calderone wrote: >> > The required key is indicated in the message. You just need to retrieve >>it: >> > >> > gpg --import 41C6E930 >> > >> > Re-running --verify should now work. > >It doesn't. I get "gpg: can't open `41C6E930': No such file or directory". > You may not have gnupg configured with any key servers. I am currently using hkp://subkeys.pgp.net, if that's any help. > >At 01:54 PM 10/23/2005 +0200, Martin v. L?wis wrote: >>Partially, yes: it will verify that the signature was made by the public >>key with that key ID. That doesn't mean you know for sure that the >>person you assume to be behind the key really is the "owner" of the key. >> >>For that, you would actually have to validate the public key, e.g. by >>looking at the signatures on the public key, and checking whether you >>recognize them, and whether you believe they would only sign keys for >>people they have verified in person. >> >>This is nothing cheeseshop could help with: the web of trust really is >>between people, not between technology. > >So, from a practical perspective, the current signature implementation is of >no use whatsoever to the vast majority of cheeseshop users. Well... It's PGP :) It's as useful or useless to cheeseshop users as it is to anyone else. For anyone with a large web of trust, the likelihood of there being a trust relationship with the package signer is greater. For people with a small web of trust (or no web of trust at all), it's smaller. Perhaps this means it is practically useless (FWIW I think I agree, I doubt I have a trust relationship with a single package owner) > >It seems like it would make more sense to use a format that includes a >certificate signature chain (as with Ruby Gems). Having to manually track >the keys of individual authors sort of goes against the whole point. > Using a chain-based system helps spread trust relationships faster. It also means someone has to manage a certificate authority (set up the certificates in the first place, manage the security of the CA cert, accept and somehow process signature requests). The attacks it is vulnerable to are also more severe in their consequences: if you compromise my PGP private key, you can pretend to be me to anyone in the world; if you compromise a certificate authority certificate, you can pretend to be anyone in the world to anyone in the world. PGP keys are also more easily revokable. Not advocating either position, just explicitly spelling out some of the differences. Jp From pje at telecommunity.com Sun Oct 23 18:47:44 2005 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 23 Oct 2005 12:47:44 -0400 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <20051023162831.27584.602406230.divmod.quotient.3045@ohm> References: <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20051023123345.01fa3208@mail.telecommunity.com> At 12:28 PM 10/23/2005 -0400, Jp Calderone wrote: >On Sun, 23 Oct 2005 12:02:17 -0400, "Phillip J. Eby" > wrote: >> >>>Jp Calderone wrote: >>> > The required key is indicated in the message. You just need to >>> retrieve it: >>> > >>> > gpg --import 41C6E930 >>> > >>> > Re-running --verify should now work. >> >>It doesn't. I get "gpg: can't open `41C6E930': No such file or directory". > >You may not have gnupg configured with any key servers. I am currently >using hkp://subkeys.pgp.net, if that's any help. This worked: $ gpg --keyserver hkp://subkeys.pgp.net --recv-keys 41C6E930 gpg: requesting key 41C6E930 from hkp server subkeys.pgp.net gpg: key 41C6E930: public key "Richard Jones " imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 $ gpg --verify roundup-0.9.0b1.tar.gz.asc roundup-0.9.0b1.tar.gz gpg: Signature made Fri Oct 7 01:39:29 2005 EDT using DSA key ID 41C6E930 gpg: Good signature from "Richard Jones " gpg: aka "Richard Jones " gpg: aka "Richard Jones " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0145 FD2B 52E8 0A8E 329A 16C7 AC68 AC04 41C6 E930 >>At 01:54 PM 10/23/2005 +0200, Martin v. L??wis wrote: >>>Partially, yes: it will verify that the signature was made by the public >>>key with that key ID. That doesn't mean you know for sure that the >>>person you assume to be behind the key really is the "owner" of the key. >>> >>>For that, you would actually have to validate the public key, e.g. by >>>looking at the signatures on the public key, and checking whether you >>>recognize them, and whether you believe they would only sign keys for >>>people they have verified in person. >>> >>>This is nothing cheeseshop could help with: the web of trust really is >>>between people, not between technology. >> >>So, from a practical perspective, the current signature implementation is >>of no use whatsoever to the vast majority of cheeseshop users. > >Well... It's PGP :) It's as useful or useless to cheeseshop users as it >is to anyone else. For anyone with a large web of trust, the likelihood >of there being a trust relationship with the package signer is >greater. For people with a small web of trust (or no web of trust at >all), it's smaller. > >Perhaps this means it is practically useless (FWIW I think I agree, I >doubt I have a trust relationship with a single package owner) If you have to meet individual authors to validate them, you could just get the package from them in person and skip all the certificate crap. :) >>It seems like it would make more sense to use a format that includes a >>certificate signature chain (as with Ruby Gems). Having to manually >>track the keys of individual authors sort of goes against the whole point. > >Using a chain-based system helps spread trust relationships faster. It >also means someone has to manage a certificate authority (set up the >certificates in the first place, manage the security of the CA cert, >accept and somehow process signature requests). The attacks it is >vulnerable to are also more severe in their consequences: if you >compromise my PGP private key, you can pretend to be me to anyone in the >world; if you compromise a certificate authority certificate, you can >pretend to be anyone in the world to anyone in the world. PGP keys are >also more easily revokable. > >Not advocating either position, just explicitly spelling out some of the >differences. Well, the flip side is having no real security at all, if you just decide to trust each author individually. In effect, the whole thing becomes just a "warm fuzzy" pseudosecurity, not unlike airline screening procedures. The sucky bit is that my choices are now to work hard to integrate this with EasyInstall, and then have crypto experts complain that by making it actually work for people I've nullified the real security (which will be true, of course), or in the alternative I can just not support it, in which case people will gripe that it doesn't verify signatures. *sigh* From martin at v.loewis.de Sun Oct 23 19:07:09 2005 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 23 Oct 2005 19:07:09 +0200 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> References: <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> Message-ID: <435BC33D.3020409@v.loewis.de> Phillip J. Eby wrote: > >> Jp Calderone wrote: >> > The required key is indicated in the message. You just need to >> retrieve it: >> > >> > gpg --import 41C6E930 >> > >> > Re-running --verify should now work. > > > It doesn't. I get "gpg: can't open `41C6E930': No such file or directory". It's not --import, but --recv-keys. I get martin at mira:~$ gpg --recv-keys 41C6E930 gpg: requesting key 41C6E930 from hkp server wwwkeys.pgp.net gpg: key 41C6E930: "Richard Jones " 31 new signatures gpg: public key CA66D0B1 is 24595 seconds newer than the signature gpg: public key CA66D0B1 is 24557 seconds newer than the signature gpg: 3 marignal-needed, 1 complete-needed, classic Trust-Modell gpg: depth: 0 valid: 3 signed: 40 trust: 0-, 0q, 0n, 0m, 0f, 3u gpg: public key CA66D0B1 is 24557 seconds newer than the signature gpg: depth: 1 valid: 40 signed: 120 trust: 36-, 0q, 0n, 0m, 4f, 0u gpg: depth: 2 valid: 60 signed: 151 trust: 53-, 0q, 0n, 0m, 7f, 0u gpg: depth: 3 valid: 29 signed: 78 trust: 26-, 0q, 0n, 0m, 3f, 0u gpg: depth: 4 valid: 6 signed: 8 trust: 5-, 0q, 0n, 1m, 0f, 0u gpg: n?chste "Trust-DB"-Pflicht?berpr?fung am 2005-11-13 gpg: Anzahl insgesamt bearbeiteter Schl?ssel: 1 gpg: neue Signaturen: 31 > So, from a practical perspective, the current signature implementation > is of no use whatsoever to the vast majority of cheeseshop users. I can't speak for the vast majority of the cheeseshop users; the vast majority of regular GPG users who ever signed somebody else's key is probably able to find a chain of trust to Richard Jones. > It seems like it would make more sense to use a format that includes a > certificate signature chain (as with Ruby Gems). Having to manually > track the keys of individual authors sort of goes against the whole point. Why is that any better? Where do I get a code-signing certificate from? Regards, Martin From colin at owlfish.com Sun Oct 23 19:09:43 2005 From: colin at owlfish.com (Colin Stewart) Date: Sun, 23 Oct 2005 18:09:43 +0100 Subject: [Catalog-sig] Policies for packages where the author is unavailable In-Reply-To: <435A9113.9030502@colorstudy.com> References: <213C2458-4C30-48E1-A552-29E76B0DB60C@groovie.org> <435A9113.9030502@colorstudy.com> Message-ID: <1130087383.3218.21.camel@roll> Hi, Ben: I'm sorry I didn't get back to you earlier - your email is in my list of things to get around to, but I've simply not had time. > Ben Bangert wrote: > > Several packages out there, including Python Paste, and several I'm > > working on have dependencies on a Python package called WSGI Utils. > > Unfortunately WSGI Utils is not packaged for setuptools and the > > Cheese Shop, nor have I been able to contact the author about having > > it added. The name also needs to be changed to WSGIUtils as the space > > appears to cause problems. > > Colin has applied some changes I've sent to him, but I haven't heard > back on a couple things I've sent him since then. Oh well, it happens > to all of us at times. Ian: Am I right in thinking that only the space in the package name and the other HTTP methods (HEAD, PUT, etc) are outstanding at this point? I don't recall anything else. I'm happy to remove the space in the name, although it's really just working around bugs in other software! As far as setuptools support goes - please send me a patch against version 0.6 and I'll review it. If the impact's minimal I can just include it, in the worst case I can put it under a "contrib" folder for those than would like it. >From what I can tell the Cheese Shop is just a place to gather links to Python software - I'm happy for someone else to put an entry to WSGIUtils or any of the other Python software I maintain. Regards, Colin. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/catalog-sig/attachments/20051023/af832a7b/attachment.html From martin at v.loewis.de Sun Oct 23 19:20:21 2005 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 23 Oct 2005 19:20:21 +0200 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <5.1.1.6.0.20051023123345.01fa3208@mail.telecommunity.com> References: <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> <5.1.1.6.0.20051023123345.01fa3208@mail.telecommunity.com> Message-ID: <435BC655.70505@v.loewis.de> Phillip J. Eby wrote: > If you have to meet individual authors to validate them, you could just > get the package from them in person and skip all the certificate crap. :) You don't: you just need to know somebody who knows somebody... It's a web of trust. Also, I met Richard Jones only once, and can still verify the packages that he created after that meeting. > Well, the flip side is having no real security at all, if you just > decide to trust each author individually. In effect, the whole thing > becomes just a "warm fuzzy" pseudosecurity, not unlike airline screening > procedures. Code-signing *is* just warm fuzzy pseudosecurity. Even if I knew that the code really came from Richard Jones, how would I know to trust him that he isn't writing malware? If I have never heard of an author, what does it help me to know that he really is the author? > The sucky bit is that my choices are now to work hard to integrate this > with EasyInstall, and then have crypto experts complain that by making > it actually work for people I've nullified the real security (which will > be true, of course), or in the alternative I can just not support it, in > which case people will gripe that it doesn't verify signatures. *sigh* There is still a value in verifying the signatures: you can trust that the package really hasn't been tampered with after it got signed. When you found the key on the keyserver, you can also display the name on the key, and optionally the list of signers of that key. It is then up to the user to trust (you could use the user's gpg trust database to skip this step if the signer is found to be trusted). When you have package dependencies, the using package could include the key fingerprint of the expected signer of the used package. A user would then only have to trust the "topmost" package author, to not include malware in its own package, and to have verified the signer of the lower packages for both identity and moral trustworthiness. Regards, Martin From pje at telecommunity.com Sun Oct 23 19:39:10 2005 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 23 Oct 2005 13:39:10 -0400 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <435BC655.70505@v.loewis.de> References: <5.1.1.6.0.20051023123345.01fa3208@mail.telecommunity.com> <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> <5.1.1.6.0.20051023123345.01fa3208@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20051023132422.01f9c560@mail.telecommunity.com> At 07:20 PM 10/23/2005 +0200, Martin v. L?wis wrote: >When you have package dependencies, the using package could include the >key fingerprint of the expected signer of the used package. A user would >then only have to trust the "topmost" package author, to not include >malware in its own package, and to have verified the signer of the >lower packages for both identity and moral trustworthiness. In this case, that person could simply distribute everything from their site, and the user can simply require all the downloads to come from that site using easy_install's --allow-hosts option. For example, since TurboGears distributes all its dependencies, I could trust only turbogears.org. Or, I could choose to trust anything from cheeseshop.python.org. In other words, host-based trust seems a lot easier to implement and almost as useful. From pje at telecommunity.com Sun Oct 23 19:39:38 2005 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 23 Oct 2005 13:39:38 -0400 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <435BC33D.3020409@v.loewis.de> References: <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20051023132909.0337b538@mail.telecommunity.com> At 07:07 PM 10/23/2005 +0200, Martin v. L?wis wrote: >I can't speak for the vast majority of the cheeseshop users; the vast >majority of regular GPG users who ever signed somebody else's key is >probably able to find a chain of trust to Richard Jones. I'm making the (not unreasonable) assumption that most cheeseshop users either don't have, or at least don't know how to use GPG, and therefore don't have any trust chain at all. >>It seems like it would make more sense to use a format that includes a >>certificate signature chain (as with Ruby Gems). Having to manually >>track the keys of individual authors sort of goes against the whole point. > >Why is that any better? Where do I get a code-signing certificate from? Since as you've already pointed out, merely knowing that it's Richard Jones doesn't prove the code isn't malware, then it would suffice for the cheeseshop to certify that a particular public key belongs to the person who registered under a particular author ID. Mostly, I'm just feeling frustrated because this looks like an awful lot of tricky design work is needed to make this whole thing work for people who are not crypto experts. (And by "crypto expert", I mean anybody who actually understands how to use GPG, which is to say, not me. :) ) From martin at v.loewis.de Sun Oct 23 19:56:10 2005 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 23 Oct 2005 19:56:10 +0200 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <5.1.1.6.0.20051023132422.01f9c560@mail.telecommunity.com> References: <5.1.1.6.0.20051023123345.01fa3208@mail.telecommunity.com> <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> <5.1.1.6.0.20051023123345.01fa3208@mail.telecommunity.com> <5.1.1.6.0.20051023132422.01f9c560@mail.telecommunity.com> Message-ID: <435BCEBA.5070602@v.loewis.de> Phillip J. Eby wrote: > In this case, that person could simply distribute everything from their > site, and the user can simply require all the downloads to come from > that site using easy_install's --allow-hosts option. For example, since > TurboGears distributes all its dependencies, I could trust only > turbogears.org. Or, I could choose to trust anything from > cheeseshop.python.org. > > In other words, host-based trust seems a lot easier to implement and > almost as useful. IMO, common sense is just as useful: people know what software to install, so go right ahead and do it. Host-based trust really adds very little here: even if I like the software, somebody could have taken over the server and replaced it with a trojan. In that scenario, neither host-based trust nor common sense would help; I can't think of a scenario where host-based trust would help beyond common sense. Regards, Martin From pje at telecommunity.com Sun Oct 23 20:04:15 2005 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 23 Oct 2005 14:04:15 -0400 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <435BCEBA.5070602@v.loewis.de> References: <5.1.1.6.0.20051023132422.01f9c560@mail.telecommunity.com> <5.1.1.6.0.20051023123345.01fa3208@mail.telecommunity.com> <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> <5.1.1.6.0.20051023123345.01fa3208@mail.telecommunity.com> <5.1.1.6.0.20051023132422.01f9c560@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20051023140053.01f9d950@mail.telecommunity.com> At 07:56 PM 10/23/2005 +0200, Martin v. L?wis wrote: >Phillip J. Eby wrote: >>In this case, that person could simply distribute everything from their >>site, and the user can simply require all the downloads to come from that >>site using easy_install's --allow-hosts option. For example, since >>TurboGears distributes all its dependencies, I could trust only >>turbogears.org. Or, I could choose to trust anything from >>cheeseshop.python.org. >>In other words, host-based trust seems a lot easier to implement and >>almost as useful. > >IMO, common sense is just as useful: people know what software to >install, so go right ahead and do it. > >Host-based trust really adds very little here: even if I like the >software, somebody could have taken over the server and replaced >it with a trojan. In that scenario, neither host-based trust nor >common sense would help; I can't think of a scenario where host-based >trust would help beyond common sense. It doesn't - except for the fact that easy_install automatically locates and downloads dependencies using information on PyPI. So --allow-hosts can be used to reign in its enthusiasm a bit. :) It's also useful to set up a machine to only download software from a designated location by default, or to prevent automatic downloading altogether (by allowing only localhost). From martin at v.loewis.de Sun Oct 23 20:07:30 2005 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 23 Oct 2005 20:07:30 +0200 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <5.1.1.6.0.20051023132909.0337b538@mail.telecommunity.com> References: <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> <5.1.1.6.0.20051023132909.0337b538@mail.telecommunity.com> Message-ID: <435BD162.1030405@v.loewis.de> Phillip J. Eby wrote: > Since as you've already pointed out, merely knowing that it's Richard > Jones doesn't prove the code isn't malware, then it would suffice for > the cheeseshop to certify that a particular public key belongs to the > person who registered under a particular author ID. So the assumption is that the cheeseshop is trusted, right? If so, the gpg keyid gives you the guarantee that you want: that the package was really signed by the person of the particular author ID. > Mostly, I'm just feeling frustrated because this looks like an awful lot > of tricky design work is needed to make this whole thing work for people > who are not crypto experts. (And by "crypto expert", I mean anybody who > actually understands how to use GPG, which is to say, not me. :) ) Depends on what you mean by "to work". If you get the package from cheeseshop, you don't need to verify it, because the cheeseshop is trusted. If you get it elsewhere, how do you verify it? Regards, Martin From pje at telecommunity.com Sun Oct 23 21:16:39 2005 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 23 Oct 2005 15:16:39 -0400 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <435BD162.1030405@v.loewis.de> References: <5.1.1.6.0.20051023132909.0337b538@mail.telecommunity.com> <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> <5.1.1.6.0.20051023132909.0337b538@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20051023150721.01f9de00@mail.telecommunity.com> At 08:07 PM 10/23/2005 +0200, Martin v. L?wis wrote: >Phillip J. Eby wrote: >>Since as you've already pointed out, merely knowing that it's Richard >>Jones doesn't prove the code isn't malware, then it would suffice for the >>cheeseshop to certify that a particular public key belongs to the person >>who registered under a particular author ID. > >So the assumption is that the cheeseshop is trusted, right? > >If so, the gpg keyid gives you the guarantee that you want: that the >package was really signed by the person of the particular author ID. Right, but only at the same level that the cheeseshop-provided md5 is correct. Assuming that the cheeseshop download area is distinct from the cheeseshop application database, and one might be hacked but not the other, then keeping the information separate is more useful than storing it together. (In this sense, the md5 could actually be considered more secure than the signature, since it comes from the database, not the download area.) >>Mostly, I'm just feeling frustrated because this looks like an awful lot >>of tricky design work is needed to make this whole thing work for people >>who are not crypto experts. (And by "crypto expert", I mean anybody who >>actually understands how to use GPG, which is to say, not me. :) ) > >Depends on what you mean by "to work". If you get the package from >cheeseshop, you don't need to verify it, because the cheeseshop is >trusted. If you get it elsewhere, how do you verify it? By "to work", I mean something that provides users who are unconvinced by md5 (which easy_install already checks) with a comfortable illusion of a higher degree of security. :) I suppose it's relatively moot right now anyway, since there are so few signed packages. I should probably just ignore the issue until there are enough of them to be meaningful, or until somebody with the necessary expertise can put forward a plan for integrating gpg support in easy_install. (Which of course might not be until there are enough signatures for it to be worth having a more automated way to verify them.) From martin at v.loewis.de Sun Oct 23 21:32:08 2005 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 23 Oct 2005 21:32:08 +0200 Subject: [Catalog-sig] How to verify cheeseshop signatures? In-Reply-To: <5.1.1.6.0.20051023150721.01f9de00@mail.telecommunity.com> References: <5.1.1.6.0.20051023132909.0337b538@mail.telecommunity.com> <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> <20051023065556.27584.1976550431.divmod.quotient.2917@ohm> <5.1.1.6.0.20051023115133.01f9fbf8@mail.telecommunity.com> <5.1.1.6.0.20051023132909.0337b538@mail.telecommunity.com> <5.1.1.6.0.20051023150721.01f9de00@mail.telecommunity.com> Message-ID: <435BE538.6050609@v.loewis.de> Phillip J. Eby wrote: >> So the assumption is that the cheeseshop is trusted, right? > > Right, but only at the same level that the cheeseshop-provided md5 is > correct. Assuming that the cheeseshop download area is distinct from > the cheeseshop application database, and one might be hacked but not the > other, then keeping the information separate is more useful than storing > it together. Of course, this assumption is wrong: the download area is not different from the database, and whoever can hack one can easily hack the other. Regards, Martin From gh at ghaering.de Wed Oct 26 22:35:10 2005 From: gh at ghaering.de (=?ISO-8859-1?Q?Gerhard_H=E4ring?=) Date: Wed, 26 Oct 2005 22:35:10 +0200 Subject: [Catalog-sig] RfE: Allow users to upload eggs they did not build themselves Message-ID: <435FE87E.1000509@ghaering.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I'm not sure if that's the right place to ask for enhancements to easy_install/setuptools?! I'm just starting with eggs and all the fancy new stuff, and I had somebody build a MacOS X egg for me, which I tried to upload to PyPI. Unfortunately, setuptools did not support that out of the box, and I had to hack a new distutils command that did that, just copying setuptools upload command and modifying it. This has now led to this entry in PyPI: http://cheeseshop.python.org/pypi/pysqlite/2.0.6 Python Egg 2.4 built on Linux-2.6.12-9-k7-i686-with-glibc2.3 pysqlite-2.0.5-py2.4-macosx-10.4-ppc.egg (md5, sig) 89KB 0 ;-) - -- Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDX+h+dIO4ozGCH14RAhuBAJ0XvQChHx3y8YyU4mRfKkuxSp3MygCfdgRS UvPIAqRT++qzCBdnHX/37U4= =Z6/Z -----END PGP SIGNATURE----- From amk at amk.ca Fri Oct 28 00:23:14 2005 From: amk at amk.ca (A.M. Kuchling) Date: Thu, 27 Oct 2005 18:23:14 -0400 Subject: [Catalog-sig] [lfini@arcetri.astro.it: cannot submit a package] Message-ID: <20051027222314.GA5814@rogue.amk.ca> Forwarded. --amk -------------- next part -------------- An embedded message was scrubbed... From: Luca Fini Subject: cannot submit a package Date: Fri, 28 Oct 2005 01:13:11 +0200 (CEST) Size: 3294 Url: http://mail.python.org/pipermail/catalog-sig/attachments/20051027/86262fb4/attachment.mht From exarkun at divmod.com Fri Oct 28 00:30:35 2005 From: exarkun at divmod.com (Jean-Paul Calderone) Date: Thu, 27 Oct 2005 18:30:35 -0400 Subject: [Catalog-sig] [lfini@arcetri.astro.it: cannot submit a package] In-Reply-To: <20051027222314.GA5814@rogue.amk.ca> Message-ID: <20051027223035.10365.1437255401.divmod.quotient.1113@ohm> On Thu, 27 Oct 2005 18:23:14 -0400, "A.M. Kuchling" wrote: >Forwarded. > >--amk > I've had the described problem when trying to update a project and not having sufficient permissions to do so. The interface gives no indication that this is the case, since it is just a standard HTTP auth dialog. The issue is conflated by the fact that sometimes (all the time?), after doing this, your old credentials are dropped and you have to log back in as yourself. Another case can come up that is related to login (which I have not yet been able to deterministically reproduce) where any page will report that an error has occurred, give a Python exception string, and nothing else. Quitting your browser seems to be the only remedy for this. Dunno if any of this relates to the original reporter's problem, but it seemed like it might a bit. From pje at telecommunity.com Sat Oct 29 03:18:23 2005 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 28 Oct 2005 21:18:23 -0400 Subject: [Catalog-sig] RfE: Allow users to upload eggs they did not build themselves In-Reply-To: <435FE87E.1000509@ghaering.de> Message-ID: <5.1.1.6.0.20051028211533.02fc3ea8@mail.telecommunity.com> At 10:35 PM 10/26/2005 +0200, Gerhard H?ring wrote: >I'm not sure if that's the right place to ask for enhancements to >easy_install/setuptools?! See the distutils-sig at python.org instead. >I'm just starting with eggs and all the fancy new stuff, and I had >somebody build a MacOS X egg for me, which I tried to upload to PyPI. > >Unfortunately, setuptools did not support that out of the box, and I had >to hack a new distutils command that did that, just copying setuptools >upload command and modifying it. > >This has now led to this entry in PyPI: >http://cheeseshop.python.org/pypi/pysqlite/2.0.6 > >Python Egg 2.4 built on Linux-2.6.12-9-k7-i686-with-glibc2.3 >pysqlite-2.0.5-py2.4-macosx-10.4-ppc.egg (md5, sig) 89KB 0 Um, a macosx egg built on Linux? :) Really, if you need to upload a file manually like this, I would suggest using the PyPI web interface and just uploading it by hand. You can go to your file management URL from the package, and from there you can delete the file and then re-upload it, perhaps inserting a more appropriate comment about the build platform. :)