[Twisted-Python] Password hash for Perspective Brokers

[Louis]

Hello
I have a problem with checkers in Twisted, which could be solved by
adding a new feature. I think I can write the necessary code, but before
doing so, I would like to hear you about it.

# The problem

If I am right, the only way passwords can be hashed when using
authentication with perspective brokers is using MD5 [1]. However, there
are two flaws with it.

* First, MD5 is no longer considered sure. It may be possible, from the
hashed password, to find the original one.
* Second, in the current implementation of Twisted, no salt is used to
hash the password. A salt is considered good practise : it is harder to
find the password from the hashed form, and two identical passwords have
different hashed form, which prevent someone looking at the hashed
passwords to see if two users have the same password.

# A solution

I tried to implement the solution proposed in [1], and I think I can
manage to do it. However, this seems to be a not-so-smart hack, which is
not guaranteed to work in future releases of Twisted. That is why I am
proposing a patch.

The patch would introduce some arguments to class PBServerFactory [2]
to use (or not) a salt, and a different hash function. I am not settled
down yet about the new signature of this class, but what is sure is that
the default must be the actual behaviour, not to break programs already
using Twisted. Then, I hesitate between

* two arguments (salt, hash) : salt is a boolean, telling whether to use
a salt or not ; hash is the function used to hash the password;

* one argument, with possible values being "legacy", "crypt" or "glib2",
where:

** "legacy": current behaviour : hashed passwords are md5 hashed
passwords without salt;
** "crypt" : crypt [3] behaviour (I would like it to be compatible with
[4]): hashed passwords are strings where the first two characters are
the salt, and the following ones are the hashed password (using this salt);
** "glib2" : glib2 [5] behaviour: hashed password is of the form
$ID$SALT$HASH, where ID identifies the encryption method, SALT being the
salt, and HASH being the password, hashed using given encryption method
and salt.

# My implementation

I have not implemented it yet, but I you think my idea is good, I offer
to write it. I think I have understood well enough the relevant pieces
of code to do so. Of course, I would also write the corresponding tests.


Some ideas or comments ?
Cheers,
Louis


[1] http://markmail.org/message/wlzmeesplsriym2a
[2]
http://twistedmatrix.com/documents/current/api/twisted.spread.pb.PBServerFactory.html
[3] http://man7.org/linux/man-pages/man3/crypt.3.html
[4] http://www.giuseppetanzilli.it/mod_auth_pgsql2/#encrypted
[5] http://www.gnu.org/software/libc/manual/html_node/crypt.html#crypt

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] [RFC] Introducing six as a dependency

[Vladimir Perić]

Hello all,

as part of my work on porting Twisted to Python 3, I have considered
using the six library[1] to help with some issues. six is basically a
compatibility library - same idea as our twisted.python.compat module.
Now, one approach is to add six as a dependency of Twisted - it is a
very small library so hardly a problem; on the other hand, it is an
additional dependency. The other approach would be to copy the
required code over to the t.p.compat module (six' license[2] is
basically "do what you want with this code"), but this is additional
work and we might miss out on the eventual bugfix (though there has
only been a couple since the project started). In general, I have
heard good things about six.

As a note, currently, I would need at least the reraise and exec_
functions from six; additionally, a lot of the things from the
six.moves package are useful. And, of course, there might be other
compatibility functions which I'd need, I just haven't encountered yet
(I do only use these if absolutely required, though).

What do you all think? In the end, it boils down to "additional
dependency" vs. "less code to maintain".

Personally, I could go either way - using six makes things slightly
easier, but I could just copy over the code we need and be done with
it.


[1] http://packages.python.org/six/
[2] https://bitbucket.org/gutworth/six/src/d81f633c45dd/LICENSE
-- 
Vladimir Perić

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [RFC] Introducing six as a dependency

[Jonathan Lange]

On Thu, Jul 26, 2012 at 4:55 PM, Vladimir Perić  wrote:
> Hello all,
>

Hi!

