Using the system property will effect CXF instance across the JVM.
It could be good if we can do it on the bus level.

--  
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
          http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: willemjiang




On Thursday, October 18, 2012 at 9:05 PM, Aki Yoshida wrote:

> Hi Freeman,
> yes. This should be an option and disabled by default.
> I am thinking about introducing a system property
> org.apache.cxf.io.CachedOutputStream.something to set the cipher
> transformation name to enable this option.
>  
> regards, aki
>  
> 2012/10/18 Freeman Fang <[email protected] 
> (mailto:[email protected])>:
> > Hi Aki,
> >  
> > Basically I'm +1 for this good idea. Just a little bit concern about the 
> > performance impact.
> > Could we add a flag to enable this encryption behavior? By default the 
> > value is false, so keep same behavior as is, and users can explicitly 
> > enable it if they need a higher secure runtime.
> >  
> > My 2 cents.
> > Best Regards
> > Freeman
> > -------------
> > Freeman(Yue) Fang
> >  
> > Red Hat, Inc.
> > FuseSource is now part of Red Hat
> > Web: http://fusesource.com | http://www.redhat.com/
> > Twitter: freemanfang
> > Blog: http://freemanfang.blogspot.com
> > http://blog.sina.com.cn/u/1473905042
> > weibo: http://weibo.com/u/1473905042
> >  
> > On 2012-10-18, at 下午8:31, Aki Yoshida wrote:
> >  
> > > Hi,
> > > There is a concern that these temporary files are written out to the
> > > file system without any protection. And I was wondering if we can add
> > > an option to enable encryption for the stream output and keep the key
> > > in the COS instance so that only that COS instance can later read the
> > > data from the file system.
> > >  
> > > Is there any security concern to this approach? If none, I will go
> > > ahead and add this option.
> > >  
> > > thanks.
> > > regards, aki
> >  
>  



Reply via email to