There is an opinion that a device like FST-01 should have DFU which allows users (developers) to update its firmware.
Yes, some boards (STBee and STBee Mini, for example) have DfuSe (DFU with STmicroelectronics' extension) installed, which eases developments. Developers are not required to have JTAG/SWD debuggers but can just send firmware with a software tool.
I think that real developer has JTAG/SWD debugger. And I know some bug (or feature) of DfuSe implementation. Thus, I use FST-01 with SWD debugger and don't install any type of DFU.
When you use the device for Gnuk (or similar application), firmware update by DFU might nullify the goodness or the purpose of Gnuk. So, you should be really carefull when you install Gnuk to some board with DFU feature.
The assumption of Gnuk
When user put his keys to Gnuk Token, user expects none is able to read out his keys from the device.
We can lock flash ROM of STM32F103 so that we prohibit access by JTAG/SWD debugger, and Gnuk Token should use this method.
Given the situation that Gnuk doesn't have severe bug to disclose user's key, Gnuk Token could be considered safe with flash ROM lock.
DFU should respect flash ROM lock
Even if flash ROM is locked against access by JTAG/SWD debugger, it is possible for DFU implementation to access flash ROM content.
For applications like Gnuk, DFU should check if flash ROM lock is enabled and prohibit reading from flash ROM when it's locked.
DFU should not keep any data when updating its firmware
Gnuk Token users might think that it would be convenient to do firmware update by DFU and it would be better to do it while keeping data untouched.
However, if DFU has a feature to keep some part of flash ROM untouched, it means that it is possible to read out the content of flash ROM (by loading the firmware to read out data).
Users need to have backup of data and need to restore backup after firmware update, but it is worth to do that.