Smalltalk › Squeak › Squeak - Dev

Monticello authentication methods?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

25 messages Options

Bakki Kudva

Monticello authentication methods?

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

Bert Freudenberg

Re: Monticello authentication methods?

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 -

Philippe Marschall

Re: Monticello authentication methods?

2006/9/13, Bert Freudenberg <[hidden email]>:

> 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

Avi Bryant

Re: Monticello authentication methods?

On Sep 13, 2006, at 1:47 PM, Philippe Marschall wrote:

> 2006/9/13, Bert Freudenberg <[hidden email]>:
>> 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

Philippe Marschall

Re: Monticello authentication methods?

2006/9/13, Avi Bryant <[hidden email]>:
>
> On Sep 13, 2006, at 1:47 PM, Philippe Marschall wrote:
>
> > 2006/9/13, Bert Freudenberg <[hidden email]>:
> >> 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

Avi Bryant

Re: Monticello authentication methods?

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

tblanchard

Re: Monticello authentication methods?

In reply to this post by Philippe Marschall

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 <[hidden email]> wrote:

>2006/9/13, Avi Bryant <[hidden email]>:
>>
>> On Sep 13, 2006, at 1:47 PM, Philippe Marschall wrote:
>>
>> > 2006/9/13, Bert Freudenberg <[hidden email]>:
>> >> 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
>
>
>

Philippe Marschall

Re: Monticello authentication methods?

In reply to this post by Avi Bryant

2006/9/13, Avi Bryant <[hidden email]>:

>
> 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

Bakki Kudva

Re: Monticello authentication methods?

In reply to this post by Avi Bryant

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 <[hidden email]> wrote:

Avi Bryant

Re: Monticello authentication methods?

In reply to this post by Philippe Marschall

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

Raymond W. Lucke IV

Re: Monticello authentication methods?

In reply to this post by Philippe Marschall

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 <[hidden email]>:
>>
>> 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!
>

tblanchard

Re: Monticello authentication methods?

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 <[hidden email]> 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?
>

stephane ducasse-2

Re: Monticello authentication methods?

In reply to this post by Philippe Marschall

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
>

Philippe Marschall

Re: Monticello authentication methods?

In reply to this post by Avi Bryant

2006/9/13, Avi Bryant <[hidden email]>:

>
> 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

tblanchard

Web Clients (was Re: Monticello authentication methods?)

In reply to this post by stephane ducasse-2

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
>>
>
>

stephane ducasse-2

Re: Monticello authentication methods?

In reply to this post by Philippe Marschall

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 <[hidden email]>:
>>
>> 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
>

Ken Causey-3

Re: Web Clients (was Re: Monticello authentication methods?)

In reply to this post by tblanchard

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
> >>
> >
> >
>
>

signature.asc (196 bytes) Download Attachment

Colin Putney

Re: Monticello authentication methods?

In reply to this post by Philippe Marschall

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

J J-6

RE: Web Clients (was Re: Monticello authentication methods?)

In reply to this post by tblanchard

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 <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>CC: Ken Causey <[hidden email]>
>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
>>>
>>
>>
>
>

Ken Causey-3

RE: Web Clients (was Re: Monticello authentication methods?)

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 <[hidden email]>
> >Reply-To: The general-purpose Squeak developers
> >list<[hidden email]>
> >To: The general-purpose Squeak developers
> >list<[hidden email]>
> >CC: Ken Causey <[hidden email]>
> >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
> >>>
> >>
> >>
> >
> >
>
>
>
>

signature.asc (196 bytes) Download Attachment