You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Avalon <th...@gmx.de> on 2007/02/04 22:25:15 UTC
Feature request: argument to accept not trusted certificate when
using --non-interactive
Hello,
the described problem has already been discussed - with no solution - in
the thread
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=105743 and
a related issue http://subversion.tigris.org/issues/show_bug.cgi?id=2597
When using subversion from a script with --non-interactive and a
ssl-server with a self-signed certificate the certificate verification
fails because the issuer is not trusted.
The described workarounds to:
- interactively accept the certificate once permanently
- add the certificate to the "accepted" list
are unfortunately not feasible in some scenarios.
Is their any way to get an additional argument like
"--trust-server-cert" or do the developers think relaxing the security
in that way is a no-go?
Best regards,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: argument to accept not trusted certificate when
using --non-interactive
Posted by Jens Peters <jp...@gmx.de>.
> Automated, non-interactive scripts, 'round about the time a particular
> certificate gets renewed?
>
Or running the Subversion testsuite against a non trusted https
location :)
Regards,
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: Feature request: argument to accept not trusted certificate when using --non-interactive
Posted by Will Wilson <wi...@fireflyworlds.com>.
> Or, an automation script that is run on a list of systems to
> get/update local working copies. It'd be nice not to have to log on to
> each system to accept the "not trusted" certificates from all
Subversion servers.
Just to add a vote for such a facility. We use a "non trusted"
certificate for internal development and this issue often comes up when
creating build slaves. We simply need the basic encryption, so paying
for a trusted certificate is simply not worth it.
Will.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: Feature request: argument to accept not trusted certificate when using --non-interactive
Posted by "Rowell, Geoff" <gr...@ENVOYWW.COM>.
C. Michael Pilato <cm...@collab.net> wrote:
>
> mark benedetto king wrote:
> > Sorry to come so late to the thread, but can you give an example
> scenario
> > in which is it not feasible to accept the certificate once?
>
> Automated, non-interactive scripts, 'round about the time a particular
> certificate gets renewed?
Or, an automation script that is run on a list of systems to get/update
local working copies. It'd be nice not to have to log on to each system
to accept the "not trusted" certificates from all Subversion servers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: argument to accept not trusted certificate when
using --non-interactive
Posted by "C. Michael Pilato" <cm...@collab.net>.
mark benedetto king wrote:
> Sorry to come so late to the thread, but can you give an example scenario
> in which is it not feasible to accept the certificate once?
Automated, non-interactive scripts, 'round about the time a particular
certificate gets renewed?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Feature request: argument to accept not trusted certificate when using --non-interactive
Posted by mark benedetto king <mb...@lowlatency.com>.
On Tue, Feb 06, 2007 at 02:35:53PM -0800, Daniel Rall wrote:
> On Sun, 04 Feb 2007, Avalon wrote:
>
> > Hello,
> >
> > the described problem has already been discussed - with no solution - in
> > the thread
> > http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=105743 and
> > a related issue http://subversion.tigris.org/issues/show_bug.cgi?id=2597
> >
> > When using subversion from a script with --non-interactive and a
> > ssl-server with a self-signed certificate the certificate verification
> > fails because the issuer is not trusted.
> >
> > The described workarounds to:
> > - interactively accept the certificate once permanently
> > - add the certificate to the "accepted" list
> > are unfortunately not feasible in some scenarios.
> >
> > Is their any way to get an additional argument like
> > "--trust-server-cert" or do the developers think relaxing the security
> > in that way is a no-go?
>
> I am very much in favor of some support for untrusted certificates.
>
> I currently use a patched version of Subversion in my company's
> product to work around this limitation. I do not find having to patch
> Subversion to be an acceptable work-around for this (valid) use case.
>
Sorry to come so late to the thread, but can you give an example scenario
in which is it not feasible to accept the certificate once?
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature request: argument to accept not trusted certificate when using --non-interactive
Posted by Daniel Rall <dl...@collab.net>.
On Sun, 04 Feb 2007, Avalon wrote:
> Hello,
>
> the described problem has already been discussed - with no solution - in
> the thread
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=105743 and
> a related issue http://subversion.tigris.org/issues/show_bug.cgi?id=2597
>
> When using subversion from a script with --non-interactive and a
> ssl-server with a self-signed certificate the certificate verification
> fails because the issuer is not trusted.
>
> The described workarounds to:
> - interactively accept the certificate once permanently
> - add the certificate to the "accepted" list
> are unfortunately not feasible in some scenarios.
>
> Is their any way to get an additional argument like
> "--trust-server-cert" or do the developers think relaxing the security
> in that way is a no-go?
I am very much in favor of some support for untrusted certificates.
I currently use a patched version of Subversion in my company's
product to work around this limitation. I do not find having to patch
Subversion to be an acceptable work-around for this (valid) use case.
- Dan