Re: [Repoze-dev] Creating a custom index

[Tres Seaver]

Millie Ngoka wrote:
> Does anyone have any experience setting up a custom index, that can be used
> to install versions of specific libraries.

I'm attaching the script we use for building an index from a directory
full of tarballs.  It creates a subdirectory, 'index', which serves as
the target for 'easy_install --index' / 'index_url' (buildout.cfg).

Run it via something like:

 $ /path/to/python makeindex.py *.{gz,tgz,zip,egg}


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com



makeindex.py
Description: application/httpd-cgi
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] Creating a custom index

[Chris McDonough]

We use a derivative of http://pypi.python.org/pypi/basketweaver/0.1.2-r6 for 
this.

- C

On 5/20/09 6:17 PM, Millie Ngoka wrote:
> Does anyone have any experience setting up a custom index, that can be used
> to install versions of specific libraries.
>
> Millie
>
>
>
> 
>
> ___
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org
> http://lists.repoze.org/listinfo/repoze-dev

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] Creating a custom index

[Millie Ngoka]

Does anyone have any experience setting up a custom index, that can be used
to install versions of specific libraries.

Millie
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator

[Douglas Mayle]

Douglas Mayle  added the comment:

Hopefully, the last of the unit tests that don't work properly in Python 2.4

__
Repoze Bugs 

__

repozewho_salted_hashes_with_bcrypt.diff
Description: Binary data
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator

[admin]

System message:


__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator

[admin]

System message:


__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator

[admin]

System message:


__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator

[admin]

System message:


__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator

[Douglas Mayle]

Douglas Mayle  added the comment:

Whoops, bad unittest passed through because I was testing in Python 2.5

__
Repoze Bugs 

__

repozewho_salted_hashes_with_bcrypt.diff
Description: Binary data
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue58] Repoze.who does not allow identity to be set programmatically

[Chris McDonough]

Chris McDonough  added the comment:

What you ended up doing is the "recommended standard" right now.  Thanks for the
report.

--
status: chatting -> resolved

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator

[Douglas Mayle]

Douglas Mayle  added the comment:

New version of the patch which also supports blowfish hashes when bcrypt is
installed, and uses pycrypto on python < 2.5 for sha256 support.  This patch
superseded the previous two patches.

__
Repoze Bugs 

__

repozewho_salted_hashes_with_bcrypt.diff
Description: Binary data
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue73] repoze.who IAuthenticator cannot report the reason for authentication failure

[Chris McDonough]

Chris McDonough  added the comment:

Note that you can use the "identity" or "environ" passed in to an authenticator
as a scratchpad to communicate with other plugins (such as the challenger).

--
status: unread -> resolved

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue74] repoze.who form plugins have no obvious way to show "logged out" or "login failed" messages

[Chris McDonough]

Chris McDonough  added the comment:

Form plugins will be deprecated for common use in the next release of r.who,
FWIW.  It's much easier to tell people to return a login form as their
"unauthorized" response rather than trying to "challenge" based on a 401
response from the application and do arbitrary things to pass through reasons
for failure and so on.

But for the record, the RedirectingFormPlugin currently has such a facility
(albeit undocumented but in CHANGES.txt): if the unauthorized response contains
a header named X-Authentication-Failure-Reason, that will cause the redirect to
the login form to contain a "reason" query string parameter will the value  of
that header.

--
status: unread -> resolved

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue75] repoze.who should document logging.Logger support

[Chris McDonough]

Chris McDonough  added the comment:

Fixed in r4790 of the trunk, thank you.

--
status: unread -> resolved

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue77] repoze.who metadata plugin is called on every request

[Chris McDonough]

Chris McDonough  added the comment:

You can currently write your own metadata plugin which could try to get info
from a cookie value first, then the database.  Or better yet, retrieve the data
from cache instead of the database or a cookie.

But in general, yes, the "eagerness" of repoze.who to populate the repoze.who
identity into the environment is a design bug.  We'll try to do something about
it in the next version of repoze.who (v2).  For example, instead of "eagerly"
populating the environment with "repoze.who.identity", we might put a callback
in the environment that must be called to get metadata.  This would help with
requests to static resources and so on.

--
status: unread -> resolved

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue82] Add HashFormPlugin - JavaScript hashing

[Chris McDonough]

Chris McDonough  added the comment:

We're actually trying to encourage people to release plugins in separate
packages these days.   This is a good candidate.  I'm going to mark this one as
"resolved" as a result, although really the task is to create a separate Python
package that houses the hashform.py module and tests.  For a sample of how
others have packaged repoze.who plugins, see
http://pypi.python.org/pypi/repoze.who-friendlyform/1.0b3

