I was reviewing the status of distribution security messages for #2137095: Should supported releases be shown on downloads table even if it contains insecure modules? If so, how? when I noticed these distributions hadn't been updated since several security updates had been release, yet didn't show a warning about the potential security problem. These distributions aren't built from a .make file, but simply committed copies of Drupal core and all the modules they wanted directly to git. They should be flagged as not secure since they include versions of core < 7.32 and several modules w/ security updates, but I believe the security update messages are being derived from the .make. No .make = no warning, but potentially even worse this has really created several forks of core and copies of several popular libraries.

The following distribution projects are not sandbox repos and have a database.inc file in them that has a security issue (from @mmlhess). Those with a strikeout has had their releases pulled and maintenance status set to "Unsupported".

Distribution Reported Usage Last Updated Warned
Arabic Installation Profile 0 2 years ago
Commerce DrupalGap Kickstart 1 5 days ago
DrupalCamp Colorado 0 4 months ago
Education Profile 46 11 months ago
Fuse Media Management 8 8 months ago 3/13/2015
OnePage 29 December 10, 2012
Spanish Drupal Distribution 5 11 months ago
Spinetta 4 May 8, 2014 3/13/2015
TB Blog Starter 318 1 year ago December 9, 2013
TB Events Starter 260 1 year ago December 9, 2013
TB Hadelis Starter 466 1 year ago December 9, 2013
TB Methys Starter 568 1 year ago December 9, 2013
TB Mollise Starter 548 1 year ago December 9, 2013
TB Neris Starter 283 1 year ago December 9, 2013
TB Palicico Starter 118 1 year ago December 9, 2013
TB Purity Starter 470 1 year ago December 9, 2013
TB Rave Starter 804 1 year ago December 9, 2013
TB Simply Starter 134 1 year ago December 9, 2013
TB Sirate Starter 2,503 1 year ago December 9, 2013
tr_kurulum 12 1 year ago April 12, 2013
xEditor 2.0 10 1 month ago
Zircon Profile 706 11 months ago

As discussed in #2385919: Unpublish all 7.x distributions packaged with < 7.32, because the Security Team has the authority to define the specifics of their policies and procedures within the limits of their charter, changing their policy for distributions to include distributions with < 1.0 release would give them the authority to unpublish the releases of all distributions that include core.

It should actually be much easier to unpublish the non-make distributions because they also violate the Git Usage Policy. All of these violate "do not branch/fork Drupal modules/themes". Many of them also violate "DO NOT include code from a non-Drupal project in the repository."

Comments

killes@www.drop.org’s picture

killes@www.drop.org commented

IMO these profiles just waste diskspace even if they use a makefile.

kreynen’s picture

kreynen commented

@killes That is really condescending and completely unnecessary. Adding "IMO" doesn't make it any less of an insult.

I wasn't looking for feedback about the quality of the code or purpose for the project. I'm more concerned that this approach bypasses both the security and GPL compatibility checks. I only spent a few minutes looking at the committed files in those projects @themebrain is involved in and don't understand the relationship between @themebrain and @WeebPal, but I found several files that aren't GPL compatible. I've opened specific issues for those to give the developer a chance to respond...

#2153121: Font Awesome is not GPL compatible and must be removed from git
#2153135: Revoke Weebpal and HaiNN's git access and remove releases from projects that violate git usage policy
#2153267: Oswald font uses SIL 1.1 Open Font License which is not GPL compatible
#2153271: Font Awesome is not GPL compatible and must be removed from git

dww’s picture

dww
we/he/they
commented

@kreynen - Holy crap, thanks for bring this to our attention! I just investigated a few more while looking into the details of #2137095: Should supported releases be shown on downloads table even if it contains insecure modules? If so, how? and this is just the tip of the iceberg. It appears that most distros on d.o have completely subverted the d.o distro packaging system, and just check in whatever they want directly into Git. :( We should either open a separate META about this or turn this issue into that discussion. But this is a big mess. Ugh.

