I'm not clear on this and the document is a little vague, so perhaps
I should be perusing the source, but if you don't protect against a
serverkey MITM and you are supposed to update the serverkey any
time a signature doesn't match up, couldn't an attacker just MITM
you, produce a known bad
That's true; transmission of the serverkey is not currently protected
against MITM. How would you suggest to fix that?
As for perusing the source: the client behavior is not implemented yet,
so there isn't really any source to check, yet.
Following up to myself: The mirroring protocol doesn't
On Tue, Jun 15, 2010 at 11:09 PM, Martin v. Löwis mar...@v.loewis.de wrote:
I'm not clear on this and the document is a little vague, so perhaps
I should be perusing the source, but if you don't protect against a
serverkey MITM and you are supposed to update the serverkey any
time a signature
Note that Martin is doing the final step (checking the changes before
they go in production
and updating the production server).
For sure ! I wasn't saying that I wanted to be able to push anything
directly on PyPi or on the official repository.
My point was more about making it easier for
Martin v. Löwis martin at v.loewis.de writes:
As a maintainer of the PyPI project, it makes your workflow simpler,
- contributors can clone the repo, change the code and ask you for a pull
- you can pull changes by direct hg commands, and merge them
After using Mercurial in one
Tarek Ziadé ziade.tarek at gmail.com writes:
And we happen to have this network already: lots of people
will host a PyPI mirror as soon as it's easy to set one imho.
You must be careful that the mirrors are properly managed and administered,
though. Having stale/dysfunctioning mirrors is
M.-A. Lemburg mal at egenix.com writes:
Setting up some Zenoss or Nagios monitoring system to take
care of monitoring the PyPI server (and our other servers)
would be a separate project.
Just for the record, I would mention that someone started a rewrite of the
Nagios software in Python:
Even more OT, we might try setting up the PyPI server under supervisord
(http://supervisord.org) plus superlance's HTTPOK and memmon event
listeners. This would make sure that the process is restarted when it
stops answering HTTP requests or if it begins to consume too much
memory. It's slightly
Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
Setting up some Zenoss or Nagios monitoring system to take
care of monitoring the PyPI server (and our other servers)
would be a separate project.
Just for the record, I would mention that someone started a rewrite of the
Antoine Pitrou wrote:
Tarek Ziadé ziade.tarek at gmail.com writes:
And we happen to have this network already: lots of people
will host a PyPI mirror as soon as it's easy to set one imho.
You must be careful that the mirrors are properly managed and administered,
though. Having
Howdy folks --
I've received a request from the Debian and Ubuntu maintainers to
rename one of my packages [1] so that it'd comply better with the
Debian/Ubuntu naming standards. I'd like to help them out, and ideally
I'd like to rename my package on PyPI to match the name that APT will
use.
On 2010-06-11, at 1:56 PM, Martin v. Löwis wrote:
If you are willing to invest *a lot* of time, then it seems that rewriting
PyPI in Django would make a lot of people happy, because
they claim they can't contribute to the current code base because
they don't understand that. I don't want to
On Wed, Jun 16, 2010 at 2:41 AM, Justin Cappos
just...@cs.washington.edu wrote:
On Tue, Jun 15, 2010 at 11:09 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
I'm not clear on this and the document is a little vague, so perhaps
I should be perusing the source, but if you don't protect against a
Am 16.06.2010 13:53, schrieb Antoine Pitrou:
Tarek Ziadéziade.tarekat gmail.com writes:
And we happen to have this network already: lots of people
will host a PyPI mirror as soon as it's easy to set one imho.
You must be careful that the mirrors are properly managed and administered,
Am 16.06.2010 13:44, schrieb Antoine Pitrou:
Martin v. Löwismartinat v.loewis.de writes:
As a maintainer of the PyPI project, it makes your workflow simpler,
- contributors can clone the repo, change the code and ask you for a pull
- you can pull changes by direct hg commands, and merge
Am 16.06.2010 18:39, schrieb Jacob Kaplan-Moss:
Howdy folks --
I've received a request from the Debian and Ubuntu maintainers to
rename one of my packages [1] so that it'd comply better with the
Debian/Ubuntu naming standards. I'd like to help them out, and ideally
I'd like to rename my package
Le mercredi 16 juin 2010 à 20:40 +0200, Martin v. Löwis a écrit :
Am 16.06.2010 13:44, schrieb Antoine Pitrou:
Martin v. Löwismartinat v.loewis.de writes:
As a maintainer of the PyPI project, it makes your workflow simpler,
- contributors can clone the repo, change the code and ask
On Wed, Jun 16, 2010 at 2:40 PM, Martin v. Löwis mar...@v.loewis.de wrote:
However, I admit that switching from RCS to CVS was easy, and so was
switching from CVS to SVN. Switching to hg is the most difficult change for
me. I'm probably getting old.
Pretty much the same here; DVCS systems have
On 6/16/2010 8:20 AM, M.-A. Lemburg wrote:
Antoine Pitrou wrote:
Tarek Ziadéziade.tarekat gmail.com writes:
And we happen to have this network already: lots of people
will host a PyPI mirror as soon as it's easy to set one imho.
You must be careful that the mirrors are properly managed
After using Mercurial in one project, I'm skeptical that this really
makes things simpler. I find it very hard to find out what changes a
specific clone has that I still need to integrate.
There are commands to compare repositories: incoming and outgoing (read
“hg help incoming”).
Also,
Hey all,
the recent activity on this mailinglist has kickstarted my
contributing sense. As long as the mirroring debate is still ongoing I
will focus my efforts somewhere else. Namely: the HTML/Javascript/CSS.
This email has also been submitted to the distutils-sig list as a lot
of power
Hi,
Andreas Jung wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
I propose a policy change for packages registered with PyPI:
- packages registered on PyPI have at least one release
- one release of registered package on PyPI _must_ contain
a valid source code
22 matches
Mail list logo
