I work for a large company where we use an internally installed maven proxy for downloading dependencies. We have to use a proxy as our Network(Websense) does not allow downloading of files with the .jar extension. So whenever a pom declares an external dependency, maven tries to the get the jar files from the proxy. If it is not there in the proxy, the proxy will itself download it from the internet as the proxy is outside the purview of this Websense Nonsense. This method while not perfect works by and large.
The things that don't work are
Whenever we need to include a dependency for which there is no repository declared in the proxy server, that repository url has to be included manually.
The internal maven proxy does not have enough bandwidth to scale up. Some days it takes 10 minutes to download 7 MB jar file.
As a workaround we were thinking that if it were possible to install a P2P plugin in maven, then whenever a jar file is required maven could first check peers (for example local maven repo of the developer sitting next to me) before hitting the internal maven proxy. This will dramatically reduce the time it takes to download dependencies and also potentially avoid the bureaucracy of having someone to put an email to manually add maven repository urls.
You should install a repository manager (Artifactory, Archiva, Nexus in alphabetical order). The intention is to a have a single point which access the internet via the proxy and that should solve the problem. All developers only access the repository manager.
Related
I work within a very large enterprise that is reasonably paranoid about security. We have an enterprise Maven repository that mirrors central and other external repositories.
We are attempting to use an artifact whose source is on github, and which specifies its artifact repository is oss.sonatype.org. The main artifact has one dependency, developed by the same group, also on github, and also on oss.sonatype.org. Our mirror of central has both of those artifacts. I'm deliberately not mentioning the artifact, although it's probably not necessary. It's likely used by many other companies.
We have a service that specifies the first artifact as a dependency. When the build runs, it is able to get the artifact from our internal mirror. However, it also attempts to connect to oss.sonatype.org to see if it can find the artifacts there also. However, we intentionally do not have a proxy setting in our settings.xml file, which effectively prevents attempts to get artifacts from external repositories. This functionally works. We get the artifact from our internal mirror, not from the external repository.
However, what happens in this case is that the connection attempt to oss.sonatype.org, takes a long time, only to give up when it fails. It apparently attempts this connection quite a few times. In fact, when we tested a build with a customized settings.xml that DID set a proxy, we found that this ran two orders of magnitude faster than the one that times out the connection each time. Ironically, even though the build with the proxy goes much faster, it still fails to connect to oss.sonatype.org, with 401 errors (which is odd, as I though it allows anon access). This is not a problem, as we're getting the artifacts from our internal mirror, and with the proxy set, we simply get the 401 error much much quicker than without the proxy.
So, is there some way we can configure our Maven builds, such that when it gets the initial artifact, it simply gets both artifacts from our internal mirror, without attempting a connection to oss.sonatype.org, and very importantly, not changing the original artifacts at all?
Update:
I've examined the information about "mirrors" cited in the comment. Our setttings.xml in our CI server already has one mirror specification, which is approximately the following:
<mirror>
<id>nexus</id>
<mirrorOf>central</mirrorOf>
<url>https://.../nexus/content/groups/...-public-group</url>
</mirror>
If it helps, our intranet repository is Nexus.
It's not clear what additional mirror specifications I have to add to ensure that repository references to oss.sonatype.org go to our intranet repository instead.
I'm trying to understand how to work with a remote repository in Artifactory for a Go project. My initial expectation was that it'll work transparently, all I would need to do is to point GORPOXY variable to a virtual repository (with local and remote behind it), do go build and dependencies will either be downloaded from the Artifactory cache or Artifactory would download them transparently. Similar to the way it works for maven dependencies.
When I tried that, it complained that the dependencies weren't found in artifactory. Ok.
Reading the documentation two things stand out. First, there's nothing there about GOPROXY and everything is about using artifactory cli. That's a big downside for several reasons.
Second, is that you need to publish dependencies manually with jfrog rt go-publish go --self=false --deps=ALL and then dependencies appear under a local repository.
So I'm trying to figure out if 1) I can avoid using JFrog CLI and 2) what's the point of remote repositories if they don't proxy? Or maybe I'm missing something?
Artifactory 6.3.0
I understand your confusion on the blog post you mentioned, though I have a feeling the intent of the writer was to more show how the JFrog CLI can be used.
To answer your questions:
1) Yes, you don't have to use the JFrog CLI to build. Please check out the documentation on how to set up a remote repository for Go. This will guide you through setting up GitHub or GoCenter as a remote repository for your Go builds. This will allow you to set the GOPROXY environment variable following this structure <protocol>://<username>:<password>#<artifactory domain>/api/go/<go repository>.
2) Remote repositories will absolutely act as a proxy, caching the contents you download from the remote repository (copying a part from the user guide: A remote Go repository in Artifactory serves as a caching proxy for a public Go registry such as GoCenter or GitHub.)
I want to setup a development environment that allows reusing some artifacts from public Maven repositories like Maven Central, Code Haus. Specifically, I like the concept of transitive dependencies.
In our company, our production network cannot export any data outside, but we can push data inside. We already have some gateways to copy file from the outside into our network. Therefore, I could use this to copy the required packages manually but we would miss the power of maven. In our case, the perfect solution would be to be able to get data from public repository but be forbidden to deploy to the external repo.
So I would like to have your expert view on this problem.
We can use various means, as long as the capability to export data outside our network is guarantee:
External packages are created on a disk area that is read-only from production servers.
Some HTTP requests are filtered.
Using a repository manager, as Nexus.
In the repository management guide, Nexus talks about this possibility (http://books.sonatype.com/nexus-book/reference/confignx-sect-manage-repo.html). I would like a confirmation from you guys about how secure it is. Specifically, this has to be updated only by the IT manager.
Regards,
Loïc.
This is completely feasible and a common setup with Nexus. Here are the steps roughly.
Lock all developers and CI server inside the network disallowing direct access to outside servers
Setup Nexus to proxy external repositories like Central as desired
Allow Nexus to reach to those external repositories via the proxy
Configure developers and CI server machines to access Nexus to get the dependencies (and transitive dependencies) as desired
Optionally you can also
Configure CI servers to deploy any internal packages to Nexus
Configure deployment tools to get components for deployment from Nexus
Also note this can be done via different repository formats and toolchains. The common one is Maven, but Nexus also supports NPM, Nuget, Rubygems, sites, YUM and others.
And if you want to make some of your packages in Nexus available to the outside you can configure this as well following multiple options.
Also note that a proxy repository is by definition read only in terms of deployments to it directly. Thats what a hosted repository is for...
I have small open-source projects hosted on Github which I want to make available for others via Maven. I have a small webspace where I can host static files. How can I create a repo? Also, I would want to remove old snapshots from there if possible.
Standard maven repository implementations are almost all Tomcat web apps. Each one of them should have a static repository, just as your local repository. The webapp serves to the purpose of searching and management of the artifacts stored in that static repository.
If you want to host the repository with static web access only, you'll have to perform the management manually and provide a static manually generated html page that contains GAV coordinates of all artifacts in the repo. No other user but you could ever upload to the repository unless you give your password or enable anonymous FTP acces.
If maven doesn't try to upload anything to the repo until the deploy phase then this approach is still partly usable, since running a mvn clean deploy should fail.
You can check if is it doable like this (I suppose that you have that projects in your local repo):
upload your local repoistory folder to a URL
for the purpose of testing mirror your central repo to that URL
try to build your project with dependencies from your repo
Open your settings.xml file and under <mirrors> node add:
<mirror>
<url>http://your/url/repo</url>
<mirrorOf>*</mirrorOf>
</mirror>
and see if mvn clean install suceeds. Please feedback.
In this SO answer I have outlined the way I set up my OSS projects which are all hosted in Github. There are actually a number of free services out there you could you when you would like to run an OSS project.
I would recommend publishing to Maven Central, if your plugin is well-tested and expected to bring other people benefits as well. You can use CloudBee's BuildHive as a free Jenkins CI.
A static repo works great, per my experience.
I scp'd up my local repository into a static apache server. Legit repo. Not as easy to maintain as a real repo of course, but quite a bit cheaper if you've already got a plain vanilla web host.
Other than setting the permissions properly (same as required for you to browse the folders), it was a pretty painless procedure.
The only two things I did to make it more reasonable were
1 - Wrote a script to "rm -rf ...." on most of the contents of my local repo so that the only thing I am deploying is those few artifacts that are not available in the general repos.
2 - Tarred it up first before scping to my web host.
Hope this helps.
The guy below did something similar, only using FTP which saves him a lot of hand work if he updates his binaries very often.
http://stuartsierra.com/2009/09/08/run-your-own-maven-repository
I think I know how to do it now. I'm using mvn deploy now to create a local repository on the file system and then I upload it to the webserver. If I'm not wrong, there doesn't even need to be a file listing.
The command I'm using is:
mvn deploy -DaltDeploymentRepository=local::default::file:./repo
This creates/updates the local repository automatically, so the repo can be synced with a server.
I was trying to find if there is SSL enabled central repository but there probably isn't. I noticed that there are signatures for every jar and pom file in maven central repository. So at least I'd like to check signatures of all maven downloaded files (pom/jar).
The example from http://repo1.maven.org/maven2/org/apache/ant/ant/1.8.2/:
ant-1.8.2.jar
ant-1.8.2.jar.asc
ant-1.8.2.jar.asc.md5
ant-1.8.2.jar.asc.sha1
ant-1.8.2.jar.md5
ant-1.8.2.jar.sha1
ant-1.8.2.pom
ant-1.8.2.pom.asc
ant-1.8.2.pom.asc.md5
ant-1.8.2.pom.asc.sha1
ant-1.8.2.pom.md5
ant-1.8.2.pom.sha1
I realize that I'll have to import public keys for every repository and I'm fine with that. I guess that public keys for maven central are here https://svn.apache.org/repos/asf/maven/project/KEYS.
There are PLENTY of tutorials on web on how to sign with maven. However I didn't find any information on how to force maven (2 or 3) to verify signatures of downloaded jar/pom files. Is it possible?
(Nexus Professional is not an option)
Thank you for help.
Now, that people seem to realize this is a real security problem (as described in this blog-post (the blog seems down, here is an archived version of the blog)), there is a plugin for verifying PGP signatures. You can verify the signatures for all dependencies of your project with the following command:
mvn org.simplify4u.plugins:pgpverify-maven-plugin:check
Of course, to be 100% sure the plugin is not malicious by itself, you would have to download and verify the source for the plugin from maven central, build it with maven, and execute it. (And this should also be done with all the dependencies and plugins that are needed for the build, recursively.)
Or you use Maven 3.2.3 or above (with a clean repository), which uses TLS for downloading all artefacts. Thus man-in-the-middle attacks are impossible and you get at least the artefacts as they are on maven central.
See also:
related Question and Answer
Sonatype's Blog to this topic
Could you write a bash shell script using GnuPG to verify each sig?
Something like:
for x in *.jar; do gpg --verify "${x}".asc; done
Obviously you would need the public keys for all the sigs before you started.
SSL access to Central is now available for a token payment. From https://blog.sonatype.com/people/2012/10/now-available-ssl-connectivity-to-central/ :
We’re making SSL connectivity to Central available to anyone that downloads open source components regardless of the repository manager.
...
In order to ensure the highest level of performance for those who count on SSL, we are securing the service with a token. You can get a token for your organization simply by providing a $10 donation that will be donated to open source causes.
Assuming you only want to download artifacts w/ valid checksums, one option would be to run the OSS version of Nexus and configure it to have a proxy of central. Then configure your settings.xml to only load from your repo (mirror tag in settings.xml). You can then configure nexus to only allow artifacts that have a valid checksum.