Thanks again for pointing this out!
-Derek

p.s. Agreed, that comment #1 is totally unhelpful. :/

themebrain’s picture

themebrain commented

Hi @kreynen & @dww,

We'd appreciate your information and your kind acts of helping maintain Drupal secured. We are taking a close look at this matter and will get back to this discussion asap. This is the first time we encounter such issues hence it might take a while to study and put in practice so please bear with us.

Regarding the relationship between us & WeebPal, we are independent parties, WeebPal just uses our base theme Nucleus and build their own theme. The approach/practice seems similar but we actually have no business connection with WeebPal whatsoever.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Closed #2175983: A list of distributions Doing It Wrong™ (checking in full copies of Drupal core/modules vs. using make files) as a duplicate.

Tim asked me to grep my checkout of Drupal contrib the other day, and I accidentally found the following distros that have checked in full copies of Drupal core / contrib modules vs. using make files properly:

https://drupal.org/node/1087726 (Arabic Installation Profile)
https://drupal.org/project/async_drupal
https://drupal.org/project/b2b_store_solution
https://drupal.org/project/datapublic
https://drupal.org/project/MobileARKickstart
https://drupal.org/project/onepage
https://drupal.org/project/Open_Badging_Installation_Profile
https://drupal.org/project/plato_tipico
https://drupal.org/project/tb_* (already covered above)
https://drupal.org/project/tr_kurulum
https://drupal.org/project/transcribe_distribution

It seems like we ought to build some kind of validation to protect against this in the packaging scripts.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Title: Forks of core in TB Distributions » Forks of core in TB Distributions (and others)
gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented
Issue tags: +licensingpolicy

Added tag.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Hm. I wouldn't call this a licensing issue, per se. These projects are all distributed on Drupal.org so they're all compatible with Drupal's license. It's more a factor of not using Drush make properly; these projects are trying to do what the packager will already do for them.

kreynen’s picture

kreynen commented
Title: Forks of core in TB Distributions (and others) » Forks of core, modules, and libraries in Distributions

Some of these distributions have licensing issues. Some don't.

But since bypassing the .make packaging also bypasses the whitelist check on the libraries and the new security warning check on the distribution's project page, I think it is related to the current "licensingpolicy" discussion.

For the tb_ distributions I originally created the issue for, we're finally making some progress on #2153271: Font Awesome is not GPL compatible and must be removed from git with a developer who is new to that project to get the licensing issues resolved while also fixing their approach to just committing forks of core, modules, and libraries directly.

I've updated the title to reflect that this is no longer TB specific.

This is also related to licensing in that there needs to be a clearly defined process for dealing with the maintainers of a project and/or code in git when open issues are ignored... or as we've seen, nothing happens. If a "licensing team" with at least one member of the security team is going to take over the responsibility for taking action on these issues based on a mission of "keeping downloads from Drupal.org GPLv2 compatible", it would make sense to include dealing with these distribution packing errors as one of their responsibilities.

kreynen’s picture

kreynen commented
Priority: Normal » Critical

With the SA in the 7.32 release, is it fair to bump this up to critical? Can we finally unpublish distributions that package outdated forks of core?

The second distribution listed on https://www.drupal.org/project/project_distribution installs a fork of 7.19 (http://cgit.drupalcode.org/tb_sirate_starter/tree/CHANGELOG.txt). That means it takes 2 clicks download a code from Drupal.org with both security and GPL licensing issues.

Multiple attempts to reach out to anyone involved in the tb_ projects hasn't resulted in any progress on resolving the forking and creating an actual .make. While we did resolve the inclusion of FontAwesome (http://cgit.drupalcode.org/tb_megamenu/commit/?id=7d77eec), it is still in the packaged releases.

mlhess’s picture

mlhess commented
Assigned: Unassigned » mlhess

I will work on getting a full list, and then we can figure out how to proceeded from there.

kreynen’s picture