--
status: in-progress -> resolved

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue80] [patch] advise against using include_ip

[Tres Seaver]

Tres Seaver  added the comment:

Duplicates #81, already closed.

--
status: unread -> resolved

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] SQLAuthenticator Plugin...

[David Turner]

Doug's analysis of the patch is right on, but he doesn't go far enough.

1. The author of the patch clearly thinks that security consists of
sprinkling magic SHA-1 HMAC challenge response pixie dust over the code
in a random fashion.  This means that any revised patch must be viewed
with suspicion.

2. SHA-1 isn't even the recommended flavor of pixie dust anymore.  Use
SHA-256.

The right thing to do is have the login over SSL.

The next best thing to do is to use SRP.  It's the only thing that lets
you have secure passwords on the server and secure transmission of
passwords from the client.  There's a Javacsript library available at
http://sourceforge.net/projects/clipperz

Otherwise you have a choice of insecure password storage or insecure
password transmission.



___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue79] [patch] Some tests fail on Windows

[Tres Seaver]

Tres Seaver  added the comment:

Fix committed in r4788.

--
assignedto:  -> tseaver
nosy: +tseaver
status: in-progress -> resolved

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue79] [patch] Some tests fail on Windows

[Paul Johnston]

Paul Johnston  added the comment:

Yep, works a treat

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue79] [patch] Some tests fail on Windows

[Tres Seaver]

Tres Seaver  added the comment:

Does adding a call to 'logging.shutdown()' at the end of that
testcase make Windows happy?

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue79] [patch] Some tests fail on Windows

[Paul Johnston]

Paul Johnston  added the comment:

Nearly there... you hit the same problem I did. We need to close the log file.

ERROR: test_sample_config_w_log_file (repoze.who.tests.test_config.TestConfigMid
dleware)
--
Traceback (most recent call last):
  File "C:\code\repoze.who\repoze\who\tests\test_config.py", line 337, in tearDo
wn
shutil.rmtree(self.tempdir)
  File "c:\python25\lib\shutil.py", line 180, in rmtree
onerror(os.remove, fullname, sys.exc_info())
  File "c:\python25\lib\shutil.py", line 178, in rmtree
os.remove(fullname)
WindowsError: [Error 32] The process cannot access the file because it is being
used by another process: 'c:\\docume~1\\paul\\locals~1\\temp\\tmpwtmexf\\who.log
'

--
Ran 206 tests in 2.688s

FAILED (errors=1)

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] SQLAuthenticator Plugin...

[Paul Johnston]

Hi,

> I've had a look at your patch, and I've noticed a couple of security
> holes...  If your only desire is to prevent eavesdropping of passwords, I
> suggest you use SSL, as this is a system that actually works (if used
> correctly).

Although it has limitations, some people want this feature. I'm not
proposing this be the default authentication method; if you don't want
it, don't use it in your applications. The risks are well understood;
you may like to read my site for more information
http://pajhome.org.uk/crypt/md5/

>   The hashing system is entirely optional at the client level, so you don't
> provide password protection for all clients.

Sure. We could potentially have a server-side option
allow_disabled_js, with the html tweaked so the submit button only
appears when js is enabled. Not something for the first attempt
though, and in fact, I expect almost everyone would rather allow users
without javascript.

> * The challenge used for verification is the challenge supplied by the
> client.  This defeats entirely the point of a challenge.  I see you do some

Sure. Instead of seeing a plaintext password, a sniffer sees a hash
that they can replay in a given time window, and try to brute force
the password against. That's better than them seeing a plaintext
password. The session key is going plaintext on the wire anyway, so
replay attacks are a risk anyway.

> * You're performing an HMAC with the challenge as the key.  The purpose of
> an HMAC is to provide authentication of the message in the case of a shared

That's one purpose of an HMAC. Here, we're using HMAC differently, as
an alternative to sha1(password + challenge). I don't think there's
any great cryptographic advantages to this, but it is the recommended
way - I communicated with one of the authors of the HMAC RFC about
this a few years ago. Not got the mail to hand now.

> * In the case of a hashed password, you perform an HMAC of the hashed
> password.  In a standard hashed password system, the user must know the

Good point. This is a serious enough weakness that the docs should
mention it, and I can look at revising the patch. But with salted
hashes, it keeps the main benefit of hashing - that a captured
password database doesn't let the attacker use your customers'
password on other sites. Remember, if an attacker has your password
database, they're pretty far into your app already.

Paul
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue82] Add HashFormPlugin - JavaScript hashing

