Log In
Register
Forum
Topic RSS
14:03, EET
May 19, 2020
Offline
Hi everyone,
it seems like there are critical vulnerabilities regarding Apaches log4j library (see Link below). I would like to know if this could be an issue regarding Java-SDK even tho we use 1.2.x currently.
https://www.kaspersky.com/blog/log4shell-critical-vulnerability-in-apache-log4j/43124/
Kind regards
Christopher
14:45, EET
April 3, 2012
Offline
Hi,
We are aware of this.
SDK 1.x (and Stack that it used) uses Log4j version 1; so it is not affected by this, as log4j1 is not (per http://slf4j.org/log4shell.html, that being said log4j1 is at end of life) basically the log4shell is Log4j2 problem as far was we are aware. However, while investigating … at https://www.lunasec.io/docs/blog/log4j-zero-day/ it does also say:
“
log4j v1​
Version 1 of log4j is vulnerable to other RCE attacks, and if you’re using it you need to migrate to 2.15.0.
“
(we are not aware what these other RCE attacks would be however as of writing this)
So you might be affected by something else, but not this particular issue.
SDK 2.x-4.x by itself “cannot be affected”, as it uses slf4j. However, if you have used log4j2 as the slf4j implementation in your apps that use the SDK you would be (i.e. it is outside of the SDK so to say). SDK still uses log4j1 in the SDK samples, as that was the only Java 6 slf4j implementation (and the SDK even in 4.x is still 6+). But in the light of (https://www.lunasec.io/docs/blog/log4j-zero-day/ log4j1 mention) we probably have to start to use something else (slf4j-simple maybe, or finally move to Java 8+) in the future, but regardless the selection of logging library is on the SDK user in SDK 2+ world.
Meanwhile also writing this here (we will make a blog once we have time…). Our apps are affected (servers more, clients maybe if connected to a attacker’s UA Server) and the server side apps have just been released (though news about might take a bit of time to write, simulationserver can be updated via the auto-update or via Help->Check for Updates..). Client side apps will be updated as well once server apps release pipeline is fully done.
So in practice I would recommend you to update first to SDK 3.x (as the stack part is merged in 4.x and in different packages this is probably easier) and then to 4.x to be 100% safe.
14:53, EET
April 3, 2012
Offline
…aand sorry! I interpreted that as using SDK 1.2.x, but obiviously you mean the log4j1 version 1.2.x … but anyway, I sort of covered everything in the post, but to reiterate: Per the http://slf4j.org/log4shell.html log4j1 is NOT affected by this issue.
Per https://www.lunasec.io/docs/blog/log4j-zero-day/ there might be something ELSE (of what it would be, we are not aware, could also be an error; but currently no idea). Log4j1 is at end of life and at least per that page it is recommended to update to log4j2 2.15.0.
16:46, EET
April 3, 2012
Offline
OK, also updating this to here: blog is at https://www.prosysopc.com/blog/log4shell-attack/ and also updated as of today.
All our apps are patched (by updating the log4j2 version) in their latest versions. Everyone should update to those versions (or to any later versions, if reading this later).
We noticed a different CVE has been made vs. log4j1: https://access.redhat.com/security/cve/CVE-2021-4104. Quote from the page:
“
…
Note this flaw ONLY affects applications which are specifically configured to use JMSAppender, which is not the default, or when the attacker has write access to the Log4j configuration for adding JMSAppender to the attacker’s JMS Broker.
If the Log4j configuration is set TopicBindingName or TopicConnectionFactoryBindingName configurations allowing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228 Log4j 2.x, Log4j 1.x is vulnerable. However, the attack vector is reduced as it depends on having write access, which is not a standard configuration rather than untrusted user input. These are sufficient factors beyond the attacker’s control.
Applications using Log4j 1.x may be impacted if their configuration uses JNDI as described above.
…
“
Thus unless that specific condition hold (which should not be a default, at least SDK samples do not use it as they just use org.apache.log4j.ConsoleAppender and org.apache.log4j.RollingFileAppender + org.apache.log4j.RollingFileAppender in some older releases), log4j1 is not affected by CVE-2021-44228. I assume this is the https://www.lunasec.io/docs/blog/log4j-zero-day/ reference to log4j1. Also as noting here that this is still “SDK samples” not the SDK itself (though, version 1.x of the SDK used log4j1 directly, as mentioned in the above post)
In addition at https://logging.apache.org/log4j/1.2/ there is a link to: https://www.cvedetails.com/cve/CVE-2019-17571/ with the note “A security vulnerability, CVE-2019-17571 has been identified against Log4j 1. Log4j includes a SocketServer that accepts serialized log events and deserializes them without verifying whether the objects are allowed or not. This can provide an attack vector that can be expoited. Since Log4j 1 is no longer maintained this issue will not be fixed. Users are urged to upgrade to Log4j 2.”
However, for this one I do not know when the vulnerability would be in play i.e. when this ‘ServerSocket’ would be in use. https://nvd.nist.gov/vuln/detail/CVE-2019-17571 mentions “Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data.”
If “deserialization gadget” means e.g. java serialization, it is not a problem for the SDK itself, as we do not use java serialization (the OPC UA serialization process is custom logic). Of course some other parts (outside of our control, outside SDK) in apps SDK users have done might use java serialization (or whatever “deserialization gadget” means), but that is outside of the “SDK scope” anyway.
So, my personal take on this exactly right now as of writing this would be that it might be that log4j1 is not directly unsafe depending on the conditions, but regradless it probably should not be used anymore. Thus, we’ll work towards remove it from the SDK samples somehow in the next release (unless we get some new info).
17:42, EET
April 3, 2012
Offline
And continuing… blog post (https://www.prosysopc.com/blog/log4shell-attack/) is updated once again.
Per my current understanding another CVE-2021-45046 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 would not affect us, since our SDK for Java nor our applications use ‘MDC’ in code, but it is hard to say for certain (due to libs). Thus, we have released a second version of our apps just in case (note that Browser was already updated to log4j2 2.16.0 as it happened a bit later than the rest).
Anyway, apps use PatternLayout pattern=”%d{MM/dd/yyyy HH:mm:ss.SSS} %-5p [%t] %47c %3x – %m%n” i.e. does not include `Context Lookup` nor `Thread Context Map (MDC)` flags mentioned in the CVE text. Note that there is a difference in small x vs. large X in the layout. The small x is NDC (https://stackoverflow.com/questions/14134734/what-is-the-difference-between-log4js-ndc-and-mdc-facilities) is not mentioned in the CVE. Also, our SDK and applications also do not use `NDC` context either. However, as of writing we cannot say with 100% certainty a library used by our SDK or application would not use internally MDC/NDC. Also the CVE link does state “Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP lookups to localhost by default. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. “
Thus, I would recommend to update to the newer versions. Also updating to log4j2 2.16.0 if you are using it in your own apps (this is outside of the SDK etc. but just to note) is recommended.
…
…
Also … we basically just noted now: https://arstechnica.com/information-technology/2021/12/patch-fixing-critical-log4j-0-day-has-its-own-vulnerability-thats-under-exploit/. The first part of the article is about CVE-2021-45046. The second however is something else that links to https://www.praetorian.com/blog/log4j-2-15-0-stills-allows-for-exfiltration-of-sensitive-data/. So there could be a second problem with 2.15.0, but my understanding (per the link) would be that that too would be fixed by 2.16.0. Thus basically without knowing any better at this point I would recommend everyone to update to log4j2 2.16.0 as soon as possible.
16:36, EET
March 16, 2017
Offline
As the journey continues there is now the recommendation to update to log4j 2.17.0.
Do you plan to provide updates version of Browser, Simulation Server, etc the next days?
17:29, EET
April 3, 2012
Offline
Hi,
Per our understanding we are NOT affected by the thing 2.17.0 fixes. We do NOT use Context Lookup in the PatternLayout the applications create on first startup. And that is the only attack vector mentioned in https://logging.apache.org/log4j/2.x/security.html + https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105.
The blog post at https://www.prosysopc.com/blog/log4shell-attack/ now has updated info.
Thus (while not exactly up to me to decide this) we are not making new releases per current info. I managed to do beta versions before the analysis of the situation was done, so ask sales@prosysopc.com if needed, but per my understanding they are not needed. We’ll notify if the situation changes.
18:57, EEST
June 8, 2016
Offline
It would be helpful to remove Log4J1 completely in order to avoid any discussion (especially customers who emply scanning tools).
I find it way easier to remove the dependency then to argue that it’s “safe” (we may even have to legally declare that it’s “safe”, not an easy task).
As for now, this scanner https://github.com/hillu/local-log4j-vuln-scanner/releases reports a CVE.
Seems like prosys-opc-ua-java-sdk-codegen-standalone-4.4.2-326.jar has “unpack-dependencies” to Log4J1 in it and a sample references Log4J1.
C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk>c:\temp\local-log4j-vuln-scanner.exe C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary
local-log4j-vuln-scanner.exe – a simple local log4j vulnerability scanner
Checking for vulnerabilities: CVE-2019-17571, CVE-2021-44228, CVE-2021-45105
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib\jaxb-api-2.2.11.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib\org.eclipse.persistence.asm-2.7.4.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib\org.eclipse.persistence.core-2.7.4.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib\org.eclipse.persistence.moxy-2.7.4.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib\prosys-opc-ua-java-sdk-codegen-standalone-4.4.2-326.jar
indicator for vulnerable component found in C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib\prosys-opc-ua-java-sdk-codegen-standalone-4.4.2-326.jar (org/apache/log4j/net/SocketNode.class): SocketNode.class SocketNode class missing FilteredObjectInputStream patch CVE-2019-17571
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\maven-integration
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\maven-integration\maven-install-helper
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\maven-integration\maven-install-helper\data
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\maven-integration\maven-install-helper\data\prosys-opc-ua-java-sdk-codegen-maven-plugin-4.4.2-326.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-mandatory
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-mandatory\bcpkix-jdk15to18-1.64.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-mandatory\bcprov-jdk15to18-1.64.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-mandatory\slf4j-api-1.7.28.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-opc-https
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-opc-https\commons-codec-1.11.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-opc-https\commons-logging-1.2.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-opc-https\httpclient-4.5.10.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-opc-https\httpcore-4.4.12.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-opc-https\httpcore-nio-4.4.12.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-samples
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-samples\commons-cli-1.4.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-samples\log4j-1.2.17.jar
indicator for vulnerable component found in C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-samples\log4j-1.2.17.jar (org/apache/log4j/net/SocketNode.class): SocketNode.class log4j 1.2.17 CVE-2019-17571
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-samples\slf4j-log4j12-1.7.28.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\prosys-opc-ua-sdk-client-4.4.2-1266.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib-android
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib-android\bcpkix-jdk15on-1.58.0.0.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib-android\core-1.58.0.0.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib-android\prov-1.58.0.0.jar
Scan finished
Samples referencing Log4J1
$ grep log4j $(find . -name pom.xml)
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/sampleconsoleclient/pom.xml: slf4j-log4j12
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/sampleconsoleclient/pom.xml: log4j
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/sampleconsoleclient/pom.xml: log4j
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/sampleconsoleclient/pom.xml:
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/simpleclient/pom.xml: slf4j-log4j12
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/simpleclient/pom.xml: log4j
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/simpleclient/pom.xml: log4j
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/simpleclient/pom.xml:
10:35, EEST
April 3, 2012
Offline
Please note that you are replying to old things that have changed compared to the current release.
That above post is from December 20, 2021. The linked blog was updated multiple times: https://www.prosysopc.com/blog/log4shell-attack/, though it for the most parts was about 2.x.
The SDK version 4.4.2 is old. The current release version is 4.8.0. The samples were moved to use logback in https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html#version-4-7-0, that also has more text on the matter. Codegen internals were moved also to use reload4j (I do not remember exactly when, but at least in 4.8.0).
11:07, EEST
June 8, 2016
Offline
I always prefer to follow up on a thread rather than polluting with new threads.
Sorry that I did not catch the newest binaries. Samples from 4.8 look OK now.
But 4.8.0 the code generator still contains log4j1 classes though, the scanner tells us:
C:\Users\fnke>c:\temp\local-log4j-vuln-scanner.exe C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.8.0-25-client-server-binary
local-log4j-vuln-scanner.exe – a simple local log4j vulnerability scanner
Checking for vulnerabilities: CVE-2019-17571, CVE-2021-44228, CVE-2021-45105
…
indicator for vulnerable component found in C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.8.0-25-client-server-binary\codegen\commandline\lib\prosys-opc-ua-java-sdk-codegen-standalone-4.8.0-16.jar (org/apache/log4j/net/SocketNode.class): SocketNode.class SocketNode class missing FilteredObjectInputStream patch CVE-2019-17571
14:00, EEST
April 3, 2012
Offline
I guess I should have explained a bit more, reload4j is basically log4j1 with fixes, https://reload4j.qos.ch/:
“… the reload4j project is a fork of Apache log4j version 1.2.17 with the goal of fixing pressing security issues. It is intended as a drop-in replacement for log4j version 1.2.17. By drop-in, we mean the replacement of log4j.jar with reload4j.jar in your build with no source code changes in .java files being necessary. “
In Codegen 4.8.0 we used reload4j 1.2.18.1. That page listed above says that “CVE-2019-17571 (SocketServer) – fixed in 1.2.18.0 by hardening”, thus it is a bit odd it would show up with 1.2.18.1. Anyway, we are making an SDK 4.8.2 release during the next 2 weeks with the current plan. The included Codegen will have the latest reload4j.
P.S.
Basically in this tool we just use a ConsoleAppender programmatically (i.e. logging is not intended to be configured otherwise) as that allows equal output to our maven plugin.
15:33, EEST
June 8, 2016
Offline
Just to follow up on this, first of all THANKS for the fast update!
https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html#version-4-8-2 states
“No functional changes, but internals use now slf4j-simple when logging in the commandline mode.”
And I can confirm that the Scanner no longer has any findings!
c:\temp\local-log4j-vuln-scanner.exe C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.8.2-35-client-server-binary
…
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.8.2-35-client-server-binary\codegen\commandline\lib\prosys-opc-ua-java-sdk-codegen-standalone-4.8.2-20.jar
…
Scan finished
Great! 
18:12, EEST
April 3, 2012
Offline
Glad you like it. You were faster than me in making the reply here 🙂
That was the easiest way to solve it ‘now’ i.e. avoids the need to prove things.
So basically the “problem” is now outside of the SDK. We like might still need to comment on that, since we have suggested reload4j as log4j1 replacement.
We actually tried the scanner with latest reload4j (even the jar alone), but it did give the same output. Now then, since https://reload4j.qos.ch/ does say “CVE-2019-17571 (SocketServer) – fixed in 1.2.18.0 by hardening” either reload4j or the tool has a problem (or it is possible that I have misunderstood something or that we ran the scanner incorrectly). I could see a possiblity that the tool checks something like a sequence of bytecode, which might not exist 1:1 as reload4j is basically the log4j1 with fixes, thus like e.g. java compiler differences etc. could potentially produce a jar that still has the fix, but would not be detected by the scanner. Just a theory though, proving that might be something to be asked from reload4j or the scanner developers.
16:55, EEST
February 14, 2020
Offline
Hi,
Is it safe to use the com.prosysopc.ua-client-server-sdk.version 4.5.8-1468 that has the log4j-1.2.17.jar?
10:11, EEST
April 3, 2012
Offline
SDK only depends on slf4j, which is a facade for logging frameworks, the choice of an actual logging framework is the SDK users responsibility, see e.g. https://www.slf4j.org/manual.html for slf4j works, but it doesn’t list all logging frameworks that support it; e.g. log4j2 supports slf4j). In the past we used log4j1 in the samples, because it was one of the few slf4j supported frameworks to work on Java 6 (which is still the minimum for 4.x non-pubsub editions; pubsub editions need Java 8).
Thus, the actual question should be instead “should I still use log4j version 1”, for which the answer is: No. While according to memory it was not affected by https://www.prosysopc.com/blog/log4shell-attack/, it is EOL (end-of-life) and has other issues. SDK 4.7.0 moved to use logback classic as that too works on Java 6, but another option would have been reload4j, which I believe appeared just as we had changed to logback. And as noted before, this is only for the purposes of the samples (as they actually want to output the log to the console), nothing prevents making use of logback classic in e.g. SDK 4.5.8 as it just uses slf4j.
As to the SDK version itself, we have made numerous security fixes since 4.5.8 (https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html) and recommend everyone to update to the latest version.
P.S.
Technically we could have made the SDK samples require larger than the minimum Java version of the SDK itself, but we think it makes sense to keep the samples working on the same minimum, thus the choice of logging framework for the samples also had to work in Java 6.
Most Users Ever Online: 1919
Currently Online:
22 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 727
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1525
Posts: 6456
Newest Members:
ernestoportus31, martin123, rickie5305, shaylamaggard4, rickyjuarez140, jonathonmcintyre, fannielima, kristiewinkle8, rust, christamcdowallModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1028, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1
