smartnode VS Log4jAttackSurface

Fixed a bug that prevented nonce overrides from working with nonce 0. (https://github.com/rocket-pool/smartnode/issues/169)

node sync and node deposit will now make sure your Beacon Chain client is running on the chain that Rocket Pool expects it to be running on before letting you do a deposit (https://github.com/rocket-pool/smartnode/issues/158).

https://github.com/rocket-pool/smartnode/commits/testnet)

As many here who plan to operate a Rocketpool node probably know, the hot wallet required by the node software is a bit of a hot topic (pun intended). I opened an issue about this some time ago, and there are efforts underway by the developer team to solve this issue. Basically there will be a way to define a separate and locked withdrawal-address, where any withdrawals and RPL claims will be paid out to. This is an important security feature and should definitely be used for mainnet.

Relevant issue on github about this: https://github.com/rocket-pool/smartnode/issues/83

Checkout this link for knowing Log4j impact on manufacturers https://github.com/YfryTchsGD/Log4jAttackSurface

Just look at the currently ongoing insanity that is the log4j exploit, and how one single exploit has lead to a generic attack that can impact tons of companies. Imagine if a state decided to use voting machines, and someone found this style of exploit in the system.

Last week (Dec 9th) a major vulnerability was discovered in an open source logging project for Java called log4j. The vulnerability called Log4Shell would allow anyone to remotely run arbitrary code if they sent a message in the right format to the server. This is one of the worst attacks your system can be susceptible to and if you are interested in the technical details of the problem, here is an overview. The attack surface of Log4Shell is staggering, Amazon, Apple, Google, and the Apache Server are affected; it can almost not get bigger than this. We will see the real fallout of Log4Shell in the next weeks and months as right now servers worldwide are being scanned and prodded for this vulnerability.

Companies should verify they are not running any exposed Log4j Java code.  Here is a list of impacted 3rd party software for your reference.  If you find a server at risk, there are three potential ways to fix it as follows.

Looking for vendors/software on known lists like https://github.com/YfryTchsGD/Log4jAttackSurface

Blender ist nicht betroffen, #42

It does and was also affected by log4j.

Thanks, sure it isn't complete but it does contain some scary and surprising (at least when first reading, of course the really aren't) things like: https://github.com/YfryTchsGD/Log4jAttackSurface/blob/master/pages/UniFi.md

Apparently there's proof Steam along with many others are vulnerable.