kreynen commented
Related issues: +#2385919: Unpublish all 7.x distributions packaged with < 7.32
mlhess’s picture

mlhess commented

This is a list of repos that are not sandbox repos and have a database.inc file in them that has a security issue.

1087726
commerce_drupalgap_kickstart
dcco
education_profile
fuse
onepage
plato_tipico
rebuild
rebuild
spanish_distribution
spinetta
tb_blog_starter
tb_events_starter
tb_hadelis_starter
tb_methys_starter
tb_mollise_starter
tb_neris_starter
tb_palicico_starter
tb_purity_starter
tb_rave_starter
tb_simply_starter
tb_sirate_starter
timebit
transcribe_distribution
tr_kurulum
xeditor
yandex_metrics
zircon_profile

Konstantin Komelin’s picture

Konstantin Komelin commented

Hi @mlhess,

I don't remember that yandex_metrics module ever contained database.inc file.
Moreover, it's not a distribution.

Can you give me more information?

Thanks,
Konstantin

mlhess’s picture

mlhess commented

yandex_metrics should not be on this list sorry for the extra email.

Konstantin Komelin’s picture

Konstantin Komelin commented

Okay

kreynen’s picture

kreynen commented
Title: Forks of core, modules, and libraries in Distributions » Unpublish Distributions with Forks of Core < 7.32
Issue summary: View changes
Issue tags: -licensingpolicy

I updated the issue title and description to reflect the list @mlhess compiled (- yandex_metrics). Removed the licensingpolicy tag since this now goes beyond that. I believe the ALL distributions that have committed forks of core should be unpublished/deleted, but this would be a good first step... and may actually include all of them? I'll open a new issue about adding a check to packaging to prevent releases of projects with forks of core in the future if there isn't already an existing issue for that.

I've also added links to any existing issues that discussed the lack of a .make and/or the need to make security updates. I'm not sure if @mlhess already attempted to contact these maintainers. @konstantin.komelin's comments make me think this happened, but maintainers should be given an opportunity to address this themselves.

kreynen’s picture

kreynen commented
Related issues: +#2387311: Add Check in Packaging to Prevent Distributions from Including Forks of Core
kreynen’s picture

kreynen commented
Issue summary: View changes

removing https://www.drupal.org/project/rebuild since it isn't a distribution either

drumm’s picture

drumm
he/him
Location NY, US
commented

I believe the ALL distributions that have committed forks of core should be unpublished/deleted

In general, we want to keep tarballs of releases working, so anything build have built that expects them will keep working consistently. Licensing would be an exception, we need to stay legal. Security could be an exception, but there's no precedent I can think of.

The releases that exist also set up the available versions for project issues.

kreynen’s picture

kreynen commented

I've been pushing to get this resolved based on the fact that committing forks of any project already hosted on Drupal.org is a violation of https://www.drupal.org/git-repository-usage-policy. These projects violate "do not branch/fork Drupal modules/themes" and as a result the "repository maintainers" should be able to "remove any content at their discretion and without prior notice to the affected party."

If committing a fork of core isn't a violation worth of unpublishing the release, what would someone have to do to violate that clause of the policy? Are all forks now acceptable?

kreynen’s picture

kreynen commented
Issue summary: View changes

moving the list into a table with the last update date and number of installs

kreynen’s picture

kreynen commented
Issue summary: View changes
japerry’s picture

japerry
Location KOMK
commented
Status: Active » Needs review

It seems like we could follow a similar process like unsupported projects, IE: https://www.drupal.org/project/admintools

Some projects are unpublished, which we don't have to do here (Except maybe for licensing?) but this would help remove these dangerous distributions from being used as much, and might even get maintainers to be proactive to fix their projects before allowing them to become supported again.

japerry’s picture

japerry
Location KOMK
commented

Here is a draft book page describing the policy that has somewhat existed but isn't cemented anywhere:

https://www.drupal.org/node/2392557

Konstantin Komelin’s picture