...
> Now, one approach is to add six as a dependency of Twisted - it is a
> very small library so hardly a problem; on the other hand, it is an
> additional dependency.
...
> What do you all think? In the end, it boils down to "additional
> dependency" vs. "less code to maintain".
>

Not strictly what I think, but here's the relevant bits from what
Glyph said last time I asked about adding a dependency, testtools, to
Twisted:

"""
Users still routinely struggle with the one dependency we allowed
Twisted core to have - zope.interface. I do still think that's worth
it, since it freed us from a significant and complex maintenance
burden.  And I do sometimes wish that we could make it an optional or
bundled dependency, to give users who have to download Twisted
themselves a gentler on-ramp. [...]

[...] I would set the bar very high for making testtools a required
dependency for Twisted's own test suite.  Just for starters, the
Python packaging ecosystem disaster would need to be fixed; also, the
name of the package should be changed to be more unique so that users
wouldn't find things like  and
 when searching around the web
for the contents of the inevitable packaging error message.
"""

jml

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [RFC] Introducing six as a dependency

[Duncan McGreggor]

On Thu, Jul 26, 2012 at 10:55 AM, Vladimir Perić  wrote:
> Hello all,
>
> as part of my work on porting Twisted to Python 3, I have considered
> using the six library[1] to help with some issues. six is basically a
> compatibility library - same idea as our twisted.python.compat module.
> Now, one approach is to add six as a dependency of Twisted - it is a
> very small library so hardly a problem; on the other hand, it is an
> additional dependency. The other approach would be to copy the
> required code over to the t.p.compat module (six' license[2] is
> basically "do what you want with this code"), but this is additional
> work and we might miss out on the eventual bugfix (though there has
> only been a couple since the project started). In general, I have
> heard good things about six.
>
> As a note, currently, I would need at least the reraise and exec_
> functions from six; additionally, a lot of the things from the
> six.moves package are useful. And, of course, there might be other
> compatibility functions which I'd need, I just haven't encountered yet
> (I do only use these if absolutely required, though).
>
> What do you all think? In the end, it boils down to "additional
> dependency" vs. "less code to maintain".
>
> Personally, I could go either way - using six makes things slightly
> easier, but I could just copy over the code we need and be done with
> it.

FWIW, I'm +1 on copying the bits we need into Twisted and +0 on adding
a new dep.

d

>
> [1] http://packages.python.org/six/
> [2] https://bitbucket.org/gutworth/six/src/d81f633c45dd/LICENSE
> --
> Vladimir Perić
>
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [RFC] Introducing six as a dependency

[Laurens Van Houtven]

Does Glyph still believe these arguments to be true today? I don't know how 
long ago he said that, but I do know there's a lot of stuff that's been done to 
make packaging better :)

Perhaps we could look into shipping twisted releases with and without 
dependencies? I personally have no such issues since I just let pip/tox handle 
everything for me and it figures it out already.


cheers
lvh



On 26 Jul 2012, at 18:02, Jonathan Lange  wrote:

> On Thu, Jul 26, 2012 at 4:55 PM, Vladimir Perić  wrote:
>> Hello all,
>> 
> 
> Hi!
> 
> ...
>> Now, one approach is to add six as a dependency of Twisted - it is a
>> very small library so hardly a problem; on the other hand, it is an
>> additional dependency.
> ...
>> What do you all think? In the end, it boils down to "additional
>> dependency" vs. "less code to maintain".
>> 
> 
> Not strictly what I think, but here's the relevant bits from what
> Glyph said last time I asked about adding a dependency, testtools, to
> Twisted:
> 
> """
> Users still routinely struggle with the one dependency we allowed
> Twisted core to have - zope.interface. I do still think that's worth
> it, since it freed us from a significant and complex maintenance
> burden.  And I do sometimes wish that we could make it an optional or
> bundled dependency, to give users who have to download Twisted
> themselves a gentler on-ramp. [...]
> 
> [...] I would set the bar very high for making testtools a required
> dependency for Twisted's own test suite.  Just for starters, the
> Python packaging ecosystem disaster would need to be fixed; also, the
> name of the package should be changed to be more unique so that users
> wouldn't find things like  and
>  when searching around the web
> for the contents of the inevitable packaging error message.
> """
> 
> jml
> 
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [RFC] Introducing six as a dependency

