Not to mention a lot of the subsequent requests when loading https://www.tesla.com/ contains the HTTP header+value "x-generator: Drupal 9 (https://www.drupal.org)"

So yeah, not exactly a secret.

And for the lay man: https://builtwith.com/tesla.com .

Haven't seen Drupal in the wild for years. Good on them!

Probably you have, lots of websites still using Drupal, heavily customised of course. Search for "websites made with Drupal" and have your jaw dropped, as probably a website or two you visited recently will show up :)

Then you aren't visiting too many US government sites , most of the are on Drupal.

More to that point, see https://www.tesla.com/MAINTAINERS.txt

You can compare it to the current version of the same file in the most recent Drupal release https://github.com/drupal/drupal/blob/9.5.x/core/MAINTAINERS...

D10 will be out soon :)

Is this a normal Drupal practice? You just deploy the Git repo?

I think, generally speaking, it’s a PHP standard practice and more broadly a scripting language practice, though it doesn’t really apply to Node.

No pre-compiling is required, so you just ship the files. Especially true for anything that offers an Apache module (like mod_php).

Ship the files sure, ship the top-level folder not really. Most sites will have a "public" subfolder or equivalent, so the READMEs, scripts, sources etc don't get served. Either way, a professional would remove those files or block them at the HTTP server level.

Ehhh, I don’t know if I agree that most will have anything.

> more broadly a scripting language practice,

I can tell you it's not the case with Python.

Interesting, because that and mod_python were what I was thinking of aside from PHP. What’s the workflow there like?

Well, I mean, that might have been somewhat standard practice with mod_python the last time anyone used mod_python, which I would assume was about 15 years ago.

Looks like it's been dead since 2010: https://en.wikipedia.org/wiki/Mod_python

In practice, I think modern Python webapps usually use WSGI or similar, where you wouldn't be just dumping a bunch of files somewhere.

Modern PHP apps also would be using Nginx and phpfpm, but it ends up being the same - copying files over.

So the unusual thing about PHP (and, historically, mod_python, and CGI for that matter) is that it's normal to have the code actually under the web server's content directory tree. That is, if your content root is /var/www, then you put your code at /var/www/thing.php, so a deployment involves copying stuff into /var/www, and if the server is misconfigured, going to "https://example.com/thing.php" will actually show you the code.

For, say, Java or Ruby web apps, your code is more likely to live elsewhere (people love to fight over exactly _where_...), and run its own web server; nginx or apache or whatever will then proxy requests to that webserver. No matter how it's configured, you're never going to show the end-user the code, or extraneous files like .gitignore. Python's a bit of a corner-case (or at least it used to be last time I worked with Python webapps about a decade ago); it's customary to use WSGI or similar rather than a proper web server, but the effect is much the same.

That is very much not standard practice for PHP since about 10 years by now. Applications have a designated web root directory and an entry point that boots the application - as php is serverless by design - which is sometimes placed inside the web root by convention, but that is neither a requirement nor a security risk.

By now, stateful application servers are also powering modern php deployments: They also listen to a socket, and keep parts of the application in memory, next to an event loop.

Generally very much like Rails with a running process that could be standalone or with a web server interface module depending traffic or other requirements.

I don’t know, my servers are generally configured to serve nothing more than the index.php file and anything in the /public directory. I don’t serve up the entire content repository.

Do you deploy confidential information into the repo ? That would be the root problem.

Things don't have to be confidential to be an issue. Leaking the actual maintainer's names (as opposed to the Drupal list), for instance, would not necessarily be considered confidential, but still an issue if it showed up.

Usually passwords or keys are stored in a config file, and that is stored in a place outside the repo.