Konstantin Komelin commented

Hi @mlhess,

It's not funny! I've just received an email that says:

The releases for these project(s) will be removed sometime after 2014-12-20. Let us know if you have any questions or need help converting these into makefiles.

I can't even comment on the issue https://security.drupal.org/node/147228 because of the bug:

The referenced entity (node: 147193) is invalid.

Please remove yandex_metrics module from the block list immediately!

For reference #15

Thanks,
Konstantin

kreynen’s picture

kreynen commented

@konstantin.komelin have you been able to resolve your issue with yandex_metrics being mistakenly included in this list? While I created this issue, I have no idea what is happening with this.

mlhess’s picture

mlhess commented

@konstantin.komelin,

Not sure why you are unable to comment on the issue. However, I have removed your project from the list.

Konstantin Komelin’s picture

Konstantin Komelin commented

Thanks. Hope we won't come back to it again.

japerry’s picture

japerry
Location KOMK
commented

Per earlier discussion and #26, I haven't seen these site releases unpublished yet. Where are we with this issue?

mlhess’s picture

mlhess commented

The tb_* and tr_kurulum projects have been flagged an the releases removed.

TIMEBIT has its releases hosted on bitbucket, so the project page is just a pointer.

kreynen’s picture

kreynen commented

The download of the release for https://www.drupal.org/project/tb_sirate_starter is still published even though the project is now owned by unsupported.

All of these projects still include forks of Drupal core with known security issues:

https://www.drupal.org/project/education_profile
https://www.drupal.org/project/fuse
https://www.drupal.org/project/onepage
https://www.drupal.org/project/plato_tipico
https://www.drupal.org/project/spanish_distribution
https://www.drupal.org/project/spinetta
https://www.drupal.org/project/xeditor
https://www.drupal.org/project/transcribe_distribution

mlhess’s picture

mlhess commented

I have fixed the tb_sirate_starter issue.

I will create private issues in the s.d.o tracker for the other projects.

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented
Issue summary: View changes

I've strikeouts over those that had their releases pulled and maintenance status set to "Unsupported". In addition, it looks like the maintainer has repackaged Plato Típico to use make, so it does no longer belong on the list.

Why is the rest not acted upon?

mlhess’s picture

mlhess commented
Issue summary: View changes
mlhess’s picture

mlhess commented
Issue summary: View changes
mlhess’s picture

mlhess commented

I have created issues for this in the security.drupal.org tracker, for some projects I emailed the primary contact. In 2 weeks, we will unpublish the releases.

mlhess’s picture

mlhess commented
Issue summary: View changes
kreynen’s picture

kreynen commented
Issue summary: View changes

The Drupal Camp Colorado project moved to GitHub.

kreynen’s picture

kreynen commented
Issue summary: View changes

maintainer of Education Profile and Zircon Profile has removed those forks and is working on rebuilding the distribution using .makes.

kreynen’s picture

kreynen commented

I opened issues in the 5 remaining distributions and used the Drupal.org contact form to draw the maintainers attention to the issue.

#2452107: This distribution is an insecure fork or both Drupal core and contrib
#2452109: This distribution is an insecure fork or both Drupal core and contrib
#2452115: This distribution is an insecure fork or both Drupal core and contrib
#2452117: This distribution is an insecure fork or both Drupal core and contrib
#2452119: This distribution is an insecure fork or both Drupal core and contrib

2 of these claim to be 1.0 releases, so the normal Security Team procedures could be used to remove those if this doesn't work.

kreynen’s picture

kreynen commented
Issue summary: View changes

Maintainer removed release of https://www.drupal.org/project/onepage

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

