date:20220110

Re: [Geoserver-users] Fwd: GitHub integration - Encoding issue

2022-01-10 Thread Alexandre Gacon

Hello everyone,

Finally, Transifex cannot fix the issue they have with the encoding (they
just updated the documentation about it, see :
https://docs.transifex.com/transifex-github-integrations/github-tx-ui).

I will finish reviewing the Transifex configuration and the synchronization
with the GitHub repo to at least have one way synchronization. After this,
I will try to see if I can setup some script the APIs of Transifex to
automatize the Transifex->Git synchronization if possible.

Regards
Alexandre

Le sam. 8 janv. 2022 à 18:03, Andrea Aime 
a écrit :

> On Wed, Jan 5, 2022 at 6:46 PM Alexandre Gacon 
> wrote:
>
>> ---
>> In order to understand the following explanation, keep in mind that:
>>
>>- UTF-8 is the encoding that will preserve properly all non-ascii,
>>non-latin1 characters
>>- ISO-5589-1 (aka latin1 ) is a ascii based encoding that contains
>>all the ascii characters plus some additional ones used in the latin
>>alphabet (i.e. é, è etc..)
>>
>> Probably key to understanding the rest, latin1 and ISO8859-1 are the same
>  (it confused me at first).
>
>>
>>-
>>- us-ascii is the standard encoding for electronic communication and
>>as we already mentioned a subset of the latin1 encoding.
>>
>>
>> After the new tests regarding the retaining of the encoding of the file
>> given in the ticket, we noticed the following:
>>
>>- If a non-latin1, non-ascii character exists in the translation
>>(UTF-8 characters) then the final translation file will contain the UTF-8
>>escaped corresponding characters (i.e. \u0420 corresponds to some Cyrillic
>>letter).
>>
>> Ok, so Transifex won't support the Wicket ".utf8.properties" convention,
> and just escape chars so that they can be encoded in ISO-8859-1 instead.
>
>>
>>- In our case, the latin1 character wasn’t part of the translated
>>strings but part of the structure of the file, at the template of the 
>> file.
>>This means that we don’t want to change it to the UTF-8 escaped character.
>>
>> I don't understand what "the structure of the file" instead of "part of
> the translated strings" means. Maybe the latin1 character was in a key
> rather than
> in a value? Or maybe in a comment.
>
>
>>
>>- But on the other hand, the library that we are using in order to
>>integrate github with transifex is not supporting latin1 but UTF-8 so when
>>a non-ascii character appears it converts the whole file to the best
>>encoding that can represent that character. In our case that is UTF-8.
>>
>> It seems they have a technical limitation, and can either do us-ascii or
> escaped UTF-8, but does not support latin1 (ISO-8859-1).
>
>>
>> In order to preserve the us-ascii encoding (not the latin1) in github one
>> must make sure that the source keys and the comments of the file do not
>> contain any non ascii characters.
>>
>
> Seems that we can either use only us-ascii chars (and encode anything
> else, included accented letters, using UTF-8 escape codes),
> or maybe fully UTF-8? Regardless it seems ISO-8859-1 is simply out of the
> equation?
>
>
>> ---
>>
>> In case something wasn't clear, what this means is that because the
>> source file had a latin1 character (é) even though the translations for the
>> strings did not, this character was kept as-is (not escaped) as part of the
>> "template". Therefore, the translation files sent back to GitHub are being
>> encoded with UTF-8 by the library being used. We do not think we can do
>> anything about this, unfortunately. So, the translation files for the Java
>> Properties file format must be retrieved from Transifex directly instead of
>> using the GitHub integration.
>>
>
> I believe the "é" character was added in a comment, as an attempt to force
> Transifex to use ISO-8859-1?
> And Transifex is simply incapable of doing that?
>
> Hum... well Wicket does not really care and will support translation files
> made of us-ascii with UTF-8 escapes fine
> I believe, but translators that are doing direct commits, rather than
> going though Transifex might be less than pleased.
> I believe Jody at one point mentioned a different platform, but cannot
> remember which one that is.
> Thinking out loud, I see two avenues ahead:
>
>- Put up with Transifex limitations
>- Try to extract the good work present in Transifex once, and then
>migrate to another translation system, if you can find one that works
>better for translator
>
> Cheers
> Andrea
>
> ==
>
> 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  333 8128928
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
>

Re: [Geoserver-users] Geoserver is not starting while running startup batch script

2022-01-10 Thread Ian Turton

It looks like something else is already using that port, or you don't have
permission to use it.

Ian

On Mon, 10 Jan 2022, 19:07 Jibran Khan,  wrote:

> Hello,
>
> I am trying to run an older version of Geoserver (Ver 2.15.1) on my
> Windows 10 (64 bit) PC. The script startup.bat starts and crashes. I have
> tried running the script with Admin privileges, changing port in start.ini
> (e.g. jetty.port = 8989) and reload, opening port in Windows firewall,
> nothing seems to work.
>
> I also checked Windows services, but couldn't find Geoserver as a service
> there.
>
> Java_Home: set to JDK 11
>
> GEOSERVER data dir points to data directory of Geoserver
>
> Can someone give me some hints to fix this?
>
> Here is the crash log via Windows CMD console:
>
> 
>
> :INFO:oejsh.ContextHandler:main: Started 
> o.e.j.w.WebAppContext@1ec1f0c{GeoServer,/geoserver,file:///C:/path_to/GeoServer%202.15.1/webapps/geoserver/,AVAILABLE}{C:\path_to\GeoServer
> 2.15.1\webapps\geoserver}
> :WARN:oejx.XmlConfiguration:main:
> java.security.PrivilegedActionException: java.net.BindException: Address
> already in use: bind
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1511)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.jetty.start.Main.invokeMain(Main.java:220)
> at org.eclipse.jetty.start.Main.start(Main.java:486)
> at org.eclipse.jetty.start.Main.main(Main.java:77)
> Caused by:
> java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Unknown Source)
> at sun.nio.ch.Net.bind(Unknown Source)
> at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
> at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
> at
> org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:339)
> at
> org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:307)
> at
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
> at
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:235)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at org.eclipse.jetty.server.Server.doStart(Server.java:395)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at
> org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1572)
> at
> org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1512)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1511)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.jetty.start.Main.invokeMain(Main.java:220)
> at org.eclipse.jetty.start.Main.start(Main.java:486)
> at org.eclipse.jetty.start.Main.main(Main.java:77)
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.jetty.start.Main.invokeMain(Main.java:220)
> at org.eclipse.jetty.start.Main.start(Main.java:486)
> at org.eclipse.jetty.start.Main.main(Main.java:77)
> Caused by: java.security.PrivilegedActionException:
> java.net.BindException: Address already in use: bind
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1511)
> ... 7 more
> Caused by: java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Unknown Source)
> at sun.nio.ch.Net.bind(Unknown Source)
> at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
> at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
> at
> org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:339)
> at
> org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:307)
> at
>

