exist-open — Open discussion

[Exist-open] Error in locally built Docker 5.3.1 image

[Loren C. <lor...@gm...>]

Here is my environment setup and then my build of the Docker image and then the error that I get when I try to launch the docker image.


OS: macOS Big Sur 11.6.2
2.4 GHz 8-Core Intel Core i9
32 GB 2400 MHz DDR4
 
PATH=/usr/local/opt/openjdk@8/bin:/Users/lcahland/.npm-global/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
 
 
lcahland$ javac -version
javac 1.8.0_312
 
lcahland$ java -version
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (build 1.8.0_312-bre_2021_10_20_23_15-b00)
OpenJDK 64-Bit Server VM (build 25.312-b00, mixed mode)
 
lcahland$ brew list
==> Formulae
azure-cli     gdbm          icu4c         libnghttp2    mpdecimal     openjdk@8     python@3.10   tcl-tk
brotli        gettext       jemalloc      libpng        nghttp2       openssl@1.1   python@3.8    xz
c-ares        git           jq            libuv         node          ossp-uuid     python@3.9    yq
ca-certificates      go            kubernetes-cli libxml2       oniguruma     pandoc        readline
freetype      helm          libev         maven         openjdk       pcre2         sqlite
 
 
LAMU02ZG46HLVDQ:exist-5.3.1 lcahland$ mvn -Ddocker=true -DskipTests=true clean package
 
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for eXist-db 5.3.1:
[INFO] 
[INFO] eXist-db Parent .................................... SUCCESS [  3.121 s]
[INFO] eXist-db Startup ................................... SUCCESS [  3.657 s]
[INFO] eXist-db Jetty Configuration ....................... SUCCESS [  1.022 s]
[INFO] eXist-db Data Samples .............................. SUCCESS [  0.861 s]
[INFO] eXist-db Core ...................................... SUCCESS [ 50.424 s]
[INFO] eXist-db Ant Tasks ................................. SUCCESS [  0.798 s]
[INFO] eXist-db Service ................................... SUCCESS [  0.576 s]
[INFO] eXist-db Content Extraction Extension .............. SUCCESS [  5.790 s]
[INFO] eXist-db EXIF Tool Extension ....................... SUCCESS [  0.268 s]
[INFO] eXist-db EXPath Extensions ......................... SUCCESS [  0.566 s]
[INFO] eXist-db EXQuery Request Module .................... SUCCESS [  0.266 s]
[INFO] eXist-db RESTXQ Extension .......................... SUCCESS [  0.997 s]
[INFO] eXist-db WebDAV Extension .......................... SUCCESS [  0.859 s]
[INFO] eXist-db xqDoc Extension ........................... SUCCESS [  0.554 s]
[INFO] eXist-db Lucene Index .............................. SUCCESS [  1.428 s]
[INFO] eXist-db NGram Index ............................... SUCCESS [  0.737 s]
[INFO] eXist-db Lucene Range Index ........................ SUCCESS [  0.761 s]
[INFO] eXist-db Sort Index ................................ SUCCESS [  0.563 s]
[INFO] eXist-db Spatial Index ............................. SUCCESS [  2.815 s]
[INFO] eXist-db Cache Module .............................. SUCCESS [  0.612 s]
[INFO] eXist-db Compression Module ........................ SUCCESS [  0.699 s]
[INFO] eXist-db Counter Module ............................ SUCCESS [  0.507 s]
[INFO] eXist-db CQL Parser Module ......................... SUCCESS [  0.301 s]
[INFO] eXist-db EXPath Repository Module .................. SUCCESS [  0.630 s]
[INFO] eXist-db File Module ............................... SUCCESS [  0.677 s]
[INFO] eXist-db Image Module .............................. SUCCESS [  0.374 s]
[INFO] eXist-db JNDI Module ............................... SUCCESS [  0.341 s]
[INFO] eXist-db Email Module .............................. SUCCESS [  0.483 s]
[INFO] eXist-db Persistent Login Module ................... SUCCESS [  0.448 s]
[INFO] eXist-db Process Module ............................ SUCCESS [  0.260 s]
[INFO] eXist-db Scheduler Module .......................... SUCCESS [  0.271 s]
[INFO] eXist-db SimpleQL Module ........................... SUCCESS [  0.457 s]
[INFO] eXist-db SQL Module ................................ SUCCESS [  0.826 s]
[INFO] eXist-db XML Diff Module ........................... SUCCESS [  0.240 s]
[INFO] eXist-db XSL:FO Module ............................. SUCCESS [  1.549 s]
[INFO] eXist-db LDAP Security Module ...................... SUCCESS [  0.500 s]
[INFO] eXist-db Active Directory Security Module .......... SUCCESS [  0.411 s]
[INFO] eXist-db IP Range Security Module .................. SUCCESS [  0.318 s]
[INFO] eXist-db Distributions ............................. SUCCESS [01:11 min]
[INFO] eXist-db EXQuery Extension Modules ................. SUCCESS [  0.062 s]
[INFO] eXist-db EXQuery Extensions ........................ SUCCESS [  0.058 s]
[INFO] eXist-db Index Extensions .......................... SUCCESS [  0.055 s]
[INFO] eXist-db Example Module ............................ SUCCESS [  0.258 s]
[INFO] eXist-db EXI Module ................................ SUCCESS [  0.348 s]
[INFO] eXist-db Extension XQuery Modules .................. SUCCESS [  0.062 s]
[INFO] eXist-db Extension Security Modules ................ SUCCESS [  0.048 s]
[INFO] eXist-db Extensions ................................ SUCCESS [  0.053 s]
[INFO] eXist-db Docker Image .............................. SUCCESS [ 25.145 s]
[INFO] eXist-db ........................................... SUCCESS [  0.068 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  03:04 min
[INFO] Finished at: 2021-12-21T10:50:11-06:00
[INFO] ------------------------------------------------------------------------
LAMU02ZG46HLVDQ:exist-5.3.1 lcahland$ 
 
 
LAMU02ZG46HLVDQ:exist-5.3.1 lcahland$ docker run -it -p 8080:8080 -p 8443:8443 --name exist existdb/existdb:5.3.1
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8   -Dsun.jnu.encoding=UTF-8   -Djava.awt.headless=true   -Dorg.exist.db-connection.cacheSize=256M   -Dorg.exist.db-connection.pool.max=20   -Dlog4j.configurationFile=/exist/etc/log4j2.xml   -Dexist.home=/exist   -Dexist.configurationFile=/exist/etc/conf.xml   -Djetty.home=/exist   -Dexist.jetty.config=/exist/etc/jetty/standard.enabled-jetty-configs   -XX:+UseContainerSupport   -XX:MaxRAMPercentage=75.0   -XX:+ExitOnOutOfMemoryError
21 Dec 2021 16:53:05,929 [main] INFO  (XmlLibraryChecker.java [check]:149) - Looking for a valid Parser...
Checking for Xerces, found version Xerces-J 2.12.1-xml-schema-1.1
OK!
 
21 Dec 2021 16:53:05,974 [main] INFO  (XmlLibraryChecker.java [check]:171) - Looking for a valid Transformer...
Checking for Saxon, found version 9.9.1.7
OK!
 
21 Dec 2021 16:53:05,974 [main] INFO  (XmlLibraryChecker.java [check]:183) - Looking for a valid Resolver...
Checking for Resolver, found version XmlResolver 1.2
OK!
 
21 Dec 2021 16:53:05,981 [main] INFO  (XmlLibraryChecker.java [check]:189) - Using parser org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser 
21 Dec 2021 16:53:05,988 [main] INFO  (XmlLibraryChecker.java [check]:190) - Using transformer org.apache.xalan.transformer.TransformerIdentityImpl 
21 Dec 2021 16:53:05,989 [main] INFO  (JettyStart.java [run]:181) - Running with Java 1.8.0_275 [Oracle Corporation (OpenJDK 64-Bit Server VM) in /usr/lib/jvm/java-8-openjdk-amd64/jre] 
21 Dec 2021 16:53:05,992 [main] INFO  (JettyStart.java [run]:188) - Approximate maximum amount of memory for JVM: 2 GB 
21 Dec 2021 16:53:05,992 [main] INFO  (JettyStart.java [run]:189) - Number of processors available to JVM: 8 
21 Dec 2021 16:53:05,992 [main] INFO  (JettyStart.java [run]:191) - Running as user 'root' 
21 Dec 2021 16:53:05,993 [main] INFO  (JettyStart.java [run]:192) - [eXist Home : /exist] 
21 Dec 2021 16:53:05,994 [main] INFO  (JettyStart.java [run]:193) - [eXist Version : 5.3.1] 
21 Dec 2021 16:53:05,995 [main] INFO  (JettyStart.java [run]:194) - [eXist Build : 20211214201345] 
21 Dec 2021 16:53:05,995 [main] INFO  (JettyStart.java [run]:195) - [Git commit : 0c0669eef1fdd50ce029398e3852b239f6052e6f] 
21 Dec 2021 16:53:05,995 [main] INFO  (JettyStart.java [run]:197) - [Operating System : Linux 5.10.47-linuxkit amd64] 
21 Dec 2021 16:53:05,996 [main] INFO  (JettyStart.java [run]:198) - [log4j.configurationFile : /exist/etc/log4j2.xml] 
21 Dec 2021 16:53:06,018 [main] INFO  (JettyStart.java [run]:199) - [jetty Version: 9.4.42.v20210604] 
21 Dec 2021 16:53:06,019 [main] INFO  (JettyStart.java [run]:200) - [jetty.home : /exist] 
21 Dec 2021 16:53:06,019 [main] INFO  (JettyStart.java [run]:201) - [jetty.base : /exist] 
21 Dec 2021 16:53:06,019 [main] INFO  (JettyStart.java [run]:202) - [jetty configuration : /exist/etc/jetty/standard.enabled-jetty-configs] 
21 Dec 2021 16:53:06,029 [main] INFO  (Configuration.java [<init>]:184) - Reading configuration from file /exist/etc/conf.xml 
21 Dec 2021 16:53:06,052 [main] WARN  (Configuration.java [getConfigAttributeValue]:1513) - Configuration value overridden by system property: org.exist.db-connection.cacheSize, with value: 256M 
21 Dec 2021 16:53:06,055 [main] INFO  (Configuration.java [configureStartup]:1260) - Registered StartupTrigger: org.exist.security.BouncyCastleJceProviderStartupTrigger 
21 Dec 2021 16:53:06,057 [main] INFO  (Configuration.java [configureStartup]:1260) - Registered StartupTrigger: org.exist.protocolhandler.URLStreamHandlerStartupTrigger 
21 Dec 2021 16:53:06,057 [main] INFO  (Configuration.java [configureStartup]:1260) - Registered StartupTrigger: org.exist.extensions.exquery.restxq.impl.RestXqStartupTrigger 
21 Dec 2021 16:53:06,059 [main] INFO  (Configuration.java [configureStartup]:1260) - Registered StartupTrigger: org.exist.repo.AutoDeploymentTrigger 
21 Dec 2021 16:53:06,060 [main] WARN  (Configuration.java [getConfigAttributeValue]:1513) - Configuration value overridden by system property: org.exist.db-connection.pool.max, with value: 20 
21 Dec 2021 16:53:06,200 [main] INFO  (Configuration.java [configureValidation]:1470) - Add catalog uri file:///exist/etc/webapp//WEB-INF/catalog.xml <file:///exist/etc/webapp//WEB-INF/catalog.xml> 
21 Dec 2021 16:53:06,201 [main] INFO  (GrammarPool.java [<init>]:54) - Initializing GrammarPool. 
21 Dec 2021 16:53:06,203 [main] INFO  (JettyStart.java [run]:211) - Configuring eXist from /exist/etc/conf.xml 
21 Dec 2021 16:53:06,213 [main] INFO  (BrokerPool.java [<init>]:414) - database instance 'exist' will wait  120,000 ms during shutdown 
21 Dec 2021 16:53:06,213 [main] INFO  (BrokerPool.java [<init>]:417) - database instance 'exist' is enabled for recovery : true 
21 Dec 2021 16:53:06,213 [main] INFO  (BrokerPool.java [<init>]:421) - database instance 'exist' will have between 1 and 20 brokers 
21 Dec 2021 16:53:06,213 [main] INFO  (BrokerPool.java [<init>]:424) - database instance 'exist' will be synchronized every 120,000 ms 
21 Dec 2021 16:53:06,222 [main] INFO  (LockManager.java [<init>]:141) - Configured LockManager with concurrencyLevel=16 use-path-locks-for-documents=false paths-multi-writer=false 
21 Dec 2021 16:53:06,264 [main] INFO  (DefaultCacheManager.java [<init>]:152) - Cache settings: 262,144k; totalPages: 65,536; maxCacheSize: 58,982; cacheShrinkThreshold: 10,000 
21 Dec 2021 16:53:06,308 [main] INFO  (XQueryPool.java [configure]:107) - QueryPool: size = 128; maxQueryStackSize = 64 
21 Dec 2021 16:53:06,310 [main] INFO  (QuartzSchedulerImpl.java [getQuartzProperties]:143) - Successfully loaded Quartz Scheduler properties from: /exist/etc/quartz.properties 
21 Dec 2021 16:53:06,349 [main] INFO  (FileLock.java [release]:188) - Deleting lock file: /exist/etc/../data/dbx_dir.lck 
21 Dec 2021 16:53:06,349 [main] ERROR (BrokerPools.java [configure]:183) - Unable to initialize database instance 'exist': java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer; 
org.exist.EXistException: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
       at org.exist.storage.BrokerPool.initialize(BrokerPool.java:465) ~[exist.uber.jar:5.3.1]
       at org.exist.storage.BrokerPools.configure(BrokerPools.java:177) [exist.uber.jar:5.3.1]
       at org.exist.storage.BrokerPools.configure(BrokerPools.java:112) [exist.uber.jar:5.3.1]
       at org.exist.jetty.JettyStart.run(JettyStart.java:216) [exist.uber.jar:5.3.1]
       at org.exist.jetty.JettyStart.main(JettyStart.java:103) [exist.uber.jar:5.3.1]
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_275]
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_275]
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_275]
       at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_275]
       at org.exist.start.Main.invokeMain(Main.java:153) [exist.uber.jar:5.3.1]
       at org.exist.start.Main.runEx(Main.java:292) [exist.uber.jar:5.3.1]
       at org.exist.start.Main.run(Main.java:158) [exist.uber.jar:5.3.1]
       at org.exist.start.Main.main(Main.java:95) [exist.uber.jar:5.3.1]
