* This is accomplished through Fido (https://github.com/pbatard/Fido), a *SIGNED*
PowerShell script, that is downloaded from GitHub and that resides in memory for
the duration of a session.
* The reason we use a downloaded PS script, rather than an embedded on, is because:
- Microsoft have regularly been changing the deal with regards to how retail ISOs
can be downloaded, and not for the better, so we can't simply embed a static
means of downloading ISOs and expect that to work forever.
- By using an external script, we can immediately respond to whatever new means of
*ANNOYING* their legitimate users Microsoft will come up with next, as well as
make sure that, the minute a new retail version of Windows becomes available, it
also becomes available for download in Rufus.
* Note that if you are concerned about downloading a remote PS script that is being
run at the same level as an elevated application, you should understand that:
- Only scripts downloaded from GitHub, from an account that is protected with 2FA,
are allowed to run (i.e. someone would first have to steal a *physical* 2FA key
to be in a position to upload a malicious script).
- On top of this, only scripts that are signed with a separate private key (RSA +
AES-256), that is itself also protected with a strong unique password which only
a single person knows (and must manually enter each time they want to make a new
version of the script available for download), are allowed to run.
The above means that there's about as much chance for someone to manage to upload
a malicious script on the GitHub servers, that Rufus would allow to run, as there
is for someone to upload a malicious version of Rufus itself.
Still, if you are paranoid and have concerns that, even as you can validate from
its source that Rufus does not attempt to execute any remote script unless a user
actively selected and clicked the DOWNLOAD button, you can also completely disable
the remote script download feature, if you just set the update check to disabled
(which, by the way, Rufus *EXPLICITLY* asks you to choose whether you want to
enable or not, the very first time you run the application).
* Also remove _unlinkU() which duplicates what DeleteFileU() already does.
* Closes#1268
* Issue was introduced in 521034da99 and has
to do with VS2017's handling of static strings in RELEASE mode.
Fix is to use a static char array instead.
* Also fix MinGw build warnings and increase process search timeout
* Relying on system MUIs was too brittle and provides us with no guarantee
that the translated messages we need will actually be there.
* Also fix space before question mark in French translation.
* With no thanks whatsoever to Microsoft for *NOT* documenting that you need
to pass flag 0x2000000 to WIMCreateFile() if you want to avoid an open error.
One has to wonder if Microsoft isn't deliberately adding *BULLSHIT FLAGS*
that only they know of, to hinder competing third-party tools...
* Also revert a472e96e87 as this is creating
unwanted detection issues as per #1239. We'll try to devise a better way
to avoid intempestive refreshes later on.
* efi.img was not always being properly process (e.g. proxmox-ve_5.2-1.iso)
* Note that this doesn't mean that the ISO will properly boot, just that we will
now properly detect and install the EFI bootloaders that reside within the .img
* Instead of x86_32 and x86_64.
* This should aid with our appxbundle creation and if Microsoft want to
be wholly incorrect in their arch designations, who am I to judge?...
Pete Batard
Radosław Serba
Arif Budiman
Sopor
Charles Stevens
dmex
ImgBotApp
marcellogianola