Re: [Geoserver-users] Geoserver is not starting while running startup batch script

2022-01-10 Thread Russ

I might be wrong but I think Java 11 needs a liter. version of GeoServer.

Why do you need the old version?

> On 10 Jan 2022, at 19:10, Jibran Khan  wrote:
> 
> 
> Hello,
> 
> I am trying to run an older version of Geoserver (Ver 2.15.1) on my Windows 
> 10 (64 bit) PC. The script startup.bat starts and crashes. I have tried 
> running the script with Admin privileges, changing port in start.ini (e.g. 
> jetty.port = 8989) and reload, opening port in Windows firewall, nothing 
> seems to work.
> 
> I also checked Windows services, but couldn't find Geoserver as a service 
> there.
> 
> Java_Home: set to JDK 11
> 
> GEOSERVER data dir points to data directory of Geoserver
> 
> Can someone give me some hints to fix this?
> 
> Here is the crash log via Windows CMD console:
> 
> **
> 
> :INFO:oejsh.ContextHandler:main: Started 
> o.e.j.w.WebAppContext@1ec1f0c{GeoServer,/geoserver,file:///C:/path_to/GeoServer%202.15.1/webapps/geoserver/,AVAILABLE}{C:\path_to\GeoServer
>  2.15.1\webapps\geoserver}
> :WARN:oejx.XmlConfiguration:main:
> java.security.PrivilegedActionException: java.net.BindException: Address 
> already in use: bind
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1511)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.jetty.start.Main.invokeMain(Main.java:220)
> at org.eclipse.jetty.start.Main.start(Main.java:486)
> at org.eclipse.jetty.start.Main.main(Main.java:77)
> Caused by:
> java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Unknown Source)
> at sun.nio.ch.Net.bind(Unknown Source)
> at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
> at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
> at 
> org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:339)
> at 
> org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:307)
> at 
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
> at 
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:235)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at org.eclipse.jetty.server.Server.doStart(Server.java:395)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1572)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1512)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1511)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.jetty.start.Main.invokeMain(Main.java:220)
> at org.eclipse.jetty.start.Main.start(Main.java:486)
> at org.eclipse.jetty.start.Main.main(Main.java:77)
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.jetty.start.Main.invokeMain(Main.java:220)
> at org.eclipse.jetty.start.Main.start(Main.java:486)
> at org.eclipse.jetty.start.Main.main(Main.java:77)
> Caused by: java.security.PrivilegedActionException: java.net.BindException: 
> Address already in use: bind
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1511)
> ... 7 more
> Caused by: java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Unknown Source)
> at sun.nio.ch.Net.bind(Unknown Source)
> at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
> at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
> at 
> org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:339)
> at 
> org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:307)
> at 
>