Caused by: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
       at org.exist.storage.lock.FileLock.save(FileLock.java:240) ~[exist.uber.jar:5.3.1]
       at org.exist.storage.lock.FileLock.tryLock(FileLock.java:158) ~[exist.uber.jar:5.3.1]
       at org.exist.storage.lock.FileLockService.prepare(FileLockService.java:104) ~[exist.uber.jar:5.3.1]
       at org.exist.storage.BrokerPoolServicesManager.prepareServices(BrokerPoolServicesManager.java:181) ~[exist.uber.jar:5.3.1]
       at org.exist.storage.BrokerPool._initialize(BrokerPool.java:546) ~[exist.uber.jar:5.3.1]
       at org.exist.storage.BrokerPool.initialize(BrokerPool.java:451) ~[exist.uber.jar:5.3.1]
       ... 12 more
21 Dec 2021 16:53:06,353 [main] ERROR (JettyStart.java [run]:224) - configuration error: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer; 
org.exist.EXistException: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
       at org.exist.storage.BrokerPool.initialize(BrokerPool.java:465) ~[exist.uber.jar:5.3.1]
       at org.exist.storage.BrokerPools.configure(BrokerPools.java:177) ~[exist.uber.jar:5.3.1]
       at org.exist.storage.BrokerPools.configure(BrokerPools.java:112) ~[exist.uber.jar:5.3.1]
       at org.exist.jetty.JettyStart.run(JettyStart.java:216) [exist.uber.jar:5.3.1]
       at org.exist.jetty.JettyStart.main(JettyStart.java:103) [exist.uber.jar:5.3.1]
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_275]
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_275]
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_275]
       at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_275]
       at org.exist.start.Main.invokeMain(Main.java:153) [exist.uber.jar:5.3.1]
       at org.exist.start.Main.runEx(Main.java:292) [exist.uber.jar:5.3.1]
       at org.exist.start.Main.run(Main.java:158) [exist.uber.jar:5.3.1]
       at org.exist.start.Main.main(Main.java:95) [exist.uber.jar:5.3.1]
