6 ms·

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

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 3mo ago
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?
- juancn 3mo ago
  It's kinda like that, there could be a proprietary fraud detection heuristic in there that you don't want to get out.
- hk__2 3mo ago
  Maybe that’s some scoring to decide if you should be able to pay or not with some method.
- kurthr 3mo ago
  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.
- danudey 3mo ago
  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.com/zdnn/stories/news/0,4586,2605858,00.html https://web.archive.org/web/20001216031800/https://www.zdnet...
  - formerly_proven 3mo ago
    > 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.
    - NewJazz 3mo ago
      Also Steve Jobs Apple is probably much different than today's Apple.
    - danudey 3mo ago
      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.
  - ifh-hn 3mo ago
    Sounds like a bit of a dick...
    - 3mo ago
- zer00eyz 3mo ago
  > 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 3mo ago
    Alternatively, you can also just try not to have security issues, and resolve them with urgency when they do pop up.
- user_of_the_wek 3mo ago
  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.
- HWR_14 3mo ago
  The code revealed the existence of Apple Pay, which had not been publicly confirmed.
- arianvanp 3mo ago
  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 https://youtu.be/PPJ6NJkmDAo?is=iUuJ0W9xUHF_6gTU
- edoceo 3mo ago
  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.
- kazinator 3mo ago
  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.
contingencies 3mo ago
Can confirm split repos is an excellent solution for protecting IP.
yaur 3mo ago
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.
sroussey 3mo ago
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.
Meneth 3mo ago
Banks absolutely love security by obscurity. No clue why.
- mvkel 3mo ago
  It's the most effective kind of security
- jeremyjh 3mo ago
  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 3mo ago
  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 3mo ago
    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 3mo ago
  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.
BobbyTables2 3mo ago
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 3mo ago
Could you not have placed the code in a submodule and likited access to the submodule repo ?

SoftTalker 3mo ago

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?

juancn 3mo ago
It's kinda like that, there could be a proprietary fraud detection heuristic in there that you don't want to get out.
hk__2 3mo ago
Maybe that’s some scoring to decide if you should be able to pay or not with some method.
kurthr 3mo ago
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.
danudey 3mo ago
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.com/zdnn/stories/news/0,4586,2605858,00.html https://web.archive.org/web/20001216031800/https://www.zdnet...
- formerly_proven 3mo ago
  > 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.
  - NewJazz 3mo ago
    Also Steve Jobs Apple is probably much different than today's Apple.
  - danudey 3mo ago
    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.
- ifh-hn 3mo ago
  Sounds like a bit of a dick...
  - 3mo ago
zer00eyz 3mo ago
> 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 3mo ago
  Alternatively, you can also just try not to have security issues, and resolve them with urgency when they do pop up.
user_of_the_wek 3mo ago
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.
HWR_14 3mo ago
The code revealed the existence of Apple Pay, which had not been publicly confirmed.
arianvanp 3mo ago
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 https://youtu.be/PPJ6NJkmDAo?is=iUuJ0W9xUHF_6gTU
edoceo 3mo ago
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.
kazinator 3mo ago
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.

contingencies 3mo ago

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

yaur 3mo ago

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.

sroussey 3mo ago

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.

Meneth 3mo ago

Banks absolutely love security by obscurity. No clue why.

mvkel 3mo ago
It's the most effective kind of security
jeremyjh 3mo ago
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 3mo ago
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 3mo ago
  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 3mo ago
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.

BobbyTables2 3mo ago

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 3mo ago

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