That is an email best sent to geoserver-security email list (where we figure out such stuff).
For more information please see our security policy https://github.com/geoserver/geoserver/security -- Jody Garnett On May 30, 2024 at 8:00:00 AM, "Lahr-Vivaz, Emilio" < emilio.lahr-vi...@ga-ccri.com> wrote: > Hey guys, > > I don't want to put any additional work on anyone, but if anyone is > feeling inspired, netty 4.1.41.Final has several high-severity CVEs out > against it[1] (current latest is 4.1.110.Final). > > Thanks, > > *Emilio Lahr-Vivaz* > General Atomics, CCRi > > [1]: https://github.com/netty/netty/security > > ------------------------------ > *From:* Andrea Aime <andrea.a...@geosolutionsgroup.com> > *Sent:* Thursday, May 30, 2024 10:45 AM > *To:* Gabriel Roldan <gabriel.rol...@camptocamp.com> > *Cc:* GeoServer <geoserver-devel@lists.sourceforge.net> > *Subject:* Re: [Geoserver-devel] Thinking about community modules > packaging > > Hi Gabriel, > my plan would be to split the COG module into sub-parts, because when one > needs to deploy on AWS, the azure libraries are not needed, > and vice versa. So make a packaging looking like: > > - cog-core (http support) > - cog-aws > - cog-azure > - cog-google > > That should hopefully solve the issue, because cog-azure uses the > azure-storage-blob v11, just like the blobstore. > > > Regards, > > Andrea Aime > > > == > GeoServer Professional Services from the experts! > > Visit http://bit.ly/gs-services-us for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions Group > phone: +39 0584 962313 > > fax: +39 0584 1660272 > > mob: +39 339 8844549 > > https://www.geosolutionsgroup.com/ > > http://twitter.com/geosolutions_it > > ------------------------------------------------------- > > Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE > 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si > precisa che ogni circostanza inerente alla presente email (il suo > contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è > riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il > messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra > operazione è illecita. Le sarei comunque grato se potesse darmene notizia. > > This email is intended only for the person or entity to which it is > addressed and may contain information that is privileged, confidential or > otherwise protected from disclosure. We remind that - as provided by > European Regulation 2016/679 “GDPR” - copying, dissemination or use of this > e-mail or the information herein by anyone other than the intended > recipient is prohibited. If you have received this email by mistake, please > notify us immediately by telephone or e-mail > > > On Thu, May 30, 2024 at 4:38 PM Gabriel Roldan < > gabriel.rol...@camptocamp.com> wrote: > > I'm afraid this would solve the packaging issue but not the problem of > deploying both the COG and the Azure blobstore extensions, as you'd end up > with duplicate netty dependencies with incompatible versions. > > In GeoServer Cloud I had to deal with this specific issue, using the > "dependencyConvergence" maven enforcer plugin rule [1], and ensuring a > single version of each duplicate dependency is in place. With the > additional overhead of ensuring the plugins whose dependencies are > overridden still work. > > For the specific case of the netty version, I'm pegging it to > 4.1.41.Final. Both COG and Azure blobstore work with that one. > The libs are in the pom's "dependencyConvergence" maven profile [3]. > > So probably we could do something similar in geoserver to ensure a single > version of each dependency is ever present. > Though that'd probably open its own can of worms. Perhaps just making sure > both COG and Azure blobstore carry over netty 4.1.41.Final would suffice > for the time being, without a rewrite of the Azure blobstore? > > [1] > https://github.com/geoserver/geoserver-cloud/blob/main/src/pom.xml#L904 > [2] > https://github.com/geoserver/geoserver-cloud/blob/main/src/pom.xml#L30-L32 > [3] > https://github.com/geoserver/geoserver-cloud/blob/main/src/pom.xml#L1070-L1124 > *camp**to**camp* > INNOVATIVE SOLUTIONS > BY OPEN SOURCE EXPERTS > > *Gabriel Roldán* > Geospatial Developer > > > > On Wed, May 29, 2024 at 12:35 PM Lahr-Vivaz, Emilio < > emilio.lahr-vi...@ga-ccri.com> wrote: > > Sounds good, dependency sets do provide include/exclude filtering[1] (or > if the pom already has things correctly scoped as provided vs compile then > you can easily filter out provided), but I'm all for easy wins! > > Thanks, > > Emilio > > [1]: > https://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html > > *Emilio Lahr-Vivaz* > General Atomics, CCRi > ------------------------------ > *From:* Andrea Aime <andrea.a...@geosolutionsgroup.com> > *Sent:* Wednesday, May 29, 2024 11:15 AM > *To:* Lahr-Vivaz, Emilio <emilio.lahr-vi...@ga-ccri.com> > *Cc:* Jody Garnett <jody.garn...@gmail.com>; GeoServer < > geoserver-devel@lists.sourceforge.net> > *Subject:* Re: [Geoserver-devel] Thinking about community modules > packaging > > Hi Emilio, > I'm aware of it, but there are issues... one one side, we want to package > in the zip file only the jars that are not already covered by core. > The other bit is, even if there was a way to achieve the above, all 74 > community module packaging files would have to be individually rewritten. > > What I'm proposing is simple, mechanical, and can be at least partially > automated, which means, it fits a small budget. > If we can party up with several people and attempt a technically better > approach, so that my isolated effort is more or less the same, > I'm all for it! > > Regards, > > Andrea Aime > > > == > GeoServer Professional Services from the experts! > > Visit http://bit.ly/gs-services-us for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions Group > phone: +39 0584 962313 > > fax: +39 0584 1660272 > > mob: +39 339 8844549 > > https://www.geosolutionsgroup.com/ > > http://twitter.com/geosolutions_it > > ------------------------------------------------------- > > Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE > 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si > precisa che ogni circostanza inerente alla presente email (il suo > contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è > riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il > messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra > operazione è illecita. Le sarei comunque grato se potesse darmene notizia. > > This email is intended only for the person or entity to which it is > addressed and may contain information that is privileged, confidential or > otherwise protected from disclosure. We remind that - as provided by > European Regulation 2016/679 “GDPR” - copying, dissemination or use of this > e-mail or the information herein by anyone other than the intended > recipient is prohibited. If you have received this email by mistake, please > notify us immediately by telephone or e-mail > > > On Wed, May 29, 2024 at 5:06 PM Lahr-Vivaz, Emilio < > emilio.lahr-vi...@ga-ccri.com> wrote: > > If it's helpful, the maven assembly plugin has a concept of > 'dependencySets', which could replace some of the fileSets and allow you to > avoid running dependencies:dependency-copy. > > Thanks, > > Emilio > > ------------------------------ > *From:* Andrea Aime <andrea.a...@geosolutionsgroup.com> > *Sent:* Wednesday, May 29, 2024 10:40 AM > *To:* Jody Garnett <jody.garn...@gmail.com> > *Cc:* GeoServer <geoserver-devel@lists.sourceforge.net> > *Subject:* Re: [Geoserver-devel] Thinking about community modules > packaging > > Hi Jody. > yes each module would have the assembly configuration local, besides its > pom.xml. > I've made a small experiment, on the COG module alone, this should work: > > <assembly> > <id>cog-plugin</id> > <formats> > <format>zip</format> > </formats> > <includeBaseDirectory>false</includeBaseDirectory> > <fileSets> > <fileSet> > <directory>target/dependency</directory> > <outputDirectory></outputDirectory> > <includes> > <include>annotations-2.*.jar</include> > <include>auth-2.*.jar</include> > <include>aws-*-2.*.jar</include> > <include>azure-storage*.jar</include> > <include>checksums-*2*.jar</include> > <include>client-runtime*.jar</include> > <include>crt-core-*-2*.jar</include> > <include>endpoints-spi-2*.jar</include> > <include>gs-cog*.jar</include> > <include>http-auth-*2*.jar</include> > <include>http-client-spi-2*.jar</include> > <include>http*-osgi*.jar</include> > <include>imageio-ext-*rangereader*.jar</include> > <include>identity-spi*.jar</include> > <include>jackson-datatype*.jar</include> > <include>jackson-module*.jar</include> > <include>kotlin-stdlib*.jar</include> > <include>metrics-spi-2.*.jar</include> > <include>*netty*.jar</include> > <include>okhttp*.jar</include> > <include>okio*.jar</include> > <include>profiles-2.*.jar</include> > <include>protocol-core-2.*.jar</include> > <include>reactive-streams*.jar</include> > <include>regions-2.*.jar</include> > <include>rxjava*.jar</include> > <include>s3-2.*.jar</include> > <include>sdk-core-2.*.jar</include> > <include>utils-2.*.jar</include> > </includes> > </fileSet> > <fileSet> > <directory>target</directory> > <outputDirectory></outputDirectory> > <includes> > <include>gs-cog*.jar</include> > </includes> > </fileSet> > </fileSets> > </assembly> > > To work, it still requires dependencies:dependency-copy to run, which we > can either have running > subject to a flag, or move it as part of the explicit build instructions. > > Regards, > > Andrea Aime > > > == > GeoServer Professional Services from the experts! > > Visit http://bit.ly/gs-services-us for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions Group > phone: +39 0584 962313 > > fax: +39 0584 1660272 > > mob: +39 339 8844549 > > https://www.geosolutionsgroup.com/ > > http://twitter.com/geosolutions_it > > ------------------------------------------------------- > > Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE > 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si > precisa che ogni circostanza inerente alla presente email (il suo > contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è > riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il > messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra > operazione è illecita. Le sarei comunque grato se potesse darmene notizia. > > This email is intended only for the person or entity to which it is > addressed and may contain information that is privileged, confidential or > otherwise protected from disclosure. We remind that - as provided by > European Regulation 2016/679 “GDPR” - copying, dissemination or use of this > e-mail or the information herein by anyone other than the intended > recipient is prohibited. If you have received this email by mistake, please > notify us immediately by telephone or e-mail > > > On Wed, May 29, 2024 at 4:35 PM Jody Garnett <jody.garn...@gmail.com> > wrote: > > I would like to see each module contains its own assembly, it would make > things more normal. > > Initially we made the release module to force assembly to occur at the > end, and to avoid taking the time to build download artifacts during day to > day development. > > We could keep the release profile and only build zip download bundles when > it is used. > -- > Jody Garnett > > > On Wed, May 29, 2024 at 1:15 AM Andrea Aime < > andrea.a...@geosolutionsgroup.com> wrote: > > Hi all, > I've got reports that the COG community module packaged zip bundles are > not working any > longer. Looking into it, it seems there are conflicting versions of > dependencies that are causing the trouble. > > As you probably know, the packaging is currently done this way: > > - A "release" module depends on all the modules that want to be > packages > - The release module dumps all these module dependencies into a single > directory > - Each module packaging descriptor picks from that pile of jars using > globs > > Now, we already had some issues with incompatible dependency versions, but > we more or less managed. Now there is a group of 3 different community > modules that depend, in turn, to AWS and Azure cloud libraries, which in > turn depend on Netty. Unfortunately, two different and incompatible > versions of it. > Ideally, we could just upgrade the Azure blob storage library in GWC, but > that amounts to a rewrite of the module. > > Rather than doing that, I'd suggest to untangle community module packaging > in the simplest possible way: > > - Have each module collect its own dependencies in target/dependencies > when a specific profile is used (e.g., -Passembly?) > - Have the assembly descriptor point at its own module > - Get rid of the "release" module > > Ideally we could do that for extensions as well, but I'd try that with > community modules first. > > Thoughts? > > Regards, > > Andrea Aime > > > == > GeoServer Professional Services from the experts! > > Visit http://bit.ly/gs-services-us for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions Group > phone: +39 0584 962313 > > fax: +39 0584 1660272 > > mob: +39 339 8844549 > > https://www.geosolutionsgroup.com/ > > http://twitter.com/geosolutions_it > > ------------------------------------------------------- > > Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE > 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si > precisa che ogni circostanza inerente alla presente email (il suo > contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è > riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il > messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra > operazione è illecita. Le sarei comunque grato se potesse darmene notizia. > > This email is intended only for the person or entity to which it is > addressed and may contain information that is privileged, confidential or > otherwise protected from disclosure. We remind that - as provided by > European Regulation 2016/679 “GDPR” - copying, dissemination or use of this > e-mail or the information herein by anyone other than the intended > recipient is prohibited. If you have received this email by mistake, please > notify us immediately by telephone or e-mail > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
