Apply accepted, we are all learning a good way forward. Even if a library has a public CVE it may or may not be exploitable from geoserver user interface or web service; or may be limited to a specific extension etc…
If a CVE in a dependency does affect geoserver we make a CVE for our project, if not we just update the dependency. Folks get very worried about vulnerabilities so public discussion is EXPENSIVE. With regulation requirements taking shape in Europe and the US it is becoming even more expensive. -- Jody Garnett On Thu, May 30, 2024 at 9:44 AM Lahr-Vivaz, Emilio < emilio.lahr-vi...@ga-ccri.com> wrote: > Apologies - since the upstream CVEs are already public, I didn't realize > it was necessary to keep the discussion private. > > Thanks, > > *Emilio Lahr-Vivaz* > General Atomics, CCRi > > ------------------------------ > *From:* Jody Garnett <jody.garn...@gmail.com> > *Sent:* Thursday, May 30, 2024 11:14 AM > *To:* Lahr-Vivaz, Emilio <emilio.lahr-vi...@ga-ccri.com> > *Cc:* GeoServer <geoserver-devel@lists.sourceforge.net>; Andrea Aime < > andrea.a...@geosolutionsgroup.com>; Gabriel Roldan < > gabriel.rol...@camptocamp.com> > > *Subject:* Re: [Geoserver-devel] Thinking about community modules > packaging > > 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
