Login | Register
My pages Projects Community openCollabNet

Discussions > users > [feature request] ssl client-certificate auth

fsvs
Discussion topic

Hide all messages in topic

All messages in topic

Re: [feature request] ssl client-certificate auth

Author tekknokrat
Full name Gunnar Thielebein
Date 2008-08-21 02:43:36 PDT
Message Philipp Marek wrote:

> conflict with FSVS' "config"; I'll put a default of "/etc/fsvs//auth//" in the
> option, OK?
>
I'd appreciate that :)

For everyone who is interested I moved the topic with credentials saving
to dev group.

Re: [feature request] ssl client-certificate auth

Author pmarek
Full name P.Marek
Date 2008-08-13 08:59:16 PDT
Message On Wednesday 13 August 2008 Gunnar Thielebein wrote:
> Philipp Marek wrote:
> > On Tuesday 12 August 2008 Gunnar Thielebein wrote:
> >>> Maybe the config hash in cb_init() has to include the
> >>> [auth]
> >>> store-auth-creds = yes
> >>> configuration for the subversion libraries.
> >>
> >> I don't understand why it doesn't use this option, yet. Normally it
> >> defaults to "yes"
> >
> > In your config, that is?
>
> No, this is stated by the comments configuration:
> > [auth]
> > ### Set store-passwords to 'no' to avoid storing passwords in the
> > ### auth/ area of your config directory. It defaults to 'yes'.
Yes ... but that's likely been there since you installed subversion < 1.5,
because AFAIK subversion >= 1.5 has changed that to "no".

> > Well, cb__init() uses an empty hash - because the result given by
> > svn_config_get_config() can't be used directly.
> >
> >>> Yes, please - although I don't think so. The config hash mentioned
> >>> above seems like a better bet.
> >>
> >> I'll try to compile with userdir and if it helps let you know.
> >
> > Thank you.
>
> You are right, it doesn't change the behaviour of fsvs.
> I'll stay with the password option until I hear something from your side.
Would you try using a meaningful "cfg" value in cb__init()?

> Thanks for taking time into this.
I imagine there's more than a single user for that :-)


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: [feature request] ssl client-certificate auth

Author tekknokrat
Full name Gunnar Thielebein
Date 2008-08-13 08:42:14 PDT
Message Philipp Marek wrote:
> On Tuesday 12 August 2008 Gunnar Thielebein wrote:
>
>>> Maybe the config hash in cb_init() has to include the
>>> [auth]
>>> store-auth-creds = yes
>>> configuration for the subversion libraries.
>>>
>> I don't understand why it doesn't use this option, yet. Normally it
>> defaults to "yes"
>>
> In your config, that is?
>
No, this is stated by the comments configuration:
> [auth]
> ### Set store-passwords to 'no' to avoid storing passwords in the
> ### auth/ area of your config directory. It defaults to 'yes'.


> Well, cb__init() uses an empty hash - because the result given by
> svn_config_get_config() can't be used directly.
>
>
>>> Yes, please - although I don't think so. The config hash mentioned above
>>> seems like a better bet.
>>>
>> I'll try to compile with userdir and if it helps let you know.
>>
> Thank you.
>
>
You are right, it doesn't change the behaviour of fsvs.
I'll stay with the password option until I hear something from your side.
Thanks for taking time into this.

Regards,
Gunnar

Re: [feature request] ssl client-certificate auth

Author pmarek
Full name P.Marek
Date 2008-08-12 09:34:33 PDT
Message On Tuesday 12 August 2008 Gunnar Thielebein wrote:
> > Maybe the config hash in cb_init() has to include the
> > [auth]
> > store-auth-creds = yes
> > configuration for the subversion libraries.
>
> I don't understand why it doesn't use this option, yet. Normally it
> defaults to "yes"
In your config, that is?
Well, cb__init() uses an empty hash - because the result given by
svn_config_get_config() can't be used directly.

> Will you have a look at that?
It'll take a bit.


> >>> Do I understand you correctly: Because /etc/ is the configuration path,
> >>> the password (that gets asked on checkout) is not stored in the files;
> >>> but for commit you use client certificates, so you don't need it
> >>> anyway?
> >>
> >> this was only assumption from my side.
> >> I don't know if the behaviour changes when using ~/.subversion should I
> >> test this?
> >
> > Yes, please - although I don't think so. The config hash mentioned above
> > seems like a better bet.
>
> I'll try to compile with userdir and if it helps let you know.
Thank you.

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: [feature request] ssl client-certificate auth

