Long Wiki Edits Thread

Answered on twitter just now.

Great work on the 2FA page!

Added 1 more sentence on the 2FA page.

2FA can also be useful for advanced users the have the capability to easily detect any phishing attempt. That is because even if the e-mail address used to sign-up for a (financial) service got hacked because of the e-mail service got hacked, attackers could still not login into the user’s accounts due to lack of 2FA.

Advanced users sometimes have the mindset “I know how to detect phishing therefore I am not in the target group of people who could benefit frrom 2FA” but then even their e-mail account could get hacked without their fault (malicious employee, database leak) and in this cases they’d be better off with 2FA protected logins for everything else. Then a simple password recovery request wouldn’t suffice to hack all of their logins.

Not sure that point was made on that page?

Not really. My best understanding of 2FA benefit is for web services. 2FA “strengthens any password” and makes a hacked e-mail address less painful.

New wiki chapter:
Whonix ™ Binary Images Policy

New wiki chapters:

Could you please review my minor by comparison title and description changes?

new wiki chapter:

Builds from Source Code versus Builds including Binary Packages

For Whonix 16, let’s please do a “staged rollout”, i.e. not post on too many announcement channels right on first day of release.

A post was split to a new topic: Kicksecure (not Whonix!): using /etc/hosts to block advertisements and trackers

A post was merged into an existing topic: apt-key Deprecation / Apt 2.2 changes

Could you review Passwords: Difference between revisions - Whonix please? @HulaHoop

1 Like

I had to look up what a kibibyte is. I learn something everyday.

1 Like

Updated chapter Install the Signal Desktop Client.

The Notable Changes in a release announcement are based on git commit log. A recommend practice for git commit messages is:

“Use the imperative mood.”

For example:

This then gets rewritten in (Stable Release: Difference between revisions - Whonix) on Stable Release - Whonix to:

Which might be more appropriate for the wiki. Should I ignore that git commit messages best practices part and try change my habits to use “descriptive mood” instead of “imperative mood”?

I am wondering if some effort on @torjunkie’s side for maintaining Stable Release - Whonix could be lowered.

Maybe Notable Changes could be left out in release announcements by me.

  1. To avoid duplication.
  2. Notable Changes would then be auto generated in mediawiki markup instead of markdown makeup (forums). I could post them in the wiki instead. (Maybe with a comment if still in testing and not actually stable yet or wiki pending moderation as long as not in stable yet.)

Then there would be no need to copy/paste (and duplicate) them from forums to wiki. And fixes on top of my writeups would still be very much welcome.

Also if it seems useful… Feel free to edit my forum posts with the usual very much appreciated enhancements that are happening in the wiki all the time all over the place. :slight_smile:

Other suggestions to simplify the changelog writing process?

To be honest, I hadn’t thought about it too much - I just preferred that phrasing. Happy to go either way.

It would be good if you can edit the stable release notes going forward, and just reference it in your forum post. Saves a lot of time. Then I’ll just do any finer edits later on.

1 Like

This will be done that way from now. I’ve adjusted the changelog auto generator to use your chosen format. Example:

grub-live:

  • Fixed grub-live (initramfs-tools version).

([archive] link is added by a mediawiki extension.)

Any idea how/where to document this?

//cc @adw

Thanks.

As some dipshit keeps editing the “Contact” wiki page with spam, suggest you lock that page to contributors only.

Nobody should really be adding things there anyhow except for a few select people.

1 Like

Done.