ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <>
Subject secure dependency artifacts
Date Thu, 24 Apr 2008 20:05:25 GMT
Currently we have an ivy repository that is within our corporate firewall on a shared Netapp
storage device.  It is constantly being added to as each continuous build publishes its latest
version.  In the past as part of the ANT build, we would zip up the source code used to produce
each build and publish it as an artifact along with the build.  This is useful for when developers
working on modules high up in the dependency chain need to debug down to a dependent module
inside their IDE.  Having the source zip files gives them the source code to debug into.

This is working great, but here comes a new corporate policy.  We have to increase the security
of our source code and closely monitor who has access to what.  We do this with our SVN server,
but by publishing the on a shared netapp storage device, anybody can go to the
network share and browse into these source zip files.  This essentially gives everybody access
to all source code.

So my question is if there is a way to have secured dependency artifacts?  Can we have all
artifacts be readable but then have the require a username and password before
it downloads with a resolve/retrieve?  Even if this were possible, we would still need to
keep the shared netapp storage device readable by everybody so that they could successfully
download dependencies other than the source zip files.

Any ideas?  Perhaps use the svnivy plugin and store our repository artifacts inside SVN which
has authentication options to protect against what is accessible??

Shawn Castrianni

This e-mail, including any attached files, may contain confidential and privileged information
for the sole use of the intended recipient.  Any review, use, distribution, or disclosure
by others is strictly prohibited.  If you are not the intended recipient (or authorized to
receive information for the intended recipient), please contact the sender by reply e-mail
and delete all copies of this message.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message