UEFI:NTFS developer here.

As much as I'd like to see Chinese users be able to access the required content, applying this pull request will prevent WoeUSB to receive updates and bugfixes that I apply to the uefi-ntfs.img, such as the recent one that makes UEFI:NTFS compatible with Secure Boot.

So, unless you are going to monitor closely when I am updating the image, I don't think you want to freeze the one you use for WoeUSB to a specific Rufus tag or commit, like this PR proposes...

Oh and incidentally, the latest image size was bumped from 512 KB to 1 MB, something that some WoeUSB users appear to have a problem with on account of the partition size being hardcoded. Obviously, while I expect the 1 MB size to remain for a while, I can't guarantee that it will always be so, so you might want to update the code to download the uefi-ntfs.img image first and then create the partition according to its size...

UEFI:NTFS developer here.

As much as I'd like to see Chinese users be able to access the required content, applying this pull request will prevent WoeUSB to receive updates and bugfixes that I apply to the uefi-ntfs.img, such as the recent one that makes UEFI:NTFS compatible with Secure Boot.

So, unless you are going to monitor closely when I am updating the image, I don't think you want to freeze the one you use for WoeUSB to a specific Rufus tag or commit, like this PR proposes...

Oh and incidentally, the latest image size was bumped from 512 KB to 1 MB, something that some WoeUSB users appear to have a problem with on account of the partition size being hardcoded. Obviously, while I expect the 1 MB size to remain for a while, I can't guarantee that it will always be so, so you might want to update the code to download the uefi-ntfs.img image first and then create the partition according to its size...

can pin it as a master branch:
https://cdn.jsdelivr.net/gh/pbatard/rufus@master/res/uefi/uefi-ntfs.img

@Rsplwe

Apologies for the ignorance. I've reviewed the patch and have merged it manually after conflict resolution.

I also made a change so that it uses the recent release that has the signed drivers.

@pbatard

...applying this pull request will prevent WoeUSB to receive updates and bugfixes that I apply to the uefi-ntfs.img, such as the recent one that makes UEFI:NTFS compatible with Secure Boot.

So, unless you are going to monitor closely when I am updating the image, I don't think you want to freeze the one you use for WoeUSB to a specific Rufus tag or commit, like this PR proposes...

Oh and incidentally, the latest image size was bumped from 512 KB to 1 MB, something that some WoeUSB users appear to have a problem with on account of the partition size being hardcoded.

I understand your concern, however, the recent WoeUSB incident is exactly the reason why we should pin the version of the UEFI:NTFS image(to avoid breakage due to similar upstream changes). I am also investigating the possibility to bundle the image with WoeUSB so it wouldn't need to download it from the GitHub in the first place.

you might want to update the code to download the uefi-ntfs.img image first and then create the partition according to its size...

Despite it being less necessary due to the above action I plan to do it as soon as possible.

to avoid breakage due to similar upstream changes

I understand your position. But, as I pointed out, this should be weighted against the possibility of penalizing your users on account of missing important bugfixes and improvements. And I get a strong feeling that you are approaching this whole matter the wrong way...

The 512KB → 1MB increase issue appears to indicate that you don't seem to be monitoring UEFI:NTFS that closely. In fact, had you applied the change prompted from this PR sooner, I would venture to say that users of WoeUSB would still be missing on the Secure Boot signed version of UEFI:NTFS, since it the only reason you eventually picked on it was because the size increase created an actual breakage that you had no choice but to investigate.

So, rather than "the recent WoeUSB incident is exactly the reason why we should pin the version of the UEFI:NTFS image(to avoid breakage due to similar upstream changes).", which I would say is a somewhat narrow way of considering the whole matter, I would instead posit that "the recent WoeUSB incident is exactly the reason why you should NOT pin the version of the UEFI:NTFS image (to avoid penalizing your users by not letting them benefit from a much requested feature like Secure Boot support)."

Additionally, on an Open Source project such as this one, I also tend to think that having a wide range of users reporting on how the latest version fares is better than having a handful of developers performing a limited set of tests.

But then again, this is only a suggestion, which is really all I can voice as the developer of the upstream UEFI:NTFS project...

The 512KB → 1MB increase issue appears to indicate that you don't seem to be monitoring UEFI:NTFS that closely.

That's true, previously I only selected the "Participating and @mentions" watch option on the GitHub project page, I've switched to "Custom > Releases" after patching the bug to rectify the problem.

I would instead posit that "the recent WoeUSB incident is exactly the reason why you should NOT pin the version of the UEFI:NTFS image (to avoid penalizing your users by not letting them benefit from a much requested feature like Secure Boot support)."

I understand your stance, however, pinning dependencies is a common practice to avoid user frustration due to dependencies changes, and no matter how much I appreciate the advancement of UEFI:NTFS I can't weigh it over the cost of product stability ATM.

I have made the pinned UEFI:NTFS revision(Rufus's revision to be precise) changeable in the runtime so that one can always use the latest version when they prefer, which should partially remedy the problem.

on an Open Source project such as this one, I also tend to think that having a wide range of users reporting on how the latest version fares is better than having a handful of developers performing a limited set of tests.

I would prefer to have both, while letting the user to have their choices on what fits their need the most, in my opinion ;)

this is only a suggestion

I would like to express that I am grateful for all of them, please feel free to do more if you are willing to.

Reference

• Should I pin my Python dependencies versions? - Stack Overflow
• How should you pin dependencies and why? - The Guild Blog
• To pin or not to pin dependencies: reproducible vs. reusable software
• About alerts for vulnerable dependencies - GitHub Docs
• Pin exact dependency versions - Better Dev