Hi Ernesto, On Tue, Jan 21, 2020 at 10:30 PM Ernesto Reinaldo Barreiro < reier...@gmail.com> wrote:
> IMHO more than marketing it is important not to lose/disrupt customers and > people that has been using wicket for MANY years. Even less when 9.x has > been waiting to be released for quite some time. e.g. for my current > customer I've been keeping a branch of application that is 9.x. A few > months ago there was a tlak that 9,x will be out sooner than later, I > haven't updated that branch for a while now. I'm afraid is some disruptives > changes are rolled out now this will discourage people to migrate. I > haven't been following development of CSP in detail, but if there exists > the risk that this will brake existing applications, at this stage of > releasing 9.x, I would say leave it for 10.x > I don't expect big issues for the users due to CSP. If there are errors in the browser console related to CSP then it is one line change in YourApplication#init() to disable it and move on. > > On Tue, Jan 21, 2020 at 10:10 PM Emond Papegaaij < > emond.papega...@gmail.com> > wrote: > > > In my opinion marketing is very important, but I think it is more > > important to have this option enabled on as many applications as > > possible. Enabling this by default will give this a much wider reach > > than just having it available. Most importantly, it will be enabled on > > new applications, guiding the developer into making a more secure > > application. If it is not enabled by default, I doubt many developers > > will enable it on their new application. For that you have to look > > into the guide, see that it's available and then enable it. > > > > For existing applications, I think many will either disable it or at > > least configure CSP to be less strict. But still, if this triggers > > just a few to make their application work with CSP, I'd consider that > > a win. > > > > IMHO as developers of a popular web framework it is our duty to work > > on a secure internet and push these features actively. > > > > Emond > > > > On Tue, Jan 21, 2020 at 3:07 PM Andrea Del Bene <an.delb...@gmail.com> > > wrote: > > > > > > I agree with the marketable value of CSP but I don't think it will lose > > > appeal if we make it disabled by default. As I said, I agree to > > eventually > > > enable it by default, but I don't think the time is ripe yet. > > > > > > On Tue, Jan 21, 2020 at 2:27 PM Martijn Dashorst < > > martijn.dasho...@gmail.com> > > > wrote: > > > > > > > Not sure if enabling it by default is a bad thing when you can, as > per > > > > migration guide, disable it with one statement in your > > > > WebApplication#init(). > > > > > > > > Also, when looking at marketable features, having CSP, and enabled by > > > > default, is something that publications will take notice of. Just > like > > > > being Jakarta EE prepared: > > > > > > > > "Deliver Secure Future Proof Web Applications with Apache Wicket 9 > > > > > > > > Apache Wicket 9 delivers Content Security Policy (CSP) protection > > > > out-of-the-box, protecting web applications against a variety of web > > > > based attack vectors. CSP is a cross-browser technology that prevents > > > > several attacks on web applications by limiting the .... > > > > > > > > With the adoption of the Jakarta EE standards, Apache Wicket 9 is one > > > > of the first Java frameworks prepared for the new future of > enterprise > > > > Java. <insert blurb about licensing etc> > > > > " > > > > > > > > Martijn > > > > > > > > On Tue, Jan 21, 2020 at 2:00 PM Andrea Del Bene < > an.delb...@gmail.com> > > > > wrote: > > > > > > > > > > IMHO forcing users to adopt a new potential breaking feature is a > > > > > mistake. We should wait for a wider interest in CSP to enable it by > > > > > default. Don't get me wrong, I'm not underestimating the importance > > of > > > > > this feature which is a fantastic tool to ensure security. > > Nonetheless, > > > > > I believe that forcing users to comply with it will only have the > > effect > > > > > of upsetting them. > > > > > > > > > > On 1/21/20 1:27 PM, Emond Papegaaij wrote: > > > > > > On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov < > > mgrigo...@apache.org> > > > > wrote: > > > > > >> On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij < > > > > emond.papega...@gmail.com> > > > > > >> wrote: > > > > > >> > > > > > >>> I've discussed this with our unit manager, and got permission > to > > > > > >>> donate our CSP code to Wicket. I think a strong, out of the box > > CSP > > > > is > > > > > >>> a killer feature to have for Wicket 9. Not many frameworks can > > match > > > > > >>> this. For this, I would like to continue working on the > following > > > > > >>> parts: > > > > > >>> * Remove all inline styling and JS from Wicket. I will need > some > > help > > > > > >>> with this, especially the Form related code. > > > > > >>> * Make sure all examples work find with a strong CSP enabled > > > > > >>> * Add the CSP code to Wicket and provide several presets > (strong, > > > > > >>> unsafeJsAndStyling, reportOnly, disabled) > > > > > >>> * Enable CSP with the strong preset by default > > > > > >>> > > > > > >> I think this will break all applications which migrate from > > earlier > > > > version. > > > > > >> I like that Wicket will be more secure by default but > > > > > >> 1) most people do not really care about CSP (yet) > > > > > >> 2) last time when I tested CSP it was behaving differently on > > > > different > > > > > >> browsers. I hope it is better now since only Firefox is not > based > > on > > > > > >> Chromium. According to https://caniuse.com/#search=csp IE11 > > might be > > > > > >> problematic. > > > > > >> > > > > > >> Whatever we choose as default we should document how to switch > it > > on > > > > and > > > > > >> off. > > > > > >> The user guide needs to be updated! > > > > > >> > > > > > > Yes, enabling a strict CSP will probably break all existing > > > > > > applications on upgrade. But the upgrade will do that anyway (I > > had to > > > > > > fix quite a few compilation errors to get my app starting again). > > We > > > > > > do have to document this in the migration guide. Switching to an > > > > > > unsafe CSP or disabling it entirely is just one line of code. > > That's a > > > > > > lot less work than fixing the compilation errors. I hope enabling > > CSP > > > > > > by default will make more people aware of this browser feature. > At > > > > > > Topicus we intent to fix our applications to work with the strict > > CSP, > > > > > > probably not directly after migrating to 9, but Wicket 9 is a > good > > > > > > push in this direction. > > > > > > > > > > > > It is true that support is lacking for some browsers. A browser > > that > > > > > > does not support CSP at all (like IE11) is not hindered by it > > either. > > > > > > It becomes more problematic when a browser does not support the > > > > > > directives used (like strict-dynamic). This might cause issues > and > > we > > > > > > need to test that and change the CSP to make sure it works in > those > > > > > > browsers as well. IMHO as a framework it is our job to set an > > example > > > > > > and show how we think this is done best. When a user thinks the > > gained > > > > > > security is not worth the pain, he/she can disable it and hope > for > > the > > > > > > best. > > > > > > > > > > > > Best regards, > > > > > > Emond > > > > > > > > > > > >>> I've already started the work on the 'csp' branch. On this > > branch, > > > > > >>> I've also migrated all but the servlet API to the jakarta > > namespace. > > > > > >>> > > > > > >>> Best regards, > > > > > >>> Emond > > > > > >>> > > > > > >>> On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij > > > > > >>> <emond.papega...@gmail.com> wrote: > > > > > >>>> Searching through our Jira, I've found WICKET-6687, filed by > > Andrew. > > > > > >>>> He already pinpointed several places that break with a strict > > CSP > > > > > >>>> enabled. I'm going to convert that bug into a task (we do not > > have > > > > > >>>> epic) and create new bugs for all issues in that ticket. That > > should > > > > > >>>> make it easier to track progress. > > > > > >>>> > > > > > >>>> Best regards, > > > > > >>>> Emond > > > > > >>>> > > > > > >>>> On Sat, Jan 11, 2020 at 10:31 PM Emond Papegaaij > > > > > >>>> <emond.papega...@gmail.com> wrote: > > > > > >>>>> Hi all, > > > > > >>>>> > > > > > >>>>> For the past few days I've been experimenting with the new > CSP > > > > > >>>>> features in Wicket 9. I really want to thank Andrew, Sven and > > > > Martin > > > > > >>>>> for the great work you guys did in making this possible. I'm > > > > getting > > > > > >>>>> very close to running my application with a very tight and > > secure > > > > CSP. > > > > > >>>>> Unfortunately, some parts of Wicket still use inline styling > > and > > > > > >>>>> scripting. So far I've found the following two issues: > > > > > >>>>> > > > > > >>>>> * hidden components with setOutputMarkupPlaceholderTag(true) > > have > > > > > >>> display:none > > > > > >>>>> * Forms render inline styling and javascript in some cases to > > > > improve > > > > > >>>>> submit handling > > > > > >>>>> > > > > > >>>>> I think we should try to fix these before Wicket 9 is > > released. I > > > > will > > > > > >>>>> continue to debug our application to see if there are more > > places. > > > > > >>>>> > > > > > >>>>> At Topicus we wrote a IRequestCycleListener that applies the > > CSP > > > > > >>>>> automatically to every request via HTTP headers. The API > makes > > it > > > > easy > > > > > >>>>> to configure the CSP. I've added support for the nonce as > > well. It > > > > > >>>>> uses a new nonce for every request, which should be more > secure > > > > than a > > > > > >>>>> nonce bound to a session. I'll discuss with my employee next > > week > > > > if > > > > > >>>>> we can donate this code to Wicket. > > > > > >>>>> > > > > > >>>>> Best regards, > > > > > >>>>> Emond > > > > > > > > > > > > > > > > -- > > > > Become a Wicket expert, learn from the best: > http://wicketinaction.com > > > > > > > > > > > > > -- > > > Andrea Del Bene. > > > Apache Wicket committer. > > > > > -- > Regards - Ernesto Reinaldo Barreiro >
