They said "lesser technical people", not "less-technical people". A more technical person might not be able to read between the lines, but a better technical person should.

Here follows the definitions I am familiar with:

"premise" - a house or building, together with its land and outbuildings, occupied by a business or considered in an official context.

"premise" - a previous statement or proposition from which another is inferred or follows as a conclusion.

(I have the privilege of worrying about this because my company uses Confluence Cloud. It's vastly inferior to our old aelf-hosted mediawiki, but at least it's not an open barn door.)

We got hit by this and had to shut down and upgrade. Atlassian are taking a while to send new license keys.

It’s incidentally also exactly why they’re often horrid to work with.

If you are maintaining the software of someone else and this software is exposed to the internet that's your responsibility to update the software. If you want your service to be available from the web and have good security, use the cloud offering, that's what it's for.

And if you don't want to use external software to manage your internal knowledge, then create some shared windows folders that nobody use and quickly becomes a mess. What alternative do your propose ?

Oh, you mean like Microsoft and Google in the examples I gave?

Why are you changing the goal posts? Your original statement was that this issue is evidence that "everyone is now aware of the awful engineering practices that underpin their products." My clear argument is that this is not the case, as lots of companies with systemically critical software also have bugs of this magnitude, or more.

Imagine being so naive as to think that documentation would be improved by e2e encryption. It's not bad enough convincing developers to write things down, now we need to explicitly share those things with every new person who joins the team?

"Sorry, we can't fix your bug for 6 weeks, Bob's on paternity and the fix is documented on his page".

> MAJOR difference between Chrome getting owned, and the program that hosts all of a company’s internal communications

There's at best 0 difference between these things. Pop chrome, harvest tokens, access Jira. Think about that for a second. What critical company information is not accessible to someone who has arbitrary code execution in your browser.

I absolutely agree that runtimes, frameworks, and server code should do a better job at trust and sanitization, but you will always get to a point where if you want to get something done, you need to do the work.

I guess I’m skeptical that eval() or runtime.exe could or even should take in lists and configs of what the code is allowed to do and monitor for it during execution. It seems like doing that would add countless issues and complexity, but more so just kick the can down the code to another layer with the same eventual issue.

Instead, they just won't update the doc at all and will pester the kind of person who does know how to use git until they do it for them. Then the doc will sit there dormant and un-updated until the process repeats.

> a bloated code editor

Have you ever used Confluence? SMH.

All those defending Atlassian need to go read this other current front page hn article: https://news.ycombinator.com/item?id=28414308 and probably lots of other articles about good documentation.

To be fair, I understand what you are saying, but the problem is you are trying to meet the needs of suits, while I'm trying to meet the needs of technical teams. I can acknowledge that git can be daunting for suits, and probably not the correct method for them to write docs, (e.g., I'm not saying force the suits to use git, even though, with a web interface like GHE or gitlab etc, this is actually quite easy and visually intuitive, no terminal or (laughing) "bloated code editor" required) but it seems the "suits side" of this argument doesn't want to acknowledge that the needs of technical teams aren't being met when they force their lowest common denominator tool on the entire org.

That difference would undoubtedly have saved every single company that was affected in the current story.

Perhaps you should consider that not knowing a thing is very, very different than that thing not being true...

That said, I can't think of a single feature Atlassian released in the past several years that made the experience of using Jira or Confluence substantially better. (I could at least say markdown support if that was ever ported to Jira Data Center.)

The argument for software subscriptions is that it funds continuous improvement, but most of the top complaints from 2011 are just as relevant in 2021.

Access the janitor's account on the facilities Jira, which is all that runs on an old Pentium II in the broom cupboard and you get one set of benefits; access the CFO's on the Big Money Server and you get something else entirely. How on Earth did you manage not to realise this by yourself?

Both I and another colleague looked at the issue when it first came out and decided we were “safe” for a bit based on the initial communication. Many IT/IS teams were probably scrambling over the long weekend to patch this issue.

Just a note on this, this is something I'd like to build in eventually. It's just that each layer of our own we add upon the underlying methods increase the risk of error in something fairly critical.

A simple command-line based backup solution wouldn't be too difficult to add, but restore and admin-panel usage are more significant challenges once you get into it.

One of the main things to consider with BookStack is the semi-fixed Shelf > Book > Chapter > Page structure (Where pages have content, chapters & shelves are optional, and Books can be within multiple shelves). For some this structure is limiting, For others it helps drive organization.

