even if they only leak the seed in a low percentage of transactions, there is risk of detection by RFC6979 compliance test. Once detected, shit hits fan and it's over for them. Risk too high for reward (at least compared to when using random k)
6. Combine some of above or invent your own.
Since all of above are weak approaches, this one is also weak.
In my opinion, the true random k is a better option than RFC6979, but some devs don't even know how to generate random numbers and they still write wallets to store your money....
In my opinion it's not. True random k cannot be checked for at all. It's easy to slowly leak the seed (bit by bit if need be, or completely in one go XORed with or encrypted to attacker secret) in the "random" numbers without anyone being able to prove it. (just noticed XOR would be a bad idea since it would enable "freeloaders")
Let me be clear here. I'm talking about ALL wallets, not just Trezor. Using above techniques, you can have deterministic signatures, that comply with RFC6979 most of the time and when they don't they leak your seed. You will not detect is, because the only test you actually do is to check whether it is deterministic, not whether it is RFC6979 compliant (i.e. equality across multiple runs). You can sell or spread your hardware/software wallet for a while while collecting the keys and when competition crushes you eventually, then you can use all those seeds you collected to clear their wallets and fly to Carribean.
I'm not saying that this is Trezor guys intention. I'm just saying that if this was any wallet maker intention it would be EXTREMELLY difficult to find. It is easy to prove it from code, but I disagree that it is simple to prove in blackbox testing. It depends on your luck. From this perspective I really like this initiative of signing the build by third parties. If only everybody did this. But still there are problems like the bootloader that is not signed by anyone etc.
You see, proving that you are not evil is difficult. In a sense, it is similar to using random K in signatures. In the code it is easy to see whether the number comes from the HW rng that is on the chip (much simpler than checking your RFC6979 implementation). But it is impossible to prove this from the generated signature.