[LugosFergus]

Something else that git isn't good at: permissions. In gamedev, you might have proprietary work that you want to restrict to certain users. In P4, you can add restrictions to certain directories for only those who have signed the required NDAs. That's not something that you can do in git: it's all or nothing. Maybe you can set something up with submodules, but that's going to upend your repository if you hadn't planned for it.

[MrDresden]

I once worked in a git repository that required those kinds of restrictions.

This was within a bank and the code in question was related to enabling Apple Pay from within the banking application. The consequences of that information and code leaking or being seen by anyone who had not signed the NDA were very serious (don't remember the details but it made the lawyers were extremely stressed about it).

Needing to figure out a way to protect those parts of the codebase it was decided in the end that the "easiest" way of doing this was to split the repository in half, with the actual artifact building taking place from the half that had the NDA code. The rest of the application (basically the whole application) was then used as a dependency by it.

Still didn't quite solve the issue, but access to that repository was heavily controlled.

[SoftTalker]

Strikes me as bizarre that payment code would be sensitive, unless it's a security by obscurity thing (which would also be concerning).

Keys, secrets, etc. yes. But code? What am I missing here?

[danudey]

As others have said, it's Apple and they do not take kindly to other people leaking their technology/announcements ahead of time.

See also: the time that ATI's CEO told his employees that their chips would be powering Apple's to-be-announced hardware a few days before the announcement. Steve Jobs responded by pulling all of ATI's hardware from its demo units at the announcement, not mentioning ATI at all, cancelling a joint demonstration of the Radeon card that was going to be in the system, and never partnering with ATI again.

https://web.archive.org/web/20001216031800/https://www.zdnet...

[gouggoug]

From the linked article, it was a press release, not just to his employees.

> The incident began Monday when ATI, which supplies graphics cards for all Apple's current models, issued a four-paragraph news release that stated its Radeon processor would be featured in three new Mac models -- none of which were announced by Apple (Nasdaq: AAPL) until CEO Steve Jobs' Wednesday morning keynote address.

[danudey]

Oh, I misremembered then. Yikes.

[formerly_proven]

> and never partnering with ATI again.

Except of course shipping ATI hardware for years afterwards, then also using nvidia, then dropping nvidia and only using ATI/AMD until transitioning to Apple Silicon.

[danudey]

Well:

1. They kept existing designs, since even Jobs wasn't so crazy as to demand a complete re-architecture of existing laptop models on a whim; plus they probably also had contractual obligations/pre-purchase arrangements

2. They switched to nvidia, but from everything I know they also hated working with nvidia (IIRC Jobs accused nvidia of stealing Pixar tech)

3. AMD is a different company than ATI (technically), and Apple of that era was different than the Steve Jobs temper tantrum era.

But yes, relevant details.

[NewJazz]

Also Steve Jobs Apple is probably much different than today's Apple.

[ifh-hn]

Sounds like a bit of a dick...

[therealpygon]

For violating an embargo and publishing a press release announcing products of another company that hadn’t been debuted? What “non-dick” response do you think is appropriate against a prospective partner that violated clear guidelines that defined their partnership which basically included “#1: Keep your mouth shut”, exactly?

[paulddraper]

They unilaterally issued a press release about Apple's upcoming release.

That's kinda a no-no for partnerships.

[MoonWalk]

He was, but this incident wasn't an example. That's a righteous punishment for an infraction like that.

[rib3ye]

Going scorched earth was kind of Steve’s thing.

[yonatan8070]

One word: "Courage"

[ifh-hn]

Not sure I understand? Sounds like a temper tantrum to me.

[MoonWalk]

Four words: You're holding it wrong.

[kazinator]

I believe that the action does reflect Jobs' ego in the following way.

Namely, his belief that CEO == company.

Jobs would never take the view that the action of the CEO of ATI is actually one bad actor acting alone which doesn't represent what ATI wants as an organization, and is unfair and damaging to that organization and all of its employees.

The reason he would not take that view is because then he would not be able to believe that he is the single most important thing at Apple, overshadowing everything else.

If the leak had been the responsibility of some rank and file employee at ATI, with appropriate action taken against that employee by the ATI CEO, it is likely that Jobs would likely have reacted differently, because it then would not longer be seen as a personal matter between him and the CEO, where the corporations are just pawns in a game of teach-you-a-lesson.

[Hendrikto]

Ultimately, it is the CEO who has to take responsibility. They are the chief executive officer, after all. And they are well compensated for it.

[isodev]

It’s funny how exciting Apple Pay was when introduced, only Apple pulled the lock-everyone-in card and now we’re all using QRcodes.

[mixdup]

In the US you can use Apple Pay anywhere NFC payments are accepted. It's generally completely open on the acceptance side at this point

[account42]

It's anywhere close to open and requires vendors to seek approval from Apple for every implementation - Apple just has the market share to make everyone dance to their tune.

[josephg]

Same here in australia. We had NFC payments ("tap and pay") since ~2006. Nearly a decade before apple pay launched in Nov 2015. For us, apple pay was like "oh, I can use my phone instead of my credit card? Neat."

People use it everywhere here, just because its easier than carrying around a card.

[hylaride]

Most developed countries I've been to use NFC/Apple Pay. Where you see the use of QR codes is in China, Africa, and other countries that VISA/MC/AMEX hasn't penetrated (for either political or socioeconomic reasons).

[FabHK]

I'm in HK, most HKers use ApplePay with NFC, and don't use QR codes. Over in mainland China, however, it's all QR codes (with AliPay, WePay).

[ZekeSulastin]

I guess the "we" depends strongly on location - I've no problem using Apple Pay basically everywhere except Walmart.

[MoonWalk]

No idea what this is referring to...

[necovek]

Many countries in the world have local systems for quick, direct bank transfers encoded with QR codes to be used by local payment systems or local banking apps.

[NetOpWibby]

SHEESH

[kurthr]

Because it's Apple. They are huge, have scary lawyers, write scary contracts, and want to "delight the user" with features only when they announce them. They hate leaks, and demand separate teams for basically any/all development.

[zer00eyz]

> security by obscurity thing... What am I missing here?

You are looking at the problem from the wrong direction.

If you build a honeypot, to trap hackers, does it behove you to explain what the bait is, and how the trap works?

Know your customer, fraud detection heuristics, finger prints, behavioral triggers are all areas where banks, and financial institutions need to keep the sauce secret. Telling the other party "how" you catch them just gives them the steps of what not to do.

[necovek]

Alternatively, you can also just try not to have security issues, and resolve them with urgency when they do pop up.

[HWR_14]

The code revealed the existence of Apple Pay, which had not been publicly confirmed.

[user_of_the_wek]

It seems this wasn’t about the code itself, it was about Apple Pay not being announced yet. So only people under NDA would be allowed to even know what they are working on.

[juancn]

It's kinda like that, there could be a proprietary fraud detection heuristic in there that you don't want to get out.

[arianvanp]

Yes Apple Pay relies on security through obscurity even today. See the Veritasium recently made a video about it https://youtu.be/PPJ6NJkmDAo?is=iUuJ0W9xUHF_6gTU

[kazinator]

The non-strawman version of "security through obscurity" is the belief that a system is secured by means of keeping its mechanisms secret.

Suppose an organization doesn't believe such a thing; it's still more secure to keep code secret than not.

Obscurity is a valid layer of security, just not a valid corner stone or linchpin of security.

In particular, when code operates as a service (end users don't have the executable code on their machines) then protecting the source code is a real security measure. Without it, attackers can only probe the service as a black box, guessing about what it is doing.

[edoceo]

There is a bunch of mundane stuff in the banking/finance world masked off by paperwork.

It's not sensitive in the leaking state secrets sense it's sensitive in the risk adverse lawyers on both sides think it's sensitive.

The Bureaucracy exists to perpetuate the Bureaucracy.

[hk__2]

Maybe that’s some scoring to decide if you should be able to pay or not with some method.

[contingencies]

Can confirm split repos is an excellent solution for protecting IP.

[sroussey]

PCI DSS has various controls for code handling credit card cards which tends to require different workflows for code that touches credit card numbers, from say, marketing pages. So splitting the code into different repos can be quite common.

[yaur]

Not sure what it is on the Apple Pay side but with FPLS it is/was basically your keys would be revoked and you would be ineligible to ever get new ones… so no content that requires DRM on iOS for the life of the company.

[Meneth]

Banks absolutely love security by obscurity. No clue why.

[jeremyjh]

It had nothing to do with security - it had to do with contractual obligations. Contracts with Apple (also Google, Samsung, Mastercard and Visa) required the product to be kept absolutely secret before the public launch. I was a tech lead with developers working on Bank of America’s ATM client - which had firmware and software updates ahead of launch - and I found out about Apple Pay the day it launched. Across the aisle were developers who supported the debit auth platform and they had no idea either.

[vorticalbox]

security by only obscurity is bad. Having both is better.

For example say I have a hollowed out wall that is hidden behind a painting.

Just putting my money in the hole is bad once it’s found it’s gone but if I put my money in a safe in the hole. Well now you need to find it and break the safe and a hidden safe is objectively better than just having a safe on the floor because you need to find it first.

[dessimus]

Sure, if there's many paintings scattered around the house of various sizes, but if there's only one painting, in your office, behind the desk, mounted to cover a safe at standing height, then you might as well hang a neon sign saying "Look Here!" next to it.

[kazinator]

Banks run a lot of code as a service. Most people never get to see the executable code. If the source code for those services were easily visible to employees that don't need to have access to it or external consultants and such, that would be monumentally stupid.

[mvkel]

It's the most effective kind of security

[BobbyTables2]

I assume compiling the payment code as a library (w/o debug symbols) and making that available to the wider group wast allowed? Header files a problem?

[ryanm101]

Could you not have placed the code in a submodule and likited access to the submodule repo ?

[stevefan1999]

That's by design of git, you can't forget that git is first developed for a bazaar model of information flow, especially with a big decentrailized project like the Linux Kernel, not the silo and isolated corporate NDA and closed model you described. Git prefers open information and discourages information closures and segregation of information by placing restrictions exactly like this.

Git enthusiast would often tell you to do this separately with a submodule, and set permission on the version control forge software level (which means Gitea/Github private RBAC access to certain repos for cloning), sure, but that is also painful as hell.

But my point is that all of this is exactly by design from Linus Torvalds's need for Linux Kernel to replace BitKeeper. Git simply isn't the tool for everything, it was developed for a software project with liberalism in mind, but corporate stuff is monoculture and prefers proprietary, shut-in model, and the eat your own dog food mindset, and no wonder it is so painful to deal with.

[kccqzy]

Git submodules aren’t convenient either. For the silo and corporate development use case, just use multiple repositories and make your build tool aware of multiple repositories. It is slightly less painful than submodules.

[packetlost]

I feel like submodules could be a lot easier to work with if the git command made it easy to update all submodules in one go based on branch head for the submodule.

[InitialLastName]

That and a way to recursively commit/push (i.e. make a change within a submodule, commit in one step with the same message in the parent submodule).

Right now, if you want to push a change to a file in a submodule such that it propagates to the users of your repo, you have to:

1. Change the file

2. Commit within the submodule

3. Push the submodule

4. add the submodule change in the outer repo

5. commit in the outer repo

6. push the outer repo

[gritzko]

In the Beagle SCM, I am doing my best to simplify that flow, but that is only doable because Beagle has multi-project repos. Still, there are some difficulties with submodule recursion. In the git model, difficult to imagine this working smoothly.

[1718627440]

You can combine the push step. A submodule intentionally follows a different development/commit/version cycle, otherwise you are supposed to use a subtree.

[a1o]

git submodule update —recursive —remote is that, isn’t? Perhaps throws also an —init if it’s the first time.

[Orphis]

To add to this, you can add in your .gitmodules the name of the branch that the --remote flag will follow. It just works.

[1718627440]

You can set submodule.recurse to true and then git commands operate as if you passed --recurse to them? It's just that most people don't actually want that, because a submodule is generally something you intentionally want to handle separate.

[1718627440]

Submodules ARE multiple repositories. This is not an either or.

[kccqzy]

I understand that. I am just arguing that making your build tool aware of multiple repos is enough; no need to use submodules in git and make your build tool pretend to operate on a single repo.

[stackghost]

I think everyone knows that this is a consequence of git's design. Nobody's disputing that.

Unfortunately there are many people who think git is a panacea and is suitable for all version control tasks of anything.

[PaulDavisThe1st]

And a few of them think that it is corporate structure and development models that are actually the problem.

I'm just asking questions!

[stackghost]

I don't understand what you're trying to imply.

If you're making the point that there are multiple confounding factors to just about any non-trivial problem, then I agree.

[PaulDavisThe1st]

No, I'm making the point that the way in which git doesn't fit well into many corporate processes can be interpreted as more of a negative commentary on those processes than on git.

[Freedom2]

I ended up writing my own layer over git for permissions for a specific client a long time ago. It has a huge amount of useful features - sadly, I never took the idea further.

[stogot]

Turn it into a business

[Melatonic]

That always seemed crazy to me about git. Permissions are a pretty basic enterprise offering.

Does Gitlab do better with this?

[wtetzner]

I guess it's because git wasn't developed as enterprise software.

[yallpendantools]

This. People forget a lot of Git's design philosophy harks back to the ethos of open source development. Enterprise features have made it in over the years but still mostly with the FOSS development workflow/model in mind. Also why the most enterprise-y of features (like LFS) are add-ons rather than core.

[GabeIsko]

It's pretty sad in the indie gamedev world that handling and versioning binary data is considered an enterprise feature. I understand that git was explicitly designed for source code, but it would be nice to have any open system that handled versioning binary files well. This is pretty much the only reason I am going to try out lore at some point, although I am not super psyched at some of its implementation.

[m463]

Maybe you could go to linus and demand enterprise features and support.

;)

[oneplane]

How is it crazy? It's perhaps not granular (the repository is the boundary, and that's that), but you can definitely restrict who can pull or push as easy as you can make rules for SSH.

