Zeronetwork content signing: ZeroNet UI or CLI?
· updated
ZeroNet gives site owners browser controls and a command-line route for signing content updates. The Python 3 sidebar offers separate Sign and Publish menu items and a combined Sign and publish button; the CLI can also sign alone, or request publication after successful signing with
--publish
. Both depend on the site’s private key to authorize its signed file manifest.
What the signed manifest establishes
The site’s
content.json
records file hashes and carries a signature created with its private key. ZeroNet uses Bitcoin cryptography to authenticate this manifest and SHA512 hashes to check file integrity. Peers verify the signed manifest before retrieving modified files, so the signature and file hashes connect the owner’s authorized update to the content peers receive.
Browser controls and terminal commands
Finish the edits in
data/[yoursiteaddress]
, complete any required asset build, and have the site’s signing key available. The command templates below use the Python 3 source-run form from the ZeroNet directory. Replace
SITE_ADDRESS
with your site’s address; it is a command placeholder.
| Operation | ZeroNet browser interface | Python 3 CLI |
|---|---|---|
| Access |
Open your site in the running client. Drag the top-right
0
control left to expose the site sidebar.
|
Run the relevant command from a terminal in the ZeroNet directory. |
| Sign locally | Choose Sign from the menu beside the sidebar’s Sign and publish button. |
python3 zeronet.py siteSign SITE_ADDRESS
|
| Publish an already signed revision | Choose Publish from the sidebar menu to publish without re-signing. |
python3 zeronet.py sitePublish SITE_ADDRESS
|
| Sign and request publication | Use the sidebar’s Sign and publish button; it requests publication only after signing succeeds. |
python3 zeronet.py siteSign SITE_ADDRESS --publish
. Publication is called only if signing succeeds.
|
Key lookup and manifest scope
The Python 3 signing implementation uses an explicitly supplied private-key argument first. If none is supplied, it looks for the site’s stored private key in the user’s data. When no key is found there, the console requests it with hidden input. Knowing the site’s public address is insufficient to sign its content.
The CLI targets the root
content.json
by default. Its
--inner_path
option selects a different manifest path within the site; the selected content still needs an authorized signing key.
In Python 3,
siteCreate
defaults to
use_master_seed=True
. A site’s private key created in that mode can be derived again from the master seed in
users.json
and its site address index. Setting
use_master_seed=False
creates an independent private key, so recovery then depends on retaining that key.
Example: Another edit after signing
For this hypothetical comparison, assume an owner has signed a revision of
index.html
, then edits that file again before publication. The matching site key remains available, and the owner is comparing the UI with the Python 3 CLI.
Using the sidebar’s Publish menu item alone or the CLI’s
sitePublish
would leave the manifest describing the earlier file contents. Its recorded hash would no longer match the edited file. The sidebar’s Sign and publish button re-signs the updated manifest before requesting publication. The equivalent combined CLI request is
python3 zeronet.py siteSign SITE_ADDRESS --publish
, replacing
SITE_ADDRESS
with the owner’s site address.
Successful re-signing produces a manifest matching the second revision, after which the combined command calls publication. If the file had remained unchanged after the first signing, switching interfaces alone would not require another signing pass. If signing fails, the combined command does not proceed to publication.
Build output and peer delivery are separate checks
The
ZeroNet site development tutorial #1
, published June 22, 2015, generates
js/all.js
from CoffeeScript in debug mode and describes compiler configuration differences between platforms. In that tutorial’s workflow, the generated file needs to exist before it can be included in the signed update. Publishing alone does not generate the missing bundle.
The Python 3 command
python3 zeronet.py siteVerify SITE_ADDRESS
checks manifest signatures and local site file hashes. It can help separate a signed-file mismatch from a publication problem. In the CLI’s standalone publication path, an unsuccessful push can produce a
No peers found
message. A valid local signature does not establish that another peer received the revision.