Author tekknokrat
Full name Gunnar Thielebein
Date 2008-08-12 09:06:38 PDT
Message Hi,

Philipp Marek wrote:
> Hello Gunnar!
>
>
> Thank you for your answer, but I'm still confused ;-/
> I'll try to repeat what I read.
>
> On Tuesday 12 August 2008 Gunnar Thielebein wrote:
>
>> I think I need to explain our scenario a little bit.
>> On one hand we use ssl-keybased authorisation for servers. This keeps us
>> from typing password in authentication process because of security.
>>
> Don't you secure your client-certificates? Are they in smartcards? Do you
> store the password for the PKCS#11 files?
>
the client ssl-certificates have password set atm. But the password is
cleartext in config which throws the problem you mentioned in your last
mail. I think later we will restrict access from allowed hosts only and
remove the passwords from keys.
>
>> On the other hand we need the username of the commiter to track changes
>> to the config. This wont be the case without using htaccess.
>>
> You want a *real* username in the commits, not "root" - that's why you use
> http(s).
>
>
IMO you mean httpauth not https, if this is the case - yes.
>> So we use anonymous access on server so that only a (real) username is
>> needed on clientside, no matching password.
>>
> Why do you need an username for anonymous? Or is the username "real" so that
> the commit authentication works, but it wouldn't work on checkout without
> *any* password?
>
the username should be real to track commits via trac btw. (and later
also to log the general access to repository)
>
>> Without the local ~/.subversion directory and performing "svn ls" fsvs
>> also asks for the password when doing a commit.
>> So i wasn't able to nail this issue down and I created the patch.
>>
> And you don't want to have a ~root/.subversion - right?
>
Yes, I want to keep the users home on sudo for preserving individual
settings.
>
>> Perhaps another configuration "anonymous_access" would make more sense
>> but I don't know what to use as an argument to this function instead of
>> a string or NULL:
>>
> What do you need for anonymous access? I'd understand that as allowing
> everyone.
>
Yes, in more detail allowing everyone from authenticated hosts.
>
>>> And what exactly does not work?
>>>
>> saving the httpauth-credentials
>>
> To repeat:
> Using a ~/.subversion, that is pre-populated by "svn ls", works for fsvs.
> But you'd like to avoid that directory, and avoid the pre-population.
> FSVS does already ask for the authentication data, but doesn't store it -
> you'd have to enter that for every invocation?
> Is that what you say?
>
>
Yes thats what i mean, I need to hit at least <enter> everytime.
This doesn't sound much, but is annoying over time and blocks usage of
fsvs in apt-hook/cron-jobs.

> Maybe the config hash in cb_init() has to include the
> [auth]
> store-auth-creds = yes
> configuration for the subversion libraries.
>
>
I don't understand why it doesn't use this option, yet. Normally it
defaults to "yes"
Will you have a look at that?
>
>>> Do I understand you correctly: Because /etc/ is the configuration path,
>>> the password (that gets asked on checkout) is not stored in the files;
>>> but for commit you use client certificates, so you don't need it anyway?
>>>
>> this was only assumption from my side.
>> I don't know if the behaviour changes when using ~/.subversion should I
>> test this?
>>
> Yes, please - although I don't think so. The config hash mentioned above seems
> like a better bet.
>
I'll try to compile with userdir and if it helps let you know.
> Regards,
>
> Phil
>
>

Thanks for your help!

Cheers,
Gunnar

Re: [feature request] ssl client-certificate auth

Author pmarek
Full name P.Marek
Date 2008-08-12 08:22:54 PDT
Message Hello Gunnar!


Thank you for your answer, but I'm still confused ;-/
I'll try to repeat what I read.

On Tuesday 12 August 2008 Gunnar Thielebein wrote:
> I think I need to explain our scenario a little bit.
> On one hand we use ssl-keybased authorisation for servers. This keeps us
> from typing password in authentication process because of security.
Don't you secure your client-certificates? Are they in smartcards? Do you
store the password for the PKCS#11 files?

> On the other hand we need the username of the commiter to track changes
> to the config. This wont be the case without using htaccess.
You want a *real* username in the commits, not "root" - that's why you use
http(s).

> So we use anonymous access on server so that only a (real) username is
> needed on clientside, no matching password.
Why do you need an username for anonymous? Or is the username "real" so that
the commit authentication works, but it wouldn't work on checkout without
*any* password?

