Re: [VOTE] Release Apache Wicket 9.16.0
+1.. updating dependencies would be welcomed > On Nov 21, 2023, at 2:34 PM, Andrea Del Bene wrote: > > If you like to update dependencies I can't start a new vote. No problem. > > On 11/21/23 08:39, Maxim Solodovnik wrote: >> I would update dependencies before release :))) >> >> +1 >> >> Tested: >> - signatures >> - build from sources >> - wicketstuff build >> - some examples >> >> On Mon, 20 Nov 2023 at 19:29, Ernesto Reinaldo Barreiro >> wrote: >>> +1. I have tested our application against wicket 9.16.0 >>> >>> On Sun, Nov 19, 2023 at 6:00 PM Andrea Del Bene >>> wrote: >>> This is a vote to release Apache Wicket 9.16.0 Please download the source distributions found in our staging area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 9.16.0 [ ] No, don't release Apache Wicket 9.16.0, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/9.16.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-1195 The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. Staging git repository data: Repository: g...@github.com:bitstorm/wicket.git Branch: build/wicket-9.16.0 Release tag: rel/wicket-9.16.0 CHANGELOG for 9.16.0: ** Bug * [WICKET-7056] - HttpSessionStore#getAttribute called on invalidated session * [WICKET-7074] - [AJAX] malformed XML is produced if an error is produced during AJAX rendering and a redirect is issued * [WICKET-7076] - JavaScriptReferenceType newly created is not serializable * [WICKET-7081] - Open packages to expose resources to other modules ** Improvement * [WICKET-7078] - CSP: inline JS in Choices and Selection of Palette * [WICKET-7080] - [Events] make default events delivery machinery pluggable and roll usable annotation based one * [WICKET-7082] - Easier to work with polymorphic values inside IModel * [WICKET-7083] - Trigger client side validation when using SubmitLinks ** Task * [WICKET-7073] - Update JQuery to 3.7.1 >>> -- >>> Regards - Ernesto Reinaldo Barreiro >> >>
Re: wicket and commons-fileupload 2.0.0-M1
Hi Maxim- I understand that preference— this is a build-vs-buy decision. My point is that a file upload handler makes sense for Wicket to host itself, considering it is a small set of functions and relates to storage management needed by Wicket apps. Also, Wicket is more active in development and adopting JDK and Jakarta EE than the commons-file upload project. I suspect we’ll be right back here as the Servlet spec is evolving in Jakarta EE. -Matt > On Jun 16, 2023, at 2:32 AM, Maxim Solodovnik wrote: > > On Thu, 15 Jun 2023 at 00:40, Matt Pavlovich wrote: >> >> Why add it back? The feature is just a couple of classes. >> commons-fileupload2 can continue to serve as a reference implementation to >> draw from. >> >> These backside dependencies create headaches when building web applications >> with Wicket that are platforms that allow end-users to provide their own >> plugins or extensions that may use the same or similarly versioned >> dependencies. > > IMO it's bad practice to copy/paste other libraries, > having fileupload2 as dependency we have all fixes and additional testing :) > > BTW the build of my branch seems to be green, only minor issues with > Automatic-Module-Name remain unresolved :) > >> >> Thanks, >> Matt >> >>> On Jun 14, 2023, at 11:48 AM, Maxim Solodovnik wrote: >>> >>> Hello All, >>> >>> I've start working on migration back to commons-fileupload 2.0.0-M1 >>> (the branch is here: [1] :))) >>> >>> Latest version of commons-fileupload2 has couple of issues >>> 1) missing `Automatic-Module-Name` >>> 2) FileItemHeadersImpl is not public anymore >>> (discussion is here: [2]) >>> >>> I'm going to have vacation in a couple of days (will be offline almost >>> all the time :) >>> >>> Can someone take a look at [2] ? >>> So we have all required features at 2.0.0-M1 release? >>> >>> Thanks in advance :) >>> >>> [1] https://github.com/apache/wicket/blob/commons-fileupload2-back >>> [2] https://lists.apache.org/thread/gjglf0c1xzdrhm143swfcq0xpg5ofrqk >>> >>> -- >>> Best regards, >>> Maxim >> > > > -- > Best regards, > Maxim
Re: wicket and commons-fileupload 2.0.0-M1
Why add it back? The feature is just a couple of classes. commons-fileupload2 can continue to serve as a reference implementation to draw from. These backside dependencies create headaches when building web applications with Wicket that are platforms that allow end-users to provide their own plugins or extensions that may use the same or similarly versioned dependencies. Thanks, Matt > On Jun 14, 2023, at 11:48 AM, Maxim Solodovnik wrote: > > Hello All, > > I've start working on migration back to commons-fileupload 2.0.0-M1 > (the branch is here: [1] :))) > > Latest version of commons-fileupload2 has couple of issues > 1) missing `Automatic-Module-Name` > 2) FileItemHeadersImpl is not public anymore > (discussion is here: [2]) > > I'm going to have vacation in a couple of days (will be offline almost > all the time :) > > Can someone take a look at [2] ? > So we have all required features at 2.0.0-M1 release? > > Thanks in advance :) > > [1] https://github.com/apache/wicket/blob/commons-fileupload2-back > [2] https://lists.apache.org/thread/gjglf0c1xzdrhm143swfcq0xpg5ofrqk > > -- > Best regards, > Maxim
Re: addying support for upload to resource
+1 that’d be great! Especially w/ ability to have visibility to progress. > On Mar 15, 2023, at 5:25 AM, Ernesto Reinaldo Barreiro > wrote: > > Hi, > > In our application we are heavily using web socket push (repainting web > wicket components via web-socket push). One problem we found is that in > some pages we have some uploads and those uploads can be very large, and > while they are happening the page is "frozen" and no new web socket > messages are received. Because of that, I have implemented a custom upload > to a wicket resource. In essence some adaptation of > > https://github.com/martin-g/blogs/blob/master/file-upload/src/main/java/com/mycompany/fileupload/AbstractFileUploadResource.java > > > But I also had to adapt the upload progress bar in order to be able to > report progress upload. Would this be something interesting to have in > a "generic" way in Wicket itself? > > > -- > Regards - Ernesto Reinaldo Barreiro
Re: Time for Wicket M1?
This would be great for OSGi too =) Perhaps move the class that import junit.* to a wicket-junit5 maven module? Thanks, Matt Pavlovich > On Feb 22, 2023, at 2:11 AM, Martin Grigorov wrote: > > BTW there is a ticket from Apache Causeway team requesting to extract > WicketTester in its own Maven module because currently it causes problems > when trying to use wicket-core as a Java module. > > https://issues.apache.org/jira/browse/WICKET-7019 > > But maybe it could be done for M2 > > On Thu, Feb 9, 2023 at 1:10 PM Maxim Solodovnik > wrote: > >> from mobile (sorry for typos ;) >> >> >> On Thu, Feb 9, 2023, 18:03 Andrea Del Bene wrote: >> >>> Excuse my silly question but isn't ok for milestone version to depend on >> a >>> snapshot version (fileupload 2.0-SNAPSHOT)? >>> >> >> Unfortunately not :( >> The build will not be reproducible >> >> >> >>> On Thu, Feb 9, 2023 at 8:36 AM Emond Papegaaij < >> emond.papega...@gmail.com> >>> wrote: >>> >>>> Op do 9 feb. 2023 om 08:32 schreef Martin Grigorov < >> mgrigo...@apache.org >>>> : >>>> >>>>> On Thu, Feb 9, 2023 at 9:16 AM Emond Papegaaij < >>>> emond.papega...@gmail.com> >>>>> wrote: >>>>> >>>>>> Op do 9 feb. 2023 om 07:47 schreef Martin Grigorov < >>>> mgrigo...@apache.org >>>>>> : >>>>>> >>>>>>> Please update >>>>>>> >>>>>> >>>>> >>>> >>> >> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0 >>>>>>> that the Component Queueing is gone >>>>>>> >>>>>>> Before releasing M1 I think we need to: >>>>>>> 1) update all dependencies to their latest stable version >>>>>>> 2) copy over commons-fileupload2 classes to wicket-util or a new >>>> Maven >>>>>>> module >>>>>>> >>>>>> >>>>>> What about shading the classes in an internal package? I'm a bit >>>>> concerned >>>>>> with having to cope with different classes with the same fqcn when >>> some >>>>>> other dependency also pulls in commons-fileupload. >>>>>> >>>>> >>>>> I am not sure whether Maven would be happy to use a -SNAPSHOT for the >>>>> shading process when making a release. If you mean >> maven-shade-plugin. >>>>> Doing it manually should work! >>>>> >>>> >>>> Yes, releasing against a SNAPSHOT version is not a very good idea, even >>> if >>>> shaded. That will give issues trying to rebuild a certain version if >>>> something has changed. Copy-pasting and changing the package should be >>> ok. >>>> >>>> Best regards, >>>> Emond >>>> >>> >>> >>> -- >>> Andrea Del Bene. >>> Apache Wicket committer. >>> >>
Re: Release Wicket 10.0.0-M1?
IMO relying on the annotation to do configuration would be a show stopper. > On Dec 17, 2022, at 7:01 AM, Martijn Dashorst > wrote: > > Is commons-fileupload still necessary with the addition of multipart > support? > > https://www.baeldung.com/upload-file-servlet > > I assume we require servlet 3.0 at the minimum? > > Martijn > > > On Sat, Dec 17, 2022 at 1:56 AM Maxim Solodovnik > wrote: > >> According to this: >> https://lists.apache.org/thread/22ro2qbstmrhrdq92g370kdsgf3fpfv2 >> >> There should be release soon :) >> >> >> from mobile (sorry for typos ;) >> >> >> On Sat, Dec 17, 2022, 01:38 Martin Grigorov wrote: >> >>> Maybe copy the commons-file upload classes in a new Maven module? >>> >>> On Fri, Dec 16, 2022, 17:07 Thomas Heigl wrote: >>> Hi, There doesn't seem to be any progress with commons-fileupload. Should >> we start exploring other options? Or should we try to push some more on >> the JIRA? I'm still blocked by one other dependency (Apache Shiro) but they are >>> close to releasing Jakarta artifacts. Best, Thomas On Tue, Apr 19, 2022 at 9:27 PM Martin Grigorov wrote: > On Tue, Apr 19, 2022 at 2:42 PM Thomas Heigl wrote: > >> OK I just saw that Martin already asked them to do a release in >> >> https://issues.apache.org/jira/projects/FILEUPLOAD/issues/FILEUPLOAD-309 > . >> > > 1 year ago ... > I see you JIRA voted for the issue. I think no one cares about the >>> number > of votes. Better add a comment! Comments go to the mailing list and >> the > maintainers are notified. > > > >> >> On Tue, Apr 19, 2022 at 1:35 PM Thomas Heigl > wrote: >> >>> Hi, >>> >>> I started migrating our app to the new Jakarta APIs. Wicket is >> the only >>> dependency that doesn't yet have a pre-release. Is there anything >>> preventing us from releasing 10.0.0-M1? >>> >>> Is the SNAPSHOT dependency on commons-fileupload the only >> remaining >> issue? >>> If so, we should probably ask them to create a release candidate. >>> >>> Best, >>> >>> Thomas >>> >> > >>> >> > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: [VOTE] Release Apache Wicket 9.12.0
+1 (non-binding) Thanks!
> On Oct 11, 2022, at 12:06 PM, Andrea Del Bene wrote:
>
> This is a vote to release Apache Wicket 9.12.0
>
> Please download the source distributions found in our staging area
> linked below.
>
> I have included the signatures for both the source archives. This vote
> lasts for 72 hours minimum.
>
> [ ] Yes, release Apache Wicket 9.12.0
> [ ] No, don't release Apache Wicket 9.12.0, because ...
>
> Distributions, changelog, keys and signatures can be found at:
>
> https://dist.apache.org/repos/dist/dev/wicket/9.12.0
>
> Staging repository:
>
> https://repository.apache.org/content/repositories/orgapachewicket-1177
>
> The binaries are available in the above link, as are a staging
> repository for Maven. Typically the vote is on the source, but should
> you find a problem with one of the binaries, please let me know, I can
> re-roll them some way or the other.
>
> Staging git repository data:
>
> Repository: g...@github.com:bitstorm/wicket.git
> Branch: build/wicket-9.12.0
> Release tag: rel/wicket-9.12.0
>
>
>
>
> CHANGELOG for 9.12.0:
>
> ** Bug
>
> * [WICKET-6955] - Wicket uses unstable slf4j version
> * [WICKET-6996] - NotSerializableException near
> KeyInSessionSunJceCryptFactory
> * [WICKET-6999] - Missing Export-Package of packages with "internal" in
> name
> * [WICKET-7007] - Code snippets for CSRF documentation fixing
>
> ** Improvement
>
> * [WICKET-6958] - Allow to use Slf4j 1.7.x in OSGi runtime
> * [WICKET-6982] - Unnecessary initialization of stateful pages in
> ListenerRequestHandler
> * [WICKET-6998] - Bump slf4j-api to 2.0.0
> * [WICKET-7000] - ParseException ("Malformed tag") if
Re: Time for 9.12.0?
PR #540 is ready for review. I completed updates for the wicket modules that we use and can spot check. Note— It would be contract-breaking to ship wicket-9.x w/ slf4j 2.0 without this change in place, so next up it’d be good to back-port this to the wicket-9.x branch and get some testing underway. Completed: wicket-util wicket-request wicket-core wicket-auth-roles wicket-devutils wicket-extensions wicket-jmx Not yet updated: wicket-bean-validation wicket-cdi wicket-guice wicket-ioc wicket-native-websocket wicket-objectsizeof-agent wicket-spring wicket-velocity Thanks, Matt > On Sep 30, 2022, at 12:44 PM, Matt Pavlovich wrote: > > Update — draft PR here: https://github.com/apache/wicket/pull/540 > <https://github.com/apache/wicket/pull/540> > > This PR works for wicket-util and wicket-request modules right now. > > At issue is the use of enforcer plugin to limit configurations per-execution. > maven-bundle-plugin runs at various phases and if there is not a config for > each, the default behavior will execute on the last phase and we don’t get > the version override as configured in the 'instructions'. I’m working on > identifying the last goal that runs and perhaps we can get away with a single > definition for that phase without changing the enforcer plugin rules. > > Thanks, > Matt > >> On Sep 29, 2022, at 2:35 PM, Andrea Del Bene > <mailto:an.delb...@gmail.com>> wrote: >> >> Thank you Matt! >> >> On 29/09/22 16:43, Matt Pavlovich wrote: >>> I got pulled off onto other tasks. I will have time to get the PR out this >>> weekend. >>> >>> Thanks, >>> Matt Pavlovich >>> >>>> On Sep 29, 2022, at 6:19 AM, Andrea Del Bene >>> <mailto:an.delb...@gmail.com>> wrote: >>>> >>>> I think I've lost track about this activity...what do we still miss to >>>> proceed with the new release? >>>> Thank you. >>>> >>>> On Fri, Sep 16, 2022 at 6:19 PM Matt Pavlovich >>> <mailto:mattr...@gmail.com>> wrote: >>>> >>>>> I can help w/ the OSGi import package. Should just be a simple override in >>>>> the bundle plugin config. >>>>> >>>>>> On Sep 15, 2022, at 3:00 PM, Andrea Del Bene >>>>> <mailto:an.delb...@gmail.com>> >>>>> wrote: >>>>>> I agree with Martijn. Probably the downgrade is the best solution at the >>>>> moment. Like Martin suggests it would be nice to investigate how >>>>> Import-Package for OSGi are generated, but it's not a trivial task and we >>>>> need someone with more experience with OSGi >>>>>> On 14/09/22 09:22, Martijn Dashorst wrote: >>>>>>> IIUC sfl4j 2.0.0 API is the same as 1.7.x API, so from a Wicket >>>>> perspective >>>>>>> it doesn't matter if we ship with 2.0.0 or 1.7.x, right? >>>>>>> >>>>>>> If that is the case, I suggest we fall back to 1.7.x, and note that one >>>>> can >>>>>>> easily upgrade to 2.0.0 without issue if someone so desires. >>>>>>> >>>>>>> This will keep it working for most folks, yet give an upgrade path for >>>>>>> those that wish so. It is harder to convince someone to downgrade from >>>>> 2.0 >>>>>>> to 1.7 than to upgrade to 2.0 from 1.7. >>>>>>> >>>>>>> But this is my .02 (which is even worth less with the current exchange >>>>>>> rates). >>>>>> ... >>>>>>> Martijn >>>>>>> >>>>>>> >>>>> >>>> -- >>>> Andrea Del Bene. >>>> Apache Wicket committer. >
Re: Time for 9.12.0?
Update — draft PR here: https://github.com/apache/wicket/pull/540 <https://github.com/apache/wicket/pull/540> This PR works for wicket-util and wicket-request modules right now. At issue is the use of enforcer plugin to limit configurations per-execution. maven-bundle-plugin runs at various phases and if there is not a config for each, the default behavior will execute on the last phase and we don’t get the version override as configured in the 'instructions'. I’m working on identifying the last goal that runs and perhaps we can get away with a single definition for that phase without changing the enforcer plugin rules. Thanks, Matt > On Sep 29, 2022, at 2:35 PM, Andrea Del Bene wrote: > > Thank you Matt! > > On 29/09/22 16:43, Matt Pavlovich wrote: >> I got pulled off onto other tasks. I will have time to get the PR out this >> weekend. >> >> Thanks, >> Matt Pavlovich >> >>> On Sep 29, 2022, at 6:19 AM, Andrea Del Bene wrote: >>> >>> I think I've lost track about this activity...what do we still miss to >>> proceed with the new release? >>> Thank you. >>> >>> On Fri, Sep 16, 2022 at 6:19 PM Matt Pavlovich wrote: >>> >>>> I can help w/ the OSGi import package. Should just be a simple override in >>>> the bundle plugin config. >>>> >>>>> On Sep 15, 2022, at 3:00 PM, Andrea Del Bene >>>> wrote: >>>>> I agree with Martijn. Probably the downgrade is the best solution at the >>>> moment. Like Martin suggests it would be nice to investigate how >>>> Import-Package for OSGi are generated, but it's not a trivial task and we >>>> need someone with more experience with OSGi >>>>> On 14/09/22 09:22, Martijn Dashorst wrote: >>>>>> IIUC sfl4j 2.0.0 API is the same as 1.7.x API, so from a Wicket >>>> perspective >>>>>> it doesn't matter if we ship with 2.0.0 or 1.7.x, right? >>>>>> >>>>>> If that is the case, I suggest we fall back to 1.7.x, and note that one >>>> can >>>>>> easily upgrade to 2.0.0 without issue if someone so desires. >>>>>> >>>>>> This will keep it working for most folks, yet give an upgrade path for >>>>>> those that wish so. It is harder to convince someone to downgrade from >>>> 2.0 >>>>>> to 1.7 than to upgrade to 2.0 from 1.7. >>>>>> >>>>>> But this is my .02 (which is even worth less with the current exchange >>>>>> rates). >>>>> ... >>>>>> Martijn >>>>>> >>>>>> >>>> >>> -- >>> Andrea Del Bene. >>> Apache Wicket committer.
Re: Time for 9.12.0?
I got pulled off onto other tasks. I will have time to get the PR out this weekend. Thanks, Matt Pavlovich > On Sep 29, 2022, at 6:19 AM, Andrea Del Bene wrote: > > I think I've lost track about this activity...what do we still miss to > proceed with the new release? > Thank you. > > On Fri, Sep 16, 2022 at 6:19 PM Matt Pavlovich wrote: > >> I can help w/ the OSGi import package. Should just be a simple override in >> the bundle plugin config. >> >>> On Sep 15, 2022, at 3:00 PM, Andrea Del Bene >> wrote: >>> >>> I agree with Martijn. Probably the downgrade is the best solution at the >> moment. Like Martin suggests it would be nice to investigate how >> Import-Package for OSGi are generated, but it's not a trivial task and we >> need someone with more experience with OSGi >>> >>> On 14/09/22 09:22, Martijn Dashorst wrote: >>>> IIUC sfl4j 2.0.0 API is the same as 1.7.x API, so from a Wicket >> perspective >>>> it doesn't matter if we ship with 2.0.0 or 1.7.x, right? >>>> >>>> If that is the case, I suggest we fall back to 1.7.x, and note that one >> can >>>> easily upgrade to 2.0.0 without issue if someone so desires. >>>> >>>> This will keep it working for most folks, yet give an upgrade path for >>>> those that wish so. It is harder to convince someone to downgrade from >> 2.0 >>>> to 1.7 than to upgrade to 2.0 from 1.7. >>>> >>>> But this is my .02 (which is even worth less with the current exchange >>>> rates). >>> ... >>>> Martijn >>>> >>>> >> >> > > -- > Andrea Del Bene. > Apache Wicket committer.
Re: Time for 9.12.0?
I can help w/ the OSGi import package. Should just be a simple override in the bundle plugin config. > On Sep 15, 2022, at 3:00 PM, Andrea Del Bene wrote: > > I agree with Martijn. Probably the downgrade is the best solution at the > moment. Like Martin suggests it would be nice to investigate how > Import-Package for OSGi are generated, but it's not a trivial task and we > need someone with more experience with OSGi > > On 14/09/22 09:22, Martijn Dashorst wrote: >> IIUC sfl4j 2.0.0 API is the same as 1.7.x API, so from a Wicket perspective >> it doesn't matter if we ship with 2.0.0 or 1.7.x, right? >> >> If that is the case, I suggest we fall back to 1.7.x, and note that one can >> easily upgrade to 2.0.0 without issue if someone so desires. >> >> This will keep it working for most folks, yet give an upgrade path for >> those that wish so. It is harder to convince someone to downgrade from 2.0 >> to 1.7 than to upgrade to 2.0 from 1.7. >> >> But this is my .02 (which is even worth less with the current exchange >> rates). > ... >> Martijn >> >>
Re: [CVE-2020-11976] Apache Wicket information disclosure vulnerability
+1 upgrading v6 -> v7 -> v8 -> v9 is the way to go. FWIW our experience has been similar— upgrades take a day, or a couple days at most. Thanks, Matt Pavlovich > On Aug 11, 2022, at 9:09 AM, Chris Colman > wrote: > > Hi Daniel, > > On 11/08/2022 7:45 pm, Daniel Stoch wrote: >> We have a plan to upgrade (at last ;)) > Yeehah! >> Wicket to a newer version (9.x), but >> it is not quite easy for a big application > Our app has 1034 Wicket UI classes - that's just pure Wicket UI classes - > don't ask about the number of classes in the business layer/domain model ;) >> and unfortunately we have to >> patch Wicket code by ourselves to fix issues described in WICKET-5588 >> (including JavaScript: if this code have many changes between 6.x and 9.x >> it can be quite hard to do it). >> It would be much easier to upgrade if this problem was fixed in the >> standard version of Wicket. > > I think jumping from 6 -> 9 directly might be a bit too adventurous - you > have to consider all framework changes across 7, 8 and 9. > > That's why we decided to migrate one step at a time: "single stepping" from > 6->7 (done) then 7->8 then 8->9. > > The good thing about 6->7->8 is that you can stick with Java 8 and so not > have to be concerned with in any issues that changing your Java version may > bring (assuming you're currently using 1.8) > >> >> -- >> Best regards, >> Daniel Stoch >> >> >> >> czw., 11 sie 2022 o 10:06 Martin Grigorov napisał(a): >> >>> Hi, >>> >>> Wicket 6.x is no more supported. >>> Wicket 7.x is the current security maintaince branch. >>> >>> Your options are: >>> - patch locally >>> - upgrade to a newer version >>> >>> On Wed, Aug 10, 2022 at 6:17 PM Daniel Stoch >>> wrote: >>> >>>> Hi, >>>> >>>> Is there any JIRA issue for this? I tried to find but none issue in >>> Wicket >>>> JIRA points directly to CVE-2020-11976. >>>> One possible candidate to me is WICKET-6792 :). Am I right? If yes, this >>> is >>>> already fixed also for Wicket 6.31.0, can you release this version? >>>> >>>> -- >>>> Best regards, >>>> Daniel Stoch >>>> >>>> >>>> pon., 10 sie 2020 o 18:23 napisał(a): >>>> >>>>> Severity: Important >>>>> >>>>> Vendor: >>>>> The Apache Software Foundation >>>>> >>>>> Versions Affected: >>>>> Apache Wicket 7.16.0, 8.8.0 and 9.0.0-M5 >>>>> >>>>> Description: >>>>> >>>>> By crafting a special URL it is possible to make Wicket deliver >>>>> unprocessed HTML templates. >>>>> This would allow an attacker to see possibly sensitive information >>>>> inside a HTML template that is usually removed during rendering. >>>>> For example if there are credentials in the markup which are never >>>>> supposed to be visible to the client: >>>>> >>>>> >>>>> some secret >>>>> >>>>> >>>>> The application developers are recommended to upgrade to: >>>>> - Apache Wicket 7.17.0 >>>>> <http://wicket.apache.org/news/2020/07/20/wicket-7.17.0-released.html> >>>>> - Apache Wicket 8.9.0 >>>>> <http://wicket.apache.org/news/2020/07/15/wicket-8.9.0-released.html> >>>>> - Apache Wicket 9.0.0 >>>>> <http://wicket.apache.org/news/2020/07/15/wicket-9-released.html> >>>>> >>>>> Credit: >>>>> The vulnerability has been found and reported by Mariusz Popławski from >>>>> Afine. >>>>> >>>>> Apache Wicket Team >>>>>
Re: CVE-2021-23937: Apache Wicket: DNS proxy and possible amplification attack
Thank you for the notice, and the already fixed releases =) Is there a JIRA or associated PR with the fix? I’m not seeing a specific fix in the changelogs for 9.3.0 and 8.12.0. Thanks, Matt Pavlovich > On May 25, 2021, at 2:51 AM, Emond Papegaaij > wrote: > > Description: > > A DNS proxy and possible amplification attack vulnerability in > WebClientInfo of Apache Wicket allows an attacker to trigger arbitrary > DNS lookups from the server when the X-Forwarded-For header is not > properly sanitized. This DNS lookup can be engineered to overload an > internal DNS server or to slow down request processing of the Apache > Wicket application causing a possible denial of service on either the > internal infrastructure or the web application itself. > > This issue affects Apache Wicket Apache Wicket 9.x version 9.2.0 and > prior versions; Apache Wicket 8.x version 8.11.0 and prior versions; > Apache Wicket 7.x version 7.17.0 and prior versions and Apache Wicket > 6.x version 6.2.0 and later versions. > > Mitigation: > > Sanitize the X-Forwarded-For header by running an Apache Wicket > application behind a reverse HTTP proxy. This proxy should put the > client IP address in the X-Forwarded-For header and not pass through > the contents of the header as received by the client. > > The application developers are recommended to upgrade to: > - Apache Wicket 7.18.0 > <https://wicket.apache.org/news/2021/04/06/wicket-7.18.0-released.html> > - Apache Wicket 8.12.0 > <https://wicket.apache.org/news/2021/03/31/wicket-8.12.0-released.html> > - Apache Wicket 9.0.0 > <https://wicket.apache.org/news/2021/03/30/wicket-9.3.0-released.html> > > Credit: > > Apache Wicket would like to thank Jonathan Juursema from > Topicus.Healthcare for reporting this issue. > > Apache Wicket Team > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org >
Re: Wicket 10 ideas
We do not use enclosures or component queueing either. -Matt Pavlovich > On Apr 24, 2021, at 3:56 PM, Francois Meillet > wrote: > > I don't use enclosures and component queueing > > Kind regards, > François > > > >> Le 24 avr. 2021 à 20:52, Ernesto Reinaldo Barreiro a >> écrit : >> >> Hi, >> >> On Sat, Apr 24, 2021 at 2:13 PM Tobias Soloschenko >> > <mailto:tobiassolosche...@googlemail.com.invalid>> wrote: >> >>> Hi everyone, >>> >>> from my side I also would prefer removing component queuing (+1), >>> enclosures I would prefer a rework and not to remove it (+0). >>> >>> In addition to Martin’s list I would add some points >>> >>> — Martin's list — >>> 4) Move wicket-http2-servlet4 into core and remove wicket-http2-jetty / >>> wicket-http2-tomcat / wicket-http2-undertow / wicket-http2-core (I would >>> prefer doing it in 10 over 9) >>> 5) May remove wicket-metrics (I have the feeling that this is used rarely >>> over other reporting frameworks) >>> >> >> I have the impression the practice before "always" was to move things to >> wicket-stuff once they were no longer supported as core features. E.g. >> things like treetables and so on. Correct? >> >> >>> kind regards >>> >>> Tobias >>> >>>> Am 24.04.2021 um 11:07 schrieb Korbinian Bachl < >>> korbinian.ba...@whiskyworld.de>: >>>> >>>> Hi, >>>> >>>> we dont use queueing but we use enclosures in quite a few places. >>> Getting rid of it would mean we have to switch to markup containers holding >>> the content and add additonal layer of complexity and boilerplatecode for >>> us. >>>> >>>> Beside that: can wicket 10 finally get rid of jQuery? Since IE is now >>> definitely dead I dont see any reason why this is still needed >>>> >>>> Best, >>>> KB >>>> >>>> >>>> - Ursprüngliche Mail - >>>>> Von: "Ernesto Reinaldo Barreiro" >>>>> An: dev@wicket.apache.org >>>>> Gesendet: Freitag, 23. April 2021 12:04:34 >>>>> Betreff: Re: Wicket 10 ideas >>>> >>>>> Hi, >>>>> >>>>> On Fri, Apr 23, 2021 at 11:58 AM Sven Meier wrote: >>>>> >>>>>> x) remove/rework enclosures and component queueing. >>>>>> >>>>> >>>>> It would be interesting to know how many people really use queuing >>>>> >>>>> >>>>>> >>>>>> Have fun >>>>>> Sven >>>>>> >>>>>> >>>>>> On 02.04.21 13:58, Martin Grigorov wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Now since we have 9.3.0 released is it time to start thinking/working >>> on >>>>>>> Wicket 10 ? >>>>>>> >>>>>>> Here are few ideas what to break :-) >>>>>>> >>>>>>> 1) Move to Servlet 5.x, i.e. jakarta.servlet.** >>>>>>> 2) Use @Inject + @Named instead of @SpringBean. If everything is >>> covered >>>>>>> by @Inject we may deprecate @SpringBean in 9.x >>>>>>> 3) Depending on the release date we may even bump Java to 17 (it is >>> going >>>>>>> to be released this September and it is going to be LTS). I expect >>> Wicket >>>>>>> 10.0.0 to be released in 1-2 years from now, so by this time Java 17 >>>>>> should >>>>>>> be mainstream! :-) I know that this is too brave. Most projects still >>> use >>>>>>> Java 8 for some reason. >>>>>>> >>>>>>> Regards, >>>>>>> Martin >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Regards - Ernesto Reinaldo Barreiro >>> >>> >> >> -- >> Regards - Ernesto Reinaldo Barreiro >
Re: Wicket 10 based on jakarta.** APIs ?
This plan sounds great on all points. Thank you, Matt Pavlovich > On Apr 2, 2021, at 6:58 AM, Martin Grigorov wrote: > > Hi, > > Now since we have 9.3.0 released is it time to start thinking/working on > Wicket 10 ? > > Here are few ideas what to break :-) > > 1) Move to Servlet 5.x, i.e. jakarta.servlet.** > 2) Use @Inject + @Named instead of @SpringBean. If everything is covered > by @Inject we may deprecate @SpringBean in 9.x > 3) Depending on the release date we may even bump Java to 17 (it is going > to be released this September and it is going to be LTS). I expect Wicket > 10.0.0 to be released in 1-2 years from now, so by this time Java 17 should > be mainstream! :-) I know that this is too brave. Most projects still use > Java 8 for some reason. > > Regards, > Martin
Re: Wicket 8.5.0 ready?
Thank you! On 5/22/19 8:05 AM, Andrea Del Bene wrote: The time is ripe! +1 On Wed, May 22, 2019 at 9:42 AM Martin Grigorov wrote: Hi, +1 to cut a release Here are the solved issues since 8.4.0 (Apr 5 2019) https://issues.apache.org/jira/projects/WICKET/versions/12345348 On Wed, May 22, 2019 at 3:30 AM Matt Pavlovich wrote: How are things looking for 8.5.0 release? Anything I can help with to close out issues?
Wicket 8.5.0 ready?
How are things looking for 8.5.0 release? Anything I can help with to close out issues?