The recommended releases of Education Profile and Zircon Profile still contains insecure forks of core. The changes the maintainer has applied (re. #40) only affects the latest dev snapshots.

Why are those the insecure releases of Education Profile and Zircon Profile allowed to stay online and even be marked as "Recommended Releases"? Why have strikeouts (assumed to mean "fixed") been placed over Education Profile and Zircon Profile?

While it is fine that the maintainer now has started working on this, I think strikeouts should only be used if insecure releases has been replaced by secure ones, or all inssecure releases have been unpublished.

mlhess’s picture

mlhess commented

I have removed the releases above and sent the maintainer an email about why.

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

mlhess wrote:

I have removed the releases

Still, the insecure published release of 7.x-1.0-beta1 of Zircon Profile is still available for download.

The Zircon Profile 8.x-1.0-beta3 release should be removed as well. It may not be insecure, but it violates the Drupal Git Usage Policy by containing a complete fork of core.

mlhess’s picture

mlhess commented

The 7.x-1.0-beta1 of Zircon Profile has been removed. The 8.x-1.0-beta3 should be taken care of in another ticket as it is not related to this security issue.

kreynen’s picture

kreynen commented
Issue summary: View changes
kreynen’s picture

kreynen commented

All remaining distributions with this issue were warned again on 3/13/15 via the issue queue and Drupal.org contact form. Today I officially reported the security issue for all distributions with a 1.0 or greater release. That leaves 2 that need to be handled as git policy violations.

Would like to get some feedback on #2387311: Add Check in Packaging to Prevent Distributions from Including Forks of Core so that we can avoid having to clean this up again.

kreynen’s picture

kreynen commented
Issue summary: View changes

Removed 2 more from the list. One fixed. One didn't, but a release > 1.0 meant it was subject to the normal security review process.

18 months later, there are still 2 distributions users can download from Drupal.org that include a version of core < 7.32 with no security notices on the project page.

https://www.drupal.org/project/fuse
https://www.drupal.org/project/spinetta

I've tried everything I can to get this resolved.

@eleonel has been active in the last ~30 days adding https://www.drupal.org/node/2371917, but has ignored every attempt I've made at contacting him.

@xcf33 list Propeople as his current job but hasn't committed or posted in > 90 days. He also let https://www.drupal.org/project/og_tag_importer fall into unsupported.

kreynen’s picture

kreynen commented
Status: Needs review » Fixed

Fuse and Spinetta have been moved to unsupported. I was hoping to get the download link removed, but I'll take what I can get.

Without #2387311: Add Check in Packaging to Prevent Distributions from Including Forks of Core this will likely happen again, but I've only seen 1 distribution commit a fork of core since I started watching for that. Moving on to other windmills.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

williampham’s picture

williampham commented

@kreynen & other Security Team members

Hi all,

One of my colleagues and I have been assigned to release new download packages for tb_*_starter projects using make files to prevent forking Drupal core as well as other contributed modules since few days ago. We have successfully released tb_simply_starter 7.x-1.0-beta 4 for the TB Simply Starter project without forking Drupal core or contributed modules. The package has been also upgraded to Drupal 7.38 to prevent security issues. However, this project and other tb_*_starter projects have been marked as Unsupported and assigned to the special user Unsupported Projects or have been removed. Are there any chances for us to get these projects back?

williampham’s picture

williampham commented
Status: Closed (fixed) » Needs review
gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented
Status: Needs review » Needs work

williampham wrote in #52:

One of my colleagues and I have been assigned to release new download packages for tb_*_starter projects using make files to prevent forking Drupal core as well as other contributed modules since few days ago.

It is great that you've moved to using make-files for these. However, note that the majority of the tb_* projects also seem to suffer of a complete disregard of the Drupal Git Repository Usage Policy (by including 3rd party materials in the repo).

Before getting these projects back, I think the licensing violations in the underlying tb_* theme projects (that you include by means of a make file) need to be fixed as well. See: #2553865: Multiple policy violations in projects owned by ThemeBrain for details.

williampham’s picture

williampham commented

@gisle

Thanks for your feedback. We will review them to solve these licensing violations case by case.

mlhess’s picture

mlhess commented
Status: Needs work » Closed (outdated)

This seems to be taken care of at this point.