> Date: Thu, 12 Feb 2015 23:53:19 -0600
> Subject: Re: [Ant]Read buid.xml file in memory
> From: earlh...@gmail.com
> To: user@ant.apache.org
>
> 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
http://yaksman.org/~lweith/ssl.pdf
MG>the right way to implement secure connections are with certificate and
public-key and private-key
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 exchange
http://security.stackexchange.com/questions/7219/asymmetric-vs-symmetric-encryption
MG>if your client is serious about encryption i would contact these folks for
certs/keys on securing your site
https://www.symantec.com/ssl-sem-page/?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> For additional commands, e-mail: user-h...@ant.apache.org
>
