Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git files hidden in plain sight

tylercipriani.com

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Git files hidden in plain sight

#31

Post by loeg »

LukeShu wrote: post #6
eisbaw wrote: post #5

"Hiding" a file as a raw blob with a tag pointing to it, isn't bad if the thing should be able to expire. If a thing is truly expired, then why have it fill-up the commit graph. That said, a public key - even an expired one - may have value in keeping around: Verifying older historic releases.

By default, most things assume that tags are immutable and won't check for updates to a tag. So tags aren't great for things that can expire or otherwise need to be changed.

Huh, is that true? If you push a new version of a tag, Github will ignore it? Or if you 'git fetch', git does not update tags? I would be pretty surprised at either of those.

Re: Git files hidden in plain sight

#32

Post by semiquaver »

everybodyknows wrote: post #30
talkingtab wrote: post #24

Is this a git issue or a github issue? I know git is being (mis)used, but the issues seem to be with github. Maybe a better title for those of us with no interest in github would be "Github hides git files in plain sight" ?

[deleted]

The `junio-gpg-pub` key is a blob in the git repo for git, ie

  ssh://git.kernel.org/pub/scm/git/git.git
You won’t see it in any repo, just that one. This is not an easter egg in the git binary, just a quirky way to transmit a signing pubkey via a non-tree git sidechannel within the git source repo.

Re: Git files hidden in plain sight

#33

Post by WorldMaker »

talkingtab wrote: post #24

Is this a git issue or a github issue? I know git is being (mis)used, but the issues seem to be with github. Maybe a better title for those of us with no interest in github would be "Github hides git files in plain sight" ?

It's not an issue with either, they are both working "as intended". Both examples are storing data in git's object database. Git and GitHub clone the object databases as fully as they can. To keep the objects "live" in the database both examples use non-standard git refs. Git's raw object DB format was designed to be extensible so it supports non-standard refs that don't reflect (aren't reflected in) high-level git concepts (such as branches and commits). Because these examples use such non-standard refs there's not a standard UI for them in GitHub.

It's probably not a great idea to use or rely on non-standard refs in general because it may conflict with other tools or future git capabilities, even if there were a "standard UI for unknown refs".

Re: Git files hidden in plain sight

#34

Post by WorldMaker »

seeknotfind wrote: post #3
mosselman wrote: post #2

I know this isn’t about the signing really, but it is my understanding that you sign things with your private key and people can verify that it was you who signed it with the matching public key. Does this work differently with git?

This is not a security issue. The key is just hard to update when it expires. Private is private, public is public, even in git.

The name `junio-gpg-key` is a lightweight tag in the git git repo. It's not that hard to update, though it requires both force push and force pull (to an existing clone, new ones get the latest value no matter what).

It is something of a security risk because there is no audit log for force pushes and anyone with force push access to that repo could update that tag at any time.

Also, because it is a lightweight tag, it is not itself signed so could potentially be man-in-the-middled.

That said, yes it is a public key and public keys are meant to be public. In many threat models this isn't a "huge deal". The issue, as often the case, with public keys is that you still need a chain of trust somehow defining if you should trust that public key. A public key that you get from the repo itself that anyone could force push an update to is possibly not one you should trust without additional verification channels involved.

Re: Git files hidden in plain sight

#35

Post by WorldMaker »

upofadown wrote: post #21
whirlwin wrote: post #7

Earlier quoted context omitted.

Why does it need to be public? By revealing your public key you also reveal the algo used for your public/private keypair. If you are a renowned developer and have an insecure algo, you might be a victim for targeted attacks

>If you are a renowned developer and have an insecure algo, ... Example of such an insecure algorithm that might be relevant here?

Low key sizes (<= 1024) of RSA are considered vulnerable, especially to quantum computer attacks. Some ECC curves are considered vulnerable, especially to NSA backdoors.

Re: Git files hidden in plain sight

#36

Post by WorldMaker »

loeg wrote: post #31
LukeShu wrote: post #6

Earlier quoted context omitted.

By default, most things assume that tags are immutable and won't check for updates to a tag. So tags aren't great for things that can expire or otherwise need to be changed.

Huh, is that true? If you push a new version of a tag, Github will ignore it? Or if you 'git fetch', git does not update tags? I would be pretty surprised at either of those.

All tag updates require a force push and any existing clones also need a force pull.

Re: Git files hidden in plain sight

#37

Post by remram »

loeg wrote: post #31
LukeShu wrote: post #6

Earlier quoted context omitted.

By default, most things assume that tags are immutable and won't check for updates to a tag. So tags aren't great for things that can expire or otherwise need to be changed.

Huh, is that true? If you push a new version of a tag, Github will ignore it? Or if you 'git fetch', git does not update tags? I would be pretty surprised at either of those.

It's the second one

Re: Git files hidden in plain sight

#38

Post by WorldMaker »

roblabla wrote: post #17
_aaed wrote: post #16

I think you meant ascii art instead of ansi art?

That's ANSI art, since it uses ANSI escape codes for colors. The two terms are often used interchangeably though.

Also, at this point for the most/easiest portability most ANSI art today is Unicode encoded (most often UTF-8) rather than ASCII. (The block drawing characters in "Extended ASCII" aren't very portable, don't work on every OS, and also exist in a nice Unicode block that is portable.)

Re: Git files hidden in plain sight

#39

Post by semiquaver »

`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 other trees or 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 circular 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_...

Re: Git files hidden in plain sight

#40

Post by dljsjr »

semiquaver wrote: post #39

`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 .…

> Many people are only aware of the default lightweight tags

I don't know if that's true anymore, if only because the ongoing popularity of the Git Flow branching model; the `git-flow` tools use annotated tags by default for every command that creates a tag (e.g. releases).

Post reply on HN