You require the public key of the signer when verifying the signature. That needn't be before receiving the message, and could be at any point from now until doomsday.
The signature itself verifies:
1. That contents haven't been modified since they were signed. (Integrity.)
2. That a party had access to the private key in order to create the signature. (Authentication)
(You're not assured, of course, that others don't also have such access.)
Determining the real-world identity of the signer is ... another matter. Though an exchange of content encrypted against their public key, and returned to you, might help establish that. Process and protocol will depend on your own needs, intent, and goals.
If an "allowed signers" file is used, the public keys are known beforehand, and it will be secure.
But if the public key is required when verifying the signature, then where ever that key is requested from needs to be a trusted source and it's also the weakest link.
If that source is a web site, you could just as well publish the file on that web site and the files would be just as trusted as if they where signed.
Example: Alice signs a file, and uploads the file on a public FTP server. Alice public key is published under the about section on her HN profile.
Hacker bob hacks into Alice HN account and changes her public key without Alice noticing it.
Hacker bob then downloads the file from the public FTP, ads some malicious code, signs it with his own private key belonging to the public key he added to Alice HN about info.
Then hacker bob sends the file to a victim.
The victim verifies the signature using the public key on Alice HN account as instructed by Alice.
Keys themselves are content that can be signed. The PGP Web of Trust is an untrusted system for distributing content that doesn't rely on trust in the system to be able to distribute trustable content (PGP public keys).
If the SSH method descried in TFA is to become widely used, it will all but certainly end up replicating a similar model.
Otherwise: trust keys you're given directly, or which have a sufficient verification and trust chain attached to them. This is a Hard Problem of all authentication-based crypto. E.g., in our mutual transactions with Hacker News, we're implicitly trusting the site's TLS cert 02:b3:a8:b0:57:06:45:1c:7c:80:fb:d6:e8:31:e3:5e issued by DigiCert. That implied trust is the basis for multiple trillion-dollar-valuation companies, online commerce, communications, control, and other transactions. It has numerous known limitations. And yet it remains used.
The signature itself verifies:
1. That contents haven't been modified since they were signed. (Integrity.)
2. That a party had access to the private key in order to create the signature. (Authentication)
(You're not assured, of course, that others don't also have such access.)
Determining the real-world identity of the signer is ... another matter. Though an exchange of content encrypted against their public key, and returned to you, might help establish that. Process and protocol will depend on your own needs, intent, and goals.