Re: [Geoserver-users] [EXTERN!]: LOG4J Version in GeoServer

2022-01-10 Thread Stefan Ziegler

There is now a fork of log4j named reload4j: https://reload4j.qos.ch/ It is a 
drop-in replacement and the project aims to fix the most urgent issues.

Stefan


From: Ron Lindhoudt via Geoserver-users 
Sent: Monday, January 10, 2022 5:34 PM
To: geoserver-users@lists.sourceforge.net; Mark Prins
Subject: Re: [Geoserver-users] [EXTERN!]: LOG4J Version in GeoServer

Our customers are demanding to support the latest version of log4j in 
Geoserver, I mean the latest 2.* without vulnerabilities because log4j 1.* is 
EOL.
On the Geoserver website I found this (13-12-2021):

We are also aware that Log4J 1.2.17 is an “End Of Life” (EOL) project, and are 
actively looking for funding to perform an upgrade to more recent versions of 
them. All new logging libraries have a different API and a different 
configuration file layout, with potential backwards compatibility issues, so 
this will be likely done on newer versions of GeoServer (2.21.x).

What is the status at this moment?

Thanks,
Ron
On Monday, 20 December 2021, 11:38:54 CET, Mark Prins  
wrote:


On 19-12-2021 11:11, Michael Steigemann via Geoserver-users wrote:
> Hello!
> Thank you very much for providing the geoserver.war:
> log4j-1.2.17.norce.jar.
> I have integrated into geoserver and ran a OWASP dependency check (
> https://jeremylong.github.io/DependencyCheck/dependency-check-cli/index.html
> )
>
> The library is still classified as critical:
> geoserver.war: log4j-1.2.17.norce.jar
> cpe:2.3:a:apache:log4j:1.2.17:*:*:*:*:*:*:*
> pkg:maven/log4j/log4j@1.2.17-norceCRITICAL
> 2Highest27
>
> Do you think it is possible and a good idea to register the library as
> "safe" in the central database?

No, this is not a new release but the same release with some files
removed and a way of preventing people from shooting themselves in the
foot because they can no longer configure the culprit appenders.

After inspection of the new jar file you can add a suppression for false
positives like





^log4j:log4j:1\.2\.17$
CVE-2019-17571
CVE-2020-9488
CVE-2021-4104






___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Geoserver is not starting while running startup batch script

2022-01-10 Thread Jibran Khan

Hello,

