Zeronet: Plugin for Git tracking site changes

Created on 10 Sep 2019  路  13Comments  路  Source: HelloZeroNet/ZeroNet

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

Even if the ZeroNet site is distributed across multiple users, its owner still has full site access. This means that he can delete/modify the site so others won't be able to use it. Or even worse, put some changes that could be malicious but very hard to spot.

Describe the solution you'd like

ZeroNet should have a plugin for tracking site changes in Git. That plugin should:

  • Ignore .git the directory from the remote site or store it on different location outside site directory (to prevent site owner from overwriting it)
  • Automatically commit every site change/update
  • Display UI options for managing repository and history (viewing the site at specific commit, comparing changes...)

Then, users could just view site changes directly in UI or alternatively view them in a dedicated Git program if they are more advanced.

Describe alternatives you've considered

A simple solution is to manually create a repository and manually commit all changes. However, this has a downside because the site owner will probably be able to overwrite local .git directory and it is also not so convenient to manually commit every change.

Additional context

This is based on ZeroTalk topic.

Most helpful comment

It's for tracking changes and prevent malware

It is for local tracking of changes. This means that user would have local Git repository to store changes, and this plugin would automatically commit/track changes instead of user.

Few examples why this could be useful. Owner of some popular site can delete it. If changes are tracked (even if locally), other user can restore and publish it. Or site can get malicious update. With tracking, user can spot this and identify when did the change happened.

All 13 comments

It would be a great addition, idea for configuration options per site:

  • Max file size to be added to archiving repo
  • Archived file types: all, only text (json, js, css, html, etc)
  • Create new commit every: minute, hour, day (new commit for every change probably would be inefficient)
  • Archive user content: yes/no
* Create new commit every: minute, hour, day (new commit for every change probably would be inefficient)

Are you kidding me ?

a downside because the site owner will probably be able to overwrite local .git directory

Do you think malicious user would keep git repo as you wish ?

Are you kidding me ?

Adding 1000 files as separate commits: 7 min, 29 MB .git
Adding 1000 files as 10 commits: 6 sec, 3.6 MB .git

I see no real reason to commit every change, but sure, that should be an option too.

@HelloZeroNet That's not the point, but content-addressing.

They should commit once or more each time they publish, obviously

The proposal is for a local git repository, other users won't be able to reach it, so not sure what you mean by content addressing

As @filips123 said:

That should give me an easy way to check changes when a zite owner updates.

I think it is a low probability that some "agency" would push out malware to a zite. They like to keep their exploits secret and sending one to every zite user in an update would effectively "blow" that exploit. Never know though...

It's for tracking changes and prevent malware

Posting an issue for a local repo makes no sense

Yes, the commit interval should also depend on the file type/location:

  • Commit immediately for non-user content
  • Commit every X for user content (if you want to do at all)

It's for tracking changes and prevent malware

It is for local tracking of changes. This means that user would have local Git repository to store changes, and this plugin would automatically commit/track changes instead of user.

Few examples why this could be useful. Owner of some popular site can delete it. If changes are tracked (even if locally), other user can restore and publish it. Or site can get malicious update. With tracking, user can spot this and identify when did the change happened.

why this could be useful.

No, site owners can directly modify the git repo instead of commiting

Yes, so

Ignore .git the directory from the remote site or store it on different location outside site directory (to prevent site owner from overwriting it)

Even better to store .git in different directory, so it could not be written by the site owner.

maybe auto sharable to site peers(so that everyone keeps git logs and shares to peers that ask for it)
redundancy and you dont need to count on yourself(sites are signed by owner so it's not possible to fake)
but begin realistic maybe this is just over engineering

Was this page helpful?
0 / 5 - 0 ratings

Related issues

BenMcLean picture BenMcLean  路  3Comments

yurivict picture yurivict  路  4Comments

imachug picture imachug  路  3Comments

blurHY picture blurHY  路  3Comments

unsystemizer picture unsystemizer  路  4Comments