Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster dev » Question on SVN materialisation when svn+ssh (and subclipse)
Question on SVN materialisation when svn+ssh (and subclipse) [message #21255] Wed, 16 July 2008 08:47 Go to next message
Adrian Skehill is currently offline Adrian SkehillFriend
Messages: 55
Registered: July 2009
Member
Hi There,

Until a few days ago I had a good reliable automated build system
running using Buckminster. For the moment my code is only accessible via
svn+ssh plus username and password. But I had inadvertently configured
my subversion authentication so I didn't have to use a username and
password in the URL's placed in the RMAP. My VPS system got attacked and
I realised I needed to tighten up security, changed the password to my
build administrator account and then things started to go wrong on me.
Buckminster just refused to resolve the code from that point on. After
lots of googling I was unable to re-create the stuff in the auth
directory to provide under the covers svn configuration, so I thought
I'd see what was going wrong with Buckminster.

I took a look at the code.

In org.eclipse.buckminster.subclipse.internal.SvnSession a subclass of
ISVNPromptUserPassword is created which allows the SVN client to get
authentication information for the request. As is, I was able to get
things to work if, I put the username and password in the URL *and*
modified the promptSSH() method to return true. Grand, materialisation
succeeded.

But I don't want to have the password in the URL. Removed it, but then
ran into problems as Buckminster relies on *both* password and username
to be present in the URL before it will register the PasswordPrompt
class (see SvnSession:572 & 728).

Subversive is similar in logic, however, if the password is specified in
the URL, it works without code modification as the password prompting
logic is different.

So before I jump in with both feet into the code is there a particular
reason for this logic? Ideally what I'd like to do is define the
username in the url, but then use a key at runtime rather than having to
supply the password.

And one last thing, Buckminster now swallows exceptions on me and
finding these problems is becoming very difficult. I run with loglevel
of DEBUG but the only way I was able to see the exception with the
actual cause of the problem was in the debugger. Is there a command line
arg to get even more verbose info out?

Many thanks,
Adrian.
Re: Question on SVN materialisation when svn+ssh (and subclipse) [message #21273 is a reply to message #21255] Wed, 16 July 2008 09:55 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Adrian,
There's no reason other then perhaps ignorance for the current
user-name/password design for the SVN providers and your improvements
sounds reasonable to me.

Ideally, the SVN provider should be able to connect when:

1. No username/password specified in case a matching repository has been
declared in the workspace already (with associated credentials) or when
anonymous access is granted.
2. Both username/password are specified in the URL.
3. Only username specified in the URL in combination with a key.

Buckminster should normally not swallow exceptions. The behavior we are
trying to incourage is to print the exception message as an ERROR and to
display the stack-trace of the exception if the log-level is set to
DEBUG. If we have exceptions that do not behave that way then that's to
be considered a bug. Hiding exceptions is generally a bad thing.

Regards,
Thomas Hallgren


Adrian Skehill wrote:
> Hi There,
>
> Until a few days ago I had a good reliable automated build system
> running using Buckminster. For the moment my code is only accessible via
> svn+ssh plus username and password. But I had inadvertently configured
> my subversion authentication so I didn't have to use a username and
> password in the URL's placed in the RMAP. My VPS system got attacked and
> I realised I needed to tighten up security, changed the password to my
> build administrator account and then things started to go wrong on me.
> Buckminster just refused to resolve the code from that point on. After
> lots of googling I was unable to re-create the stuff in the auth
> directory to provide under the covers svn configuration, so I thought
> I'd see what was going wrong with Buckminster.
>
> I took a look at the code.
>
> In org.eclipse.buckminster.subclipse.internal.SvnSession a subclass of
> ISVNPromptUserPassword is created which allows the SVN client to get
> authentication information for the request. As is, I was able to get
> things to work if, I put the username and password in the URL *and*
> modified the promptSSH() method to return true. Grand, materialisation
> succeeded.
>
> But I don't want to have the password in the URL. Removed it, but then
> ran into problems as Buckminster relies on *both* password and username
> to be present in the URL before it will register the PasswordPrompt
> class (see SvnSession:572 & 728).
>
> Subversive is similar in logic, however, if the password is specified in
> the URL, it works without code modification as the password prompting
> logic is different.
>
> So before I jump in with both feet into the code is there a particular
> reason for this logic? Ideally what I'd like to do is define the
> username in the url, but then use a key at runtime rather than having to
> supply the password.
>
> And one last thing, Buckminster now swallows exceptions on me and
> finding these problems is becoming very difficult. I run with loglevel
> of DEBUG but the only way I was able to see the exception with the
> actual cause of the problem was in the debugger. Is there a command line
> arg to get even more verbose info out?
>
> Many thanks,
> Adrian.
Re: Question on SVN materialisation when svn+ssh (and subclipse) [message #21299 is a reply to message #21273] Wed, 16 July 2008 11:19 Go to previous message
Adrian Skehill is currently offline Adrian SkehillFriend
Messages: 55
Registered: July 2009
Member
Thomas Hallgren wrote:
> Hi Adrian,
> There's no reason other then perhaps ignorance for the current
> user-name/password design for the SVN providers and your improvements
> sounds reasonable to me.
>
> Ideally, the SVN provider should be able to connect when:
>
> 1. No username/password specified in case a matching repository has been
> declared in the workspace already (with associated credentials) or when
> anonymous access is granted.
> 2. Both username/password are specified in the URL.
> 3. Only username specified in the URL in combination with a key.
>
> Buckminster should normally not swallow exceptions. The behavior we are
> trying to incourage is to print the exception message as an ERROR and to
> display the stack-trace of the exception if the log-level is set to
> DEBUG. If we have exceptions that do not behave that way then that's to
> be considered a bug. Hiding exceptions is generally a bad thing.


Thanks Thomas,

I'll create a bugzilla and submit a patch for it. Wont be this week,
hopefully next week I'll get a bit of time to look at it. In the
meantime I've put the password into my URL to keep my builds going.

A.
Previous Topic:Problems materialising & building Buckminster
Next Topic:Automated build / test stuff for Buckminster
Goto Forum:
  


Current Time: Tue Mar 19 11:34:48 GMT 2024

Powered by FUDForum. Page generated in 0.02627 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top