ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <>
Subject RE: [Ant]Read buid.xml file in memory
Date Fri, 13 Feb 2015 13:23:18 GMT

> Date: Thu, 12 Feb 2015 23:53:19 -0600
> Subject: Re: [Ant]Read buid.xml file in memory
> From:
> To:
> On Thu, Feb 12, 2015 at 7:54 PM, Jackie Xiao wrote:
> > The thing is, we need to enable customers to work with us, but we
> > don’t want to share the build scripts (I know it’s weird).
> Then maybe you should consider using the Ant API directly to set your
> tasks and what not, or a different tool entirely.
> One method you can try, depending on how paranoid you are about your
> customers accessing your "build scripts" is the following:
>   - Store your build script encrypted, maybe stored as a resource in
>     a jar file.
>   - Decrypt the file to a temp file, launch Ant with the temp file, then
>     after it loads it, delete the temp file.
> This sets up a race condition, but I think this may be sufficient
> because a determined persion will be able to see your scripts even if
> they are all in memory.  E.g. Run your program in a debugger and trace
> thru until the data is decrypted to access the raw script.
> Also, you mention "encrypt", but that requires a decryption key, so how
> would you prevent a customer from finding the key and decrypting the
> file(s)?  Are you running as a service or privileged process and your
> customers do not have local access to the systems?
> > So, we want to encrypt the build.xml and give them the encrypted file.
> >
> > In the build process, we will decrypt build.xml in memory, and if Ant
> > can read the content from memory, this should work.
> Another possible approach is register your own URL protocol handler.  It
> appears that Ant's builtin project helper does support a URL to a
> resource, so if you create your own custom protocol and handler, this
> will give you the opportunity to do your decryption phase when Ant
> requests the inputstream to the resource.
> Without knowing the full context of your operating environment and your
> relationship with your customers, you may be looking at the problem in
> the wrong way, where alternative approachs may exist that satisfy your
> business constraints.
> --ewh
MG>a customised protocol would solve the problem but 99% of web app webmasters would
MG>implement their webapps on a HTTPS connection implementing SSLv3/TLS
MG>the right way to implement secure connections are with certificate and public-key and
MG>so you can implement certificate with 1 key (symmetric key)
MG>but symmetric is not as hardened as 2 way asymmetric which protects both sides of the
MG>if your client is serious about encryption i would contact these folks for certs/keys
on securing your site
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message