Atlassian products (Jira Server) are no longer supported, and their more Enterprise offering dies in 2029, so everything is ending up in their cloud now yeah.
I know a lot of companies vibe-coding alternatives. I'm not an expert but it's perhaps even illegal for most European companies to migrate any customer data to Atlassian servers.
If someone wants to vibe code an alternative to a SaaS tool, my gut feeling is "no, this is bad and it will blow up" as vibe-coded projects tend to do.
But then the alternative is often paying $X million per year for licenses to a half-assed program that hasn't had a UI update since 2005.
I just don't have a good argument on why they shouldn't when the outcome will be just as dogshit, only cheaper and flashier.
They just started updating the UI and I am pissed off.
I don’t want them to change UI. I have plenty of work to do and have plenty of other tools that I use daily.
I have my workflows, I am swamped with work and now I have to change my workflows because someone changed options in UI where ones that O used are not there anymore.
I think there's ways to have a solid app by giving ai precise instruction about the architecture it has to follow. Especially by configuring read-only agent for security and quality and builder agents for everything else. It isn't perfect and I wouldn't do critical apps for a company with it but it's solid enough to replace a SaaS tool in my opinion. I think the real subject is wether this vibe-coder knows he'll have to maintain his app...
I'd pay embarrassing amounts of money for applications which do not get biweekly UI overhauls.
I'm still using the 2024 version of JetBrains IDEs because the UI hadn't changed in over ten years. I quit paying JetBrains when they ripped out the perfectly functional UI and replaced it with a VSCode reskin.
Please, for the love of god, give me software with a consistent UI.
Atlassian is a US-parented company and this means that CLOUD act can affect it. Even this only can make it unsuitable. Then there are questions to data-in-transit. Also nothing is legally tested. Vibe-coding an alternative is much safer if you have sensitive customer data (even simple support tickets).
This person is just posting absolutely baseless claims, as if Atlassian, a company that basically exists purely on the back of B2B SaaS sales, has not considered EU data residency requirements in their core product offering: https://www.atlassian.com/software/data-residency
FWIW nearly every SaaS or IaaS is making bold claims about supporting data sovereignty, but unless it has been challenged in court I wouldn’t put much stock into it.
The fact that Jira/Confluence are being processed by their LLMs puts them in direct legal conflict with several statutes in the EU, its a matter of time for them to get hit by this and I’m betting that they think the fine will be lower than the revenue they acquire for doing it- and they’re hoping they don’t get hit at all.
This seems to be the common case for a lot of the non-EU tech companies, and it seems to be working.
Oracle is currently the market leader in “sovereign” compute for EU governments for example, as ironic as that is.
> This person is just posting absolutely baseless claims
You don't need to be so hostile. I know about the EU requirements but many EU companies have sensitive data on hosted JIRA / Confluence that simply cannot be in the possession of a non-European company. I know because I'm working for one. I cannot even remote-work from outside Europe. Some stuff cannot even leave the VPN. There's also the CLOUD act.
Yeah I thought Jira at least was all built on AWS these days. I've never set up a Jira Cloud instance but I'd be surprised if you don't chose where your data lives.
In short gdpr compliant means you can configure it but it must not be compliant by default and also there is no guarantee.
They are constantly changing their software and settings. More than once they believed that something is legal but can be risky for the atlassian customer.
For example training AI on metadata which they believe are anonymized but are maybe not enough changed.
Training data or metadata permisson can not be configured on all subscriptions. But as a data processor they must follow the contract otherwise they become data controller.
Also there are risks associated with privacy data framework, cloud act etc. to be non compliant just by data transfers to other countries.
If your PHP application accesses a database, you've got exfiltration, it doesn't matter in this case. Unless your PHP application is just echoing non sensitive data (i.e. rendering md files)...
It's a RCE bug, it does not matter if you disable php functions. It's not arbitrary PHP execution, it's an exploit chain resulting in arbitrary code execution.
Indeed, an attacker theoretically can access anything the PHP process has permission to access. However even without limiting permissions (also a good idea) that means the simple/published exploits won't work on your server, and there's a high chance criminals will look for other targets, assuming you're not targeted.
Presumably this makes SELinux enabled distros like fedora are significantly less vulnerable, as the PHP process can only access files in a few contexts?
By corrupting memory and causing the CPU to jump from the intended instruction to a different one controlled by the attacker, at which point their instructions control what your process does next. Getting shell does not mean getting it to feed a spicy string to system(), it means tricking something in the process into overwriting memory with bytes that, if read as instructions, tell the CPU to make a system call to spawn a different process running arbitrary code.
You could do that to an internet-connected toaster with a JPEG. The system() function has nothing to do with it.
What is lower than what? This exploit causes the flow of control to reach zend_call_function with the argument "system". It works at the PHP level and having disabled that function is an absolute defense against the exploit.
It isn't 1998 any more and you can no longer just inject shell code on the heap.
Look, at the end of the day, every major security researcher is going "oh shit" and no amount of tweaks to your configuration is going to limit the blast radius in a way that will actually matter. You're going to need to update PHP, that's the _only_ solution to this problem.
"Shell" in security parlance is just a standin (or the standard benchmark for) for arbitrary unrestricted code execution. If you can launch a shell you can do anything the process user can.
The biggest frustration for a lot of people is that their municipalities use Twitter almost exclusively to communicate with their constituents, it _sucks_. I've pleaded and begged my city and county to have some other form of communication, in addition to Twitter/X, to mass distribute information.
reply