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.

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...

GitHub

FAQ

The Reliable USB Formatting Utility. Contribute to pbatard/rufus development by creating an account on GitHub.

The plan, in short, calls for rebuilding each library that includes time_t somewhere in its ABI, and renaming the library by adding t64 to its name (thus allowing the older library to stay in place initially). Once all packages have been rebuilt to use the new libraries, the old ones can be removed and the t64 suffix taken off again.