`junio-gpg-pub` uses a git feature called annotated tags [1]. These are one of two types of tags that git supports. Many people are only aware of the default lightweight tags. They are not stored in git's object database, instead they're just simple refs, which you can think of as a symlink in `refs/tags` that contains nothing but a pointer to the object id of the commit you are tagging.

  $ git tag v1.2.3.4.5
  $ cat .git/refs/tags/v1.2.3.4.5
  ee48e70a829d1fa2da82f14787051ad8e7c45b71

But annotated tags are full git objects hashed and stored in the object database (one of four things that can be stored, alongside blobs, trees, and commits). An annotated tag can store a tag message and records the user that created it plus a timestamp. All the metadata in an annotated tag can be GPG-signed. It can also point to any type of object, which is the feature being "abused" here, where we have a tag (currently oid dd20f6ea5) that points to a blob (currently debb772bf) instead of a commit. Normally blobs are only used within trees which are pointed to by commits.

  $ git show-ref -d junio-gpg-pub
  dd20f6ea53bf6828baba3e2f279bf633eaae6815 refs/tags/junio-gpg-pub
  debb772bfc2bfedbfd5830dbe2c1c149dbf054e9 refs/tags/junio-gpg-pub^{}

  $ git cat-file -t junio-gpg-pub # i.e. dd20f6ea5
  tag
  $ git cat-file -t junio-gpg-pub^{} # i.e. debb772bf
  blob

Interestingly, it's perfectly legal to have chains of annotated tags (and lightweight tags) which eventually resolve to a non-reference object. This process is called unwrapping and needs to be done carefully to avoid loops or excessively long reference chains. It's a very common thing to get wrong in git implementations that handle the plumbing themselves.

You can see the tag object itself including the message using `git cat-file -p junio-gpg-pub` and the key it points to with the command in the article.

[1] https://git-scm.com/book/en/v2/Git-Basics-Tagging#_creating_...