Hi all,
I have a web server which currently runs subversion but uses only BasicAuth on Apache2. I'd like to change it to Digest authentication. I was wondering if Monticello supports Digest? Any suggestions on the best practice for securing a Monticello repository? Thanks,
bakki
Bakki Kudva wrote:
Hi all,
I have a web server which currently runs subversion but uses only BasicAuth on Apache2. I'd like to change it to Digest authentication. I was wondering if Monticello supports Digest? Any suggestions on the best practice for securing a Monticello repository? Thanks,
My version at http://source.impara.de/mc.html does. Not sure if it was merged into other versions.
You will need to patch the HTTPSocket>>md5Hash: method with a class that provides MD5 hashing - should be in one of the Crypto packages.
Note that this is not doing you any good security-wise, because MC will send the basic-auth user:password anyway, and only if that fails, digest is tried. HTTPSocket authentication needs to be completely reworked.
- Bert -
2006/9/13, Bert Freudenberg bert@freudenbergs.de:
Bakki Kudva wrote:
Hi all,
I have a web server which currently runs subversion but uses only BasicAuth on Apache2. I'd like to change it to Digest authentication. I was wondering if Monticello supports Digest? Any suggestions on the best practice for securing a Monticello repository? Thanks,
My version at http://source.impara.de/mc.html does. Not sure if it was merged into other versions.
You will need to patch the HTTPSocket>>md5Hash: method with a class that provides MD5 hashing - should be in one of the Crypto packages.
Note that this is not doing you any good security-wise, because MC will send the basic-auth user:password anyway, and only if that fails, digest is tried. HTTPSocket authentication needs to be completely reworked.
Not only authentication, everything. The whole class is just awful.
Philippe
On Sep 13, 2006, at 1:47 PM, Philippe Marschall wrote:
2006/9/13, Bert Freudenberg bert@freudenbergs.de:
HTTPSocket authentication needs to be completely reworked.
Not only authentication, everything. The whole class is just awful.
Hence my interest in a libCURL plugin...
Avi
2006/9/13, Avi Bryant avi.bryant@gmail.com:
On Sep 13, 2006, at 1:47 PM, Philippe Marschall wrote:
2006/9/13, Bert Freudenberg bert@freudenbergs.de:
HTTPSocket authentication needs to be completely reworked.
Not only authentication, everything. The whole class is just awful.
Hence my interest in a libCURL plugin...
Which is just the confession that HTTPSocket will not be fixed. Otherwise there would be no need for libCURL, the protocols would be implemented in Squeak and work wherever Squeak works.
Philippe
On Sep 13, 2006, at 2:42 PM, Philippe Marschall wrote:
Hence my interest in a libCURL plugin...
Which is just the confession that HTTPSocket will not be fixed. Otherwise there would be no need for libCURL, the protocols would be implemented in Squeak and work wherever Squeak works.
True. But recognize that doing that right requires implementing SSL in pure Squeak, since being able to access HTTP services without supporting HTTPS is nearly pointless.
Avi
2006/9/13, Avi Bryant avi.bryant@gmail.com:
On Sep 13, 2006, at 2:42 PM, Philippe Marschall wrote:
Hence my interest in a libCURL plugin...
Which is just the confession that HTTPSocket will not be fixed. Otherwise there would be no need for libCURL, the protocols would be implemented in Squeak and work wherever Squeak works.
True. But recognize that doing that right requires implementing SSL in pure Squeak, since being able to access HTTP services without supporting HTTPS is nearly pointless.
Sure. Java does it, so why can't we?
Philippe
On Sep 13, 2006, at 2:53 PM, Philippe Marschall wrote:
True. But recognize that doing that right requires implementing SSL in pure Squeak, since being able to access HTTP services without supporting HTTPS is nearly pointless.
Sure. Java does it, so why can't we?
So does VisualWorks, FWIW. And we should too, in the long run. But a plugin is useful in the meantime.
Avi
2006/9/13, Avi Bryant avi.bryant@gmail.com:
On Sep 13, 2006, at 2:53 PM, Philippe Marschall wrote:
True. But recognize that doing that right requires implementing SSL in pure Squeak, since being able to access HTTP services without supporting HTTPS is nearly pointless.
Sure. Java does it, so why can't we?
So does VisualWorks, FWIW. And we should too, in the long run. But a plugin is useful in the meantime.
Have they implemented it in Smalltalk or do they just use OpenSSL? I though I remember a post from James that suggested the later.
Philippe
seems to me that they just use it. Did someone check in dolphin Smalltalk?
Stef
On 14 sept. 06, at 09:27, Philippe Marschall wrote:
2006/9/13, Avi Bryant avi.bryant@gmail.com:
On Sep 13, 2006, at 2:53 PM, Philippe Marschall wrote:
True. But recognize that doing that right requires
implementing SSL
in pure Squeak, since being able to access HTTP services without supporting HTTPS is nearly pointless.
Sure. Java does it, so why can't we?
So does VisualWorks, FWIW. And we should too, in the long run. But a plugin is useful in the meantime.
Have they implemented it in Smalltalk or do they just use OpenSSL? I though I remember a post from James that suggested the later.
Philippe
On Sep 14, 2006, at 12:27 AM, Philippe Marschall wrote:
Have they implemented it in Smalltalk or do they just use OpenSSL? I though I remember a post from James that suggested the later.
It was originally just a Smalltalk implementation, IIRC, and later they added the wrappers to use OpenSSL via the same API. Pretty nifty.
Colin
One of the things I have really appreciated during my time of learning SmallTalk has been being able to just keep looking browse up the chain to the low level of operations. It's also nice to not have to deal with updating libCURL and OpenSSL every time they release a new patch to a C buffer overflow they experience. So I second the idea of implementing SSL in Squeak. I'm quite new, so what's the issue with HTTPSocket aside of not supporting SSL?
On Sep 13, 2006, at 2:53 PM, Philippe Marschall wrote:
2006/9/13, Avi Bryant avi.bryant@gmail.com:
On Sep 13, 2006, at 2:42 PM, Philippe Marschall wrote:
Hence my interest in a libCURL plugin...
Which is just the confession that HTTPSocket will not be fixed. Otherwise there would be no need for libCURL, the protocols
would be
implemented in Squeak and work wherever Squeak works.
True. But recognize that doing that right requires implementing SSL in pure Squeak, since being able to access HTTP services without supporting HTTPS is nearly pointless.
Sure. Java does it, so why can't we?
Philippe
!DSPAM:45087d86186561804284693!
Read the code and all will become clear (or rather - very muddy). Do a debug it on
'http://www.yahoo.com' asUrl retrieveContents
and trace the execution if you really want to see.
On Wednesday, September 13, 2006, at 03:53PM, Raymond W. Lucke IV smalltalk@raylucke.com wrote:
One of the things I have really appreciated during my time of learning SmallTalk has been being able to just keep looking browse up the chain to the low level of operations. It's also nice to not have to deal with updating libCURL and OpenSSL every time they release a new patch to a C buffer overflow they experience. So I second the idea of implementing SSL in Squeak. I'm quite new, so what's the issue with HTTPSocket aside of not supporting SSL?
Hmm...In that case how about creating a local repository on each machine and then using subversion on that directory? It will be a two step process but I can use subversion to do SSL?
-bakki
On 9/13/06, Avi Bryant avi.bryant@gmail.com wrote:
On Sep 13, 2006, at 2:42 PM, Philippe Marschall wrote:
Hence my interest in a libCURL plugin...
Which is just the confession that HTTPSocket will not be fixed. Otherwise there would be no need for libCURL, the protocols would be implemented in Squeak and work wherever Squeak works.
True. But recognize that doing that right requires implementing SSL in pure Squeak, since being able to access HTTP services without supporting HTTPS is nearly pointless.
Avi
Even if we fix HTTPSocket (and I have added a couple fixes for 3.9 to allow it to get things like css files), we still don't have https without doing an openssl plugin or writing our own ssl socket layer in Smalltalk. The plugin makes more sense - and since we are already doing a plugin - we might as well get the most capability from it that we can.
I've certainly got some uses for it and look forward to its release.
-Todd Blanchard
On Wednesday, September 13, 2006, at 02:43PM, Philippe Marschall philippe.marschall@gmail.com wrote:
2006/9/13, Avi Bryant avi.bryant@gmail.com:
On Sep 13, 2006, at 1:47 PM, Philippe Marschall wrote:
2006/9/13, Bert Freudenberg bert@freudenbergs.de:
HTTPSocket authentication needs to be completely reworked.
Not only authentication, everything. The whole class is just awful.
Hence my interest in a libCURL plugin...
Which is just the confession that HTTPSocket will not be fixed. Otherwise there would be no need for libCURL, the protocols would be implemented in Squeak and work wherever Squeak works.
Philippe
So why a group of guy start to fix it! Let's try to step by step little peeble by little peeble improve...No giant step just a tiny and simple one
Note that this is not doing you any good security-wise, because MC will send the basic-auth user:password anyway, and only if that fails, digest is tried. HTTPSocket authentication needs to be completely reworked.
Not only authentication, everything. The whole class is just awful.
Philippe
I was under the impression we were going to deprecate that stuff in favor of the Steve Waring's http client package.
Right Ken?
-Todd Blanchard
On Sep 13, 2006, at 11:21 PM, stephane ducasse wrote:
So why a group of guy start to fix it! Let's try to step by step little peeble by little peeble improve...No giant step just a tiny and simple one
Note that this is not doing you any good security-wise, because MC will send the basic-auth user:password anyway, and only if that fails, digest is tried. HTTPSocket authentication needs to be completely reworked.
Not only authentication, everything. The whole class is just awful.
Philippe
There was discussion of replacing it within the IO team, but never any decision as to what to replace it with. That was back in April and there's been no further discussion or action since then that I'm aware of.
Ken
On Thu, 2006-09-14 at 01:23 -0700, Todd Blanchard wrote:
I was under the impression we were going to deprecate that stuff in favor of the Steve Waring's http client package.
Right Ken?
-Todd Blanchard
On Sep 13, 2006, at 11:21 PM, stephane ducasse wrote:
So why a group of guy start to fix it! Let's try to step by step little peeble by little peeble improve...No giant step just a tiny and simple one
Note that this is not doing you any good security-wise, because MC will send the basic-auth user:password anyway, and only if that fails, digest is tried. HTTPSocket authentication needs to be completely reworked.
Not only authentication, everything. The whole class is just awful.
Philippe
So does anyone know the status of this? What is Steve Waring's http package? Is it a true replacement for the HTTP system? Is it all pure squeak?
Thanks, JJ
From: Todd Blanchard tblanchard@mac.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org CC: Ken Causey ken@kencausey.com Subject: Web Clients (was Re: Monticello authentication methods?) Date: Thu, 14 Sep 2006 01:23:29 -0700
I was under the impression we were going to deprecate that stuff in favor of the Steve Waring's http client package.
Right Ken?
-Todd Blanchard
On Sep 13, 2006, at 11:21 PM, stephane ducasse wrote:
So why a group of guy start to fix it! Let's try to step by step little peeble by little peeble improve...No giant step just a tiny and simple one
Note that this is not doing you any good security-wise, because MC will send the basic-auth user:password anyway, and only if that fails, digest is tried. HTTPSocket authentication needs to be completely reworked.
Not only authentication, everything. The whole class is just awful.
Philippe
http://map.squeak.org/packagebyname/HTTPClient
I'll let Todd comment on the status since if anyone is looking into this at the current time, it is him. His original comment that this package was the default choice was a mistake since in fact we (the I/O team) had never gotten so far as to make any such decision. At the current time I would say that anyone that cares to take the time to put together a solid test suite for any of the available choices (assuming they don't already have one) and do the work to at least enable the ability to plug it in to the rest of the Squeak HTTP-using architecture will warrant a high degree of attention and support from the I/O team.
Ken
On Wed, 2006-10-04 at 18:32 +0000, J J wrote:
So does anyone know the status of this? What is Steve Waring's http package? Is it a true replacement for the HTTP system? Is it all pure squeak?
Thanks, JJ
From: Todd Blanchard tblanchard@mac.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org CC: Ken Causey ken@kencausey.com Subject: Web Clients (was Re: Monticello authentication methods?) Date: Thu, 14 Sep 2006 01:23:29 -0700
I was under the impression we were going to deprecate that stuff in favor of the Steve Waring's http client package.
Right Ken?
-Todd Blanchard
On Sep 13, 2006, at 11:21 PM, stephane ducasse wrote:
So why a group of guy start to fix it! Let's try to step by step little peeble by little peeble improve...No giant step just a tiny and simple one
Note that this is not doing you any good security-wise, because MC will send the basic-auth user:password anyway, and only if that fails, digest is tried. HTTPSocket authentication needs to be completely reworked.
Not only authentication, everything. The whole class is just awful.
Philippe
Yep, that's pretty much how I see it. Whoever can get to the work and finish it wins.
I have actually started integrating the SWHttpClient, implementing all existing web stuff on top of it, but I have a ways to go and am short on time now. I could probably get it done about the first of the year.
I've decided I like SWHttpClient because, while it has LOT of classes, it is extremely well factored, does parallel fetching, and has proxy/auth/cookie support.
On Oct 4, 2006, at 11:48 AM, Ken Causey wrote:
http://map.squeak.org/packagebyname/HTTPClient
I'll let Todd comment on the status since if anyone is looking into this at the current time, it is him. His original comment that this package was the default choice was a mistake since in fact we (the I/O team) had never gotten so far as to make any such decision. At the current time I would say that anyone that cares to take the time to put together a solid test suite for any of the available choices (assuming they don't already have one) and do the work to at least enable the ability to plug it in to the rest of the Squeak HTTP-using architecture will warrant a high degree of attention and support from the I/O team.
Ken
On Wed, 2006-10-04 at 18:32 +0000, J J wrote:
So does anyone know the status of this? What is Steve Waring's http package? Is it a true replacement for the HTTP system? Is it all pure squeak?
Thanks, JJ
From: Todd Blanchard tblanchard@mac.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org CC: Ken Causey ken@kencausey.com Subject: Web Clients (was Re: Monticello authentication methods?) Date: Thu, 14 Sep 2006 01:23:29 -0700
I was under the impression we were going to deprecate that stuff in favor of the Steve Waring's http client package.
Right Ken?
-Todd Blanchard
On Sep 13, 2006, at 11:21 PM, stephane ducasse wrote:
So why a group of guy start to fix it! Let's try to step by step little peeble by little peeble improve...No giant step just a tiny and simple one
Note that this is not doing you any good security-wise, because MC will send the basic-auth user:password anyway, and only if that fails, digest is tried. HTTPSocket authentication needs to be completely reworked.
Not only authentication, everything. The whole class is just awful.
Philippe
Io mailing list Io@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/io
Is it missing anything that the current implimentation has? Philippe, what do you think of this? Does it fix all the things you see wrong with the current implimentation?
And if you are already using it, then what is left to do on it? Just get a more comprehensive test suite?
From: Todd Blanchard tblanchard@mac.com To: Ken Causey ken@kencausey.com CC: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org, J J azreal1977@hotmail.com, io@lists.squeakfoundation.org Subject: Re: [Io] RE: Web Clients (was Re: Monticello authentication methods?) Date: Wed, 4 Oct 2006 11:58:51 -0700
Yep, that's pretty much how I see it. Whoever can get to the work and finish it wins.
I have actually started integrating the SWHttpClient, implementing all existing web stuff on top of it, but I have a ways to go and am short on time now. I could probably get it done about the first of the year.
I've decided I like SWHttpClient because, while it has LOT of classes, it is extremely well factored, does parallel fetching, and has proxy/auth/cookie support.
On Oct 4, 2006, at 11:48 AM, Ken Causey wrote:
http://map.squeak.org/packagebyname/HTTPClient
I'll let Todd comment on the status since if anyone is looking into this at the current time, it is him. His original comment that this package was the default choice was a mistake since in fact we (the I/O team) had never gotten so far as to make any such decision. At the current time I would say that anyone that cares to take the time to put together a solid test suite for any of the available choices (assuming they don't already have one) and do the work to at least enable the ability to plug it in to the rest of the Squeak HTTP-using architecture will warrant a high degree of attention and support from the I/O team.
Ken
On Wed, 2006-10-04 at 18:32 +0000, J J wrote:
So does anyone know the status of this? What is Steve Waring's http package? Is it a true replacement for the HTTP system? Is it all pure squeak?
Thanks, JJ
From: Todd Blanchard tblanchard@mac.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org CC: Ken Causey ken@kencausey.com Subject: Web Clients (was Re: Monticello authentication methods?) Date: Thu, 14 Sep 2006 01:23:29 -0700
I was under the impression we were going to deprecate that stuff in favor of the Steve Waring's http client package.
Right Ken?
-Todd Blanchard
On Sep 13, 2006, at 11:21 PM, stephane ducasse wrote:
So why a group of guy start to fix it! Let's try to step by step little peeble by little peeble improve...No giant step just a tiny and simple one
>Note that this is not doing you any good security-wise, because MC >will >send the basic-auth user:password anyway, and only if that fails, >digest >is tried. HTTPSocket authentication needs to be completely reworked.
Not only authentication, everything. The whole class is just awful.
Philippe
Io mailing list Io@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/io
hi todd what SW stands for? Steve Warring ?
Yep, that's pretty much how I see it. Whoever can get to the work and finish it wins.
I have actually started integrating the SWHttpClient, implementing all existing web stuff on top of it, but I have a ways to go and am short on time now. I could probably get it done about the first of the year.
I've decided I like SWHttpClient because, while it has LOT of classes, it is extremely well factored, does parallel fetching, and has proxy/auth/cookie support.
Lot of classes is not a desease. :) if this is not too much classes
Stef
I think it it Steve Waring, yes. The categories start with SW but the classes all begin with Spt.
I don't think it is too many classes - however, it lacks a nice facade and end user api. The classes model all of the 'things' in the Http protocol, but there is no really easy to use end user api. This could be fixed and I'd like to see a virtual web browser built on top of it which also handles http-meta refreshes and caching.
Meanwhile, I started implementing the existing api on top of it. Its not yet usable, its just something I started and then got distracted from by income generating activities.
-Todd
On Oct 4, 2006, at 2:10 PM, stephane ducasse wrote:
hi todd what SW stands for? Steve Warring ?
Yep, that's pretty much how I see it. Whoever can get to the work and finish it wins.
I have actually started integrating the SWHttpClient, implementing all existing web stuff on top of it, but I have a ways to go and am short on time now. I could probably get it done about the first of the year.
I've decided I like SWHttpClient because, while it has LOT of classes, it is extremely well factored, does parallel fetching, and has proxy/auth/cookie support.
Lot of classes is not a desease. :) if this is not too much classes
Stef
Several years ago Doug Way ran ConflictChecker on the HTTPClient and found a number of "house-keeping" issues that needed to be addressed (and still haven't been). For one, the HTTPClient package references a number of classes not defined in the package.
As Karl found out, I haven't done any work maintaining it in quite a long time. Does anyone want to take ownership of this package?
On 10/4/06, Ken Causey ken@kencausey.com wrote:
squeak-dev@lists.squeakfoundation.org
-
Avi Bryant -
Bakki Kudva -
Bert Freudenberg -
Brent Vukmer -
Colin Putney -
J J -
Ken Causey -
Philippe Marschall -
Raymond W. Lucke IV -
stephane ducasse -
Todd Blanchard