Caused by: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
       at org.exist.storage.lock.FileLock.save(FileLock.java:240) ~[exist.uber.jar:5.3.1]
       at org.exist.storage.lock.FileLock.tryLock(FileLock.java:158) ~[exist.uber.jar:5.3.1]
       at org.exist.storage.lock.FileLockService.prepare(FileLockService.java:104) ~[exist.uber.jar:5.3.1]
       at org.exist.storage.BrokerPoolServicesManager.prepareServices(BrokerPoolServicesManager.java:181) ~[exist.uber.jar:5.3.1]
       at org.exist.storage.BrokerPool._initialize(BrokerPool.java:546) ~[exist.uber.jar:5.3.1]
       at org.exist.storage.BrokerPool.initialize(BrokerPool.java:451) ~[exist.uber.jar:5.3.1]
       ... 12 more
org.exist.EXistException: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
       at org.exist.storage.BrokerPool.initialize(BrokerPool.java:465)
       at org.exist.storage.BrokerPools.configure(BrokerPools.java:177)
       at org.exist.storage.BrokerPools.configure(BrokerPools.java:112)
       at org.exist.jetty.JettyStart.run(JettyStart.java:216)
       at org.exist.jetty.JettyStart.main(JettyStart.java:103)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       at java.lang.reflect.Method.invoke(Method.java:498)
       at org.exist.start.Main.invokeMain(Main.java:153)
       at org.exist.start.Main.runEx(Main.java:292)
       at org.exist.start.Main.run(Main.java:158)
       at org.exist.start.Main.main(Main.java:95)
Caused by: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
       at org.exist.storage.lock.FileLock.save(FileLock.java:240)
       at org.exist.storage.lock.FileLock.tryLock(FileLock.java:158)
       at org.exist.storage.lock.FileLockService.prepare(FileLockService.java:104)
       at org.exist.storage.BrokerPoolServicesManager.prepareServices(BrokerPoolServicesManager.java:181)
       at org.exist.storage.BrokerPool._initialize(BrokerPool.java:546)
       at org.exist.storage.BrokerPool.initialize(BrokerPool.java:451)
       ... 12 more
 
 

Re: [Exist-open] Link error

[Roy W. <gar...@ya...>]

 Hi Joe,
http://exist-db.org/exist/apps/homepage/index.html
R.

    On Saturday, 18 December 2021, 14:37:09 GMT, Joe Wicentowski <jo...@gm...> wrote:  
 
 Hi Roy,
What is the URL of the page where you are seeing the wrong link?
Thanks,Joe
On Sat, Dec 18, 2021 at 9:13 AM Roy Walter via Exist-open <exi...@li...> wrote:

Link to latest stable  (5.3.1) going here:
https://github.com/eXist-db/exist/releases/tag/eXist-4.8.0
Thanks,Roy
_______________________________________________
Exist-open mailing list
Exi...@li...
https://lists.sourceforge.net/lists/listinfo/exist-open

-- 
Sent from my iPhone  

Re: [Exist-open] Link error

[Joe W. <jo...@gm...>]

Hi Roy,

What is the URL of the page where you are seeing the wrong link?

Thanks,
Joe

On Sat, Dec 18, 2021 at 9:13 AM Roy Walter via Exist-open <
exi...@li...> wrote:

> Link to latest stable  (5.3.1) going here:
>
> https://github.com/eXist-db/exist/releases/tag/eXist-4.8.0
>
> Thanks,
> Roy
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>
-- 
Sent from my iPhone

[Exist-open] Link error

[Roy W. <gar...@ya...>]

Link to latest stable  (5.3.1) going here:
https://github.com/eXist-db/exist/releases/tag/eXist-4.8.0
Thanks,Roy

Re: [Exist-open] eXide: Switch off automatic XML indenting when opening documents?

[Kevin B. <kev...@xp...>]

We implement a simple identity XSL that strips space before a checkin. We need to so this as we have contributors using many different tools and found it easier to fix automatically.KevinSent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: Vincent Neyt <vin...@gm...> Date: 12/17/21  12:40 AM  (GMT-08:00) To: Joe Wicentowski <jo...@gm...> Cc: exi...@li... Subject: Re: [Exist-open] eXide: Switch off automatic XML indenting when opening documents? Thank you very much.I'd like to make a suggestion: in a future version, please make indent=no the default serialization option for when a user opens an XML document. Users do not want the editor to make changes to a document when they open it. All of these newlines and extra whitespaces are harmful to the XML document, especially TEI/XML transcriptions with many many in-text nested tags.I've recently started using eXide as an editor for collaborators to use to make and revise their XML documents, and I'd estimate that in the past week about 30 documents, some of them very large, have been corrupted with extra whitespace that will need to be manually removed again. Simply by opening the document in eXide, making a small correction, and saving in eXide. This is quite a setback. I'm relieved we noticed this was happening quite early, but I probably should have noticed earlier.Sorry for cross-posting.Best wishes,VincentOn Thu, Dec 16, 2021 at 7:10 PM Joe Wicentowski <jo...@gm...> wrote:Hi Vincent,eXide v3.2.0 added fine-grained serialization preferences, including the ability to control indentation when opening an XML document in eXide. See the documentation on this at https://github.com/eXist-db/eXide/blob/develop/docs/docs.md#options-for-xml-documents-loaded-from-the-database.I've also posted a screenshot of the serialization portion of the preferences to the issue that you cross-posted:  https://github.com/eXist-db/eXide/issues/400#issuecomment-996043866JoeOn Thu, Dec 16, 2021 at 2:41 AM Vincent Neyt <vin...@gm...> wrote:Hello list,Where in the eXide code can I switch off the "auto-indent" feature that happens when you open an XML document in eXide?When I open a document formatted like this:<emptyTemplate>This is an ex<del>e</del><add>a</add>mple.</emptyTemplate>eXide will automatically insert hard returns and spaces:<emptyTemplate>This is an ex<del>e</del>
    <add>a</add>mple.</emptyTemplate>
Where can I change the code to prevent this from happening, and to make eXide open the documents as they are instead of automatically formatting them and indenting nested tags?It took me a while to notice this was happening, and it will take many hours of manual work to correct all of the errors (by way of unwanted extra whitespace) that have crept into my project's XML transcriptions because of this.best,Vincent Neyt
_______________________________________________
Exist-open mailing list
Exi...@li...
https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-open] URGENT: Log4j 2.15.0 still affected by RCE

[Omar S. <Oma...@oe...>]

Thanks for these instructions!

Just two additions:

Please remember that the 4.x series broke binary compatibility of the 
database files with 4.4.0. That means you can only do a quick update 
without backup and restore from 3.0 to 4.3.1.
After that you will most probably will need to do a dump and restore 
when upgrading.

