Using == inside the template has to be done with care, so it does not break any pages that use the template. It currently looks broken on the Invisible Internet Project (I2P) page.
I wonder if isn't → is not mass replacement would be a great idea? Then the not is easily mentally skipped while reading. And I think we should value success rates understanding the documentation over form.
I don’t think many users will understand that. What @HulaHoop probably meant to say is
yeah, you can see the fingerprint below, compare it, but also do your own research figuring out what the fingerprint is, don’t trust the wiki since it’s also only on a webserver over SSL or onion. (Not the same level of verification as gpg.) For best security, use the OpenPGP - Kicksecure.
Well, now you’ve opened a can of worms, you could probably do a mass find and replace for some or all of the following, depending on your level of energy:
isn’t -> is not
aren’t -> are not
don’t -> do not
doesn’t -> does not
haven’t -> have not
hasn’t -> has not
won’t -> will not
hadn’t -> had not
weren’t -> were not
wouldn’t -> would not
couldn’t -> could not
shouldn’t -> should not
can’t -> cannot
mustn’t -> must not
shan’t -> shall not
mightn’t -> might not
mustn’t -> must not
needn’t -> need not
oughtn’t -> ought not
daren’t -> dare not
Being careful not to overwrite instances in (block)quoted text throughout the wiki.
There are other contracted forms (believe it or not), but they probably aren’t in regular use in the wiki. Generally, formal language avoids contractions.
God English is a strange POS language. Did anyone tell you that editing is like diving down a rabbit hole?
RE: ProxyFoxy Template -> fixed (hopefully).
It seems to fit now with I2P and other entries in the wiki. Reverted most of the fingerprinting text.
I should have followed my own doc guidelines. ha.
Template:Gpg_fingerprint_verification -> Done. See what you think:
Before adding any foreign repository or software source, it is necessary to fetch the associated signing key (if available) and verify the fingerprint.
It is not safe to only rely on the Whonix wiki for confirmation of a key’s expected fingerprint. The reason is websites rely on fallible SSL or .onion architecture, which provides a lower verification standard than the OpenPGP implementation. Users should always check the fingerprint for themselves. In practice, this means:
Researching the expected key fingerprint from multiple, trusted Internet sources.
Explicitly checking the key fingerprint matches the expected output, before importing it or adding it to a trusted key-ring.
For the best possible security, users should always rely on the [[OpenPGP#The_OpenPGP_Web_of_Trust|OpenPGP Web of Trust]].
Re: small introduction for documentation_guidelines. Added->
Note: These suggestions are recommendations for best authoring practices and do not constitute absolute rules. Whonix welcomes contributions from people who are willing to invest their time to help improve the wiki. Therefore, use this information as a guide only in the first instance.
Are you happy with the FoxyProxy template now? I just deleted that stuff you didn’t like. I can put in the “accessing other anonymizing networks like I2P” line again if you want.
So perhaps it should actually be DisposableVM → DispVM? …what I don’t really like myself. Hm hard case. I actually disagree with Glossary | Qubes OS using contractions. But it would have to be fixed in Qubes first before it can be changed in Whonix documentation.
Even the kernel guru over at Qubes can’t get the 4.9 kernel with pvgrub2 VM to boot. Makes me feel a little better.
He gets the same error I did with the Debian-8 template.
So, this can be written off in the grsec instructions until this issue is solved. I’ve changed the text in the grsecurity wiki entry to reflect this.
That is, people should only run the latest available 4.8 coldkernel branch (4.8.17), or maybe use the Debian 9 template for 4.9 coldkernels (which I know this same poster has previously gotten working, according to Qubes Users forum threads I’ve seen).
Dependencies aren’t a problem anymore since the needed updates have passed to the stable Qubes repos since the update yesterday.