Hacker News Reader

Hacker News

Comment by piker | Hacker News Reader

Parent Full thread

piker

Drupal. Interesting choice in 2024

View on HN

Not really, most government websites use it. It’s still very popular.

Most? Source?

https://groups.drupal.org/government-sites

https://www.acquia.com/blog/drupal-for-government

https://www.drupal.org/industries/government

https://www.zyxware.com/article/6229/top-7-reasons-why-drupa...

https://www.drupal.org/openplus

https://www.applytosupply.digitalmarketplace.service.gov.uk/...

Now most may be a stretch, it's a hard metric to calculate without going around and counting every gov site. But for English speaking countries, it is very popular enough so that I'd say most gov/state/department websites are Drupal.

That and I am a Drupal consultant. So I may be biased.

Wheels remain an interesting choice in 2024 as well.

I agree. Unless Drupal redesigned their core, the way plugins and themes work is insecure by design. Similar to how software was back in the 80's where it was assumed no bad actors were running within the environment, and due to that assumption every single thing is available to be mucked with.

Is there a CMS with such an ability?

Plone was closest I saw, also run by several gov agencies, but drupal popularity won out to due to ease of staffing.

Yeah this is why you use a php platform like laravel which actually is engineered to build abd extend rather than say WordPress with an insane plugin system

Drupal is way more similar to Laravel these days (Drupal is now also built on top of Symfony) than WordPress.

> the way plugins and themes work is insecure by design.

Tell us more. (A lot more. "Extraordinary claims require extraordinary proof".)

Anytime any plugin does anything, the submission of that "anything" into the Drupal subsystem proceeds to pass that plugin's payload to every single plugin in the system so they can make modifications. What those modifications are, you do not know, they are just applied and then your modified payload is accepted into the subsystem to modify whatever it modifies.

If you are installing rogue code then you will have a bad time.

Modules/themes on drupal.org which show "Stable releases for this project are covered by the security advisory policy" are written by trusted users. There is no other protection from rogue code because they are inherently able to access the database. It utterly doesn't matter what extension points the code supports and how because of that. In very broad strokes, if you are using any CMS which a) accesses a database b) allows installing additional code and it runs that in the same process as the CMS code accessing the database -- then you are vulnerable to rogue code. Like, a headless CMS where the frontend only talks to it via an API is protected from rogue code in the frontend part but that's about it.

This means the Drupal ecosystem is vulnerable to a supply chain attack, yes but ... um ... that doesn't make Drupal design insecure, does it?

Consider that often, far too often, a hierarchically senior non-tech individual mandates that various plugins be installed, without security checks or plugins that fail security checks, but that manager/c-suite individual demands the change. Far too often.

Most of the time they will go from drupal.org luckily there's very little else

And once again, what does rogue code has to do with Drupal? Nothing. The same would happen with almost any system. Name any CMS which is actually used in the wild and doesn't get compromised if you install rogue code right into the codebase.

You don’t have to use third-party plugins or themes though?

I mean if you built a site from scratch in Spring or Next.js and you start using third-party libraries or UI frameworks, all those third-party bits have full access to everything too.

Reply on news.ycombinator.com