Earlier quoted context omitted.
You are missing the point entirely. Any sufficiently complicated product will eventually have major CVEs, as you say. Anyone having hosted Atlassians product know that these products are nothing but garbage fires on the inside, as the commenter above said. Both of these statements are true and not mutually exclusive in any way.
Where may I learn more about exactly how they are "garbage fires on the inside"? Thanks
US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing
221–230 of 344 posts
Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing
#222Earlier quoted context omitted.
And I've witnessed first hand the truly garbage nothing changes after adopting Jira and Confluence - a wasteland of process management through bad automation and forgotten wiki articles with Write Once Read Never behavior. Nothing Atlassian does is that much better than past tooling, it all comes down to how you want to run your org, what discipline you apply, and where you apply it.
I'm no fan of Jira or Confluence but you'll get forgotten wiki articles, for example, no matter what tech you choose. Confluence? Forgotten Git repos? Forgotten Notion? New hotness, still forgotten Google Docs / Office 365 ? Forgotten This is just a difficult problem to solve, especially for organisations growing at speed.
Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing
#223Earlier quoted context omitted.
> The good thing about the fact that Atlassian offers both on-prem and cloud versions of their offerings is, everyone is now aware of the awful engineering practices that underpin their products. Regardless of what one thinks about Atlassian, this is a completely ridiculous bullshit statement, and anyone who works in the world of business software knows it. I don't think there is a company out there that hasn't had c…
I don't remember a company like whatsapp having this kind of problems.
Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing
#224Admittedly low-value comment: Can we appreciate the amazing vulnerability name? Confluenza. https://censys.io/blog/cve-2021-26084-confluenza/
Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing
#225> The vulnerability only affects on-premise servers, not those hosted in the cloud. This is a dangerous statement to make and should be revised to say: > The vulnerability only affects standalone versions of the software, not the managed service of confluence provided directly by Atlassian. The problem with the former is that lesser technical people, especially directors, might assume they're fine because their stand…
We got hit by this and had to shut down and upgrade. Atlassian are taking a while to send new license keys.
Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing
#226Atlassian was so kind to update their mailing lists somewhere over the last year or so. Previously, they would email the 'technical contact' of the license about any vulnerabilities. They quietly switched to some other notification system and never informed us about it. Hence we missed the update and got a free Bitcoin miner. Thanks Atlassian, I'll make sure to get your products out of the door as soon as possible. […
Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing
#227Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing
#228Earlier quoted context omitted.
So basically you are describing an organization of people that don't really understand what they should be doing. People led by a tool and not the other way around - and you blame the tool? I hear what you are saying, and I've seen the very symptoms you're describing - I've just stopped chalking it down to the tools. It's a symptom of something entirely different and much more challenging to deal with than a change i…
If you provide a tool that let's managers easily and arbitrarily increase the requirements on their employees, over time they'll continue to do so, because it's a management tool and their job is to manage. I experienced this phenomenon when I was a designer / CNC programmer. We had a form for requesting a part to be designed and machined. It had a box for tolerance allowance, where the person requesting a part could…
Why on earth would a manager be allowed to set tolerances like how you describe, tool or no tool?
It makes no sense and is first and foremost a management and cultural issue. Second a work process issue. Solid third, one of competency. Probably ways below numerous other problems lies the tool.
You obviously needed to be able to set tight tolerances for some work, so… you seem to need the setting on occasion.
These stories just blow wind in my sails!
If you have management like this (american?) you must be measured like crazy - set goals based on metrics that will push things in a direction you see effective.
Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing
#229Earlier quoted context omitted.
Because Jira is flexible and has the needed features and integrates with most things you care about. To the point where everyone in the org can tolerate it. Alternatives tend to focus on one group of users and the rest HATE the product. I've tried a lot of these products and in the end come back to Jira because it works better on average for everyone.
This comment nails it - anyone who has had to investigate other offerings that satisfy the needs of project management, design, and engineering will quickly find that all the other options out there are total garbage in comparison to Jira, which is why Jira remains at the top of the totem pole for what it does. As an engineer & former manager, there are definitely things I didn't like about Jira like slowness, but ev…
Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing
#230Earlier quoted context omitted.
Atlassian products are vast, integrated, and support all the crazy draconian processes that every insane project manager wants to implement. You can't easily dump Jira if you are using Jira, confluence, bitbucket, and whatever their CI/CD product is called (bamboo?)
How many PMs actually use those features? In my organization, for example, I don't see any reason why we should prefer Atlassian over Taiga, other than familiarity and inertia.
It isn't the set of features that makes them sticky. It is the 10% of features the lead PM can't live without, and the slightly-overlapping-but-different 10% of features the team PM's can't live without, and the slightly-overlapping-but-different 10% of features the developers can't live without, and the roll-up report features the leadership team can't live without... There has been some research into this phenomena [1]. I'm not aware of a handy term for the phenomena, would surely appreciate someone pointing me to it, and the industry recognizing it and building for it, though.
Internally in my head I call it "multiplexing feature sets". Though I never say that aloud and just give the long-winded explanation if I have to bring it up in meetings.
> ...I don't see any reason why we should prefer Atlassian over Taiga, other than familiarity and inertia.
In large-organization dynamics, never underestimate the familiarity and inertia factors. I regularly see vendors screw this up so badly. Account management teams of even large organization vendors (so they should be taking action upon this, but apparently are not) regularly have no clue what kind of massive red flag it takes to push their decade(s)-entrenched product from "man we wish this could be better" to "you really need to fix this, or we need to start looking elsewhere".
How do you tell when a customer is just kvetching and presenting empty threats, or is laying it on the line to you? Easy: the customer is happy to share with you specific details of how the product shortcomings/defects are impacting line of business processes and the business impact (ask for this under the cover of learning what the critical business impact is so your support teams can devise the most appropriate tactical technical solution for immediate partial/total relief), and is eager for live working sessions with the customer's engineers.
And understand this: rarely will a customer reveal they have switched away until it is practically finished. They want to maintain what little interim support quality they have left, until they can step off. If your account management practices engage "all hands on deck" priority support when you get wind of a competitor in the wheelhouse, then you've lost before you even started. That's why the reveal is always a shock to vendors, and always a done deal when it is shared.
The time to understand that your product and product support consumption experience for a particular set of customer needs is horribly broken is when you notice a customer requesting product support leadership engagement more than 2-3 times in a year. If you aren't tracking those engagement touch points, then I guarantee you are losing license sales. They just don't show up in the sales metrics.
[1] https://www.sciencedirect.com/science/article/pii/S187770581...