gpg verify Whonix images when you, the developer downloads it for installer maintenance purposes
create sha256 or sha512 checksums of the images, include them into the installer, verify them using the installer
(also, signed sha256 and sha512 checksum files are available on download.whonix.org)
If images are integrated into Windows installer:
Then users only have to verify your installer. No need for the installer to automatically verify the integrated Whonix images.
I’d say for the initial release, keep it a bit more verbose. Once all issues are ironed out, hide it (if there can be a command line switch or even a small checkbox or so to re-enable them in case should debugging be required).
Are already delivered with it to make deployment in unsafe/uncontrolled enviroments easier.
I see.
Ok. My initial concept was actually meant to automate that step to (i.e. bundle GPG with the signature for the installer, run it in the background and hand over to the installer once it received the go-ahead) since most “Windows-users” aren’t really used to doing things like it. That’s why I am slightly anxious about whether an attacker might have the capabilities of changing this “verification-part” on the fly…
Maybe a good idea would be to, rather than bundle the verification and the installer together, thus making manipluation of both easier, delivering the two seperatley, while still being smpler than doing it yourself. What I mean by this is the following: The user first downloads the installer as usual. He then downloads a second, seperate .exe. This .exe would have to be put in the same folder as the “Install Whonix.exe” and once executed would run a portable version of GPG with the signed and verificated keys already bundled. It then outputs “OK!” or “File corrupted! Download again” giving the user a tangible and simple way to verify the installer.
The hard part remains. Users would have to gpg verify your installer. There is nothing you can do to improve that situation on the Whonix installer level. [[Improvements are possible on operating system / browser level. For browser, metalink would help. Etc. off-topic]]
Maybe a good idea would be to, rather than bundle the verification and the installer together, thus making manipluation of both easier, delivering the two seperatley, while still being smpler than doing it yourself. What I mean by this is the following: The user first downloads the installer as usual. He then downloads a second, seperate .exe. This .exe would have to be put in the same folder as the “Install Whonix.exe” and once executed would run a portable version of GPG with the signed and verificated keys already bundled. It then outputs “OK!” or “File corrupted! Download again” giving the user a tangible and simple way to verify the installer.
That makes things more complicated. Defeats the purpose of the easy installer. And adds no security. Users who download the windows installer could receive a compromised version to begin with. So they have to verify that one. From there, there is no more need for Whonix image verifications that are integrated in the installer. If users received a compromised copy of the installer, that compromised installer could also fool the integrated verification.
Where the automated verification could make sense is within the Windows installer build process. But even then, perhaps have it verified automatically, but continue manually after reading gpg’s output. I’d say that is low priority if things work for you as they currently are.
Looks good to me. We can use that as initial release to get the foot into the door. It’s a HUGE improvement so or so. And it can still be improved after initial testing and feedback.
Ok, I can see and understand where you are comming from in regards to the verification. Leaving it up to the user is likely the best solution, espcially when keeping the fact in mind that Windows isn’t the best enviroment for critical communication in the first place.
Ok, great. Will tomorrow (hopefully) be able to upload a new build which should include this basic version.
For a more presentable version I was thinking about something like this:
Sure, how about perhaps naming it “Shut down host”? Though something I didn’t account for would be accidentally clicking it and losing progress. Maybe having some kind of “safety switch” might help…
Or we do it unix style. Do one thing and do it well. Leave that feature out?
And combine it with apple style. Leave out all buttons and have just one start button that starts both VMs and one stop button, that stops both VMs.
Plus the a smaller advanced button to open the usual virtualbox interface. I guess we’ll not be able to avoid exposing the virtualbox interface anytime soon since it still is required for many actions.
This thread moved to the staff section? Why?
As for finding testers of the installer, I suggest creating a Whonix blog post?
This is just so some testing can be done before we’d publish this officially. To catch any obvious bugs.
Once this “launcher” has been finalized, I’d like to be able to deploy this “installer” immediately which is why finding bugs now is rather advantageous.
Since I didn’t change “that much” between the version currently uploaded and the newest build (other than adding the now “finished” launcher and fixing a bug which lead to the uninstaller not being able to remove the virtualbox.msi files) I have uploaded the three files necessary to run the “launcher” seperatley to save time: MEGA
Simply drop these three files in the same folder in which “Whonix for Windows” has been installed and everything, including start menu and search integration should work.
I will of course upload the complete and corrected version including source to Github (hopefully without crashing this time) as well.
Have a nice day,
Ego
P.S.: Just saw I forgot to mention but .NET Framework 4 is needed to run Whonix.exe. According to Microsoft, it is currently installed on over 70% of all PC’s, though I’m of course still looking into ways of getting it to run with .NET Framework 2.0 which has been included with every Windows since XP.
I seem to reach a “presentable build” quite rapidly actually. Since I currently only have access to my Surface, I created dozens of different VMs in order to simulate as many systems and configurations as possible and I feel confident in saying that there shouldn’t be any too glaring bugs in the current build. I even managed to shave about 300MB of the file size by improving the compression employed. Verbose/Showing the command line while running certain external processes has also been “turned off”.
That being said, I’m currently in a bit of legal jungle in regards to whether including certain parts of the .NET Framework is actually compliant with GPL because, despite .NET actually being MIT for the most part, this does still seem to be something of a minefield in terms of copyright law, etc. Sadly excluding those aforementioned parts is hardly an option at the current time. The same reason is also why I still can’t “skip/automate” the “Oracle Certificate Import Process” which thus needs to be manually accepted by the user. Hopefully I’ll get a concrete answer on that as soon as possible.
After that is sorted out I’ll do a final compile and upload everything to Github.
No problem, I am confident in saying that I’ve been able to simulate enough configurations (different read/write speed, RAM, GPU, assigned processors, versions of Windows, …) to say that there shouldn’t be anything do problematic in the newest build, other than the whole .NET quandary and one bug/problem in regards to the UI. Specifically, that the most recent version employs a simple “IF/ELSE” approach, rather than being based on a process based one. That could lead to problems if a user decides to either close the VMs on its own or start them via the VirtualBox-UI, as then “my UI” displays the wrong button.
I currently don’t to be honest. I’d have to get the entire “thing” on Github first anyways. Sadly takes quite a long time due to the fact that the internet I currently have access isn’t really that fast.
Well, seeing how my last comment on getting this to Github is already over a month old, I should probably start working a bit more continuously on the projects I start. Anyways, have rewritten, simplified and recompiled this project now and thus tried pushing it to Github.
All in all though, I feel like the current version is usable and stable enough for a public release. I even compiled it on a fresh EC2, so there is no way my clogged up hard drive could have had any negative impact on it (as has sadly happend in the past).
The only I’d need for it now, would be the content of the legal disclaimer at the beginning of the installer. Should I simply copy the one we currently display when importing Whonix? I am not certain what legal ramifications there could be to guard against, so this is something which should definetly be discussed beforehand. Once we’ve dealt with that, this should be ready for release.
