Just wanted to add my user perspective (I am not actively participating in developing struts).
For me reading the NIST entry and following the link to the security bulletin was totally sufficient. Under 'solution' and 'backwards compatibility' it's clearly outlined that upgrading is not enough and one needs to migrate to ActionFileUploadInterceptor. Maybe it could have been a bit more highlighted (in bold, red, ... whatever), but it was good enough for me to follow the guidance. Kind regards and thanks for the good work Sebastian -----Ursprüngliche Nachricht----- Von: Arnout Engelen <enge...@apache.org> Gesendet: Donnerstag, 19. Dezember 2024 11:16 An: security-disc...@community.apache.org Cc: Lukasz Lenart <lukaszlen...@apache.org>; dev@struts.apache.org Betreff: Re: Struts / CVE-2024-53677 (adding dev@struts.a.o) On Thu, Dec 19, 2024 at 11:00 AM Jarek Potiuk <ja...@potiuk.com> wrote: > While this might be a popular feature, It's pretty well handled by the > Struts team IMHO I agree! > https://cwiki.apache.org/confluence/display/WW/S2-066, the 2.5 is not > marked as EOL (but it is EOL in fact already and well announced). The bulletin for this particular advisory (https://cwiki.apache.org/confluence/display/WW/S2-067) does mark 2.5 as EOL. I guess it might make sense to also mark it EOL in older advisories, but not sure if it'd have a huge impact. I think we should probably make the wording in the CVE advisory stronger (like in the bulletin), especially because NVD leaves out the CVE title. > any application > that used file upload before struts 6.4 must be converted to the new > mechanism. So this one is not as easy as "upgrade to new version" - > it's "upgrade to new version and modify your application to use the > new mechanism" - which I guess is why people are stirred by it. I agree, while we do mention it clearly it's still easy to miss that it is not sufficient to upgrade to 6.4.0, but that you also have to switch to the new upload mechanism. It might be worth a short blogpost+announcement to highlight that point? Would the Struts team be interested to put something like that together? > I think - to be perfectly blunt - IMHO neither we, nor Struts should > release any extra statements that could be interpreted as "we have not > already done enough". We (Struts team particularly) did everything > right, made all the necessary announcements, had very clear > explanations and followed all the best practices as far as I can see. I agree we should not present it as "we didn't do enough" but as "we're highlighting this because it may be important to you". I'm not too worried about that setting a precedent. Arnout > On Wed, Dec 18, 2024 at 9:22 PM Dirk-Willem van Gulik > <di...@webweaving.org> > wrote: > > > Quite a few of my customers appear to be taken off guard / have > > missed the significance of > > > > https://nvd.nist.gov/vuln/detail/CVE-2024-53677 > > > > even those that are normally quite awake at the help. So I am > > wondering if we need to do something a bit more pro-active ? > > > > Like a blog post or have the PR folks prepare something - i.e. more > > than just the normal struts announce noise. > > > > Any thoughts anyone ? Or not a universal thing ? And I happened to > > live in a statistical cul de sac ? > > > > Dw. > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: > > security-discuss-unsubscr...@community.apache.org > > For additional commands, e-mail: > > security-discuss-h...@community.apache.org > > > > -- Arnout Engelen ASF Security Response Apache Pekko PMC member, ASF Member NixOS Committer Independent Open Source consultant --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
