If you have a maintainer who signs their commits, you trust their signatures and call it a day. Go with the latest commit and that tells you the history that they have cryptographically claimed is "correct".
One problem I see there is that, with git, you still have to take care that you keep around all the commits that at any given point in time were declared "correct".
For example, if a commit is amended and force pushed out to remove a backdoor from a popular package, a site interested in the history of the library will want to ensure that the faulty commit stays around.
I'm not even sure that is 100% possible, but it, at least, will take some careful git configuration.
You never rewrite published history with git. It's fine to force push signed git commits to a random branch that are going to be rewritten -- that's just how development works. But when you merge something, it stays that way. Touching history in release branches is something that will always end in tears (all of the tagging breaks, everyone's clone will complain when they update it, etc). Just bad news all around.
As for a site which cares about archiving, they can almost certainly add a tag for every commit they slurp up (making sure it doesn't get hit by the git gc). Though, I'm fairly sure that you can just configure your git instance to never garbage collect.
Such problems are always theoretical, until they suddenly become real, and you're happy that someone years ago has thought of that possibility, and left behind a way to solve them...
