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

Every GitHub object has two IDs

greptile.com

Post reply on HN
Print view View original

71–76 of 76 posts

Re: Every GitHub object has two IDs

#71

Post by bastawhiz »

high_na_euv wrote: post #65
bastawhiz wrote: post #41

Earlier quoted context omitted.

That is a best practice for two real reasons: 1. You don't want third parties to know how many objects you have 2. You don't want folks to be able to iterate each object by incrementing the id But if you have composite IDs like this, that doesn't matter. All objects that belong to a repository have the repository id inside them. Incrementing the id gives you more objects from the same repo. Incrementing the repo id g…

What if you used some id that does not allow to count objs like guid?

Uuid4 is extremely random, which makes it bad for most database indexes. You can use uuid7 instead.

Uuid7 would not have helped GitHub, though, because it doesn't solve the sharding issue.

Re: Every GitHub object has two IDs

#72

Post by bastawhiz »

inopinatus wrote: post #49
bastawhiz wrote: post #39

1. The list of "scopes" are the object hierarchy that owns the resource. That lets you figure out which shard a resource should be in. You want all the resources for the same repository on the same shard, otherwise if you simply hash the id, one shard going down takes down much of your service since everything is spread more or less uniformly across shards. 2. The object identifier is at the end. That should be stric…

AES is faster than base64 on modern CPUs, especially for small messages.

AES would mean the encrypted parts of the id are ~28+ bytes. That's a long minimum identifier length.

What you're suggesting is perhaps true in the sense that the throughout is higher, but AES decryption carries a fairly high fixed overhead. If you're in a language like Ruby (as GitHub is) or Python/Node, you're probably calling out to openssl.

I did try to do my diligence and find data to support or refute your claim, but I wasn't able to find anything that does directly. That said, I'm not able to find any sources that support the idea that AES is faster at decryption than base64 in any context (for small plaintext values or in general). With SIMD, b64 often decodes in 0.2 CPU cycles or so per byte, while AES only manages 2.5-10.7 CPU cycles per byte. The numbers for AES get better as the plaintext size grow, though.

Do you happen to have data to support your claim?

Re: Every GitHub object has two IDs

#73

Post by inopinatus »

bastawhiz wrote: post #72
inopinatus wrote: post #49

Earlier quoted context omitted.

AES is faster than base64 on modern CPUs, especially for small messages.

AES would mean the encrypted parts of the id are ~28+ bytes. That's a long minimum identifier length. What you're suggesting is perhaps true in the sense that the throughout is higher, but AES decryption carries a fairly high fixed overhead. If you're in a language like Ruby (as GitHub is) or Python/Node, you're probably calling out to openssl. I did try to do my diligence and find data to support or refute your clai…

Yes.

Re: Every GitHub object has two IDs

#74

Post by bastawhiz »

maxbond wrote: post #46
bastawhiz wrote: post #41

Earlier quoted context omitted.

That is a best practice for two real reasons: 1. You don't want third parties to know how many objects you have 2. You don't want folks to be able to iterate each object by incrementing the id But if you have composite IDs like this, that doesn't matter. All objects that belong to a repository have the repository id inside them. Incrementing the id gives you more objects from the same repo. Incrementing the repo id g…

> You don't want folks to be able to iterate each object by incrementing the id If you have a lot of public or semi-public data that you don't want people to page through, then I suppose this is true. But it's important to note that separate natural and primary keys are not a replacement for authorization. Random keys may mitigate an IDOR vulnerability but authorization is the correct solution. A sufficiently long an…

I don't disagree. But it's embarrassing when someone is like "your users have only used this feature 150 times?"

Re: Every GitHub object has two IDs

#75

Post by bastawhiz »

inopinatus wrote: post #73
bastawhiz wrote: post #72

Earlier quoted context omitted.

AES would mean the encrypted parts of the id are ~28+ bytes. That's a long minimum identifier length. What you're suggesting is perhaps true in the sense that the throughout is higher, but AES decryption carries a fairly high fixed overhead. If you're in a language like Ruby (as GitHub is) or Python/Node, you're probably calling out to openssl. I did try to do my diligence and find data to support or refute your clai…

Yes.

Okay.

Re: Every GitHub object has two IDs

#76

Post by _cenw »

embedding-shape wrote: post #63
_cenw wrote: post #60

I remember a time when the v3 API didn't even have IDs and whenever someone in your org changed their username or renamed a repo you'd be left guessing who it is. This is also the reason I wrote our current user onboarding / repo management code from scratch, because the terraform provider sucks and without any management you'll have a wave of "x got offboarded but they were the only admin on this repo" requests. Eve…

> Every repo is owned by a team. Access is only ever per-team. This is indeed the working pattern, and applies not just to GitHub and organizing teams there, it's a useful pattern to use everywhere. Don't think "Give access to this user" but rather "Give access to this team, which this user is current a part of" and it solves a lot of bothersome issues.

The problem is that GitHub gives admin access to the person who clicked the create repository button personally and then calls it a day.

And the only real way around this is to make people create repositories elsewhere, on a self-service dashboard.

Post reply on HN