First, you might want to realise that a name is just that,
a name, and that it's not because someone slaps a big
"Secure" sticker onto a product or software, that it suddenly makes it any more secure. For instance, you may call the
ROT13 encryption algorithm "secure encryption" all you want, it still doesn't make it an actual secure means of encrypting data...
So, I must first stress out that, instead of being paranoid about it, you should come to terms with the fact that
YOU are actually being manipulated with the terminology that Microsoft (and others) decided to use when they introduced
"Secure Boot" because it was deliberately chosen to convey something that
it cannot really deliver (See for instance
the fiasco of Microsoft's Golden Key). Instead,
Secure Boot should more accurately have been called
Bootloader Signature Enforcement because that is really what (and only what) it does, which is different from trying to protect your computer's security. But of course, the minute you call
Secure Boot by its real name, you risk letting people realise that there may exist alternate motives for what you are trying to promote, for dubious reasons (see below) and they may also come to understand how not having
"Secure Boot" enabled, as you would like them to do always, does not necessarily equate "Leaving your computer in an insecure state".
Which brings us to point number 2: When Rufus is asking you to disable
Secure Boot, as a
temporary measure, so that you can boot the
UEFI:NTFS bootloader, it's not because this bootloader should be considered unsafe, or because we were too lazy/too cheap to get it signed for
Secure Boot, or even (as some people seem keen to suggest) out of spite because we dislike
Secure Boot (which is incorrect: We do like the principle behind
Secure Boot. We just don't like the clear abuse of power that is being demonstrated when a single entity; Microsoft, is left in control of it and abuses it to promote a nefarious agenda). No, the
ONLY reason haven't been able to provide a signed UEFI:NTFS bootloader until Rufus 3.17, which would avoid requesting that you disable
Secure Boot, is because
Microsoft (again the
only entity that controls the
Secure Boot signing process)
has unilaterally decided, for no reason that stands the test of scrutiny, that anything licensed under GPLv3 cannot be signed for secure boot, ever.
And that is really all there is to it.
Microsoft has decided it doesn't like the GPLv3 and,
in a clear abuse of power created a signing process that
forbids the submission of anything that is GPLv3. Of course, Microsoft tried to "justify" their stance with a half baked tirade about how the GPLv3 would ultimately require them to relinquish their private keys, but that reasoning can easily be demonstrated to be utter bullshit when you also know that Microsoft has no qualms signing
Linux shims, which, clearly, it should not sign, since these should logically be subjected to the same "alleged" relinquishing of private keys that the GPLv3 is supposed to entitle its users to, and therefore, if Microsoft's reasons are to be believed, having said shims load GPLv3 bootloaders such as GRUB (which they do) can only result in someone eventually demanding that the shims' private signing keys are relinquished, therefore completely defeating Secure Boot...
Well, the original NTFS driver we used for UEFI:NTFS was GPLv3, and getting a new non GPLv3 version that could be signed was anything but a walk in the park (it pretty much took us one year of hard work to get there), which means that, because the original driver can not get signed for
Secure Boot, we have no choice but to ask
YOU to
temporarily disable
Secure Boot when using UEFI:NTFS.
Now, given the feedback I am getting, I do realize that a lot of people may irrationally scream at the idea of even
temporarily disabling Secure Boot. So let me pursue further on what
Secure Boot is really about, and why your impression that even
temporarily disabling
Secure Boot is not an option, is about as wrong as thinking that UEFI cannot boot anything but FAT32 (which, as can be seen from the previous FAQ entry, is also completely wrong).
All
Secure Boot does is establish trust, by verifying that the boot files have not been altered from the version that was created by the makers of the OS, and it does so through the process of using digital signatures to validate hash of the files.
Well, guess what; even if you have
Secure Boot disabled, the exact same process can still apply because:
- Rufus is digitally signed, and therefore validated with about the same level of trust as a Secure Boot executable would be (and if you want to dispute that statement, may I invite you to read the Security page?)
- If you produced the OS installation image yourself, through official sources, or, if it's a retail ISO, validated its checksum against the one provided on the OS manufacturer's page, then you have also confirmed that the UEFI boot files you are going to launch are not malicious (which actually makes Secure Boot superfluous for the installation process).
Therefore, even with
Secure Boot disabled, you can actually have some good level of
trust that the boot files you are going to run are not going to do anything malicious, which is all
Secure Boot is about. Again the only purpose of
Secure Boot is to provide some level of "safety" if you have reasons not to trust the media you are about to boot. But if you are able to establish a sufficient level of trust from elsewhere, then
Secure Boot becomes entirely superfluous.
So, now that you understand what
Secure Boot is really about, and how Rufus tries to secure its bootloader creation process (because if
Secure Boot can misappropriate "secure" in its name, then I don't see why I shouldn't), then you should really understand how there is no increased risk associated with temporarily disabling
Secure Boot, as long as you are using legitimate installation media.
And again if you are using Rufus 3.17 or later, you should no longer have to disable Secure Boot and, if using an earlier version, since it's only a temporary measure, you can re-enable
Secure Boot once you have finished installing your OS.