[Gavin Panella]

On 26 July 2012 16:55, Vladimir Perić  wrote:
...
> As a note, currently, I would need at least the reraise and exec_
> functions from six;

Fwiw, reraise is fairly trivial and wouldn't be a big thing to carry
in Twisted.

exec(code, [globals, [locals]]) works on both Python 2 and Python 3,
and seem to have similar behaviour, so I'm not sure why exec_ is
needed. Indeed, test_exec_() from the six source passes using the
builtin exec in place of six.exec_. Ah, I've tried only with Python
2.6 and 2.7; perhaps there are differences on earlier 2.x versions?

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [RFC] Introducing six as a dependency

[Jonathan Lange]

On Thu, Jul 26, 2012 at 5:22 PM, Laurens Van Houtven <_...@lvh.cc> wrote:
> Does Glyph still believe these arguments to be true today? I don't know how 
> long ago he said that, but I do know there's a lot of stuff that's been done 
> to make packaging better :)

Sorry, should have dated: Feb 6, 2012.

jml

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Password hash for Perspective Brokers

[exarkun]

On 02:28 pm, spa...@gresille.org wrote:
> Hello
> I have a problem with checkers in Twisted, which could be 
>solved by
>adding a new feature. I think I can write the necessary code, but 
>before
>doing so, I would like to hear you about it.
>
># The problem
>
> If I am right, the only way passwords can be hashed when using
>authentication with perspective brokers is using MD5 [1]. However, 
>there
>are two flaws with it.
>
>* First, MD5 is no longer considered sure. It may be possible, from the
>hashed password, to find the original one.
>* Second, in the current implementation of Twisted, no salt is used to
>hash the password. A salt is considered good practise : it is harder to
>find the password from the hashed form, and two identical passwords 
>have
>different hashed form, which prevent someone looking at the hashed
>passwords to see if two users have the same password.

The second point is incorrect.  The hash is salted.  See the `respond` 
method in twisted/spread/pb.py.
># A solution
>
> I tried to implement the solution proposed in [1], and I think 
>I can
>manage to do it. However, this seems to be a not-so-smart hack, which 
>is
>not guaranteed to work in future releases of Twisted. That is why I am
>proposing a patch.
>
> The patch would introduce some arguments to class 
>PBServerFactory [2]
>to use (or not) a salt, and a different hash function. I am not settled
>down yet about the new signature of this class, but what is sure is 
>that
>the default must be the actual behaviour, not to break programs already
>using Twisted. Then, I hesitate between

A good approach would be to parameterize the supported authentication 
mechanisms in an extensible way, rather than just hard coding one or two 
new (probably better) options.

In other words, a SASL implementation for PB would be the best way to 
go.

The existing API and behavior should indeed be preserved as-is for 
backwards compatibility.  The new authentication features should be 
exposed under a new API - either as new optional arguments accepted by 
PBServerFactory (and perhaps PBClientFactory) and new login methods 
(again, probably on those two classes).

Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [RFC] Introducing six as a dependency

[Antoine Pitrou]

On Thu, 26 Jul 2012 17:55:50 +0200
Vladimir Perić  wrote:
> Hello all,
> 
> as part of my work on porting Twisted to Python 3, I have considered
> using the six library[1] to help with some issues. six is basically a
> compatibility library - same idea as our twisted.python.compat module.
> Now, one approach is to add six as a dependency of Twisted - it is a
> very small library so hardly a problem; on the other hand, it is an
> additional dependency. The other approach would be to copy the
> required code over to the t.p.compat module (six' license[2] is
> basically "do what you want with this code"), but this is additional
> work and we might miss out on the eventual bugfix (though there has
> only been a couple since the project started).

Copying them sounds like the saner approach to me. These
compatibility wrappers are unlikely to change significantly, and
requiring a dependency on such a small module is not very helpful.

If you really want to minimize maintenance, you can also ship six as a
twisted.python submodule, and synchronize the copy when there are
interesting bug fixes.

