Same here with a tiny twist: opensource and has a SHA512 mentioned somewhere in the repo that could be verified against whatever comes from the chrome appstore.
Very interesting. As one of the sufferers who struggled many times with setting up icinga2 with distributed (and SSL-Encrypted) monitoring, this automation takes a way a lot of the hassle. I think it is one step in the right direction. Reminds me with: https://mailinabox.email/
Nothing, it's just that the field is required for the function that's being used for the obfuscation. There's a lot of confused people in this thread. There are no mistakes made in the code, people are simply surprised that there's a mode in which Chromium that only obfuscates the keystore. Adding to the confusion is the fact that they're using an encryption library to do the obfuscation, so people see it and expect there to be real encryption going on and then see the dummy values in the important fields.
Using a salt ensures that an attacker cannot use pre-generated rainbow tables to crack something. If there is no salt, it is very fast to use rainbow table lookups for cracking.
The salt doesn't really need to be secret, as it is only there to make an attacker work harder. However, the existence of a known, hardcoded salt means that an attacker can generate rainbow tables specifically for cracking these cookies, so the salt isn't really useful here.
Salts are almost never secret, in fact; typically the salt is stored in plaintext alongside the hashed password. As you note, that's because the salt is supposed to defeat pre-computed rainbow tables, not be a shared secret.