> Without the local ~/.subversion directory and performing "svn ls" fsvs
> also asks for the password when doing a commit.
> So i wasn't able to nail this issue down and I created the patch.
And you don't want to have a ~root/.subversion - right?

> Perhaps another configuration "anonymous_access" would make more sense
> but I don't know what to use as an argument to this function instead of
> a string or NULL:
What do you need for anonymous access? I'd understand that as allowing
everyone.

> > And what exactly does not work?
>
> saving the httpauth-credentials
To repeat:
Using a ~/.subversion, that is pre-populated by "svn ls", works for fsvs.
But you'd like to avoid that directory, and avoid the pre-population.
FSVS does already ask for the authentication data, but doesn't store it -
you'd have to enter that for every invocation?
Is that what you say?

Maybe the config hash in cb_init() has to include the
    [auth]
    store-auth-creds = yes
configuration for the subversion libraries.


> > Do I understand you correctly: Because /etc/ is the configuration path,
> > the password (that gets asked on checkout) is not stored in the files;
> > but for commit you use client certificates, so you don't need it anyway?
> this was only assumption from my side.
> I don't know if the behaviour changes when using ~/.subversion should I
> test this?
Yes, please - although I don't think so. The config hash mentioned above seems
like a better bet.


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: [feature request] ssl client-certificate auth

Author tekknokrat
Full name Gunnar Thielebein
Date 2008-08-12 07:45:25 PDT
Message Philipp Marek wrote:
> On Thursday 07 August 2008 Gunnar Thielebein wrote:
>
>> When using ssl-client authentication a password is not needed anymore at
>> least in our setup.
>> So I hacked this dirty patch which introduces a new option "password"
>> for setting a global (blank) password.
>> I works for me but I don't know if there are better ways of implementing
>> this.
>>
> You just wrote "a password is not needed anymore"? Why make one configureable?
>
Hi Phil,

I think I need to explain our scenario a little bit.
On one hand we use ssl-keybased authorisation for servers. This keeps us
from typing password in authentication process because of security.
On the other hand we need the username of the commiter to track changes
to the config. This wont be the case without using htaccess.
So we use anonymous access on server so that only a (real) username is
needed on clientside, no matching password.
Without the local ~/.subversion directory and performing "svn ls" fsvs
also asks for the password when doing a commit.
So i wasn't able to nail this issue down and I created the patch.

Perhaps another configuration "anonymous_access" would make more sense
but I don't know what to use as an argument to this function instead of
a string or NULL:

racallback.c#58:
> opt__get_int(OPT__PASSWD) ?
> opt__get_string(OPT__PASSWD) : NULL, /*
> Password */

>
>
>> If it would be possible to save the credentials in home ~/.subversion
>> (without svn client) this option would
>> not be neccessary at all.
>>
> And what exactly does not work?
>
saving the httpauth-credentials
>
>> But because I have defined /etc/subversion as configuration path
>> (because ssl configuration should be in global scope) imo it isn't saved
>> yet.
>> I am interested what you think about this!
>>
> Well, seems ok so far - but there's this discussion about storing plain-text
> passwords (like svn had a few times in the past) ...
>
>
> Do I understand you correctly: Because /etc/ is the configuration path, the
> password (that gets asked on checkout) is not stored in the files; but for
> commit you use client certificates, so you don't need it anyway?
>
> I'm a bit confused.
>
this was only assumption from my side.
I don't know if the behaviour changes when using ~/.subversion should I
test this?
>
> Regards,
>
> Phil
>
>
>

Best Wishes,
Gunnar

Re: [feature request] ssl client-certificate auth

Author pmarek
Full name P.Marek
Date 2008-08-12 04:59:00 PDT
Message On Thursday 07 August 2008 Gunnar Thielebein wrote:
> When using ssl-client authentication a password is not needed anymore at
> least in our setup.
> So I hacked this dirty patch which introduces a new option "password"
> for setting a global (blank) password.
> I works for me but I don't know if there are better ways of implementing
> this.
You just wrote "a password is not needed anymore"? Why make one configureable?


> If it would be possible to save the credentials in home ~/.subversion
> (without svn client) this option would
> not be neccessary at all.
And what exactly does not work?

> But because I have defined /etc/subversion as configuration path
> (because ssl configuration should be in global scope) imo it isn't saved
> yet.
> I am interested what you think about this!
Well, seems ok so far - but there's this discussion about storing plain-text
passwords (like svn had a few times in the past) ...