I co-maintain a repository meant for building exist container images 
from source. Maybe you can get some inspirations there for how to do 
this with your source.
https://github.com/acdh-oeaw/docker-tools-environments/tree/master/existdb4x
Due to the broken binary compatibility mentioned above this builds a 
patched version of 4.3.1.

We upgraded log4j2 in several exist-db versions and nothing bad happened.
They are in $EXIST_HOME/exist/lib/core/
So you can give that a try and replace them in your instance.

If you run a security scanner like grype it may still report the 
vulnerability as there is a log4j1 to log4j2 translation jar also in 
/opt/exist/lib/user/.
It is harmless itself but may hurt visibilty of instances that still 
need to be patched.

I also maintain a patched container image for 5.3.0 and 5.2.0
These images are also different in the JRE they use (11) and the GC 
(Shenandoah). It is easy to change the latter if you don't trust it.
https://hub.docker.com/r/acdhch/existdb/tags


Am 17.12.2021 um 15:21 schrieb Juri Leino:
> This also to the recently released versions of eXist-DB (5.3.1 and 4.8.0).
>
> It is good advise to do one of the following:
>
> *1. Upgrade to log4j 2.16.0*
>
>
> Or *2. Remove the JNDI lookup class *
>
>
> Stay safe,
> Juri
Best regards

-- 
Mag. Ing. Omar Siam
Austrian Center for Digital Humanities and Cultural Heritage
Österreichische Akademie der Wissenschaften | Austrian Academy of Sciences
Stellvertretende Behindertenvertrauensperson | Deputy representative for disabled persons
Wohllebengasse 12-14, 1040 Wien, Österreich | Vienna, Austria
T: +43 1 51581-7295
oma...@oe...  |www.oeaw.ac.at/acdh

[Exist-open] URGENT: Log4j 2.15.0 still affected by RCE

[Juri L. <ju...@ex...>]

This also to the recently released versions of eXist-DB (5.3.1 and 4.8.0).

It is good advise to do one of the following:

*1. Upgrade to log4j 2.16.0*

- navigate to the exist home directory of your instance
- remove all files whose names match log4j-*.jar in the lib directory (5 in
total)

rm lib/log4j-*.jar

- replace them with their version 2.16.0 equivalent

You can download them one by one

https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-jul/2.16.0/log4j-jul-2.16.0.jar
https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-jcl/2.16.0/log4j-jcl-2.16.0.jar
https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.16.0/log4j-core-2.16.0.jar
https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.16.0/log4j-api-2.16.0.jar
https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-slf4j-impl/2.16.0/log4j-slf4j-impl-2.16.0.jar

Or bundled https://logging.apache.org/log4j/2.x/download.html

Adjust <version> and <relativePath> for those 5 dependencies in
etc/client.xml, etc/startup.xml and etc/launcher.xml

Here is an example

      <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-api</artifactId>
        <version>2.16.0</version>
        <relativePath>log4j-api-2.16.0.jar</relativePath>
      </dependency>

- restart existdb



Or *2. Remove the JNDI lookup class *

- Navigate to your exist home folder
- run

zip -q -d lib/log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class

- restart your existdb instance

Sources:

JNDI Localhost bypass
https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/#update-the-localhost-bypass-was-discovered



Stay safe,
Juri

Re: [Exist-open] eXide: Switch off automatic XML indenting when opening documents?

[Vincent N. <vin...@gm...>]

Thank you very much.

I'd like to make a suggestion: in a future version, please make indent=no
the default serialization option for when a user opens an XML document.
Users do not want the editor to make changes to a document when they open
it. All of these newlines and extra whitespaces are harmful to the XML
document, especially TEI/XML transcriptions with many many in-text nested
tags.

I've recently started using eXide as an editor for collaborators to use to
make and revise their XML documents, and I'd estimate that in the past week
about 30 documents, some of them very large, have been corrupted with extra
whitespace that will need to be manually removed again. Simply by opening
the document in eXide, making a small correction, and saving in eXide. This
is quite a setback. I'm relieved we noticed this was happening quite early,
but I probably should have noticed earlier.

Sorry for cross-posting.

Best wishes,
Vincent




On Thu, Dec 16, 2021 at 7:10 PM Joe Wicentowski <jo...@gm...> wrote:

> Hi Vincent,
>
> eXide v3.2.0 added fine-grained serialization preferences, including the
> ability to control indentation when opening an XML document in eXide. See
> the documentation on this at
> https://github.com/eXist-db/eXide/blob/develop/docs/docs.md#options-for-xml-documents-loaded-from-the-database
> .
>
> I've also posted a screenshot of the serialization portion of the
> preferences to the issue that you cross-posted:
>
>   https://github.com/eXist-db/eXide/issues/400#issuecomment-996043866
>
> Joe
>
> On Thu, Dec 16, 2021 at 2:41 AM Vincent Neyt <vin...@gm...>
> wrote:
>
>> Hello list,
>>
>> Where in the eXide code can I switch off the "auto-indent" feature that
>> happens when you open an XML document in eXide?
>>
>> When I open a document formatted like this:
>>
>> <emptyTemplate>This is an ex<del>e</del><add>a</add>mple.</emptyTemplate>
>>
>> eXide will automatically insert hard returns and spaces:
>>
>> <emptyTemplate>This is an ex<del>e</del>
>>     <add>a</add>mple.</emptyTemplate>
>>
>> Where can I change the code to prevent this from happening, and to make
>> eXide open the documents as they are instead of automatically formatting
>> them and indenting nested tags?
>>
>> It took me a while to notice this was happening, and it will take many
>> hours of manual work to correct all of the errors (by way of unwanted extra
>> whitespace) that have crept into my project's XML transcriptions because of
>> this.
>>
>> best,
>> Vincent Neyt
>> _______________________________________________
>> Exist-open mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-open
>>
>

Re: [Exist-open] eXide: Switch off automatic XML indenting when opening documents?

[Joe W. <jo...@gm...>]

Hi Vincent,

eXide v3.2.0 added fine-grained serialization preferences, including the
ability to control indentation when opening an XML document in eXide. See
the documentation on this at
https://github.com/eXist-db/eXide/blob/develop/docs/docs.md#options-for-xml-documents-loaded-from-the-database
.

I've also posted a screenshot of the serialization portion of the
preferences to the issue that you cross-posted:

  https://github.com/eXist-db/eXide/issues/400#issuecomment-996043866

Joe

On Thu, Dec 16, 2021 at 2:41 AM Vincent Neyt <vin...@gm...> wrote:

> Hello list,
>
> Where in the eXide code can I switch off the "auto-indent" feature that
> happens when you open an XML document in eXide?
>
> When I open a document formatted like this:
>
> <emptyTemplate>This is an ex<del>e</del><add>a</add>mple.</emptyTemplate>
>
> eXide will automatically insert hard returns and spaces:
>
> <emptyTemplate>This is an ex<del>e</del>
>     <add>a</add>mple.</emptyTemplate>
>
> Where can I change the code to prevent this from happening, and to make
> eXide open the documents as they are instead of automatically formatting
> them and indenting nested tags?
>
> It took me a while to notice this was happening, and it will take many
> hours of manual work to correct all of the errors (by way of unwanted extra
> whitespace) that have crept into my project's XML transcriptions because of
> this.
>
> best,
> Vincent Neyt
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

[Exist-open] [ANN] eXist-db 4.8.0 and 5.3.1 released

[Adam R. <ad...@ex...>]

Dear eXist-db users,

We have recently published eXist-db 4.8.0 and 5.3.1. These are each
intended as small hot-fixes to eXist-db 4.7.1 and 5.3.0 respectively.

They were produced to offer a solution to the "log4jshell" security
vulnerability that was identified earlier this week as CVE-2021-44228.

You can download these here:

1. https://github.com/eXist-db/exist/releases/tag/eXist-4.8.0
2. https://github.com/eXist-db/exist/releases/tag/eXist-5.3.1