[1]: https://www.bookstackapp.com/

There really isn't that many alternatives, SharePoint maybe, but then you're just suggestion something worse.

I had the impression that in a zero trust environment all apps are required to be hardened to the point that they are deemed safe to be exposed to the publc internet.

I mean right this minute there's a privacy-focused SaaS on the front page for not being as private as everyone thinks. There's also a network hardware vendor on the front page for including back doors. A philosophy like "SaaS vendors know they can't allow security breaches" is really glossing over the need for layers of security and knowing that it's ultimately all on the trustworthiness of specifically who is involved.

As an engineer & former manager, there are definitely things I didn't like about Jira like slowness, but everything else I investigated/used were worse in multiple significant ways.

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.

The last time we reviewed the Atlassian Cloud hosted products, they did not meet our security needs (requirements include isolated tenant from other customers, customer managed keys, etc) though they were much closer than a few years earlier. We also review the general security practices of the company (for example to make sure they implement a secure SDLC and follow other security best-practices).

Example: If you are a semiconductor manufacturer, you probably are not going to be storing all the documentation about your bleeding edge fabs on a cloud provider.

In short, that’s not happening for a wiki.

XWiki?

You're theoretically more in control of the data, which may be a legal requirement in certain jurisdictions and/or industries.

There's a fair few reasons other than this, it's not unthinkable to host servers yourself if you already have other servers on-prem anyway.

- Cost, VPNs and the hardware to run them can be expensive

- Single point of failure. If you run all your remote access through a VPN gateway then you run the risk of disruption if it goes down. Of course you can implement redundnt/multiple gateways but that increases cost.

- Complexity for B2B setups. If you're exposing an API and you want third party services to access it, it can be more complex if there's a VPN involved.

All that said, I still wouldn't run something like this (or indeed most services) directly on the Internet as it's a single vuln. away from problems, however I've seen plenty of services directly visible on the Internet for these reasons. You can spelunk around one of the search engines like Shodan or Censys to get an idea of how many people run application services directly on the Internet.

being connected all the time sucks for zoom meetings as the vpn server is on the other side of the continent.

I love having access to most of my work tools outside the vpn - github, confluence, jira, aws console.

- you can edit a paragraph without locking or creating conflicts for the whole page

- it is much faster, and as far as I can see the observe–orient–decide–act loop is a real thing and should be taken into account

- much better wiki syntax (compared to old Confluence)

- trivially extensible so you can create forms and other helpers to make it simpler for users to do the right thing

- if one absolutely need it I think there exist at least one wysiwyg extension for Dokuwiki

This is unrelated to any mailing-list change, since both were sent from/to the 10991049.xt.local mailing list.

Search for the header entry `List-ID: <10991049.xt.local>` in your Sep 4 email. If it came from that list, the one from Aug 25 will very likely have been lost during transit.

I use their products in the 10-user license program since 2016 and got automatically subscribed to their mailing list back then, and never made some change to the subscription. I'm receiving emails from that list since 2020-10-17.

On the 2020-07-10 I got a mail from them telling me:

```

Subject: Please double-check your contact details for Atlassian

Making sure you don't miss important emails

Hi,

When you purchased your Atlassian products, we asked for the contact information for two types of people in your organization:

Billing contact - A person we contact with invoice and billing information

Technical contact - A person we contact about product changes, security advisories, etc.

We don't want your company to miss out on important information from Atlassian, so please take a minute to make sure your contact information is current. Here's what we have in our system:

```

I’ve always found government, sensitive customers (banks, payment processors, healthcare) and big spenders get prioritised with phone call notifications.

However with a deprecated product, the financial impact is so minuscule - leadership won’t prioritise this one unless you’re big fish.

Ordinary text blah blah {{interspersed code snippet}} some more ordinary blah blah text

working, or haven't you tried it?

It wasn't atlassian that "came along" - someone penned down an agreement and, from what it sounds, there was a lack of clarity both in regards to current and future principles of work and collaboration.

What we can do, as devs, to protect ourselves from the madness you describe is to be explicit about our work processes and their purpose. Nothing much, but just a set of agreed upon principles and ways of working which should have nothing to do with tools.

What you end up with, by being explicit, is for having "something" to be supported by one or several tools.

Makes it easier to evaluate, select and change tooling that is fit for purpose.

then they get promoted, and may never learn / experience why a task / defect tracker is not where you store requirements / design.

