This page talks about Whonix ™ online hosting and (non-existing) testing infrastructure.
Hosted by mirror, downloadable using TLS.
Bug / Feature Request Tracker
(Works much better than github for a project at this scale.)
- community contribution friendly - flagged revisions - usable way to allow anonymous users to edit and to let admins review changes before these go live
- sufficient protection from spam
- seo - plugins provide good OpenGraph meta tags and meta settings (description, images)
- wiki templates
- expand buttons
- mobile view
- mediawiki markup text file backups (but are not easily importable)
- short and detailed buttons (probably not unique to mediawiki)
- does not look that great
- our mediawiki skin "foreground" looks better than usual mediawiki / wikipedia with the huge space wasting sidebar that does not have much useful content related to the wiki page being viewed
- still does not look great (but perhaps another mediawiki skin could solve that)
- the table of contents at the top may not be great? Perhaps a table of contents on the left or right side (???) would be better?
- too much white spaces everywhere
- offline documentation not solved - https://forums.whonix.org/t/offline-documentation-discussion
- translations not solved
- data base is binary (mysql) (requires mysql data base)
goals for new website
- flat file
- git based?
- prose.io (example) compatible?
- breadcrumbs navigation?
- CMS free?
- bootstrap based?
- mobile friendly
- illustrative images
- quick page load times
- footer links (legal, imprint)!
TODO: archival using httrack?
- cannot make complete backup - https://meta.discourse.org/t/how-to-backup-and-restore-a-whole-var-discourse-app-folder/152598
- backup restoration failing - https://meta.discourse.org/t/restore-problem-relation-theme-fields-does-not-exist/95500/7
- postgres database bugs - https://meta.discourse.org/t/restore-fails-could-not-create-unique-index/151380/20
- difficult to repair database - https://meta.discourse.org/t/a-basic-discourse-archival-tool/62614
- no archival - https://meta.discourse.org/t/a-basic-discourse-archival-tool/62614
- archival feature request #1 https://meta.discourse.org/t/print-long-topic-to-pdf-redux-again/44639/62
- archival feature request #2 https://meta.discourse.org/t/a-basic-discourse-archival-tool/62614/51
- feature request: Option to use flat/text backing files instead of SQL(Postgres) backend
- test websites:
- test website working example (mail): https://dane-test.had.dnsops.gov/server/dane_check.cgi?host=freebsd.org
- another website working example: https://dane.sys4.de/smtp/go6.si
- what happen to these screenshots?
- Firefox saying: Verified by: Let's Encrypt
- not yet supported by SSL Labs https://github.com/ssllabs/ssllabs-scan/issues/118
- letsencrypt vs DANE TLSA?
- DANE TLSA standalone?
- DANE TLSA update required, useful when?
The problem with regular Let’s Encrypt certificates
As you know, Let’s Encrypt certificates renew every 90 days. This is not a problem in itself, however, the standard procedure is to generate a new private key with each renewal and, thus, an entirely new public key also. This will necessarily change the hashed key value that would appear in our TLSA record meaning that we would have to remember to update our DNS records on each renewal otherwise the wrong key will be specified and no one will trust our site/server/application! We need to tell Let’s Encrypt to re-use our private key so that the public key hash value does NOT change – that way our DNS record remains valid across certificate renewals.
- todo reading:
drop-www vs yes-www
An ALIAS record will break DNSSEC on the bare domain (@), because @ A and @ AAAA responses will be missing the RRSIG records, which will break resolution on all resolvers.
Quote https://docs.gandi.net/en/domain_names/faq/dns_records.html (bold added)
A, AAAA, ALIAS (not yet supported with dnssec-enabled domains), CNAME, MX, NS, TXT, WKS, SRV, LOC, SPF, CAA, SSHFP, PTR, DNAME
Cloudflare - Note: Cloudflare use
CNAME Flattening. This is the same thing as an
Hide Server IP
Separate server/IP for e-mail required since it cannot be hidden by CDN.
To take advantage of Cloudflare’s performance and security benefits, we recommend you orange-cloud DNS records that handle HTTP traffic, including A, AAAA, and CNAME. However, do not orange-cloud A, AAAA, or CNAME records used to resolve MX records. For instance, if you have an MX record that points to mail.example.com as your mail server, orange-clouding the A record for mail.example.com will break your mail traffic.
However, there are times when some of your DNS records need to remain grey-clouded. For example: A, AAAA, or CNAME records used for mail traffic must not be orange-clouded because email routing won’t pass through Cloudflare's proxy. When you have to host multiple services (for example, a website and email) on the same physical server To mitigate this risk, we recommend that you: Host your email service in a server (in-house or external) that is different from your site’s origin server Analyze the impact of hosting multiple services on the same origin server in cases when having grey-clouded DNS records can’t be avoided Orange-cloud all records that share the same origin IP address as your root domain and can be safely proxied through Cloudflare
Use separate IP addresses for mail traffic and HTTP/HTTPS traffic. Cloudflare recommends using non-contiguous IPs from different IP ranges.
Compatible with SPF, DKIM and DANE?
pricing when sending through third party server:
Qubes Documentation using jekyll and markdown
- hosted inside git
- editable through git
- ugly table of contents anchors
- unstable table of contents anchors(?)
- no wiki templates support?
- no footnote support?
- web based editing is cumbersome
- previews so not match actual result
- links cannot be tested if those actually work as expected from github editor
- can only edit whole page, not chapter wise
- github editor does not let one use the browsers internal search function and github editor's one is cumbersome
- mediawiki, codeselect, select code, short / long / recommended / detailed buttons
- Web Backend, CMS vs non-CMS, vs github-pages, etc.
- Port Tails Test Suite to Whonix ™ or create a new one from scratch.