Regards

Antoine.


-- 
Software development and contracting: http://pro.pitrou.net



___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [RFC] Introducing six as a dependency

[Vladimir Perić]

On 7/26/12, Gavin Panella  wrote:
> On 26 July 2012 16:55, Vladimir Perić  wrote:
> ...
>> As a note, currently, I would need at least the reraise and exec_
>> functions from six;
>
> Fwiw, reraise is fairly trivial and wouldn't be a big thing to carry
> in Twisted.
>
> exec(code, [globals, [locals]]) works on both Python 2 and Python 3,
> and seem to have similar behaviour, so I'm not sure why exec_ is
> needed. Indeed, test_exec_() from the six source passes using the
> builtin exec in place of six.exec_. Ah, I've tried only with Python
> 2.6 and 2.7; perhaps there are differences on earlier 2.x versions?

Actually, Twisted now only supports 2.6 and 2.7 anyway, the issue is
that the old syntax "exec code in globs, locs" is a SyntaxError in
Python 3.


In any case, in light of the discussions (and especially Jonathan's
repost of Glyph's opinion), I'll opt for copying the required code to
our twisted.python.compat module (copying the whole of six is not
really practical, particularly because we'd still need additional
compatibility modules).

Thanks all for giving your input.

>
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>


-- 
Vladimir Perić

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [RFC] Introducing six as a dependency

[Glyph]

Le Jul 26, 2012 à 9:21 AM, Duncan McGreggor  a 
écrit :

> FWIW, I'm +1 on copying the bits we need into Twisted and +0 on adding
> a new dep.

I'd be closer to +0 on copying the bits we need (I'm not excited about it, but 
it seems to be necessary) and -1 on adding them as a new dependency, for the 
reasons that jml already cited.

-glyph___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Password hash for Perspective Brokers

[Kevin Horn]

On Thu, Jul 26, 2012 at 11:43 AM,  wrote:

> On 02:28 pm, spa...@gresille.org wrote:
> > Hello
> > I have a problem with checkers in Twisted, which could be
> >solved by
> >adding a new feature. I think I can write the necessary code, but
> >before
> >doing so, I would like to hear you about it.
> >
> ># The problem
> >
> > If I am right, the only way passwords can be hashed when using
> >authentication with perspective brokers is using MD5 [1]. However,
> >there
> >are two flaws with it.
> >
> >* First, MD5 is no longer considered sure. It may be possible, from the
> >hashed password, to find the original one.
> >* Second, in the current implementation of Twisted, no salt is used to
> >hash the password. A salt is considered good practise : it is harder to
> >find the password from the hashed form, and two identical passwords
> >have
> >different hashed form, which prevent someone looking at the hashed
> >passwords to see if two users have the same password.
>
> The second point is incorrect.  The hash is salted.  See the `respond`
> method in twisted/spread/pb.py.
> ># A solution
> >
> > I tried to implement the solution proposed in [1], and I think
> >I can
> >manage to do it. However, this seems to be a not-so-smart hack, which
> >is
> >not guaranteed to work in future releases of Twisted. That is why I am
> >proposing a patch.
> >
> > The patch would introduce some arguments to class
> >PBServerFactory [2]
> >to use (or not) a salt, and a different hash function. I am not settled
> >down yet about the new signature of this class, but what is sure is
> >that
> >the default must be the actual behaviour, not to break programs already
> >using Twisted. Then, I hesitate between
>
> A good approach would be to parameterize the supported authentication
> mechanisms in an extensible way, rather than just hard coding one or two
> new (probably better) options.
>
> In other words, a SASL implementation for PB would be the best way to
> go.
>
> The existing API and behavior should indeed be preserved as-is for
> backwards compatibility.  The new authentication features should be
> exposed under a new API - either as new optional arguments accepted by
> PBServerFactory (and perhaps PBClientFactory) and new login methods
> (again, probably on those two classes).
>
> Jean-Paul
>
>
It would probably also help if someone finished the "Generic SASL
implementation" ticket.

Lessee, who was working on that last?

Crap. It was me.

Sorry about that.

