Mailman 3 November 2013 - devpi-dev

Getting rid of the "dev" postfix in the version number
by Achim Domma 28 Jan '14

28 Jan '14

HI, when I execute a "devpi upload" in my package folder, the uploaded version always gets a "dev" postfix appended to the version. To install such a version using pip, I have to specifiy the --pre flag. I have no glue whether devpi decides to append this postfix or setuptools or ... Could somebody give me a hint how to get rid of this behavior? kind regards, Achim

4 4

Fwd How do I know if I need to re-authenticate
by Laurent Brack 20 Nov '13

20 Nov '13

Just forwarding this email thread as it might benefit others as Holger suggested. On 11/20/13 11:19 AM, "holger krekel" <hol...(a)merlinux.eu> wrote: >hi Laurent, > >On Wed, Nov 20, 2013 at 19:07 +0000, Brack, Laurent P. wrote: >> Hi Holger, >> >> Thanks a lot for the clarification. Something strange though as even if >>I am logged in, the simple case shows that I am not logged in >> >> $ devpi login lpbrac >> password for user lpbrac: >> logged in 'lpbrac', credentials valid for 10.00 hours >> >> $ devpi use >> using index: http://devpi-eu.dolby.net/lpbrac/dev/ (logged in as lpbrac) >> >> $ curl http://devpi-eu.dolby.net/lpbrac/dev/+api >> { >> "type": "apiconfig", >> "result": { >> "index": "http://devpi-eu.dolby.net/lpbrac/dev/", >> "authstatus": [ >> "noauth", >> "" >> ], >> "simpleindex": "http://devpi-eu.dolby.net/lpbrac/dev/+simple/", >> "login": "http://devpi-eu.dolby.net/+login", >> "pypisubmit": "http://devpi-eu.dolby.net/lpbrac/dev/", >> "resultlog": "http://devpi-eu.dolby.net/+tests" >> } >> } > >Indeed, as you found out below, you need to send the auth information >along with the +api request for the server to tell you if it's >actual/valid. >(The "curl" request could come from any user as it stands). > >cheers, >holger > > >> Looking a little more into it (wrireshark), I found out that the major >>difference is that the local authentication token is embedded in the >>request. >> >> Basically here is the example >> >> In [7]: from requests import * >> >> In [8]: session = Session() >> >> In [10]: r = session.request("get", url = >>"http://devpi-eu.dolby.net/lpbrac/dev/+api", auth=None) >> >> In [11]: r.json() >> Out[11]: >> {u'result': {u'authstatus': [u'noauth', u''], >> u'index': u'http://devpi-eu.dolby.net/lpbrac/dev/', >> u'login': u'http://devpi-eu.dolby.net/+login', >> u'pypisubmit': u'http://devpi-eu.dolby.net/lpbrac/dev/', >> u'resultlog': u'http://devpi-eu.dolby.net/+tests', >> u'simpleindex': u'http://devpi-eu.dolby.net/lpbrac/dev/+simple/'}, >> u'type': u'apiconfig'} >> >> In [13]: auth = s._devpi_cfg.get_auth() >> >> In [14]: r = session.request("get", url = >>"http://devpi-eu.dolby.net/lpbrac/dev/+api", auth=auth) >> >> In [15]: r.json() >> Out[15]: >> {u'result': {u'authstatus': [u'ok', u'lpbrac'], >> u'index': u'http://devpi-eu.dolby.net/lpbrac/dev/', >> u'login': u'http://devpi-eu.dolby.net/+login', >> u'pypisubmit': u'http://devpi-eu.dolby.net/lpbrac/dev/', >> u'resultlog': u'http://devpi-eu.dolby.net/+tests', >> u'simpleindex': u'http://devpi-eu.dolby.net/lpbrac/dev/+simple/'}, >> u'type': u'apiconfig'} >> >> In [16]: >> >> Thanks for the hintŠ I learnt something in the process. >> >> /Laurent >> >> >> On 11/20/13 5:35 AM, "holger krekel" >><hol...(a)merlinux.eu<mailto:hol...@merlinux.eu>> wrote: >> >> Hi Laurent, >> >> On Wed, Nov 20, 2013 at 00:47 +0000, Brack, Laurent P. wrote: >> Hi Holger, >> I am trying to determine if I need to re-authenticate from time to >> time (that is, even though I have the password key in the devpi client >> store, it might be expired on the server side). >> >> When I perform a devpi use, I see the following >> >>> SREQ* * * * * * * * * * * * * * * * * * * * * * * * * >> method get >> url http://devpi-eu.dolby.net/lpbrac/dev/+api >> kvdict None >> >>> EREQ* * * * * * * * * * * * * * * * * * * * * * * * * >> <<< SRESP* * * * * * * * * * * * * * * * * * * * * * * * * >> STATUS CODE: 200 >> REASON: OK >> RESULT: >> {u'authstatus': [u'ok', u'lpbrac'], >> u'index': u'http://devpi-eu.dolby.net/lpbrac/dev/', >> u'login': u'http://devpi-eu.dolby.net/+login', >> u'pypisubmit': u'http://devpi-eu.dolby.net/lpbrac/dev/', >> u'resultlog': u'http://devpi-eu.dolby.net/+tests', >> u'simpleindex': u'http://devpi-eu.dolby.net/lpbrac/dev/+simple/'} >> MESSAGE: >> <<< ERESP* * * * * * * * * * * * * * * * * * * * * * * * * >> which is processed by Current.configure_fromurl. >> So basically, if I perform a get the +api resource, how do I get the >>authentication status from the server side? >> >> In theory the "authstatus" above should tell if the login >> is "expired" (instead of "ok"), also according to >> devpi_server/view.py:117 and devpi_server/auth.py. >> >> So i guess you can do something like this:: >> >> r = requests.get("http://devpi-eu.dolby.net/lpbrac/dev/+api") >> status = r.json()["result"]["authstatus"] >> if status[0] != "ok": >> # need to re-login >> >> hope that helps. >> >> On a side note, i'd prefer to discuss such questions over the mailing >>list >> so that more people profit from the discussion. >> >> cheers, >> holger >> >> >> I hope my question is clear. >> Thanks in advance >> /Laurent >>

