Maybe use a release and not a weekly build?

I’m not the designer of this. I’ve also wondered. Maybe it’s just a practical choice to have something tough to attach your wires to.

Not sure what MH is but in bigger systems magnetically coupled centrifugal pumps are used afaik.

The roadmap defines 3 milestone batteries. The first is released, it’s a benchtop device that you can relatively easily build on your own. It has an electrode side of 2 x 2cm2. It does not store any significant amount of energy. The second one is being developed right now, it has a cell the size of a small 3d printer bed (20x20cm) and will also not store practical amounts of energy. It will hopefully prove though that they are on the right track and that they can scale it up. The third battery only will store significant amounts of energy but in only due end of the year (probably later).

Current Vanadium systems cost approx. 300-600$/kWh according to some random website I found. The goal of this project is to spread the knowledge about Redox Flow Batteries and in the medium term only make them commercially viable.

The aniolyth and catholyth are based on the Zink-Iodine system in an aqueous solution. There are a bunch of other systems though, each with their trade offs. The anode and cathode are both graphite felt in the case of the dev kit.

You need Polypropylen filament for printing, graphite felt as electrode, grafoil gasket material as bipolar plate, brass plate as current collector (cut by cnc), silicone gasket material and a measurment device like a potentiostat.

If you’re really interested, living somewhere in the EU, I could send you some stuff. I also have the chemicals in big quantities.

Don’t recommend using FTP. It’s a shitty old protocol that needs to die. Just use nginx or apache with directory listing enabled.

Just came here to say that the guy looks like a creep!

No, I rarely read the code of software I use, especially crypto code since thant’s not my thing. But good to know that you did. Thanks for your opinion.

Please tell us more about the actual security problems!

Agreed!

Be sure to use a passphrase

I don’t agree about the point concerning cost. You have additional training, update, maintenance and config burden. This on top of the burdon of using the VPN on top of ssh.

Ok, fair point. But why stop at one vpn? I choose to trust OpenSSH, but I agree that adding a secondary layer of security actually helps here. You basically multiply two very low probabilities to get an even lower one. The trade-off is that you add complexity. You now need to keep two services up to date, and correctly configured and access/key material distributed.

I’d only recommend this setup for projects with special security requirements.

And why exactly is that more secure?

Welcome to the internet! Your system will get probed. Make sure you run as little as possible services on open ports and only high quality ones such as OpenSSH. Don’t freak out because of your logs. You’re fine as long as your system is up to date and password login disabled! Don’t listen to the fail2ban or VPN crowd. Those are only snake oil.

A VPN is probably just as (in)secure as OpenSSH. There is no gain in complicating things. OpenSSH is probably one of the most well tested code for security around.

Public ssh is completely fine as long as you use key based auth only and keep your sshd up to date. Stop spreading bullshit.

Cookie banners are not mandated by GDPR. It’s an unrelated piece of law.

Welcome to the internet. You will be probed. Just as your immune system, or rather your body, is being probed.

Just don’t run broken software. The attackers will not be able to exploit you then. If they have zero day exploits, the WAF will most of the time not save you since they are often pretty easy to circumvent. WAFs are only effective against old and shitty exploits that should be patched anyways since ages.

Attack surface is made of the amount of code that is running when an attacker speaks to your machine. Imagine a freshly installed GNU/Linux distro with no services. The attack surface is minimal. All packages sent to your machine will only ever be touched by relatively limited parts of the linux TCP/IP stack and NIC driver. If you now run a web server, the package coes through the NIC driver, TCP/IP stack and web server. The surface is increased. Each of these parts of your machine’s code could have bugs. The more code your attacker’s packet runs through, the more opportunity to make your machine do things you don’t like.

If you want your machine to do what you like but not what random attackers like, it is therefore mandatory to have the least amount of attack surface, not adding code in contact with your attacker like a WAF or “antivirus”. Both these kind of softwares will inspect the packages coming in an take decisions (potentially bad ones) based on the content.

WAFs will mostly not help you since on a well configured and patched system, little known bugs are exposed. They might help you occasionally but usually patching the system is more effective. Of you want this to happen automatically, it’s entirely possible. Most os’s allow automatic unattended upgrades.