Kevin Horn
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [RFC] Introducing six as a dependency

[Glyph]

Le Jul 26, 2012 à 9:22 AM, Laurens Van Houtven <_...@lvh.cc> a écrit :

> Perhaps we could look into shipping twisted releases with and without 
> dependencies? I personally have no such issues since I just let pip/tox 
> handle everything for me and it figures it out already.

This is only accurate to within a first approximation, but... pip does not work 
for Windows users.  And easy_install there comes with its own set of warts.  So 
there's no good answer.

If you have a good proposal for how to ship a sumo Twisted which bundles all 
its dependencies in a way that would actually reach the users who encounter 
dependency management problems, that would be great.  I think it would be 
worthwhile to discuss it privately first though, since there are enough 
publicly-archived flamewars about Python packaging technology ;-).

-glyph___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Deferreds and progress

[Tobias Oberstein]

With Twisted, a Deferred can have it's callback only triggered once.

With Deferreds in popular JavaScript libraries (when.js, jQuery Deferred, 
upcoming JS PromiseA proposal),
there is a "progress()" callback for receiving results incrementally (or merely 
reporting on progress
until the final result arrives). Progress can be triggered more than once.

Is there anything comparable in Twisted?

Cheers,
Tobias

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Deferreds and progress

[Itamar Turner-Trauring]

On Thu, Jul 26, 2012 at 1:51 PM, Tobias Oberstein <
tobias.oberst...@tavendo.de> wrote:

> With Twisted, a Deferred can have it's callback only triggered once.
>
> ** **
>
> With Deferreds in popular JavaScript libraries (when.js, jQuery Deferred,
> upcoming JS PromiseA proposal),
>
> there is a "progress()" callback for receiving results incrementally (or
> merely reporting on progress
>
> until the final result arrives). Progress can be triggered more than once.
> 
>
> ** **
>
> Is there anything comparable in Twisted?
>

For chunks of data, Protocols; e.g. twisted.web.client.Agent delivers HTTP
response bodies to a Protocol instance. More generally, Glyph is working on
this: http://twistedmatrix.com/trac/ticket/1956
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Deferreds and progress

[Tobias Oberstein]

>>On Thu, Jul 26, 2012 at 1:51 PM, Tobias Oberstein 
>> wrote:
>>With Twisted, a Deferred can have it's callback only triggered once.
>>
>>With Deferreds in popular JavaScript libraries (when.js, jQuery Deferred, 
>>upcoming JS PromiseA proposal),
>>there is a "progress()" callback for receiving results incrementally (or 
>>merely reporting on progress
>>until the final result arrives). Progress can be triggered more than once.
>> 
>>Is there anything comparable in Twisted?

>For chunks of data, Protocols; e.g. twisted.web.client.Agent delivers HTTP 
>response bodies to a Protocol instance. More generally, Glyph is working on 
>this: http://twistedmatrix.com/trac/ticket/1956

Thanks for pointing. So if something like this is added to Twisted, it will be 
within producer/consumer, and not added to Deferred?

The reason I am asking: Autobahn implements RPC over WebSocket, and people have 
been asking why RPC results
can't be delivered in parts, as progress. However, an Autobahn RPC returns a 
Deferred, not a producer.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [RFC] Introducing six as a dependency

[Kevin Horn]

On Thu, Jul 26, 2012 at 12:48 PM, Glyph  wrote:

> Le Jul 26, 2012 à 9:22 AM, Laurens Van Houtven <_...@lvh.cc> a écrit :
>
> Perhaps we could look into shipping twisted releases with and without
> dependencies? I personally have no such issues since I just let pip/tox
> handle everything for me and it figures it out already.
>
>
> This is only accurate to within a first approximation, but... pip does not
> work for Windows users.
>

Um, howso?  I use it all the time, including for installing Twisted.
 Unless you mean it doesn't work fro installing twisted for those who don't
have a C compiler, which I guess could be true.  I always have one
installed, so I haven't tried without one.

Kevin Horn
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Deferreds and progress

[Itamar Turner-Trauring]

