Redmine

Execute command with sudoer (person who holds administrative rights).

sudo su www-data

And then issue svn checkout procedure.

Thanks for the tip. I gave that a try, and now when I can perform a svn checkout as www-data through the console, but I'm still getting the following error via Redmine.

Error validating server certificate for 'https://wush.net:443':
 - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information:
 - Hostname: wush.net
 - Valid: from Tue, 17 May 2005 00:00:00 GMT until Thu, 14 Aug 2008 23:59:59 GMT
 - Issuer: (c)2002 Comodo Limited, Terms and Conditions of use: http://www.comodo.net/repository, Comodo Trust Network, Comodo Limited, GB
 - Fingerprint: 62:ab:bf:b6:56:cd:f3:1e:11:76:2d:51:b2:da:a5:e5:e1:03:8e:5f
(R)eject, accept (t)emporarily or accept (p)ermanently? svn: PROPFIND request failed on 'path/to/repo'
svn: PROPFIND of '/path/to/repo/project': Server certificate verification failed: issuer is not trusted (https://wush.net)

Is there another approach to get this to work? E.g., what's the non-workaround way to fix this?

Did you used <redmineroot>/svn/.subversion to store your accepted certificate as indicated in FAQ? And accepted it permanently? There might be way to provide automatic acceptance of certificate, but I'm not aware of that.

I did, and the directory

<redmineroot>/svn/.subversion/auth

Thanks for your help.

I'm running into this same problem when I run the script as www-data (apache2 on Ubuntu 8.04 with a self-signed SSL key).

I also experience a problem accessing log/production.log when I run the script, even though everything in the redmine tree is owned by www-data and in the www-data group, and the log files are all chmod 0666.

So I thought, why not try root. That account should be able to do anything. Lo and behold, running the script under root user succeeds, while running as www-data fails.

Don't know exactly why, but if this is the case, it appears to be a permissions issue.

The same problem here. I did all the steps described above and it didn't help in any way.

After that I've called: 'ruby script/runner "Repository.fetch_changesets" -e production' as root and now I can see changesets in redmine's repository viewer. But there is no repo browsing available; after clicking on a stored document I get an error saying that "object or version was not found in repository"; there is also no automatic update of changesets. I must do manual updates by runnig the above script. When I run the fetch_changesets script as www-data I get the certificate validation error. I'm on the latest redmine from svn :/

Shouldn't the issue 1235 be reopened?

I confirm this problem.

Here is the exception I get when trying to access the repository tab of an https server:

Processing RepositoriesController#show (for xxx.xxx.xxx.xxx at 2008-07-03 12:24:56) [GET]
  Session ID: ccb6698a581dc2b988a43266313ddec3
  Parameters: {"action"=>"show", "id"=>"portail-ipl", "controller"=>"repositories"}
Error parsing svn output: #<REXML::ParseException: No close tag for ["lists", "list"]>
/usr/lib/ruby/1.8/rexml/parsers/treeparser.rb:26:in `parse'
/usr/lib/ruby/1.8/rexml/document.rb:190:in `build'
/usr/lib/ruby/1.8/rexml/document.rb:45:in `initialize'
/var/www/redmine-0.7.2/lib/redmine/scm/adapters/subversion_adapter.rb:65:in `new'
/var/www/redmine-0.7.2/lib/redmine/scm/adapters/subversion_adapter.rb:65:in `entries'
/var/www/redmine-0.7.2/lib/redmine/scm/adapters/abstract_adapter.rb:127:in `call'
/var/www/redmine-0.7.2/lib/redmine/scm/adapters/abstract_adapter.rb:127:in `shellout'
/var/www/redmine-0.7.2/lib/redmine/scm/adapters/abstract_adapter.rb:125:in `popen'
/var/www/redmine-0.7.2/lib/redmine/scm/adapters/abstract_adapter.rb:125:in `shellout'
/var/www/redmine-0.7.2/lib/redmine/scm/adapters/subversion_adapter.rb:62:in `entries'
/var/www/redmine-0.7.2/app/models/repository.rb:52:in `entries'
/var/www/redmine-0.7.2/vendor/rails/activerecord/lib/active_record/associations/association_proxy.rb:125:in `send'
/var/www/redmine-0.7.2/vendor/rails/activerecord/lib/active_record/associations/association_proxy.rb:125:in `method_missing'
/var/www/redmine-0.7.2/app/controllers/repositories_controller.rb:55:in `show'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/base.rb:1158:in `send'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/base.rb:1158:in `perform_action_without_filters'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/filters.rb:697:in `call_filters'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/filters.rb:689:in `perform_action_without_benchmark'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/rescue.rb:199:in `perform_action_without_caching'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/caching.rb:678:in `perform_action'
/var/www/redmine-0.7.2/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:33:in `cache'
/var/www/redmine-0.7.2/vendor/rails/activerecord/lib/active_record/query_cache.rb:8:in `cache'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/caching.rb:677:in `perform_action'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/base.rb:524:in `send'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/base.rb:524:in `process_without_filters'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/filters.rb:685:in `process_without_session_management_support'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/session_management.rb:123:in `process'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/base.rb:388:in `process'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:171:in `handle_request'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:115:in `dispatch'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:126:in `dispatch_cgi'
/var/www/redmine-0.7.2/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:9:in `dispatch'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel/rails.rb:76:in `process'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel/rails.rb:74:in `synchronize'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel/rails.rb:74:in `process'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel.rb:159:in `process_client'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel.rb:158:in `each'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel.rb:158:in `process_client'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel.rb:285:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel.rb:285:in `initialize'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel.rb:285:in `new'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel.rb:285:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel.rb:268:in `initialize'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel.rb:268:in `new'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel.rb:268:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel/configurator.rb:282:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel/configurator.rb:281:in `each'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel/configurator.rb:281:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/mongrel_rails:128:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel/command.rb:212:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.4/bin/mongrel_rails:281
/var/lib/gems/1.8/bin/mongrel_rails:18:in `load'
/var/lib/gems/1.8/bin/mongrel_rails:18
...
No close tag for ["lists", "list"]
Line:
Position:
Last 80 unconsumed characters:
Output was:
 <?xml version="1.0"?>
<lists>
<list
   path="https://my-repository/portail-ipl">
Rendering template within layouts/base
Rendering repositories/show
Completed in 0.28837 (3 reqs/sec) | Rendering: 0.03092 (10%) | DB: 0.00000 (0%) | 200 OK [https://myredmine/repositories/show/portail-ipl]

When I run the same exact svn command from the command line as the mongrel user I have no error and the output is complete.
When this command is ran in redmine the output is truncated as chown after the "Output was:" at the end of the log.

The problem seems to be on line 65 of the file lib/redmine/scm/adapters/subversion_adapter.rb when parsing the result of "svn list --xml https://repository@rev" (which is truncated).

The lines/line problem on my system was tied to the virtual hosts declaration in my apache configuration. I had used the fqdn instead of *. Once I changed it back to *, that problem worked itself out.

I also found the solution to the log file issue. Apparently, instead of asking to set permissions to 0666, there is a notation on an update in trac that indicates the permissions should be set to 0777. Once I did that, I had no problem with the log file.

Now I'm just back to the subversion balking at the invalid certificate issue.

I have created <redmineapp>/.svn/subversion

I have edited the subversion_adapter.rb file changing SVN_BIN from "svn" to "svn --config-dir <redmineapp>/.svn/subversion"

I have executed chown -R www-data:\ <redmineapp>

I have executed chown -R www-data:\<redmineapp>\.*

I execute the commands "sudo su www-data" and "svn --config-dir <redmineapp>/.svn/subversion co" and the checkout is successful.

So now I'm down to the last ditch effort. I delete the <redmineapp>/.svn folder and all subfolders and reissue the "svn --config-dir <redmineapp>/.svn/subversion list" command.

I receive the prompt to accept the certificate. Select "p" for permanent.

Make sure you enter the username and password for the repository itself.

And if the command works properly, then you should be able to go back to redmine and...

Voila, we have a repository view.

Hope this helps.

Is this the only fix for SVN over HTTPS at the moment?

I just hit the same problem, but I don't know if I want to go through such a fix to get it working (this would be last resort).

Have any fixes hit trunk, do we know?

I've tried latest trunk but there is no fix for this issue :(

Sorry, but I doubt that there ever will be :-)

This is not something for Redmine to fix, really. The prompt from the svn binary is there to make sure you really really know that this cert is not a proper one. The proposed fix is not that hard to do, another fix (for some) would be to use a real ssl cert, then svn would not prompt.

A third possible fix if your SVN archive is on the same server would be to allow redmine to do HTTP-only access from localhost/127.0.0.1.

I totally agree on the manual validation of unofficial SSL certificates. Nevertheless, as I mention before, this does not work for me.
When running on the command line with mongrel user, everything is fine, but when running from redmine, the SVN responses are truncated and so unusable. The problem does not seem to be related with the SSL certificate as redmine receives some data but it's truncated.
Perhaps my problem comes from something else but I can't find what...

So, I'm having the same problem. Certificates are good, but the issue with the 'svn list --xml' won't the repository view work. I did notice that running the command manually that there is a slight 2 second delay right after this:

<lists>
<list
path="https://server/svn/proj/trunk">

gets spit out. After the delay I see the rest of the <entry/> stuff and the closing tags.

I'm on a RHEL5 box.

Anyone else seeing this?

Kit

I'm having the same issue as Kit. I noticed 2 seconds delay for command line as well. But I deployed both redmine and VisualSVN on the same windows server machine

I think I got this working. Here are the steps:

Basic Problem:
Server Key needs to be manually accepted. Since mongrel is running under its own user, how to do that?

Setup
We have a CentOS 5 system with mongrel_cluster running under the user 'mongrel'. When connecting to SVN over https, we were getting error that server certificate is not valid and needs to be permanently accepted manually.

The Hack
Please make sure you have already done this:
http://www.redmine.org/boards/2/topics/1325#message-3928
or replace the paths accordingly.

First, I created a home directory for mongrel. We will need these to save the accepted key.
Then:
su - mongrel -c 'svn export https://<path-to-svn>/ --username=<user> --password="password"

Doing this will ask for accepting the server certificate and add permanently. Add permanently (choose 'p').

Doing this will create a folder called auth in /home/mongrel

To make sure, run the command again to double check. This time certificate error will not be shown to you.
su - mongrel -c 'svn export https://<path-to-svn>/ --username=<user> --password="password"

Good. Now copy this folder to /etc/redmine-svn (from config dir of your SVN_BIN = "svn --config-dir /etc/redmine-svn")

So you should have /etc/redmine-svn/auth/...

Now you can remove the /home/mongrel folder. That should do it! This fixed the problem for me.

Cheers
Amit Jindal
Aquevix (www.aquevix.com)

I am having trouble with this.
I have run this command

sudo -u www-data svn --config-dir /data/redmine/.subversion co https://my.svn.server delete-me

I get prompted, accept, enter credentials and the auth is stored (I check that the files are there) and I can run the command again and I don't get prompted.

When I try and view the repository in redmine though it is not found.. checking the apache log it is complaining about an untrusted cert.

Have I done something wrong?

Did you follow these first?
http://www.redmine.org/boards/2/topics/1325#message-3928

Also, did you copy the contents of auth folder (created after first successful authentication) to /etc/redmine-svn ?

There must be something different in your configuration. I am no guru but this hack did work for me.

Amit Jindal
Aquevix (www.aquevix.com)

No hadn't seen that post.
I am running as www-data user so I don't have a home directory.
Also don't have an /etc/redmine-svn what is in there?

Thanks.

If you're facing the problem when running windows then you'll need PSExec from Sysinternals (http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx) and something like the following command:

psexec.exe -s "<fullPath>\mongrel_rails.bat" start -e production -p 3000 -l <fullPath>\mongrel.log -P <fullPath>\mongrel.pid -c <fullPath>\redmine

which will run mongrel as the localsystem account using the params you passed and store the server cert fingerprint in the correct location. Once you've accepted the cert - you can then install mongrel as a service and be able to access repositories under https.

I am using linux..
but thanks anyway :)

The instructions here:
haknick.tumblr.com/post/2380507902/redmine-svn-subversion-certificate-issue-ubuntu

seemed to work on Ubuntu. The main issue was how to cache the certificate as www-data user that redmine is running as.
Once that worked the rest is easy.

I had this exact same problem... twice. First when installing 1.2.0, then some time later (today) when installing 1.2.1. I had just forgotten about it and ended up reading this thread both times.

Anyway, the easiest fix is to patch the SVN adapter such that it always trusts certificates. This may or may not pose a security risk, but for me it was a convenient solution.

I've attached a patch file which can be applied to the SVN adapter as follows:

patch {redmine_root}/lib/redmine/scm/adapters/subversion_adapter {path-of-fix}/redmine-svn-trust-certificates.patch

Tested against 1.2.0 and 1.2.1.

That command line should have been

patch {redmine_root}/lib/redmine/scm/adapters/subversion_adapter.rb {path-of-fix}/redmine-svn-trust-certificates.patch

I have weird problem with version 1.2.1. I tried everything:
- upgrading svn to version 1.6
- updating configuration.yml
- modifying environment.rb
- modifying subversion_adapter.rb

But nothing helps. All the time I have the situation as on the attached screenshot. Can someone give some hints?