Enjoy!

Thanks. Adam.

--
Adam Retter

eXist Core Developer
{ United Kingdom }
ad...@ex...

Re: [Exist-open] log4j2 vulnerability

[Dannes W. <di...@ex...>]

For 471 it is possible to just replace jars ;
For 5x it is more complex 

> On 15 Dec 2021, at 16:48, Josef Wetzel UL via Exist-open <exi...@li...> wrote:
> 
> - Replace the actual jars of log4j2 with the jars of log4j2 version 2.16, can I simply replace these jars in an eXist-db-install (e.g. eXist-db-4.7.1)?

Re: [Exist-open] log4j2 vulnerability

[Omar S. <Oma...@oe...>]

Hi all,

Am 16.12.2021 um 09:39 schrieb Josef Wetzel UL via Exist-open:
> Hi Pietro
>
> I think this procedure corresponds fully to Apaches recommendation and 
> should work as expected. Replacing the jars is maybe not completely 
> satisfying.

Sorry, but this changed yesterday. Apache now explicitly recommends 
replaceing the log4j 2 jars with 2.16.0. It seems there are ways to 
exploit this that do not rely on JNDI.
https://logging.apache.org/log4j/2.x/

The solution on MacOS is quite similar with really replacing the jars I 
think:

Got into your App package eXist-db.app/Contents/Java and replace the 
log4j jars with those of the 2.16.0 binary distribution from Apache.

>
> Josef

If you don't use MacOS as your public server OS you probably can opt to 
leave exist-db alone because you probably don't compromise your own 
development machine.
But the choice here is a bit uncertain. Maybe some malicious code will 
find exist and use it if unpatched.

If you install exist-db on a server like on a dev machine you can use 
pretty much the same steps there. If you use containers >= 5.0.0 on the 
server it is very different because they work with one uber jar und you 
don't see the individual jars anymore.

Best regards

-- 
Mag. Ing. Omar Siam
Austrian Center for Digital Humanities and Cultural Heritage
Österreichische Akademie der Wissenschaften | Austrian Academy of Sciences
Stellvertretende Behindertenvertrauensperson | Deputy representative for disabled persons
Wohllebengasse 12-14, 1040 Wien, Österreich | Vienna, Austria
T: +43 1 51581-7295
oma...@oe... | www.oeaw.ac.at/acdh

Re: [Exist-open] log4j2 vulnerability

[Josef W. UL <jwe...@hi...>]

Hi Pietro

I had the same problem. I hat to go to the location, where my eXist-5.2 
mac app is stored. There I could do the following:

ls -al eXist-db.app/Contents/Java

And then move to the Java directory:

cd eXist-db.app/Contents/Java

Here I could enter the recommended command to remove the JNDI lookup 
class from log4j-core-*:

sudo zip -q -d log4j-core-*.jar 
org/apache/logging/log4j/core/lookup/JndiLookup.class

This runs without error message and leaves the log4j-core*.jar with the 
actual modification date and time. I think one has to reset ownership 
with chown.

I think this procedure corresponds fully to Apaches recommendation and 
should work as expected. Replacing the jars is maybe not completely 
satisfying.

On another installation in Debian Linux the same procedure left 
eXist-4.7.1 in a properly working state. All logs continued to work as 
before.

Hope this helps, greetings

Josef

On 16.12.21 07:53, Pietro Liuzzo wrote:

> Thanks!
>
> I tried both and I stumbled upon the fact that there seem to be no 
> $EXIST_HOME set on my computer.
>
> This command, run from several locations, using find with several 
> context always gives me the same „nothing to do“ result.
>
> So, I gave up and I tried another way. I am not sure that it is an 
> admissible thing to do, neither that it works, that is why I am 
> sharing it, i.e. for sanity check since. What I am entirely sure about 
> is that I do not know what I am doing...
>
> After patching the log4j.xml as recommended, what I did on my MacBook 
> 10.16 with java 1.8.0_311 to test a workaround, and I would like to 
> try to replicate on server was
>
>   * download log4j 2.16 and unpack it
>   * open exist-db.app/Contents/Java replace the five log4j*.jar (2.13)
>     with the ones from the downloaded new version (2.16)
>   * open exist-db.app/Contents with an editor, search the entire
>     folder and replace every instance of 2.13 with 2.16 (all 94
>     instances found are related to log4j)
>
> I then started my exist 5.2 and everything seems to be working 
> normally. While I hope I have „manually upgraded log4j to version 
> 2.16". If that did what I wanted it to do, I am really not sure…
>
> If that is a possibility, I would like to replicate it on the server… 
> can anyone tell me if this is OK?
>
> all best
>
>> Am 15.12.2021 um 16:59 schrieb Peter Stadler 
>> <st...@we...>:
>>
>> Just for the record/convenience, I do a `find` first to take care of 
>> the different paths:
>> find ${EXIST_HOME} -name log4j-core-*.jar -exec zip -q -d {} 
>> org/apache/logging/log4j/core/lookup/JndiLookup.class \;
>>
>> Best
>> Peter
>>
>>> Am 15.12.2021 um 15:54 schrieb Clark, Ash <as....@no...>:
>>>
>>> Hi Pietro,
>>>
>>> You may need to be in EXIST_HOME/lib to run the command for removing 
>>> the JNDI class. Sorry for the omission!
>>>
>>> ~Ash
>>> From: Pietro Liuzzo <pie...@gm...>
>>> Sent: Wednesday, December 15, 2021 2:16 AM
>>> To: Clark, Ash <as....@no...>
>>> Cc: Mathias Göbel <go...@su...>; exist-open 
>>> <exi...@li...>
>>> Subject: Re: [Exist-open] log4j2 vulnerability
>>>
>>> Thanks!
>>>
>>> I have tried to do this as well but I am told that there is nothing 
>>> to do.
>>> perhaps the location of that class depends on the system?
>>>
>>> all best
>>> Pietro
>>>
>>> Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
>>> cel (DE): +49 (0) 176 61 000 606
>>> Skype: pietro.liuzzo (Quingentole)
>>> ORCID: https://orcid.org/0000-0001-5714-4011
>>> Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo
>>>
>>>
>>>
>>>
>>>
>>>
>>>> Il giorno 14 dic 2021, alle ore 22:27, Clark, Ash 
>>>> <as....@no...> ha scritto:
>>>>
>>>> zip -q -d log4j-core-*.jar 
>>>> org/apache/logging/log4j/core/lookup/JndiLookup.class
>>>
>>> _______________________________________________
>>> Exist-open mailing list
>>> Exi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/exist-open
>>
>
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

[Exist-open] eXide: Switch off automatic XML indenting when opening documents?

[Vincent N. <vin...@gm...>]

Hello list,

Where in the eXide code can I switch off the "auto-indent" feature that
happens when you open an XML document in eXide?

When I open a document formatted like this:

<emptyTemplate>This is an ex<del>e</del><add>a</add>mple.</emptyTemplate>

eXide will automatically insert hard returns and spaces:

<emptyTemplate>This is an ex<del>e</del>
    <add>a</add>mple.</emptyTemplate>

Where can I change the code to prevent this from happening, and to make
eXide open the documents as they are instead of automatically formatting
them and indenting nested tags?

It took me a while to notice this was happening, and it will take many
hours of manual work to correct all of the errors (by way of unwanted extra
whitespace) that have crept into my project's XML transcriptions because of
this.

best,
Vincent Neyt

Re: [Exist-open] log4j2 vulnerability

[Pietro L. <pie...@gm...>]

Thanks!

I tried both and I stumbled upon the fact that there seem to be no $EXIST_HOME set on my computer. 

This command, run from several locations, using find with several context always gives me the same „nothing to do“ result. 

So, I gave up and I tried another way. I am not sure that it is an admissible thing to do, neither that it works, that is why I am sharing it, i.e. for sanity check since. What I am entirely sure about is that I do not know what I am doing...

