Serge Knystautas wrote: > Stefano Bagnara wrote: > > This does bring to light an important issue. What maven is doing is > > little beyond what we ask people to do re javamail and activation... > > download jars that will invariably not be signature checked. Maven > > just makes it much easier to do this and otherwise remove jar > > dependencies from svn.
When people download manually, they are responsible to validate the authenticity of what they download. Fortunately, the majority of people who naively don't verify their downloads at least tend to download them from the author's site, not from an insecure, public, repository of dubious content that has already had faux artifacts posted, although so far not maliciously. Maven downloads from that repository and does not authenticate the contents, which is an impedance mismatch between what it does as a tool, and the necessary self-policing required of such a tool. But that issue is separable from the other than you raise: > do we want to keep dependencies in svn or not? YES. Except for the JVM, yes. They do not change that often that this is a problem, and we can trust OUR infrastructure. There is a related thread currently going on the Directory server development list regarding how relying upon the repository has turned out to be a problem because it is now not easy to go back and build versions from as recently as a year ago. The Maven infrastructure is simply not stable, and you cannot rely upon it to preserve the necessary artifacts indefinitely. I am OK to exclude derby, although I find it convenient to have the specific version we use handy, and we've already removed ant. But at least I know that I will always be able to find all released versions of ASF projects in http://archive.apache.org/. If and when the ASF decides to host our own Maven repository wherein we can ensure that for all time we have ALL necessary artfifacts to build all historical versions, I'll be happy to revisit whether we should maintain the artifacts in SVN. --- Noel