(note: the above comments are for long lived software only. it you rewrite your web site from first principles every you, do whatever. it doesn't matter)

Ohhh found the non power Jira user! Gitea is good enough for your org. Without knowing your requirements this is pretty much a blanket statement. Gitea is nowhere near good enough for a large engineering org.

Example: groovy integration with Jira allows an enterprise to build their own custom workflows. Like integrating with your Vcs to enforce funded work (requiring an open Jira issue in git commits). Features like this, until recently, left them in a league of their own. GitHub Actions has leveled that playing field. Gitlab and gitea can fight it out with bugzilla, but you won’t find them in most engineering orgs.

Another example: building out complex dev roadmaps ahead of time with constraints and relationships. Bridging the gap between dev, product, and project management

Well first its interface, if a non technical user can't user the tool that's going to be a big problem. Confluence has not the best interface but still better than Xwiki. The best the interface the better the adoption as a whole in the company. And for knowledge sharing adoption is critical. That's actually why Notion has been such a success recently. Even though their product is average, people want to use it, because they like the interface.

I don't have the time to do a full comparaison of other features, but wiki tools are in usage very different than collaboration tools. Can you have the list of last consulted documents ? Can you embed external documents ? ... Kind of the same things as Slack vs IRC

Also, regardless of whether or not I received the mail, the initial mail stated that only authorized users could exploit this. So Atlassian did not inform any of their users fully until Sep 4, whereas they were well aware on Aug 26 that the vulnerability was exploitable by anyone.

Either is was Atlassian's mailing list software which did not attempt to re-send the email to you after it noticed that the connection got dropped (should that have happened), or is was Microsoft which dropped the email after receiving it, but before storing it into the database and assigning it to your account.

You cannot know who is responsible for this delivery error unless you ask them directly.

Would you care to give us alternatives, for example, to the JIRA bug tracker (which I used a lot, slowly :-))

Thanks

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 specify how tight all the tolerances should be, and we had recently added in 0.0005 inches to the options, at the request of a customer. I left for a month to do training at another location and came back to find a ridiculously long backlog of work. The manager who'd stepped in for me had decided that tighter tolerances would make better products, so was selecting 0.0005" tolerance for every feature on every part.

To make up for how ridiculously slow that made the machining process, he tried to micro-optimize work flows, readjust hours, push machine operators to "work harder". He wasn't a bad person, was an okay manager, we'd just given him the option of doing something stupid, and he'd done it then tried to use his managing skills to make it work.

If you give someone the tool to do their job, make sure that misusing it feels hard.

Our support board has customized forms. These forms create tickets that can seamlessly be moved to our scrum board once they are vetted. We use JQL to manage a lot of the boards we use. We have custom workflows for different ticket types. We use the comprehensive access controls to grant partial access to users based on custom roles.

None of this rigidly enforces our workflows (aside form access control). Instead, it streamlines sharing information across departments.

When it comes to a company wiki system, Confluence is extremely hard to beat. (I’ve use so many wiki systems. Dokuwiki is my goto.)

All of these systems use a single user account. We use single sign-on, but we don’t have a large IT department to manage the dozens of services we access every day.

People are like”use the shiny thing” forgetting the existing thing has, you know, stuff I actually use.

The full sentence:

> 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.

I.e., because the software is available for on-prem deployment, we have experience deploying, managing and debugging it, and therefore know that it is garbage, and we can apply this knowledge to conclude that their cloud offering is garbage.

It does not say the product is garbage because of a CVE.

Maybe I should measure it and post somewhere, I thought it was a well-known problem but maybe there’s something different about our setups.

But every sufficiently complicated product will have defects of this type, and a higher probability of defects does increase the probability of CVEs.

So, it follows in practice, as can be seen by looking at CVE rates from projects with high defect rates (web browsers, kernels, ...) vs projects with low defect rate.

Note that defect rate differences can be caused by multiple things.

I used both FogBugz and Kiln at a previous employer, and I really liked FogBugz, but we had nothing but problems with Kiln. We had a fairly large team (maybe 75-100 people) and a good sized project (maybe 300k lines), and it was painfully slow to do anything in Kiln and it was down/broken at least once a month. It wasn't so bad early on when we were small, but it didn't scale with us very well.

My point is that it is experience acquired from managing these for a decade. If you wish to acquire this experience you need to run it, which is now even costlier than it used to be.

A tool is not responsible for this breakdown. Lack of clarity around ownership and responsibilities is, by the look of it.

IM humble O.