The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.As a general deployment practice, my company, finds it helpful to remove the .TXT files from the Drupal root before production deployment. While this is a bit of security through obscurity, it does make it harder for scripts to identify version and other details about the Drupal instance. Would be great to have a patch to core to eliminate these files and include it in Guardr.
| Comment | File | Size | Author |
|---|---|---|---|
| #74 | guardr-remove-changelog-txt-1878172-74.patch | 111.52 KB | catapipper |
| #72 | guardr-remove-changelog-txt-1878172-72.patch | 111.39 KB | catapipper |
| #65 | guardr-remove-changelog-txt-1878172-65.patch | 109.54 KB | shrop |
| #63 | guardr-remove-changelog-txt-1878172-63.patch | 210.38 KB | shrop |
| #62 | guardr-remove-changelog-txt-1878172-62.patch | 104 KB | shrop |
Comments
Comment #1
shrop commentedAttached is a patch to remove the following files:
Feel free to comment if you feel like we should leave any of these files in place. It was easy to remove all as a start. I wonder if it will be good to leave the LICENSE.txt file in place for licensing reasons, but will await input from others on that subject.
I have included this patch in the current Guardr dev snapshot release 7.x-1.x-dev so it can be tested and reviewed easily.
I will leave this open for a while for review to take place.
Comment #2
shrop commentedThe previous patch was created against the current tip of the master branch for Drupal and will not apply correctly. This attached patch below works against Drupal 7.18. I have also updated Guardr to use the new patch. Continue to review and comment on this as you wish! :)
Comment #3
shrop commentedA tip to help in the same vein as this issue, make sure to use the --no-patch-txt switch when using Drush make so you don't have any PATCHES.txt files generated for projects.
Comment #4
shrop commented@tecto brought up a good point on LICENSE.txt. We need to make sure that the d.o packaging system still slams the LICENSE.txt file into packaged downloads. If that doesn't work, we will re-patch so LICENSE.txt remains during drush make builds.
Comment #5
shrop commentedAlso, it looks like with each Drupal core version update, we will need to roll a new patch for this purpose.
Comment #6
deekayen commentedThere are going to be information leaks of some sort, like
CHANGELOG.txt is the main concern I think since it is the only thing that has very specific version information, though it'll be the hardest patch to maintain. I think keeping the other files would be about as informative as some other directory trolling a malicious user could do. Just whack CHANGELOG.txt?
Comment #7
shrop commentedThat makes sense to me. Here is a patch which just removes CHANGELOG.txt created against Drupal 7.18.
Comment #8
gregglesIMO this isn't super worth it http://drupalscout.com/knowledge-base/hiding-fact-your-site-runs-drupal-...
If someone wants to fingerprint the version they can use the CSS/JS/existence of a vulnerability to do it.
You're welcome to go ahead, of course. In practice there is some value to some levels of obscurity in terms of stopping a less skilled/determined attacker.
Comment #9
shrop commentedThank you weighing in on this @greggles. I hoped you would.
This "security" technique may also make some auditors happy. I agree that is is obscurity and can't be counted on to stop someone with determination to target a site or app running Drupal. I definitely want users of this distro to understand that fact. My hope is that it may stop some scanning tools which just target CHANGELOG.txt.
I don't think it hurts anything to give this a go for now, but it is an extra patch we have to roll with each Drupal core release. So, in that sense, it may be more of a maintenance headache for Guardr. We need to watch to see how it works out.
Comment #10
gregglesYeah, I think the only drawback to doing this is that it makes it harder to know what version you are using. That said...we've long had info files that have the version in them and that seems like a good solution to knowing what file you are running.
So, yeah, I'm in favor as long as the caveat is known.
Comment #11
deekayen commentedI don't ever remember opening a changelog file to see what version I was running; it's almost always the core status page.
Comment #12
gregglesIt's moot since we all agree, but http://drupal.org/node/139617#comment-226263 http://drupal.org/node/186927#comment-2077518 http://drupal.org/node/55388#comment-104761 http://drupal.org/node/36129#comment-65500
Comment #13
gregglesI should say, those were the first results on google for "what version of drupal am I running site:drupal.org" - I didn't cherry pick them :)
Comment #14
deekayen commentedI think security and convenience have an inverse relationship.
Comment #15
gregglesAgain, it's not really relevant to the conversation, but:
I couldn't disagree more. The use of l() to create links is way easier/better than concatenating things together and it's also more secure. A well designed solution makes it easier to do things the more secure way.
Comment #16
shrop commentedAttached is a patch to remove CHANGELOG.txt from Drupal 7.19.
Comment #17
deekayen commented#1841654: Add VERSION.txt to profile directly conflicts with this, kind of nullifying the entire idea. credit to bdone for realizing it.
Comment #18
shrop commentedAttached is a patch to remove CHANGELOG.txt from Drupal 7.20.
Comment #19
deekayen commentedIs there a hacker way of doing it like adding a static var to hook_requirements in Guardr core?
Comment #20
shrop commentedLike shell exec to delete the file?
Comment #21
chipway commentedMy 2 cents :
If you remove README.txt from modules folders, you will get Errors on help for modules using README.text as help. Some examples are context, context_ui, features, print, strongarm.
The good practice is to keep your drupal installation udpated from Core to contrib modules and themes, and use all security filters provided by Drupal API in your custom code.
Comment #22
shrop commented@chipaway-drupal: We are not planning on removing README.txt files. Currently, Guardr just patches core to remove the CHANGELOG.txt. I do agree that we don't want to mess around with the workings of contrib README files.
Comment #23
shrop commentedAttached is a patch to remove CHANGELOG.txt from Drupal 7.22.
Comment #25
shrop commentedI experimented with testing Guardr with qa.drupal.org, but it looks like testing for distros doesn't really work maybe?
Comment #26
deekayen commentedThat's why simplytest.me exists IMO.
Comment #27
shrop commented@deekayen: agreed. I haven't tested it in a while, but Guardr should work on simplytest.me now that we have it setup like a proper Drupal.org distro.
Comment #28
shrop commentedAfter some investigation on #1986384: Unable to download guardr from project page, it is apparent that my patch in #23 is actually failing and d.o testing did its job. So, I have turned testing back on and have an updated patch. It appears that when I diff'd to created the patch, I did the diff against the tip of 7.x and I should have diff'd against the commit where 7.22 was tagged.
Comment #29
shrop commentedComment #31
shrop commented#28: guardr-remove-changelog-txt-1878172-28.patch queued for re-testing.
Comment #33
bdone commentedupdated #28 for drupal-7.23
Comment #34
bdone commented#33 was incorrectly created against 7.x. new patch is updated against the 7.23 tagged release.
Comment #35
shrop commentedGuardr was updated to Drupal core 7.24, but this patch was not updated in the the distro. A new patch is needed and should be uploaded if we want to continue patching for this.
Comment #36
deetergp commentedAttached is the 7.24 version of the patch.
Comment #37
bdone commentedre-roll to rename this patch with corrected issue id (1878172)
Comment #38
bdone commented#36 was incorrectly created against 7.x.. new patch is updated against the 7.24 tagged release.
Comment #39
bdone commentedupdated patch against drupal-7.26.
Comment #40
bdone commentedComment #41
bdone commentedupdated patch against drupal-7.27.
Comment #43
bdone commentedupdated patch against drupal-7.28.
Comment #44
bdone commentedComment #47
deetergp commentedAttaching the latest iteration of this patch for Drupal 7.30.
Comment #48
deetergp commentedAfter updating the patch, I learned that we are actually blocking access to CHANGELOG.txt and others at the Apache level, which precludes us from having to worry about accidentally slipping it into our repos and/or deploying it to production.
Comment #49
bdone commentedComment #50
deekayen commentedYou're mixing CG with open source. Guardr still shouldn't include CHANGELOG.txt.
Comment #51
shrop commentedI think maintaining the path for CHANGELOG.txt has been an issue for maintenance of our releases. If one doesn't use our build script, they will have CHANGELOG.txt. Also, if they use Guadr as a base distro, their base scripts may not exclude CHANGELOG.txt.
I am wondering if we documenting it as a best practice on the project page (maybe create a page for best practices) and investigate a better way to accomplish this. Maybe just delete the file after install?
Also, if we do the best practices page, we should include details on how CG blocks these files. That could be how Guardr contributes to this best pracice.. just tell folks how to configure their apache to block files.
Comment #52
deekayen commentedhttps://www.drupal.org/node/475858
Comment #53
deekayen commentedIteration for Drupal 7.32.
Comment #54
deekayen commentedIteration for Drupal 7.34.
Comment #55
deekayen commentedPatch against correct 7.34 tag...
Comment #56
deetergp commentedComment #57
deetergp commentedComment #58
deekayen commentedDrupal 7.42
Comment #59
shrop commentedLooks like Guardr is at 7.43 now. We need a core patch for this one.
Comment #60
shrop commentedOr maybe the last patch by deekayen is working fine for 7.43?
Comment #61
shrop commentedI confirmed just now that 7.43 will need a new patch
Comment #62
shrop commentedDrupal 7.43
Comment #63
shrop commentedDrupal 7.44
Comment #64
shrop commentedRelated read https://danielmiessler.com/study/security-by-obscurity/
Comment #65
shrop commentedDrupal 7.52
Comment #66
shrop commentedNeed to add a patch for 7.53 and 7.54 in case others might want to use it
Comment #67
chipway commentedOn my own I prefer to use NginX config that hides *.txt files.
Comment #68
shrop commented@chipway, yeah. I agree completely. I am wondering if it makes sense to create a readme with the details on how to block CHANGELOG.txt on various platforms, allowing others to add to that. That way, it can still be a recommendations of Guardr. Thoughts?
Comment #69
chipway commentedThanks @shrop,
IMHO I would better see it in a documentation page about securing a Drupal install.
May be somewhere in https://www.drupal.org/security/secure-configuration, or the next version of this doc.
Comment #70
shrop commentedGood idea! I will work on something for docs in a centralized area like you mentioned and then Guardr's readme could simply reference the link!
Comment #71
catapipper7.56
Comment #72
catapipperSorry, rolled the wrong branch. This is Drupal 7.56
Comment #73
shrop commented@catapiper, thanks for the patch!
Comment #74
catapipperPatch for 7.57
Comment #75
shrop commentedThank you catapipper! Your patch was included with https://www.drupal.org/project/guardr/releases/7.x-2.41
Comment #76
shrop commentedI am taking the update preparation for Guardr 7.x-2.43 as an opportunity to stop removing CHANGELOG.txt via patch for this and future releases. I will make sure this is noted in the release notes for the release on March 28th, 2018.
See: https://www.drupal.org/project/guardr/issues/2955947 for details on this upcoming release related to PSA 2018-001.
There are a number of reasons for this change:
* It make it hard to maintain releases (not super hard mind you) since a patch to remove CHANGELOG.txt has to be maintained for each core release
* It is security through obscurity
* Many security departments require removal/hiding of CHANGELOG.txt, but this can be accomplished with web server rules such as Apache and Nginx provide. Even Pantheon has an easy way to block access to CHANGELOG.txt via pantheon.yml.
I am recommending that we document some of these methods in Guardr documentation, along with other Drupal files that are often recommended for obscuring by enterprise security requirements.
Thanks for everyone's help on this issue over the years! :)