I am trying to run an older version of Geoserver (Ver 2.15.1) on my Windows
10 (64 bit) PC. The script startup.bat starts and crashes. I have tried
running the script with Admin privileges, changing port in start.ini (e.g.
jetty.port = 8989) and reload, opening port in Windows firewall,
nothing seems to work.

I also checked Windows services, but couldn't find Geoserver as a service
there.

Java_Home: set to JDK 11

GEOSERVER data dir points to data directory of Geoserver

Can someone give me some hints to fix this?

Here is the crash log via Windows CMD console:



:INFO:oejsh.ContextHandler:main: Started
o.e.j.w.WebAppContext@1ec1f0c{GeoServer,/geoserver,file:///C:/path_to/GeoServer%202.15.1/webapps/geoserver/,AVAILABLE}{C:\path_to\GeoServer
2.15.1\webapps\geoserver}
:WARN:oejx.XmlConfiguration:main:
java.security.PrivilegedActionException: java.net.BindException: Address
already in use: bind
at java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1511)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:220)
at org.eclipse.jetty.start.Main.start(Main.java:486)
at org.eclipse.jetty.start.Main.main(Main.java:77)
Caused by:
java.net.BindException: Address already in use: bind
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Unknown Source)
at sun.nio.ch.Net.bind(Unknown Source)
at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at
org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:339)
at
org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:307)
at
org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
at
org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:235)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.server.Server.doStart(Server.java:395)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at
org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1572)
at
org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1512)
at java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1511)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:220)
at org.eclipse.jetty.start.Main.start(Main.java:486)
at org.eclipse.jetty.start.Main.main(Main.java:77)
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:220)
at org.eclipse.jetty.start.Main.start(Main.java:486)
at org.eclipse.jetty.start.Main.main(Main.java:77)
Caused by: java.security.PrivilegedActionException: java.net.BindException:
Address already in use: bind
at java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1511)
... 7 more
Caused by: java.net.BindException: Address already in use: bind
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Unknown Source)
at sun.nio.ch.Net.bind(Unknown Source)
at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at
org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:339)
at
org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:307)
at
org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
at
org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:235)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.server.Server.doStart(Server.java:395)
at

Re: [Geoserver-users] [EXTERN!]: LOG4J Version in GeoServer

2022-01-10 Thread Ian Turton

Currently there are no plans to change the logging framework. The question
is how much do you and your customers want to make this change happen? Even
estimating the cost of the update is probably several days work, so until
we get funding to start looking there isn't even a plan.

There is a chance we can use OSGeo funds to look at the problem but that
still won't happen unless someone organises it but we are always happy to
receive volunteers.

Ian

On Mon, 10 Jan 2022, 16:34 Ron Lindhoudt via Geoserver-users, <
geoserver-users@lists.sourceforge.net> wrote:

