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.
Keys, secrets, etc. yes. But code? What am I missing here?
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...
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.
But yes, relevant details.
People who moved to bluetooth got arguably worse sound quality.
For wired headphones, there were very few lightning headphones and they mostly sucked.
Now with usb-c you can get a broader range of headphones (because other phones have gone with usb-c).
either kind needs a dac inside the dongle, or the shell of the headphone, or have a bulky external dac.
3.5mm is still king for decent wired headphones/earbuds.
https://www.cnn.com/world/wired-headphones-comeback-spc
https://mashable.com/article/wired-headphones-instagram-acco...
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.
All my three phones have a headphone jack.
I don't have or plan to have an iPhone.
That's kinda a no-no for partnerships.
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.
> 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.
People use it everywhere here, just because its easier than carrying around a card.
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'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.
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.
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.
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.
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
Unfortunately there are many people who think git is a panacea and is suitable for all version control tasks of anything.
I'm just asking questions!
If you're making the point that there are multiple confounding factors to just about any non-trivial problem, then I agree.
Does Gitlab do better with this?
;)
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.
The maximum granularity is also 'per repo'.
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.
That is partially incorrect; you can restrict writes via hooks but not reads; you'd need a workaround like submodules
Gitolite supports per-diectory/file write access natively, for gitlab you'd probably need to write your own.
It doesn't have to be good at permissions. That's what DevOps platforms that integrate git are for.
When you use git submodules, you now have five or six problems.
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.
https://gitolite.com/gitolite/index.html
It has fine-grained permissions but works with regular git clients.
[1] https://gitolite.com/gitolite/overview.html#what-is-gitolite
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.
This is a weak argument you could use for any missing feature.
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.