After patching the log4j.xml as recommended, what I did on my MacBook 10.16 with java 1.8.0_311 to test a workaround, and I would like to try to replicate on server was 
download log4j 2.16 and unpack it
open exist-db.app/Contents/Java replace the five log4j*.jar (2.13) with the ones from the downloaded new version (2.16)
open exist-db.app/Contents with an editor, search the entire folder and replace every instance of 2.13 with 2.16 (all 94 instances found are related to log4j)
I then started my exist 5.2 and everything seems to be working normally. While I hope I have „manually upgraded log4j to version 2.16". If that did what I wanted it to do, I am really not sure… 

If that is a possibility, I would like to replicate it on the server… can anyone tell me if this is OK?

all best

> Am 15.12.2021 um 16:59 schrieb Peter Stadler <st...@we...>:
> 
> Just for the record/convenience, I do a `find` first to take care of the different paths:
> find ${EXIST_HOME} -name log4j-core-*.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;
> 
> Best
> Peter
> 
>> Am 15.12.2021 um 15:54 schrieb Clark, Ash <as....@no...>:
>> 
>> Hi Pietro,
>> 
>> You may need to be in EXIST_HOME/lib to run the command for removing the JNDI class. Sorry for the omission!
>> 
>> ~Ash
>> From: Pietro Liuzzo <pie...@gm...>
>> Sent: Wednesday, December 15, 2021 2:16 AM
>> To: Clark, Ash <as....@no...>
>> Cc: Mathias Göbel <go...@su...>; exist-open <exi...@li...>
>> Subject: Re: [Exist-open] log4j2 vulnerability
>> 
>> Thanks!
>> 
>> I have tried to do this as well but I am told that there is nothing to do.
>> perhaps the location of that class depends on the system?
>> 
>> all best
>> Pietro
>> 
>> Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
>> cel (DE): +49 (0) 176 61 000 606
>> Skype: pietro.liuzzo (Quingentole)
>> ORCID: https://orcid.org/0000-0001-5714-4011
>> Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo
>> 
>> 
>> 
>> 
>> 
>> 
>>> Il giorno 14 dic 2021, alle ore 22:27, Clark, Ash <as....@no...> ha scritto:
>>> 
>>> zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
>> 
>> _______________________________________________
>> Exist-open mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-open
> 

Re: [Exist-open] log4j2 vulnerability

[Michael W. <wes...@ja...>]

Thank you, Ash.

Logs go back to the end of November with neither jndi nor jdni (ignoring
case). :-)

I guess there are too many possible attack payloads to specify any single
thing to look for if one was compromised. The logs do provide some
reassurance.

Thank you again.

Take care.


2021年12月16日(木) 0:04 Clark, Ash <as....@no...>:

> Hi Michael,
>
> Here’s a blog post that explains how the exploit works and an example log
> message:
>
> https://www.lunasec.io/docs/blog/log4j-zero-day/#how-the-exploit-works
>
> I did a case insensitive search for `jdni` in my own logs (found nothing,
> thankfully). I’m positive there are other tells that an expert would be
> able to seek out.
>
> ~Ash
>
> ------------------------------
> *From:* Michael Westbay <wes...@ja...>
> *Sent:* Wednesday, December 15, 2021 3:16 AM
> *To:* Pietro Liuzzo <pie...@gm...>
> *Cc:* Clark, Ash <as....@no...>; exist-open <
> exi...@li...>
> *Subject:* Re: [Exist-open] log4j2 vulnerability
>
> Extracting from the JAR file worked for me with both
> the log4j-core-2.14.1.jar included with eXist 5.3.0 and with
> the log4j-core-2.15.0.jar that I downloaded.
>
> What I want to know is what are the signs of infection? I doubt if my
> systems are prime targets, but if someone was doing an automated spray to
> see what caught, what should I be looking for? I remember the PUT
> vulnerability a few years ago and found some attempts at PUTing PHP files
> on my server. They went into the eXist database at the /db root where they
> weren't effective. But their presence had me on edge.
>
>
> 2021年12月15日(水) 16:17 Pietro Liuzzo <pie...@gm...>:
>
> Thanks!
>
> I have tried to do this as well but I am told that there is nothing to do.
> perhaps the location of that class depends on the system?
>
> all best
> Pietro
>
> Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
> cel (DE): +49 (0) 176 61 000 606
> Skype: pietro.liuzzo (Quingentole)
> ORCID: https://orcid.org/0000-0001-5714-4011
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Forcid.org%2F0000-0001-5714-4011&data=04%7C01%7Cas.clark%40northeastern.edu%7Cadb8e49703274242b50c08d9bfa34c0e%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751530960132722%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AYp6IgnAXOM60N%2F3sjNnvBQNsmY2HsdcQoci3Socs34%3D&reserved=0>
> Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Funi-hamburg.academia.edu%2FPietroMariaLiuzzo&data=04%7C01%7Cas.clark%40northeastern.edu%7Cadb8e49703274242b50c08d9bfa34c0e%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751530960142680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yq9cIl6fTmCCST9XkkHAtL5Xjpkc1kFe2xdrvxyqnVE%3D&reserved=0>
>
>
>
>
>
>
> Il giorno 14 dic 2021, alle ore 22:27, Clark, Ash <
> as....@no...> ha scritto:
>
> zip -q -d log4j-core-*.jar
> org/apache/logging/log4j/core/lookup/JndiLookup.class
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fexist-open&data=04%7C01%7Cas.clark%40northeastern.edu%7Cadb8e49703274242b50c08d9bfa34c0e%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751530960142680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AaQYRaILZh%2F98fAvQFA%2BGT4EgL3VshfjGI5Fx7098ZY%3D&reserved=0>
>
>
>
> --
> Michael Westbay
> Writer/System Administrator
> http://www.japanesebaseball.com/
> <https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.japanesebaseball.com%2F&data=04%7C01%7Cas.clark%40northeastern.edu%7Cadb8e49703274242b50c08d9bfa34c0e%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751530960152635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IVS%2BYA5SSHOpNUfAoqI2uJOGDSwNdBp8zNxxtlHkMbs%3D&reserved=0>
>


-- 
Michael Westbay
Writer/System Administrator
http://www.japanesebaseball.com/

Re: [Exist-open] log4j2 vulnerability

[Peter S. <st...@we...>]

Just for the record/convenience, I do a `find` first to take care of the different paths:
find ${EXIST_HOME} -name log4j-core-*.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;

Best
Peter

> Am 15.12.2021 um 15:54 schrieb Clark, Ash <as....@no...>:
> 
> Hi Pietro,
> 
> You may need to be in EXIST_HOME/lib to run the command for removing the JNDI class. Sorry for the omission!
> 
> ~Ash
> From: Pietro Liuzzo <pie...@gm...>
> Sent: Wednesday, December 15, 2021 2:16 AM
> To: Clark, Ash <as....@no...>
> Cc: Mathias Göbel <go...@su...>; exist-open <exi...@li...>
> Subject: Re: [Exist-open] log4j2 vulnerability
> 
> Thanks!
> 
> I have tried to do this as well but I am told that there is nothing to do.
> perhaps the location of that class depends on the system?
> 
> all best
> Pietro
> 
> Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
> cel (DE): +49 (0) 176 61 000 606
> Skype: pietro.liuzzo (Quingentole)
> ORCID: https://orcid.org/0000-0001-5714-4011
> Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo
> 
> 
> 
> 
> 
> 
>> Il giorno 14 dic 2021, alle ore 22:27, Clark, Ash <as....@no...> ha scritto:
>> 
>> zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
> 
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-open] log4j2 vulnerability

[Josef W. UL <jwe...@hi...>]

Hi Omar
Thank you, I'll give it a try with eXist 4.7.1 soon.