1 0

devpi-{server,client}-1.2.1: bug fixes + refinement to test
by holger krekel 18 Nov '13

18 Nov '13

devpi-1.2.1: bug fixes and improved test command ========================================================== The devpi-{server,client}-1.2.1 releases bring important bug fixes and refinements. See Changelog below. For getting started with deploying your own pypi server on a laptop or on company server and for using the "devpi" workflow tool (optional), see: http://doc.devpi.net If you want to upgrade an existing installation, you should be able to execute:: $ pip install -U devpi $ devpi-server --upgrade-state [--serverdir YOUR_SERVER_DIR] Have fun, holger krekel Changelog 1.2.1 ---------------------- devpi-server: - fix an import issue for doc files which were wrongly tied to a newer version of a base index. now version "auto" detection for storing doc files only works within a stage. Thanks Laurent Brack for bringing it up and providing the repo. - fix issue66: api endpoints now also respect --outside-url setting so that you can serve devpi from a subpath. Thanks for Fabian Snovna for reporting and analysis. - fix issue63: skip egg links that go to a directory (this requires doing a SVN checkout which devpi-server does not do). Thanks Ken Jung for analyzing the problem. - fix issue68: don't derive metadata from filename but instead look it up in metadata or submitted form. - fix cache-invalidation when normalized_project_name != real_name (e.g. for Django but also many others). addresses issue59. - add newline to simple list output for better human readability of the page (thanks Brandon Maister) - make xmlrpc calls to pypi's changelog API use "requests" sessions so that http proxies are respected there as well (fixes issue58). thanks to riehlm for identifying the problem and testing the fix. - internally refactor and consolidate mocking against requests library - --upgrade-state will upgrade now between major.minor/major.minor+1 changes. devpi-client: - fix "python -m devpi" invocation. Thanks Sebastian Ralph. - fix issue66: "devpi use user/index" can now switch between URLs if user/index is mounted on a subpath. - fix issue71: allow pip/setuptools like requirements specs with the test subcommand, e.g. "devpi test 'pkg>=1.0'". Thanks Sebastian Rahlf for the PR.

1 0

Inheritance and Security
by Bob Corsaro 15 Nov '13

15 Nov '13

I recently started migrating my organization from localshop to devpi, which seems to be a much more active project. Thank you to everyone who has and continues to contribute. I'm worried about what I consider a security risk when using devpi as a repository for private python packages, using pypi.python.org as the attack vector. I'd like to start a discussion with this community with the hopes of determining if my fear is well founded, and what possible solutions we can implement going forward. If a legitimate package *x* is uploaded to a private devpi index at version *n*, and an illegitimate package *x* is uploaded to pypi.python.org with a version >*n*, then it is possible that your deployment scripts, or setup.py of packages dependent on* x* will install the illegitimate package instead of the intended package. All the attacker would need to know is the package name, and possibly the version depending on how strict your dependencies are defined to pwn your system. I have thought of two possible solutions to this problem, the first being secure by default and the second insecure by default, but at least security is possible. *Secure By Default* Simply don't use inheritance on packages that exist in the child index. If *x* exists in child index then don't include *x* from the parent index. I haven't used a complicated inheritance scheme, and I don't know if others are, but this could be reduced to only excluded packages from *root/pypi*. This is also the simplest solution, but also could be disruptive depending on how you are using devpi. I can't think of a case when I personally would want both *root/pypi* and my private versions of a package included in the same index, but that's not to say it's not a valid use case for others. Valid permutations of this solution would be allowing inheritance of existing packages to be toggled per index. This is the solution I'd like to see implemented. I actually have a (probably insufficient) implementation of this solution at https://bitbucket.org/doki_pen/devpi. The change is very simple<https://bitbucket.org/doki_pen/devpi/commits/33630707a73a0aff422f757f462bf6…> . *Secure By Configuration* The other idea is less elegant and harder to implement, blacklisting inherited modules per index. This would involved extending the api to allow modules to be added to and removed from the blacklist on a per index bases. The advantage to this solution is that it would be less disruptive to any existing implementations of devpi.

2 1