[Douglas Mayle]

Douglas Mayle  added the comment:

I've commented on this patch on the mailing list, but wanted to make sure my
concerns were recorded here:
* `if cleartext_password.startswith('{SHA}'):`
   The hashing system is entirely optional at the client level, so  
you don't provide password protection for all clients.

* The challenge used for verification is the challenge supplied by the  
client.  This defeats entirely the point of a challenge.  I see you do  
some calculations to restrict the range of possible challenges (based  
on time), but a challenge response only works if the challenge is  
random and server supplied.  If not, then it's vulnerable to pre- 
computation...

* You're performing an HMAC with the challenge as the key.  The  
purpose of an HMAC is to provide authentication of the message in the  
case of a shared private key.  In this case, the key is public (as  
it's sent over the wire) and that means that there is no difference  
between this HMAC and a standard hash.

* In the case of a hashed password, you perform an HMAC of the hashed  
password.  In a standard hashed password system, the user must know  
the clear text password in order to log in.  The point of the hash is  
to prevent authentication in the case of a database leak.  In your  
system, the hashed password is sufficient to login, and so you've  
removed the protection that password hashing provides.

* While it's true that using a different key per request means that  
attackers who sniff the HMAC won't be able to use rainbow tables to  
compute the password from the HMAC, the passwords are still stored as  
standard hashed passwords, and that means that a db leak leaves all of  
your accounts compromised.  With salted hashes, that is not true...

--
topic: +repoze.who

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] SQLAuthenticator Plugin...

[Douglas Mayle]

I've had a look at your patch, and I've noticed a couple of security  
holes...  If your only desire is to prevent eavesdropping of  
passwords, I suggest you use SSL, as this is a system that actually  
works (if used correctly).
For each issue, I'll address the problem as if it stands apart to give  
a clear idea of the problems:
* `if cleartext_password.startswith('{SHA}'):`
The hashing system is entirely optional at the client level, so  
you don't provide password protection for all clients.

* The challenge used for verification is the challenge supplied by the  
client.  This defeats entirely the point of a challenge.  I see you do  
some calculations to restrict the range of possible challenges (based  
on time), but a challenge response only works if the challenge is  
random and server supplied.  If not, then it's vulnerable to pre- 
computation...

* You're performing an HMAC with the challenge as the key.  The  
purpose of an HMAC is to provide authentication of the message in the  
case of a shared private key.  In this case, the key is public (as  
it's sent over the wire) and that means that there is no difference  
between this HMAC and a standard hash.

* In the case of a hashed password, you perform an HMAC of the hashed  
password.  In a standard hashed password system, the user must know  
the clear text password in order to log in.  The point of the hash is  
to prevent authentication in the case of a database leak.  In your  
system, the hashed password is sufficient to login, and so you've  
removed the protection that password hashing provides.

* While it's true that using a different key per request means that  
attackers who sniff the HMAC won't be able to use rainbow tables to  
compute the password from the HMAC, the passwords are still stored as  
standard hashed passwords, and that means that a db leak leaves all of  
your accounts compromised.  With salted hashes, that is not true...

Douglas Mayle

On May 20, 2009, at 12:07 AM, Paul Johnston wrote:

> Hi,
>
> Your timing is interesting, I'm just about to submit a patch to
> support JavaScript hashing of passwords, which interacts with this.
>
> If you use random per-user salts, which is the common approach, JS
> hashing requires an Ajax request at login. Not an enormous problem,
> but not ideal either.
>
> If the salt is hmac_sha1(master_salt, user_name) or some variant of
> this, you get the same benefits of salting, but avoid the ajax request
> at login. master_salt is a site-specific value.

This is only true as long as the secret is not known.  As soon as the  
secret is made available to the client (as in javascript hashing)  
there are no longer any benefits to using an HMAC...

>
>
> Paul
>
>
>>> So, I've finished it off and submitted the patch to issue 85:
>>> http://bugs.repoze.org/issue85

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue81] [patch] advise against using include_ip

[Tres Seaver]

Tres Seaver  added the comment:

I have checked in a modified version of this patch (I put the
advisory in an ReST '.. note::').

--
assignedto:  -> tseaver
nosy: +tseaver
status: resolved -> chatting

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue79] [patch] Some tests fail on Windows

[Tres Seaver]

Tres Seaver  added the comment:

I plan to check in an alternate patch which uses 'tempfile.mkdtemp',
with appropriate cleanup of the tempdir.  Can you confirm that it
works for you on Windows?

__
Repoze Bugs 

