For context, this comes from
here.
The OP had an issue where a program started giving a UAC prompt where it had not done so before. It turned out to be because a compatibility setting, Run as Administrator, had been turned on. Geek appears to have rather latched on to the OP's mention of the title of that UAC dialog box, "User Account Control: Do you want to allow this app from an unknown publisher to make changes to your device?".
How this has changed from "unknown publisher listed in Windows UAC dialog" to a far more generic-as-to-be-useless phrase "unknown software", I'm not entirely sure. I'm also boggled how the article linked is in any way related, as it covers a software bug completely independent of any trust-verification chain. It's something like pointing at a fryer and making an off-hand comment about the king of the potato people. It's difficult for others to really know how to properly proceed.
The question of root vegetables as the head of a monarchy notwithstanding, UAC's "verification" is done through Microsoft Authenticode. This requires publishers to pay around $500 annually so they can get a digital certificate that is linked to a root certificate authority that is installed by default on Windows. If a program has a valid digital signature than an UAC Elevation request by said program will list the publishers name (the consent dialog will also be blue).
If the file either has no digital signature or the digital signature cannot be verified with any of the root authority certificates that are installed on the system, or it has expired, then you get a UAC dialog that indicates that the software is from an unknown publisher.
This doesn't mean that the creator of the software wished to remain anonymous. If the program is not digitally signed, it still likely includes file version information, including company names or the names of authors, or even in the about box. Additionally, if the file has a certificate that could not be verified, Windows says "Unknown publisher" as a result, even though the certificate does contain publisher information and therefore it was signed with no intention of anonymity.
Microsoft's Authenticode is not the only way to perform this sort of digital verification. The software that was reference in the post, for example, qBitTorrent, was described thusly:
It does not have anything to verify itself. Nor does it have anything to prevent malware from infecting it.
qBitTorrent's downloads page quite clearly provides SHA-256 PGP verification files that can be used to verify the software downloaded has not been tampered with since it has been published. The second part doesn't seem relevant- Authenticode signing does not prevent malware from infecting files- a verified file will not pass verification but the signing process itself offers no protection for the file from being infected in the first place, so that other approaches do not offer such protection doesn't seem relevant. Additionally, There is no particularly stringent verification of ISVs when it comes to receiving a code signing certificate, because the intent is not to verify that the publisher is trustworthy, but that you can trust that the file has arrived untampered from that publisher.
Something being encrypted doesn't mean it is protected. Something being signed doesn't mean that it is verified to be non-malicious.