I am starting a new service that would be an abstraction on top of git repositories. Basically, a user would sign up and Add Project (GitHub/GitLab/BitBucket repository).

The tricky part for me is how do I verify that the person has appropriate permissions on the repository they're adding?

I was thinking of a method to generate a temporary hash that would then need to be committed as a specific file in protected (master?) branch on the repository. If the hash matches then it's safe to say the user is an owner of that repository.

Since I have a limited knowledge in this area, is there a better way? What would you recommend?

  • What kind of service? If the repo is public and you only need read-only access and what your service does is covered by copyright law etc. you might not need the permission of the true repo owner. For example, automatically running tests should be fine.
    – amon
    Dec 1, 2018 at 21:09
  • Service should be providing official support dates for the project submitted. Which can only be known or should be declared by the repository owner/maintainer. Dec 1, 2018 at 21:23
  • Good point! In that case, why not require the support dates to be stored in the repo itself in a special file?
    – amon
    Dec 1, 2018 at 22:05
  • I was thinking about it, would that be wise though? I can imagine owners of some codebases won't be happy to add an extra file there - so don't really want to set it as a requirement. Dec 1, 2018 at 22:14
  • 3
    Then maybe you start by only offering the service to the ones that are happy to do so.
    – jonrsharpe
    Dec 1, 2018 at 22:19

1 Answer 1


You could take a page out of the playbook that is used for proving ownership of, anything digital, really.

  • To prove ownership of a mobile phone number, the traditional way is to send a text message with an unforgeable token to that number and confirm that the claimant knows that token.

  • To prove ownership of a landline phone number, you do the same but with a voice message.

  • To prove ownership of an email account, you send an email with an unforgeable token to that email account and confirm that the claimant knows that token. You can make this easy by embedding the token into a confirmation link that the claimant only has to click on.

  • To prove ownership of a website, you tell the claimant to put a file with a certain name and content (an unforgeable token) at a certain path and then issue a GET request to verify its existence and content.

  • To prove ownership of a domain, you tell the claimant to put a record with a certain name and content (an unforgeable token) at a subdomain (e.g. a TXT record with the secret token at iownthisdomainreallyiswear.example.com) and then issue a DNS request to verify its existence and content.

  • This even works for proving ownership of physical addresses: send a letter with an unforgeable token via verified mail, then verify that the claimant knows the token.

So, for a Git repository, you could tell the claimant to put a blob with certain content into the repository. There is no need for this blob to be reachable via a tree, a commit, a tag, or a branch. You just need the blob. That way, it doesn't pollute the history or the repository. You just need to make sure not to run the garbage collector before the verification process is over, otherwise the object will be collected.

Of course, not everybody knows how to put a blob into a Git repository, so you could just tell them to create a throwaway branch with only a single commit that has only a single file.

  • I'm curious now; how do I put a blob in a Git repository as you described? Do you have a link to the appropriate documentation or an explanation? Thanks! Sep 19, 2022 at 13:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.