__Index: repoze/who/plugins/tests/test_authtkt.py
===
--- repoze/who/plugins/tests/test_authtkt.py	(revision 4784)
+++ repoze/who/plugins/tests/test_authtkt.py	(working copy)
@@ -1,7 +1,16 @@
 import unittest
 
 class TestAuthTktCookiePlugin(unittest.TestCase):
+tempdir = None
 
+def setUp(self):
+pass
+
+def tearDown(self):
+if self.tempdir is not None:
+import shutil
+shutil.rmtree(self.tempdir)
+
 def _getTargetClass(self):
 from repoze.who.plugins.auth_tkt import AuthTktCookiePlugin
 return AuthTktCookiePlugin
@@ -280,11 +289,15 @@
 self.assertEqual(plugin.secure, False)
 
 def test_factory_w_secretfile(self):
-from tempfile import NamedTemporaryFile
+import os
+from tempfile import mkdtemp
 from repoze.who.plugins.auth_tkt import make_plugin
-ntf = NamedTemporaryFile()
-ntf.write('s33kr1t\n')
-ntf.flush()
-plugin = make_plugin(secretfile=ntf.name)
+tempdir = self.tempdir = mkdtemp()
+path = os.path.join(tempdir, 'who.secret')
+secret = open(path, 'w')
+secret.write('s33kr1t\n')
+secret.flush()
+secret.close()
+plugin = make_plugin(secretfile=path)
 self.assertEqual(plugin.secret, 's33kr1t')
 
Index: repoze/who/tests/test_config.py
===
--- repoze/who/tests/test_config.py	(revision 4784)
+++ repoze/who/tests/test_config.py	(working copy)
@@ -326,62 +326,68 @@
 """
 
 class TestConfigMiddleware(unittest.TestCase):
-tempfile = None
+tempdir = None
 
 def setUp(self):
 pass
 
 def tearDown(self):
-if self.tempfile is not None:
-self.tempfile.close()
+if self.tempdir is not None:
+import shutil
+shutil.rmtree(self.tempdir)
 
 def _getFactory(self):
 from repoze.who.config import make_middleware_with_config
 return make_middleware_with_config
 
 def _getTempfile(self, text):
+import os
 import tempfile
-tf = self.tempfile = tempfile.NamedTemporaryFile()
-tf.write(text)
-tf.flush()
-return tf
+tempdir = self.tempdir = tempfile.mkdtemp()
+path = os.path.join(tempdir, 'who.ini')
+config = open(path, 'w')
+config.write(text)
+config.flush()
+config.close()
+return path
 
 def test_sample_config(self):
+import logging
+from repoze.who.interfaces import IIdentifier
+from repoze.who.interfaces import IAuthenticator
+from repoze.who.interfaces import IChallenger
 app = DummyApp()
 factory = self._getFactory()
-tempfile = self._getTempfile(SAMPLE_CONFIG)
+path = self._getTempfile(SAMPLE_CONFIG)
 global_conf = {'here': '/'}
-middleware = factory(app, global_conf, config_file=tempfile.name,
+middleware = factory(app, global_conf, config_file=path,
  log_file='STDOUT', log_level='debug')
-from repoze.who.interfaces import IIdentifier
-from repoze.who.interfaces import IAuthenticator
-from repoze.who.interfaces import IChallenger
 self.assertEqual(len(middleware.registry[IIdentifier]), 3)
 self.assertEqual(len(middleware.registry[IAuthenticator]), 1)
 self.assertEqual(len(middleware.registry[IChallenger]), 2)
 self.failUnless(middleware.logger, middleware.logger)
-import logging
 self.assertEqual(middleware.logger.getEffectiveLevel(), logging.DEBUG)
 
 def test_sample_config_no_log_level(self):
+import logging
 app = DummyApp()
 factory = self._getFactory()
-tempfile = self._getTempfile(SAMPLE_CONFIG)
+path = self._getTempfile(SAMPLE_CONFIG)
 global_conf = {'here': '/'}
-middleware = factory(app, global_conf, config_file=tempfile.name,
+middleware = factory(app, global_conf, config_file=path,
  log_file='STDOUT')
-import logging
 self.assertEqual(middleware.logger.getEffectiveLevel(), logging.INFO)
 
 def test_sample_config_w_log_file(self):
+import logging
+import os
 app = DummyApp()
 factory = self._getFactory()
-tempfile = self._getTempfile(SAMPLE_CONFIG)
-logfile = self._getTempfile('')
+path = self._getTempfile(SAMPLE_CONFIG)
+logfile = os.path.join(self.tempdir, 'who.log')
 global_conf = {'here': '/'}
-