Do I understand you correctly: Because /etc/ is the configuration path, the
password (that gets asked on checkout) is not stored in the files; but for
commit you use client certificates, so you don't need it anyway?

I'm a bit confused.


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: [feature request] ssl client-certificate auth

Author pmarek
Full name P.Marek
Date 2008-08-12 04:55:53 PDT
Message Hello Gunnar,

On Wednesday 06 August 2008 Gunnar Thielebein wrote:
> I changed the path to /etc/subversion, see my attached patch. For our
> scope imo it is better to have a global configuration.
> Most peoples who use fsvs are admins so they would not have problems
> with this.
I'll make that configureable, so that it's useable for normal users, too.

> Is it having the svn_config_get_config pointing to /etc/fsvs that
> subversions configuration code would interfere with fsvs config?
The subversion libraries use "config" and "servers" - so yes, that would
conflict with FSVS' "config"; I'll put a default of "/etc/fsvs/auth/" in the
option, OK?


> Thanks for your effort!
You're welcome.

So, from your point of view that works - right? I just want to know whether
something has to be changed before releasing the next version.


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: [feature request] ssl client-certificate auth

Author tekknokrat
Full name Gunnar Thielebein
Date 2008-08-07 02:57:23 PDT
Message Hi Phil,

When using ssl-client authentication a password is not needed anymore at
least in our setup.
So I hacked this dirty patch which introduces a new option "password"
for setting a global (blank) password.
I works for me but I don't know if there are better ways of implementing
this.

If it would be possible to save the credentials in home ~/.subversion
(without svn client) this option would
not be neccessary at all.
But because I have defined /etc/subversion as configuration path
(because ssl configuration should be in global scope) imo it isn't saved
yet.
I am interested what you think about this!

Best Regards,
Gunnar
Attachments

Re: [feature request] ssl client-certificate auth

Author tekknokrat
Full name Gunnar Thielebein
Date 2008-08-06 03:04:17 PDT
Message Wow, thats neat :-)
Didn't ever thought that theses small changes makes fsvs use clientcert
authentication.

I changed the path to /etc/subversion, see my attached patch. For our
scope imo it is better to have a global configuration.
Most peoples who use fsvs are admins so they would not have problems
with this.
Is it having the svn_config_get_config pointing to /etc/fsvs that
subversions configuration code would interfere with fsvs config?

Thanks for your effort!

Regards,
Gunnar

Philipp Marek wrote:
> Could you test that and tell me what you think?
>
> A simple checkout works for me - but I didn't test commit, diff etc.
>
>
> If you say it's ok I'll commit that for the next release.
>
> Thank you!
>
>
> Regards,
>
> Phil
>
>
Attachments

Re: [feature request] ssl client-certificate auth

Author pmarek
Full name P.Marek
Date 2008-08-06 01:49:56 PDT
Message Could you test that and tell me what you think?

A simple checkout works for me - but I didn't test commit, diff etc.


If you say it's ok I'll commit that for the next release.

Thank you!


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!
Attachments

Re: [feature request] ssl client-certificate auth

Author pmarek
Full name P.Marek
Date 2008-08-06 01:30:40 PDT
Message On Saturday 02 August 2008 Philipp Marek wrote:
> Or possibly the next line - "no_auth_cache" to 0 - so that an
> authentication cache is used?
That at least helps to accept the certificate permanently.


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: [feature request] ssl client-certificate auth

Author pmarek
Full name P.Marek
Date 2008-08-06 01:00:51 PDT
Message I trying to get https for fsvs running - but currently not even svn works.

I think this is bug 480041:
    http://bugs.debian.o​rg/cgi-bin/bugreport​.cgi?bug=480041

So it'll take a while.


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: [feature request] ssl client-certificate auth

Author pmarek
Full name P.Marek
Date 2008-08-02 10:12:02 PDT
Message Or possibly the next line - "no_auth_cache" to 0 - so that an authentication
cache is used?


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: [feature request] ssl client-certificate auth

Author pmarek
Full name P.Marek
Date 2008-08-02 07:52:55 PDT
Message Hello Gunnar!


In racallback.c around line 58 you can find this:

  /* Set up Authentication stuff. */
  STOPIF_SVNERR( svn_cmdline_setup_auth_baton,
      (&cb__cb_table.auth_baton,
       !(isatty(STDIN_FILENO) && isatty(STDOUT_FILENO)),
       opt__get_int(OPT__AUTHOR) ?
       opt__get_string(OPT__AUTHOR) : NULL,
       NULL, /* Password */
       NULL, /* Config dir */
       1, /* no_auth_cache */
       cfg,
       NULL, /* cancel function */
       NULL, /* cancel baton */
       pool)
      );