On Thu, Jul 26, 2012 at 2:44 PM, Tobias Oberstein <
tobias.oberst...@tavendo.de> wrote:

>
> Thanks for pointing. So if something like this is added to Twisted, it
> will be within producer/consumer, and not added to Deferred?
>
> The reason I am asking: Autobahn implements RPC over WebSocket, and people
> have been asking why RPC results
> can't be delivered in parts, as progress. However, an Autobahn RPC returns
> a Deferred, not a producer.
>

A replacement API for producer/consumer.

You might say, I just want streaming results... but then you really want to
pause upstream if you can't handle it, and you want to be able to chain
streams of data (which is where Protocols fail), and so you end up with a
more complex API than "call this function with data every time it
arrives".  And that's the goal of that ticket.

Of course, if you want something super simple, you can implement if you
want for your code only.

-- 
Itamar Turner-Trauring, Future Foundries LLC
http://futurefoundries.com/ — Twisted consulting, training and support.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [RFC] Introducing six as a dependency

[Itamar Turner-Trauring]

On Thu, Jul 26, 2012 at 3:06 PM, Kevin Horn  wrote:

>
> This is only accurate to within a first approximation, but... pip does not
>> work for Windows users.
>>
>
>
> Um, howso?  I use it all the time, including for installing Twisted.
>  Unless you mean it doesn't work fro installing twisted for those who don't
> have a C compiler, which I guess could be true.  I always have one
> installed, so I haven't tried without one.
>

My attempt to set things up on Windows did not go well, at all. Getting a
compiler going was IIRC non-trivial.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [RFC] Introducing six as a dependency

[Glyph]

Le Jul 26, 2012 à 12:06 PM, Kevin Horn  a écrit :

> ... for those who don't have a C compiler ...

AKA "windows users".

Even having full access to MSDN, it can be incredibly obscure to discover which 
Python version goes with which Visual Studio product.  (Someone, please prove 
me wrong and indicate that there's a web page that shows what the official 
python.org builds use and you don't have to go trawling through python-dev 
archives to figure it out...)

-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Password hash for Perspective Brokers

[Glyph]

Le Jul 26, 2012 à 10:36 AM, Kevin Horn  a écrit :

> 
> It would probably also help if someone finished the "Generic SASL 
> implementation" ticket.
> 
> Lessee, who was working on that last?
> 
> Crap. It was me. 
> 
> Sorry about that.

If you're looking for some encouragement and help on that ticket, Ralph Meijer 
has been looking at doing some work in that area, and generalizing the SASL 
support in twisted.words (as well as doing more SASL/cred integration on the 
server side).  I spoke to him at the last sprint in San Francisco.

Hopefully you can get together and prompt each other to actually finish it ;-).

-glyph
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Password hash for Perspective Brokers

[Kevin Horn]

On Thu, Jul 26, 2012 at 4:12 PM, Glyph  wrote:

> Le Jul 26, 2012 à 10:36 AM, Kevin Horn  a écrit :
>
> >
> > It would probably also help if someone finished the "Generic SASL
> implementation" ticket.
> >
> > Lessee, who was working on that last?
> >
> > Crap. It was me.
> >
> > Sorry about that.
>
> If you're looking for some encouragement and help on that ticket, Ralph
> Meijer has been looking at doing some work in that area, and generalizing
> the SASL support in twisted.words (as well as doing more SASL/cred
> integration on the server side).  I spoke to him at the last sprint in San
> Francisco.
>
> Hopefully you can get together and prompt each other to actually finish it
> ;-).
>
> -glyph
>
>
I am interested, though I've made some significant progress in the last few
days on what I'm thinking of as "lore2sphinx-ng", so I'm trying to keep
that momentum going.

So it may be a bit before I get back to it.

I saw that Ralph was looking at it during the sprint, though, and getting
in touch with him to discuss/cheerlead/whatever is on my todo-list.

Kevin Horn
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Password hash for Perspective Brokers

[Flint]

Hi, i've faced the same problem and submitted a patch a few month ago,
your can check it here http://twistedmatrix.com/trac/ticket/4398 you'll
find also a complet example attached.

