Unattended updates

[purplesyringa]

This is not really a feature request, more of a conversation request to see if we (as the community) can come to a solution that satisfies everyone.

Is your feature request related to a problem? Please describe.

The problem is that there were quite a lot of vulnerabilities found in ZeroNet earlier and we'll probably have many of them in the future. Every time a vuln is found, we have to broadcast the fix; unfortunately, what we are able to do now is definitely unsafe:

1. We can just publish this as a commit; looks good at the first glance but people most likely won't update and we can't count on the fact that no one reads commit history;
2. We can hide the fix in some merge commit or something; it's less likely to be noticed compared to 1. but this is definitely not a permanent solution;
3. We can publish the fix immediately and add a big "update right now" button to ZeroHello; this immediately makes the vulnerability existence (and thus the exploit) obvious, and the people who didn't update in time will have a big problem.

While some of these solutions are applicable right now, they aren't permanent and will definitely stop working well when new people come to ZeroNet.

Describe the solution you'd like

We could allow users to enable unattended updates, say, in /Config (it should probably be enabled by default because those who don't check /Config are most likely too non-techy to understand the consequences of the vulnerability). Some updates would be marked as "security". People who have unattended updates enabled would be updated automatically; those who don't will be shown a big red button on ZeroHello (probably also change 0 icon for visibility? These are implementation details though). The update would be cryptographically signed. Whether only nofish will have to sign it or someone else as well is another question; say, lowering the required signature count would make ZeroNet more vulnerable to a single person's sudden decision, and increasing the count can make the vulnerability known before the fix is signed.

Describe alternatives you've considered

The ones in the first section? Hehe.

Additional context

inb4: Quite a lot of well-known operating systems do that. For example, Ubuntu and Debian have unattended-upgrades, Windows (oh well) does that too. ZeroNet is cross-platform and also uses ZeroUpdate for updates, not a central repository, so we can't count on the OS-specific stuff.

@anoadragon453 @filips123 @blurHY

[HelloZeroNet]

Seems good to me. We could add an "Auto update policy" configuration setting with values "Important security updates (default)", "Always up to date", "No auto update"

[purplesyringa]

What do you think about the required signer list?

[anoadragon453]

Updating requires restarting ZeroNet, which would suck if you're currently in the middle of something. How exactly would applying the update work? Notify the user that restarting ZeroNet would apply an update?

[purplesyringa]

I think it'd be better to implement some kind of in-place update without restart. The propagated hotfixes will probably be small enough so they won't cause a problem.

[filips123]

Or for more advanced updates that would need restart: Download update in background, notify user that restart is recommended, and replace/update ZeroNet on next startup.

[HelloZeroNet]

We could display a notification: "New critical update received, ZeroNet will restart in 59 minutes", "Restart now", "Delay update 6 hours" For less important, normal updates it would not restart by iteself, only on update on startup.

Update without restart also could work for some parts (there is a built-in support for that), but there is side-effects as it requires to modify in-memory objects and not every update is compatible with that. So I would avoid that.

What do you think about the required signer list?

It could work, but it requires properly, tested and implemented multisig support.

[purplesyringa]

We probably shouldn't show the fix to the public before it is completely signed (nor should we show that the process is going on) so I'd use some clearnet service (e.g. GitHub/GitLab + a bot) to develop the fix and sign it. So we already have all the signatures at the moment when we're publishing the fix. This means we could just hardcode the verification.

[styromaniac]

Make the (0) button flash red for security notification or have an [!] notification (toast) flash and give the scoop.

[purplesyringa]

@HelloZeroNet Can I assume that if Config.py contains some revision number, the bundled code will contain exactly the changes up to the commit which changed the revision number?

[HelloZeroNet]

So we already have all the signatures at the moment when we're publishing the fix. This means we could just hardcode the verification.

If we don't have multi-sig, then how do we distribute the version?

Can I assume that if Config.py contains some revision number, the bundled code will contain exactly the changes up to the commit which changed the revision number?

I always do increment the rev number, so I think yes.