On 14/04/2012, at 10:50 PM, Adam Murdoch wrote: > On 13/04/2012, at 10:26 PM, [email protected] wrote: > >> It might be nice to have a convention for a custom trust store to be used >> for a build. That way the store could be checked in. > > Ultimately, our credentials management will be able to source credentials > from multiple locations (where 'credentials' here means both the stuff that > the build uses to prove who it is to other parties, and that the build uses > to verify other parties). My thought is that there won't be a baked in policy > for where to get credentials, much like there isn't a baked in policy for > where to get dependencies from. Instead, there will be something similar to > the repository DSL, plus a bunch of plugins to add new types of providers, > and some plugins to apply a convention over the top. > > So, it should definitely be easy to say in your build: "use the key store in > $rootDir/$someConventionalLocation" - whatever form that takes.
All good stuff, but I think in practice this will be slightly different if the build needs to change the _default_ trust store as it has to happen at JVM startup. The better option would be to make sure that for all of our API, we allow the user to specify the truststore to use. Right now, by far the most common case will be dealing with internal HTTPS repos that use internal CAs. I'm pretty confident we could inject the truststore into these operations, at least for the resolvers we now control (unsure about the legacy Ivy ones). If we remove the need for using the default truststore from our API, then we could reasonably put this on the user to manage if they are using some 3rd party tool in their build that doesn't allow the truststore to be injected. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