Plenty of not-very-granular "enterprise" systems out there, it's not exactly unique to not always have full ACLs on the smallest of objects.

[pornel]

git repos viewed through gitlab's slow Ruby monolith are still git repos, so it doesn't make any difference.

[pid-1]

No.

The maximum granularity is also 'per repo'.

[1718627440]

Because code is not supposed to contain parts that are secret or specific rules: those are data, that your program should work on. Git is coming from the open source movement.

[yallpendantools]

> Does Gitlab do better with this?

Not exactly but if you're not obsessed with maintaining a monorepo, Gitlab allows you to organize your repos around organizations, which then has granular permissions. The underlying primitives is still Git, of course, so you can just submodule as necessary.

[PunchyHamster]

> That's not something that you can do in git: it's all or nothing.

That is partially incorrect; you can restrict writes via hooks but not reads; you'd need a workaround like submodules

[jmaw]

Does `--no-verify` override the restriction via hooks, or are there some kind of server-side hooks that can be used?

[PunchyHamster]

no-verify cancels local hooks, remote hooks are unaffected.

Gitolite supports per-diectory/file write access natively, for gitlab you'd probably need to write your own.

[jmaw]

Interesting. I'll have to do so reading into remote hooks!

[usrbinbash]

> Something else that git isn't good at: permissions.

It doesn't have to be good at permissions. That's what DevOps platforms that integrate git are for.

[anitil]

Your comment and the parent comment are fantastic. I'd never have thought of them because I've never worked in the field

[iveqy]

The way I usually solve this is by using git submodules.

[bigbuppo]

Oh man, I've been laughing at this for 37 minutes straight now.

[orthoxerox]

Git submodules are the regular expressions of version control.

[zephen]

When you use regular expressions, you now have two problems.

When you use git submodules, you now have five or six problems.

[SCLeo]

And every PR turns into a triple recursive reverse merge.

[contingencies]

AFAIK the issue with using submodules is you still need the rights to pull the other source repo. However, you can use submodules or LFS to pull a specific build artifact from a build artifact repo or source instead of the source repo, which provides a neat way to manage the dep without fattening the main repo and allows the source repo to be kept separate and high security. I'd certainly do this before changing RCS/VCS solutions. That said, reverse engineering has become relatively trivial in the AI age so the practical utility of providing built rather than source elements is dropping.

[Jare]

You'd have the non-NDA, core stuff in the submodule. The submodule can then be referenced by the big, driving NDA repo. And maybe another repo with a non-NDA, likely simpler "shell" that lets non-NDA devs work with the codebase.

If you need to NDA the core stuff instead and thus can't pull it as a submodule, the only thing I can think of is to pull the core as binary/compiled artifacts.

[odo1242]

You can set up submodules to not pull the other source repo by default tho

[__d]

Try gitolite?

https://gitolite.com/gitolite/index.html

It has fine-grained permissions but works with regular git clients.

[LugosFergus]

Does it actually restrict read access to specific directories? Unless I missed it, I didn't see anything in the docs about that.

[Grayskull]

"write access controlled at the branch/tag/file/directory level, including who can rewind, create, and delete branches/tags."[1]

[1] https://gitolite.com/gitolite/overview.html#what-is-gitolite

[LugosFergus]

I said read access. The point is that there’s restricted information that only some can access.

[hhsecurity]

My teaspoons are terrible at peeling potatoes.

Git has no built in authentication or RBAC. Thats not what its for. Its flat file source control.

I swear loads of people havent a clue how git works or why it exists...most of the git based cloud services out there are 90% additional crap bolted on.

[cdmckay]

I think that’s the point of the OP. Git is great at certain things but is not a one size fits all.

[charcircuit]

>Thats not what its for.

This is a weak argument you could use for any missing feature.

[1718627440]

But it's more like a fundamental design choice.

[francislavoie]

Obviously, and that's why tools like perforce and lore exist. What's your point?

[Arainach]

Perforce predates Git by a decade (but your overall point is valid)

[rowanG077]

Doesn't git crypt solve this? You can have encrypted blobs in a repo that will be auto decrypted if you have a working key.

[danudey]

That depends on you distributing working keys for any components you want to restrict access to, and managing those keys for all users, revoking them when access permissions change, etc. It's a lot more complex, more work, and harder to manage than centralized RBAC or similar.

[giancarlostoro]

People don't use git crypt nearly enough unfortunately.

[freedomben]

Agreed. I use and love git crypt, but it doesn't get enough use. I think because it's easy to screw up gpg keys. Most of my uses (for one to three devs) have become symmetric keys shared out-of-band instead of using gpg keys because we've had lots of onboarding pain even from people who are quite competent. There are just a lot of sharp edges in gpg that you don't know when you don't know.

[zeratax]

i really want to use a similar tool that uses age instead of gpg, but the ones i've tried were all not as nice to use, or very undermaintained. but idk i havent checked in a while

[everforward]

Not really, precisely because it’s decentralized. You can’t audit whether a user accessed one of the hidden files, or really even who can access it once you accept the reality of the risk that some team will put a key on S3 or a shared drive or whatever.

It’s fine for things that you want devs to be able to see without the Git host being able to see them, it’s less good at RBAC because there’s no real “identity” component at read-time.

[pcdevils]

You can use Mozilla SOPS instead with IAM roles and KMS instead of gpg. They also shifted to AGE over gpg.

[chrystalkey]

What a soup of acronyms

[lkjdsklf]

It’s the same problem. You don’t have an audit trail. That’s needed in a lot of situations for compliance reasons

[rowanG077]

Why is an audit trail interesting? I would expect its basically useless as anything that can be accessed can be copied. So it doesn't even give info of user x viewed y at some time.

[embedding-shape]

Git submodules + SSH keys is another (somewhat "homebrew") solution to this.