SVN 1.6 - not a valid URL - macos

Recently I uninstalled SVN 1.7 from mac osx and installed SVN 1.6.23 following the instructions on this page: How do I uninstall subversion on OS X
'svn --version' runs well and says 1.6.23 is installed.
but when I run:
svn info http://www.domainname.com/svn/path_to_folder
it gives me following error:
http://www.domainname.com/svn/path_to_folder: (Not a valid URL)
svn: A problem occurred; see other errors for details
The command works fine on another mac which had SVN 1.6.18 preinstalled. So there is no problem with the server or the commands. Does anyone know what it could be?

You don't have any repository access module (RA) that can communicate with repositories using the HTTP protocol. If you only have ra_svn and ra_local you can only use svn: or file: URLs:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- handles 'http' scheme
- handles 'https' scheme
You've apparently compiled your own binaries. The INSTALL file mentions this:
b. Serf library 0.3.0 or newer (http://code.google.com/p/serf/)
serf is a library for HTTP and WebDAV which is an alternative to
Neon for accessing Subversion repositories over http:// and https://
URLs. serf is designed as an asynchronous library which can take
advantage of HTTP pipelining, so ra_serf may be more efficient than
ra_neon and better for HTTP proxy caches. The serf library can be
found at:
http://code.google.com/p/serf/
In order to use ra_serf instead of ra_neon, you must install serf,
and run Subversion's ./configure with the argument --with-serf. (To
only use ra_serf and not ra_neon, you should also use
--without-neon.) If serf is installed in a non-standard place, you should use
--with-serf=/path/to/serf/install
instead. If you build with both ra_neon and ra_serf, Subversion
will use ra_neon by default; add "http-library = serf" to the
[global] section of your ~/.subversion/servers file to use ra_serf
instead.
For more information on serf and Subversion's ra_serf, see the file
subversion/libsvn_ra_serf/README.

Related

Allow HTTP download in Android Studio

I am getting the following error in Android Studio:
> Could not download builder-4.1.2.jar (com.android.tools.build:builder:4.1.2)
> Could not get resource 'http://10.252.250.53:8081/lm/content/groups/public/com/android/tools/build/builder/4.1.2/builder-4.1.2.jar'.
> Could not GET 'http://10.252.250.53:8081/lm/content/groups/public/com/android/tools/build/builder/4.1.2/builder-4.1.2.jar'.
> Connect to 10.252.250.53:8081 [/10.252.250.53] failed: Connection timed out: connect
I am able to download the file from that link in a browser. So I believe the issue is that Android Studio is not allowing HTTP download.
Please guide.
The file you download is quite outdated; this is version 7.0.2 meanwhile.
Either add a self-signed SSL certificate to 10.252.250.53:8081 + local machine and define a proxy:
systemProp.https.proxyHost=10.252.250.53
systemProp.https.proxyPort=8081
Or downgrade back to Gradle < 7.0 ...if you really want to use HTTP (which is merely dead already).

Proxy authentication with s_client

Note: this is not a duplicate of openssl s_client using a proxy, as I am specifically interested in proxy authentication, not the ability to use proxy.
I'm using openssl s_client to inspect certificates of the target server to understand how/where the connection works or not. As I'm behind a corporate proxy, I can specify the proxy server with -proxy flag, however I need to pass authentication details (username/password) to this proxy - and I haven't figured out how to do that.
openssl s_client -proxy my.proxy.server:8080 -connect my.target.host
successfully connect to the proxy server, however, understandably, results in error s_client: HTTP CONNECT failed: 407 Unauthorized.
Passing proxy server in the form of user:pass#my.proxy.server or http://user:pass#my.proxy.server both result in error s_client: -proxy argument malformed or ambiguous.
How can I pass proxy authentication to s_client? I would find it hard to believe that it supports proxy but not authenticated proxy.
I'm using openssl version 1.1.1a.
Just to follow up on #Arnaud Grandville's answer: OpenSSL v3 beta 1 has now been released, and it includes proxy authentication options. You have to compile it yourself, however.
Unfortunately in v3 beta 1 the HTTP code had some issues so you can't use the code from their website as-is. Anyone looking to compile from source can use the commands below to get an OpenSSL installation with working proxy authentication:
git clone --branch openssl-3.0.0-beta1 https://github.com/openssl/openssl.git
cd openssl
git fetch
git checkout 6a1f9cd -- crypto/http/http_client.c
./Configure
make
make install
Edit: For later versions this is no longer necessary as the bug was fixed. For example for version 3.0.5 you can simply run:
git clone --branch openssl-3.0.5 https://github.com/openssl/openssl.git
cd openssl
./Configure
make
make install
You can use escape-from-intranet https://github.com/quaddy-services/escape-from-intranet#introduction
and specify
host=my.proxy.server
port=8080
in the app and use
openssl s_client -proxy localhost:3128 -connect my.target.host
and your local running application will enrich the real proxy call with your credentials.
(In case you have a transparent proxy you need to switch the default proxy decision to "PROXY" in the "Decision" Menu)
openssl v3.0 will supports proxy_user and proxy_pass options.
no solution for now, the syntax after proxy is
host + ':' + service
host + ':' + '*'
host + ':'
':' + service
'*' + ':' + service
host
service
cf. BIO_parse_hostserv