My first problem was that, the way twisted pb authentication works we're
supposed to have a plan version of passwords at server side.
Or this is not always the case, most application store a hashed version of
the password, the hash method may be different from the one twisted pb use
to pass the credential over the network
and thus, we're not able to compare those values.

In my solution the user can define a custom hash method and tell twisted to
use it, so that the password given by twisted over the network will be
hashed the same way that the application does before storing it (in
database for example), which means we can check if the password is correct
without having a plain version of it.
Not that, If we don't "customize" the hash method, the original twisted
behaviour in used instead, and thus compatibility is preserved.

-- G

Message: 1

> Date: Thu, 26 Jul 2012 12:36:57 -0500
> From: Kevin Horn 
> Subject: Re: [Twisted-Python] Password hash for Perspective Brokers
> To: Twisted general discussion 
> Message-ID:
>  zk3w21_bag9fblzzsamrjxrehsvgmryb0jlt4sgvv78...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Jul 26, 2012 at 11:43 AM,  wrote:
>
> > On 02:28 pm, spa...@gresille.org wrote:
> > > Hello
> > > I have a problem with checkers in Twisted, which could be
> > >solved by
> > >adding a new feature. I think I can write the necessary code, but
> > >before
> > >doing so, I would like to hear you about it.
> > >
> > ># The problem
> > >
> > > If I am right, the only way passwords can be hashed when using
> > >authentication with perspective brokers is using MD5 [1]. However,
> > >there
> > >are two flaws with it.
> > >
> > >* First, MD5 is no longer considered sure. It may be possible, from the
> > >hashed password, to find the original one.
> > >* Second, in the current implementation of Twisted, no salt is used to
> > >hash the password. A salt is considered good practise : it is harder to
> > >find the password from the hashed form, and two identical passwords
> > >have
> > >different hashed form, which prevent someone looking at the hashed
> > >passwords to see if two users have the same password.
> >
> > The second point is incorrect.  The hash is salted.  See the `respond`
> > method in twisted/spread/pb.py.
> > ># A solution
> > >
> > > I tried to implement the solution proposed in [1], and I think
> > >I can
> > >manage to do it. However, this seems to be a not-so-smart hack, which
> > >is
> > >not guaranteed to work in future releases of Twisted. That is why I am
> > >proposing a patch.
> > >
> > > The patch would introduce some arguments to class
> > >PBServerFactory [2]
> > >to use (or not) a salt, and a different hash function. I am not settled
> > >down yet about the new signature of this class, but what is sure is
> > >that
> > >the default must be the actual behaviour, not to break programs already
> > >using Twisted. Then, I hesitate between
> >
> > A good approach would be to parameterize the supported authentication
> > mechanisms in an extensible way, rather than just hard coding one or two
> > new (probably better) options.
> >
> > In other words, a SASL implementation for PB would be the best way to
> > go.
> >
> > The existing API and behavior should indeed be preserved as-is for
> > backwards compatibility.  The new authentication features should be
> > exposed under a new API - either as new optional arguments accepted by
> > PBServerFactory (and perhaps PBClientFactory) and new login methods
> > (again, probably on those two classes).
> >
> > Jean-Paul
> >
> >
> It would probably also help if someone finished the "Generic SASL
> implementation" ticket.
>
> Lessee, who was working on that last?
>
> Crap. It was me.
>
> Sorry about that.
>
> Kevin Horn
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> http://twistedmatrix.com/pipermail/twisted-python/attachments/20120726/191265a5/attachment-0001.htm
>
> --
>
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [RFC] Introducing six as a dependency

[Mourad Anis]

>
> Even having full access to MSDN, it can be incredibly obscure to discover
> which Python version goes with which Visual Studio product.  (Someone,
> please prove me wrong and indicate that there's a web page that shows what
> the official python.org builds use and you don't have to go trawling
> through python-dev archives to figure it out...)
>

Hi,
the python source code comes with a directory containing MSVC project
files, named after the version of Visual Studio product:
http://docs.python.org/using/windows.html#compiling-python-on-windows
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python