> Our customers are demanding to support the latest version of log4j in
> Geoserver, I mean the latest 2.* without vulnerabilities because log4j 1.*
> is EOL.
> On the Geoserver website I found this (13-12-2021):
>
> We are also aware that Log4J 1.2.17 is an “End Of Life” (EOL) project, and
> are actively looking for funding to perform an upgrade to more recent
> versions of them. All new logging libraries have a different API and a
> different configuration file layout, with potential backwards compatibility
> issues, so this will be likely done on newer versions of GeoServer (2.21.x).
>
> What is the status at this moment?
>
> Thanks,
> Ron
> On Monday, 20 December 2021, 11:38:54 CET, Mark Prins 
> wrote:
>
>
> On 19-12-2021 11:11, Michael Steigemann via Geoserver-users wrote:
> > Hello!
> > Thank you very much for providing the geoserver.war:
> > log4j-1.2.17.norce.jar.
> > I have integrated into geoserver and ran a OWASP dependency check (
> > https://jeremylong.github.io/DependencyCheck/dependency-check-cli/index.html
>
> > <
> https://jeremylong.github.io/DependencyCheck/dependency-check-cli/index.html
> >)
> >
> > The library is still classified as critical:
> > geoserver.war: log4j-1.2.17.norce.jar
> > cpe:2.3:a:apache:log4j:1.2.17:*:*:*:*:*:*:*
> > pkg:maven/log4j/log4j@1.2.17-norceCRITICAL2Highest27
> >
> > Do you think it is possible and a good idea to register the library as
> > "safe" in the central database?
>
> No, this is not a new release but the same release with some files
> removed and a way of preventing people from shooting themselves in the
> foot because they can no longer configure the culprit appenders.
>
> After inspection of the new jar file you can add a suppression for false
> positives like
>
> 
> 
> 
> 
> ^log4j:log4j:1\.2\.17$
> CVE-2019-17571
> CVE-2020-9488
> CVE-2021-4104
> 
>
>
>
>
>
> ___
> Geoserver-users mailing list
>
> Please make sure you read the following two resources before posting to
> this list:
> - Earning your support instead of buying it, but Ian Turton:
> http://www.ianturton.com/talks/foss4g.html#/
> - The GeoServer user list posting guidelines:
> http://geoserver.org/comm/userlist-guidelines.html
>
> If you want to request a feature or an improvement, also see this:
> https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
>
>
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
> ___
> Geoserver-users mailing list
>
> Please make sure you read the following two resources before posting to
> this list:
> - Earning your support instead of buying it, but Ian Turton:
> http://www.ianturton.com/talks/foss4g.html#/
> - The GeoServer user list posting guidelines:
> http://geoserver.org/comm/userlist-guidelines.html
>
> If you want to request a feature or an improvement, also see this:
> https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
>
>
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] [EXTERN!]: LOG4J Version in GeoServer

2022-01-10 Thread Ron Lindhoudt via Geoserver-users

 Our customers are demanding to support the latest version of log4j in 
Geoserver, I mean the latest 2.* without vulnerabilities because log4j 1.* is 
EOL.On the Geoserver website I found this (13-12-2021):
We are also aware that Log4J 1.2.17 is an “End Of Life” (EOL) project, and are 
actively looking for funding to perform an upgrade to more recent versions of 
them. All new logging libraries have a different API and a different 
configuration file layout, with potential backwards compatibility issues, so 
this will be likely done on newer versions of GeoServer (2.21.x).

What is the status at this moment?
Thanks,RonOn Monday, 20 December 2021, 11:38:54 CET, Mark Prins 
 wrote:  
 
 On 19-12-2021 11:11, Michael Steigemann via Geoserver-users wrote:
> Hello!
> Thank you very much for providing the geoserver.war: 
> log4j-1.2.17.norce.jar.
> I have integrated into geoserver and ran a OWASP dependency check ( 
> https://jeremylong.github.io/DependencyCheck/dependency-check-cli/index.html 
> )
> 
> The library is still classified as critical:
> geoserver.war: log4j-1.2.17.norce.jar 
> cpe:2.3:a:apache:log4j:1.2.17:*:*:*:*:*:*:* 
> pkg:maven/log4j/log4j@1.2.17-norce    CRITICAL    2    Highest    27
> 
> Do you think it is possible and a good idea to register the library as 
> "safe" in the central database?

No, this is not a new release but the same release with some files 
removed and a way of preventing people from shooting themselves in the 
foot because they can no longer configure the culprit appenders.

After inspection of the new jar file you can add a suppression for false 
positives like


    
        
    
    ^log4j:log4j:1\.2\.17$
    CVE-2019-17571
    CVE-2020-9488
    CVE-2021-4104





___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
  ___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Fwd: GitHub integration - Encoding issue

Re: [Geoserver-users] Geoserver is not starting while running startup batch script

Re: [Geoserver-users] Geoserver is not starting while running startup batch script

Re: [Geoserver-users] [EXTERN!]: LOG4J Version in GeoServer

[Geoserver-users] Geoserver is not starting while running startup batch script

Re: [Geoserver-users] [EXTERN!]: LOG4J Version in GeoServer

Re: [Geoserver-users] [EXTERN!]: LOG4J Version in GeoServer

7 matches

Site Navigation

Mail list logo

Footer information