"easiest/low tech" would be some sort of unix file-locking and inode. Only works if you are on the same host machine though...AAAND sounds like it would be quite hacky.
For example working in west Germany is quite different to working in east Germany. The same goes for north and south Spain, north and south Italy, and so on.
It's not just by region, but at the city level too. There are often significant differences between salaries in capital cities vs others, as one would expect.
The cost of living is different, larger companies in major population centers have more capital, etc.
I wouldn't say that last bit though. So much code fails outside of the origin country, also from e.g. Dutch coders even though we're well aware how small our country is and how much we rely on trade and collaboration. People across the EU come into the country so you'd need to support other languages, payment methods, currencies, special characters in names, date notations, address formatting, timezones, phone numbers, etc. Part of Belgium even speaks the same language so the barrier really small, or even across the atlantic ocean where there are more people "in" The Netherlands except nobody ever realizes that a part of the country uses the US Dollar as its currency and is in a very different timezone.
Now living in Germany, they even translate timezone names. Not only do you have to look in a timezone database to figure out what a MESZ is, when the timezone database says "there is no such timezone" you have to realize you need to look in a German translation of it. Very approachable for the international people that need to know which timezone that German picked for the meeting invite
Which is all to say: sure, people know other countries exist and are more likely to need to learn to use localization, but by default it's not like everyone knows how to do that
> Lest everyone using any flavour of Linux is liable to the same problem?
If by that you mean, if you are using Linux in production servers: You may use GPL software in a commercial setting. The source code part only applies if you are distributing software that contains GPL code.
> copy pasting chunks of code from one place to another and then modifying those chunks
That's not how you program. I've never seen anyone programing in this way unless they were just starting.
Edit: if you find yourself copying chunks and modifying them, you probably need to create an abstraction.
Don't mean to be rude, just honestly that is my personal experience.
But what if AI is better than humans, it will provide you the best service and out perform even the best human in the universe. then? would you still decline this AI ?
> A surprising number of websites still expose their .git directories to the public. When scanning for such exposures on a target, I noticed that the .git folder was publicly accessible.
[...]
> With access to .git/config, I found credentials, which opened the door to further exploitation. I could just clone the entire repository using the URL found inside the config file.
The URL with credentials was found in the `.git/config` file, defined in the [remote "origin"] section. This is the way they won full access to the repo.
I don't see how this is specific to "exploiting CI / CD Pipelines" when he's really just exploiting someone encoding their github username AND password credentials (unorthodox af) into the url for remote.
Yes, that first part was not. But the article continues like this:
- they use that credentials to make a commit adding malicious code to the CI pipeline
- The rouge pipeline job adds their public SSH key to the `.allowed_keys` file in the production server
As the pipeline is run automatically on push, they get ssh access to the remote server.
That is the "CI / CD Pipelines" bit. That being said, it's a bit underwhelming, because given the title I though they were going to exploit a bug in the CI/CD software itself. I don't know if I'd call that "exploiting" CI/CD software.
Because 1) the .git directory was deployed with the app code (the exploit vector), and 2) the deployment pipeline automatically integrated and pushed the attacker’s commit to a production system (completing the exploit), I’d say that claim is accurate. These are both defects in the thing the attacker claims to have exploited.
It sure wasn’t a good decision to use git-config to store creds for CI though! I wonder if OP found a developer’s old cached creds in the history that weren’t used anymore but happened to still be valid?
This was before the hook era.