On 15.12.21 16:52, Omar Siam wrote:
> Hi,
>
> I successfully replaced the jars in a exist 4.3.1 version which we use 
> several times. It worked so far without problems.
>
> Am 15.12.2021 um 16:30 schrieb Josef Wetzel UL via Exist-open:
>> Many Thanks to Adam (and others involved) for providing 5.3.1 so 
>> quickly!
>>
>> I use eXist-db 4.7.1 still in an active project. I think, I have the 
>> following alternatives:
>>
>> - Replace %m with %m{nolookups} in log4j2.xml (which I have done in 
>> all my installations) and which as of now seems not to be sufficient
>> - Replace the actual jars of log4j2 with the jars of log4j2 version 
>> 2.16, can I simply replace these jars in an eXist-db-install (e.g. 
>> eXist-db-4.7.1)?
>> - Wait for an updated version of eXist-db-4.7.1 (I could maybe myself 
>> update the source tree in github, if someone could instruct me 
>> briefly :-)).
>>
>> I need eXist-4.7.1 for at least a while, since my project takes 
>> advantage of Joern Turners (et.al.) betterForm package.
>>
>> Thanks
>>
>> Josef Wetzel
>>
> Best regards
>

Re: [Exist-open] log4j2 vulnerability

[Omar S. <Oma...@oe...>]

Hi,

I successfully replaced the jars in a exist 4.3.1 version which we use 
several times. It worked so far without problems.

Am 15.12.2021 um 16:30 schrieb Josef Wetzel UL via Exist-open:
> Many Thanks to Adam (and others involved) for providing 5.3.1 so quickly!
>
> I use eXist-db 4.7.1 still in an active project. I think, I have the 
> following alternatives:
>
> - Replace %m with %m{nolookups} in log4j2.xml (which I have done in 
> all my installations) and which as of now seems not to be sufficient
> - Replace the actual jars of log4j2 with the jars of log4j2 version 
> 2.16, can I simply replace these jars in an eXist-db-install (e.g. 
> eXist-db-4.7.1)?
> - Wait for an updated version of eXist-db-4.7.1 (I could maybe myself 
> update the source tree in github, if someone could instruct me briefly 
> :-)).
>
> I need eXist-4.7.1 for at least a while, since my project takes 
> advantage of Joern Turners (et.al.) betterForm package.
>
> Thanks
>
> Josef Wetzel
>
Best regards

-- 
Mag. Ing. Omar Siam
Austrian Center for Digital Humanities and Cultural Heritage
Österreichische Akademie der Wissenschaften | Austrian Academy of Sciences
Stellvertretende Behindertenvertrauensperson | Deputy representative for disabled persons
Wohllebengasse 12-14, 1040 Wien, Österreich | Vienna, Austria
T: +43 1 51581-7295
oma...@oe... | www.oeaw.ac.at/acdh

Re: [Exist-open] log4j2 vulnerability

[Josef W. UL <jwe...@hi...>]

Many Thanks to Adam (and others involved) for providing 5.3.1 so quickly!

I use eXist-db 4.7.1 still in an active project. I think, I have the 
following alternatives:

- Replace %m with %m{nolookups} in log4j2.xml (which I have done in all 
my installations) and which as of now seems not to be sufficient
- Replace the actual jars of log4j2 with the jars of log4j2 version 
2.16, can I simply replace these jars in an eXist-db-install (e.g. 
eXist-db-4.7.1)?
- Wait for an updated version of eXist-db-4.7.1 (I could maybe myself 
update the source tree in github, if someone could instruct me briefly :-)).

I need eXist-4.7.1 for at least a while, since my project takes 
advantage of Joern Turners (et.al.) betterForm package.

Thanks

Josef Wetzel


On 11.12.21 21:32, Juri Leino wrote:
> I believe everyone has heard about the critical vulnerability in 
> log4j2 at this point.
>
> Even if you did upgrade your Java version (later than JDK 8u191 for 
> Java 8) please consider additional actions to mitigate the log4j2 
> vulnerabilty (applies to all versions of exist 5):
>
> - navigate to the home folder of your exist instance (might be in 
> $EXIST_HOME)
>
> - open etc/log4j2.xml in a text editor and
>   replace _all occurrences_ of "%m" with "%m{noLookups}"
>
> - additionally or if the above cannot be applied for some reason run
>
> zip -q -d lib/log4j-core-*.jar 
> org/apache/logging/log4j/core/lookup/JndiLookup.class
>
> To remove the JndiLookup alltogether.
>
> The exist db must be restarted for these changes to take effect.
>
> Source: https://logging.apache.org/log4j/2.x/security.html
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-open] log4j2 vulnerability

[Clark, A. <as....@no...>]

Hi Pietro,

You may need to be in EXIST_HOME/lib to run the command for removing the JNDI class. Sorry for the omission!

~Ash
________________________________
From: Pietro Liuzzo <pie...@gm...>
Sent: Wednesday, December 15, 2021 2:16 AM
To: Clark, Ash <as....@no...>
Cc: Mathias G?bel <go...@su...>; exist-open <exi...@li...>
Subject: Re: [Exist-open] log4j2 vulnerability

Thanks!

I have tried to do this as well but I am told that there is nothing to do.
perhaps the location of that class depends on the system?

all best
Pietro

Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
cel (DE): +49 (0) 176 61 000 606
Skype: pietro.liuzzo (Quingentole)
ORCID: https://orcid.org/0000-0001-5714-4011<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Forcid.org%2F0000-0001-5714-4011&data=04%7C01%7Cas.clark%40northeastern.edu%7C2eb1ce62a2784ef8e6f408d9bf9ac92e%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751493786672648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HZhH7eXC4889BdwieyX1sVuXRB84GUXMwXUQPxFSQaw%3D&reserved=0>
Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Funi-hamburg.academia.edu%2FPietroMariaLiuzzo&data=04%7C01%7Cas.clark%40northeastern.edu%7C2eb1ce62a2784ef8e6f408d9bf9ac92e%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751493786672648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=s0hJ5cNM1mBSc5v%2Fa7SNm1HcvSHBPsl%2BRIbzFWsBdd4%3D&reserved=0>






Il giorno 14 dic 2021, alle ore 22:27, Clark, Ash <as....@no...<mailto:as....@no...>> ha scritto:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Re: [Exist-open] log4j2 vulnerability

[Clark, A. <as....@no...>]

Ugh. jndi​, not jdni.

I keep swapping those letters...
________________________________
From: Clark, Ash <as....@no...>
Sent: Wednesday, December 15, 2021 10:04 AM
To: Michael Westbay <wes...@ja...>; Pietro Liuzzo <pie...@gm...>
Cc: exist-open <exi...@li...>
Subject: Re: [Exist-open] log4j2 vulnerability

Hi Michael,

Here’s a blog post that explains how the exploit works and an example log message:

https://www.lunasec.io/docs/blog/log4j-zero-day/#how-the-exploit-works<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lunasec.io%2Fdocs%2Fblog%2Flog4j-zero-day%2F%23how-the-exploit-works&data=04%7C01%7Cas.clark%40northeastern.edu%7C8bfb6c354c4b4c4552dc08d9bfdc5ede%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751775537467065%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1a6FqthbFtw9SZkoMXId9maftkGZka4yWJyIMNE%2FqGw%3D&reserved=0>

I did a case insensitive search for `jdni` in my own logs (found nothing, thankfully). I’m positive there are other tells that an expert would be able to seek out.

~Ash

________________________________
From: Michael Westbay <wes...@ja...>
Sent: Wednesday, December 15, 2021 3:16 AM
To: Pietro Liuzzo <pie...@gm...>
Cc: Clark, Ash <as....@no...>; exist-open <exi...@li...>
Subject: Re: [Exist-open] log4j2 vulnerability

Extracting from the JAR file worked for me with both the log4j-core-2.14.1.jar included with eXist 5.3.0 and with the log4j-core-2.15.0.jar that I downloaded.