Does it help if you set some value for the configuration directory, which is
currently passed as NULL?


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: [feature request] ssl client-certificate auth

Author pmarek
Full name P.Marek
Date 2008-07-31 09:41:10 PDT
Message Hello Gunnar!

On Tuesday, 29 July 2008 Gunnar Thielebein wrote:
> "svn ls" works like expected.
...
> But when using the lines in the servers file globally or in .subversion
> it doesn't care about.
Do you have some publicly available server I can test against, or some other
way to make that (a bit easier) reproduceable for me?


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: Re: [feature request] ssl client-certificate auth

Author tekknokrat
Full name Gunnar Thielebein
Date 2008-07-29 07:59:26 PDT
Message Hi Phil,

first sorry for the delay on answering to this issue.
There some family affairs which keeps me currently busy.

I tested your proposal with a client certificate apache backend.

When I define a /etc/subversion/servers file with these lines:
> [groups]
> localhost = localhost
> [localhost]
> ssl-client-cert-file = /etc/ssl/version-man​agement/clientcert.p​12
> ssl-client-cert-password = ********
> [global]
> ssl-authority-files = /etc/ssl/version-man​agement/demoCA/cacer​t.pem
"svn ls" works like expected.

Without these lines "svn ls" ask for certificate file, everytime it is
performed and also when permanently accepting the key.

when using fsvs it also asks for certificate file and it works (which is
very nice) when I manullay input the keypath,
But when using the lines in the servers file globally or in .subversion
it doesn't care about.

Best Regards, Gunnar

Philipp Marek schrieb:
> On Monday 07 July 2008 Gunnar Thielebein wrote:
>
>> I have seen that this feature already exists in the svn client and can
>> be controlled via
>>
>> the following directives in subversion configuration:
>>
>>> ssl-client-cert-file
>>> ssl-client-cert-password
>>>
>> The access to the repository should be authenticated in a host-based way.
>>
> ...
>
>> Using ssh for host-based authentication does not offer the flexibility
>> of apache2 which we need in this scenario.
>>
> Maybe it already works if you get a successfull "svn ls http://..." and use
> the ~root/.subversion on the target machine?
>
> FSVS just invokes the default handler of subversion; but it's possible that
> something has to be done specially for certificate based authentication.
> (But that would be awfully nice - imagine using a smartcard!)
>
>
> Could you test that, please?
>
>
>
> Regards,
>
> Phil
>
>

Re: [feature request] ssl client-certificate auth

Author pmarek
Full name P.Marek
Date 2008-07-12 05:30:44 PDT
Message On Monday 07 July 2008 Gunnar Thielebein wrote:
> I have seen that this feature already exists in the svn client and can
> be controlled via
>
> the following directives in subversion configuration:
> > ssl-client-cert-file
> > ssl-client-cert-password
>
> The access to the repository should be authenticated in a host-based way.
...
> Using ssh for host-based authentication does not offer the flexibility
> of apache2 which we need in this scenario.
Maybe it already works if you get a successfull "svn ls http://..." and use
the ~root/.subversion on the target machine?

FSVS just invokes the default handler of subversion; but it's possible that
something has to be done specially for certificate based authentication.
(But that would be awfully nice - imagine using a smartcard!)


Could you test that, please?



Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

[feature request] ssl client-certificate auth

Author tekknokrat
Full name Gunnar Thielebein
Date 2008-07-07 07:13:20 PDT
Message I have seen that this feature already exists in the svn client and can
be controlled via
the following directives in subversion configuration:

> ssl-client-cert-file
> ssl-client-cert-password

The access to the repository should be authenticated in a host-based way.
This would also offer the oppurtinity to evaluate key attributes on
server side for url rewrite and verify the the origin of the http-request.
We need a password option for avoiding the password request when
http-auth. I am not sure for now if the svn-client does seperate
password requests (ssl/http-auth).
For our scenario if the password is stored http-auth should use this
password. We need http-auth to get the username of the committer.

Userbased authorisation makes no sense in our environment as every
fsvs-user is also admin and therefore could fake the username / spy
passwords.
Using ssh for host-based authentication does not offer the flexibility
of apache2 which we need in this scenario.

Best Regards,
Gunnar Thielebein
Messages per page: