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.
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.
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.
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.
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.
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.
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?
Most people don't like wire and don't care about genuinely good sound through wire vs. artificially sweetened (DSP-ed) sound through Bluetooth. That's what Apple is targeting at, the mass consumer.
Honestly that "most people" seems to be more marketing driven than real opinion.
When you simply can't purchase one thing, then you move to the next thing.
I have several wired and wireless headphones, all for different uses, and the existence of wireless headphones don't make the wired ones less useful for their particular strenghts.
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.
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.
Apple Pay works on any terminal that supports NFC tap to pay payments. There are thousands, tens of thousands of terminals in the US that are not "Apple Pay" that you can use it on
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.
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).
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
You can combine the push step. A submodule intentionally follows a different development/commit/version cycle, otherwise you are supposed to use a subtree.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