What I want to know is what are the signs of infection? I doubt if my systems are prime targets, but if someone was doing an automated spray to see what caught, what should I be looking for? I remember the PUT vulnerability a few years ago and found some attempts at PUTing PHP files on my server. They went into the eXist database at the /db root where they weren't effective. But their presence had me on edge.


2021年12月15日(水) 16:17 Pietro Liuzzo <pie...@gm...<mailto:pie...@gm...>>:
Thanks!

I have tried to do this as well but I am told that there is nothing to do.
perhaps the location of that class depends on the system?

all best
Pietro

Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
cel (DE): +49 (0) 176 61 000 606
Skype: pietro.liuzzo (Quingentole)
ORCID: https://orcid.org/0000-0001-5714-4011<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Forcid.org%2F0000-0001-5714-4011&data=04%7C01%7Cas.clark%40northeastern.edu%7C8bfb6c354c4b4c4552dc08d9bfdc5ede%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751775537477025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NIp%2FbORTHmxtoZijpfKPvFnv5SqC3HE91vHrm1Wo4VY%3D&reserved=0>
Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Funi-hamburg.academia.edu%2FPietroMariaLiuzzo&data=04%7C01%7Cas.clark%40northeastern.edu%7C8bfb6c354c4b4c4552dc08d9bfdc5ede%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751775537486978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=38ra3QVQSELBXVMxDUAwCkuHeWPH9INl9cKXdbFQqqU%3D&reserved=0>






Il giorno 14 dic 2021, alle ore 22:27, Clark, Ash <as....@no...<mailto:as....@no...>> ha scritto:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

_______________________________________________
Exist-open mailing list
Exi...@li...<mailto:Exi...@li...>
https://lists.sourceforge.net/lists/listinfo/exist-open<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fexist-open&data=04%7C01%7Cas.clark%40northeastern.edu%7C8bfb6c354c4b4c4552dc08d9bfdc5ede%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751775537486978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uGMn7nmcM06L7XCnlvIOVyKHfMycHrs89pIX%2BIo%2BEGE%3D&reserved=0>


--
Michael Westbay
Writer/System Administrator
http://www.japanesebaseball.com/<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.japanesebaseball.com%2F&data=04%7C01%7Cas.clark%40northeastern.edu%7C8bfb6c354c4b4c4552dc08d9bfdc5ede%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751775537496937%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CvWasB2OGbXRTH1UgW8waqdOLerGyAVOIXYuoEQBUDA%3D&reserved=0>

Re: [Exist-open] log4j2 vulnerability

[Clark, A. <as....@no...>]

Hi Michael,

Here’s a blog post that explains how the exploit works and an example log message:

https://www.lunasec.io/docs/blog/log4j-zero-day/#how-the-exploit-works

I did a case insensitive search for `jdni` in my own logs (found nothing, thankfully). I’m positive there are other tells that an expert would be able to seek out.

~Ash

________________________________
From: Michael Westbay <wes...@ja...>
Sent: Wednesday, December 15, 2021 3:16 AM
To: Pietro Liuzzo <pie...@gm...>
Cc: Clark, Ash <as....@no...>; exist-open <exi...@li...>
Subject: Re: [Exist-open] log4j2 vulnerability

Extracting from the JAR file worked for me with both the log4j-core-2.14.1.jar included with eXist 5.3.0 and with the log4j-core-2.15.0.jar that I downloaded.

What I want to know is what are the signs of infection? I doubt if my systems are prime targets, but if someone was doing an automated spray to see what caught, what should I be looking for? I remember the PUT vulnerability a few years ago and found some attempts at PUTing PHP files on my server. They went into the eXist database at the /db root where they weren't effective. But their presence had me on edge.


2021年12月15日(水) 16:17 Pietro Liuzzo <pie...@gm...<mailto:pie...@gm...>>:
Thanks!

I have tried to do this as well but I am told that there is nothing to do.
perhaps the location of that class depends on the system?

all best
Pietro

Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
cel (DE): +49 (0) 176 61 000 606
Skype: pietro.liuzzo (Quingentole)
ORCID: https://orcid.org/0000-0001-5714-4011<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Forcid.org%2F0000-0001-5714-4011&data=04%7C01%7Cas.clark%40northeastern.edu%7Cadb8e49703274242b50c08d9bfa34c0e%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751530960132722%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AYp6IgnAXOM60N%2F3sjNnvBQNsmY2HsdcQoci3Socs34%3D&reserved=0>
Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Funi-hamburg.academia.edu%2FPietroMariaLiuzzo&data=04%7C01%7Cas.clark%40northeastern.edu%7Cadb8e49703274242b50c08d9bfa34c0e%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751530960142680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yq9cIl6fTmCCST9XkkHAtL5Xjpkc1kFe2xdrvxyqnVE%3D&reserved=0>






Il giorno 14 dic 2021, alle ore 22:27, Clark, Ash <as....@no...<mailto:as....@no...>> ha scritto:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

_______________________________________________
Exist-open mailing list
Exi...@li...<mailto:Exi...@li...>
https://lists.sourceforge.net/lists/listinfo/exist-open<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fexist-open&data=04%7C01%7Cas.clark%40northeastern.edu%7Cadb8e49703274242b50c08d9bfa34c0e%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751530960142680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AaQYRaILZh%2F98fAvQFA%2BGT4EgL3VshfjGI5Fx7098ZY%3D&reserved=0>


--
Michael Westbay
Writer/System Administrator
http://www.japanesebaseball.com/<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.japanesebaseball.com%2F&data=04%7C01%7Cas.clark%40northeastern.edu%7Cadb8e49703274242b50c08d9bfa34c0e%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637751530960152635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IVS%2BYA5SSHOpNUfAoqI2uJOGDSwNdBp8zNxxtlHkMbs%3D&reserved=0>

Re: [Exist-open] log4j2 vulnerability

[Michael W. <wes...@ja...>]

Extracting from the JAR file worked for me with both
the log4j-core-2.14.1.jar included with eXist 5.3.0 and with
the log4j-core-2.15.0.jar that I downloaded.

What I want to know is what are the signs of infection? I doubt if my
systems are prime targets, but if someone was doing an automated spray to
see what caught, what should I be looking for? I remember the PUT
vulnerability a few years ago and found some attempts at PUTing PHP files
on my server. They went into the eXist database at the /db root where they
weren't effective. But their presence had me on edge.


2021年12月15日(水) 16:17 Pietro Liuzzo <pie...@gm...>:

> Thanks!
>
> I have tried to do this as well but I am told that there is nothing to do.
> perhaps the location of that class depends on the system?
>
> all best
> Pietro
>
> Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
> cel (DE): +49 (0) 176 61 000 606
> Skype: pietro.liuzzo (Quingentole)
> ORCID: https://orcid.org/0000-0001-5714-4011
> Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo
>
>
>
>
>
>
> Il giorno 14 dic 2021, alle ore 22:27, Clark, Ash <
> as....@no...> ha scritto:
>
> zip -q -d log4j-core-*.jar
> org/apache/logging/log4j/core/lookup/JndiLookup.class
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>


-- 
Michael Westbay
Writer/System Administrator
http://www.japanesebaseball.com/

Re: [Exist-open] log4j2 vulnerability

[Pietro L. <pie...@gm...>]

Thanks! 

I have tried to do this as well but I am told that there is nothing to do.
perhaps the location of that class depends on the system?

all best
Pietro

Pietro Maria Liuzzo (egli/lui,he/him,er/ihn)
cel (DE): +49 (0) 176 61 000 606
Skype: pietro.liuzzo (Quingentole)
ORCID: https://orcid.org/0000-0001-5714-4011
Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo






> Il giorno 14 dic 2021, alle ore 22:27, Clark, Ash <as....@no...> ha scritto:
> 
> zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class