How to specify svn url to access a repos on a Windows machine from a mac on a local network?

I don't use mac very often and am trying to figure out what the correct URL is to connect to a repository shared from my windows machine. I was thinking of something like file://\winMachine/svnrepo, but that's not working.
I don't see how that would differ from normal ways of accessing network shared resources. The only issue here would be that OSX might not resolve NETBIOS names, so you might want to use the IP.
You should clone the repository through command line or GUI using the URL provided by the SVN Server, ex.: http://10.0.0.1:8080/svn/Project/
[yurieastwood#mbp ~]$ svn checkout --username yeastwood http://10.0.0.1:8080/svn/SampleProject/trunk/
Authentication realm: <http://10.0.0.1:8080> VisualSVN Server
Password for 'yeastwood': *********
A trunk/SampleProject.XmlImporter
A trunk/SampleProject.XmlImporter/SampleProject.XmlImporter.csproj
A trunk/SampleProject.XmlImporter/JsonConvertTask.cs
A trunk/SampleProject.XmlImporter/packages.config
A trunk/SampleProject.XmlImporter/bin
A trunk/SampleProject.XmlImporter/bin/Release
A trunk/SampleProject.XmlImporter/bin/Debug
A trunk/SampleProject.XmlImporter/bin/Debug/SampleProject.Framework.pdb
A trunk/SampleProject.XmlImporter/bin/Debug/Autorun.mdf
A trunk/SampleProject.XmlImporter/bin/Debug/Autorun_log.LDF
A trunk/SampleProject.XmlImporter/bin/Debug/SampleProject.XmlImporter.pdb
A trunk/SampleProject.XmlImporter/bin/Debug/SampleProject.Framework.dll
A trunk/SampleProject.XmlImporter/bin/Debug/Newtonsoft.Json.dll
A trunk/SampleProject.XmlImporter/bin/Debug/SampleProject.XmlImporter.dll
A trunk/SampleProject.XmlImporter/bin/Debug/Newtonsoft.Json.xml
Checked out revision 7.
[yurieastwood#mbp ~]$
P.S.: If you want to access shared folders from Windows machines you should use the SMB protocol, ex.: smb://10.0.0.1, through Finder -> Go -> Connect to Servers.

Proxy ProGet nuget repository/feed in Nexus OSS 3?

I have two windows machines, one running Nexus OSS 3 and the other running ProGet.
Now I would like to create a nuget proxy repository in Nexus that points to one of the feeds/repositories I have in ProGet. I have followed this guide: nuget proxy repository where I basically copied the nuget.org-proxy proxy configuration that comes by default when you install Nexus OSS 3.
But I keep getting this error from command line
GET http://mynexus:8082/repository/tools-proxy/Packages(Id='x',Version='1.1.1')
GET http://mynexus:8082/repository/tools-proxy/Packages(Id='x',Version='1.1.1.0')
System.InvalidOperationException: Unable to find version '1.1.1' of package 'x'.
at NuGet.PackageHelper.ResolvePackage(IPackageRepository repository, String packageId, SemanticVersion version)
And the Nexus web log:
2016-05-25 20:13:28,252+0200 INFO [qtp1305498137-264] admin org.sonatype.nexus.rapture.internal.security.SessionServlet - Deleting session for user: admin
2016-05-25 20:13:32,971+0200 ERROR [qtp1305498137-282] *UNKNOWN org.sonatype.nexus.extdirect.internal.ExtDirectServlet - Failed to invoke action method: coreui_Repository.coreui_Repository_readStatus, java-method: org.sonatype.nexus.coreui.RepositoryComponent.readStatus
org.apache.shiro.authz.UnauthenticatedException: The current Subject is not authenticated. Access denied.
at org.apache.shiro.authz.aop.AuthenticatedAnnotationHandler.assertAuthorized(AuthenticatedAnnotationHandler.java:53) [na:na]
at org.a
When I run nuget install on a package X specifying the proxy repository URL as source:
nuget install x -Version 1.1.1 -Source http://mynexus:8082/repository/tools-proxy -Pre -NoCache -Verbosity detailed
That package indeed exists in the original ProGet feed and if I specify the direct/non-proxy feed instead the install works fine:
nuget install x -Version 1.1.1 -Source http://myproget:8181/repository/tools -Pre -NoCache -Verbosity detailed
GET http://myproget:8181/nuget/Tools/Packages(Id='x',Version='1.1.1')
GET http://myproget:8181/nuget/Tools/package/x/1.1.1
Installing 'x 1.1.1'.
Successfully installed 'x 1.1.1'.
I have tried with nuget version 2.8 and 3.4.
My ProGet server is configured with Built-In authentication:
Anonymous have download access:
Why do I get this access error when Anonymous have download access on my ProGet server?

git trouble via https: routines:SSL23_GET_SERVER_HELLO

I made my own git server on a centos distribution.
I can contact the server via git protocol at my home. But when I try to access via https at office I obtain:
Cloning into /Users/vito/Documents/... error:
error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112) while
accessing https://gitolite#myserverxyz.com/vitorepo.git/info/refs
fatal: HTTP request failed
Where is the problem? On my server or on my office-mac?
I got the exact same response from curl when trying to connect with an ubuntu instance running openssl 1.0.0e. I successfully resolved the problem by adding the -ssl3 flag to the curl command.
It seems that it's a compatibility problem between older version of OpenSSL (0.9.8) acting as a client and recent OpenSSL version (1.0.0) acting as a server with some specific options used by Curl on client side and Apache on server side.
It's probably due to some recent security fix in OpenSSL (probably the one against protocol downgrade attacks).
Try upgrading the OpenSSL library version on the client side to 1.0.0.
See:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3395520&group_id=976
In case anyone has this issue with XMLRPC.
Daniel's answer (forcing SSL version 3) solved the issue for me. just specify XMLRPC_SSLVERSION_SSLv3 in the clientXmlTransport_curl options (C++).
The problem began when we upgraded our server to OpenSSL version 1.0.1-4ubuntu5.5 and the clients were still running 0.9.8o-5ubuntu1.7.
I believe this is a host-name matching issue on the server. Error 1112 is SSL_R_TLSV1_UNRECOGNIZED_NAME, and comes from an SNI name mismatch (info on SNI). I was having the same issue in curl.
For me, the work around was to make sure the name I used on the client matched one of the ServerName or ServerAlias configurations on the server. Of course, these commands are for an apache server; I don't know what you need to do for a git server. But I suspect the server names you're using from home and work are different, and the home name is the cannonical name the git server is using (and therefore SNI is working).
The 'real' fix will probably take a client change in git to allow a way to ignore the name-mismatch warning (the way your browser already does).
Not sure if I had exactly the same problem, but the error message was the same. It only seemed to be happening on the ubuntu box I set up a git server on, for some reason the centos box with a git server set up on it was fine.
I only just solved it after 3 or 4 days. It turns out to be because git's underlying Curl library has a broken Keep-alive implementation (I ended up dumping HTTP traffic and verifying the behaviour by hand).
In a nutshell Curl (at least the version used inside every Git implementation I could find, including command line git and eclipse's EGit) doesn't seem to correctly interpret the Connection response header, or more correctly doesn't seem to correctly interpret the absence of it.
To fix the problem you need to configure the SSL virtual host inside the apache that is serving your GIT repository with an extra directive specifically for git. Add these lines just before the </VirtualHost>.
BrowserMatch "git" nokeepalive ssl-unclean-shutdown
You unfortunately can't tell apache to just downgrade to HTTP/1.0 (would be cleaner) because Curl can't handle that, but you can just tell it to force a Connection:close on every request which Curl does know how to handle.
In a misleading coincidence, if you try to test Curl directly without this change it will seem to work, because it makes a single request and then aborts. Only by getting curl to execute two requests on the same keep-alive connection over ssl will this problem become apparent.
I had the same error. The root cause seems to be incompatibility of client/server openssl versions.
I've upgraded my server with apt-get upgrade openssl and upgraded my windows git installation.
The combination of windows git client
git version 1.9.4.msysgit.0, which contains openssl version:
OpenSSL 0.9.8e 23 Feb 2007
And server with openssl version:
OpenSSL 1.0.1c 10 May 2012
seems to work fine together.

Resources