To be made a maintainer by a site moderator, move this issue to the Drupal.org Project Ownership queue, by editing the “Project” field on this issue (as instructed in the issue summary).
Reopening, based upon #14.
Excessive notifications were sent due to a quirk in the site's spam filtering. User fessouma is not to blame for this.
This user has posted a large number of support request where he also prominently features his own name. Two weeks ago I asked for an explanation for why this is done. No explanation has been provided. I am going to unpublish these posts as spam. If the user want support, please post support requests without advertising your given name. (I am leaving this one published so that the user can see my response.)
I agree that this is odd behaviour. IHowever, the posts look like legit support questions, so just deleting them and blocking the user can be perceived as overreaching moderation. I am going to monitor this, and give the person a chance to explain the motivation before taking further action.
Removed spurious tag.
Sorry about the delay. I've added you as a maintainer. Best of luck with Starshot.
The 'confirmed' role is not required for access to the slack channel. Please go ahead and use it.
Changing status based upon #7.
I've published the issue.
The owner was active last year. I an going contact markwk according to established procedure.
The 'confirmed' role is not required for helping out with tranalations.
To translate Drupal, loxte the relevant translation team(s) here; https://localize.drupal.org/translate/languages
To trnslate the Drupal core, see. https://localize.drupal.org/translate/drupal_core
Your composer command to require the module looks weird. What happens if you try this:
composer require 'drupal/news_ticker:^1.0'This sort of request is unsuitable for the "general discussion" forum. It usually is magnet for spam and bogus "recommendations" from people hustling for business. Please find another venue to locate a supplier. You may want to explore Drupal certified partners → .
apaderno has the required access to do this.
@ethan_smith123, AFAIK, there i no "migrations" option under the "structure" section in the admin area. You're answer is bogus. Also, your site is running WordPress, not Drupal. Links are deprected. Before posting again, please read the guidelines for this forum: https://www.drupal.org/converting-to-drupal-sticky →
If ctools is not in your composer.lock. it wasn't installed by composer and will not be managed by composer. Try the following:
ddev composer require 'drupal/ctools:^4.1'I've published your post. It was not spam. The problem is that our spam detector doesn't like your large chunks of non-prose, such as your Apache-config. I've olso given you the 'confirmed' role, so you're no longer subject to automatic spam filtering.
Yes. An MR/patch that does trigger rebuild permissions in the right context shall be welcome.
To show images, don't embed. Link to images posted off-site.
As for your error with Drupal Reset → , I found this issue: 🐛 database configuration is not supported by Drupal Reset Needs work . It may explain the error you see.
As for upgrading from Drupal 7 to a Symfony-based version of Drupal, well, it is a though one 😭. In my experience, the "browser" method you've tried will only work with the simplest of Drupal 7 sites. For more complex sites, including – but not limited to – sites not using English as the default language, you need to use the migrate tools provided.
PS: Drupal 9 is past EOL. It will no make thing simpler, but if you're doing the upgrade, your target should be Drupal 10, not Drupal 9.
-1
For the record: If this proposal had been accepted prior to me receiving permission to opt projects into Security Coverage, I would probably not received it, and hence not been able to participate (at least not to the extent I have been able to participate in the community). I've never had the funds to show up at an overseas event in person to prove that I'm really me.
Also, as anyone who has watched Spike Lee's excellent BlacKkKlansman would know: Assigning identity by means of having someone show up in person is not a very secure way of establishing someone's true identity.
For the record: I don't perceive this meta, or any of its child issues as something that applies to me personally in any way. I just happen to dislike some of the mitigations that has been proposed so far (for reasons that I have provided here and in some of the child issues). However, I fully agree that this was opened as a honest and sincere attempt to bring to the attention of the community by what is believed to be a serious problem in need of fixing.
However, I take issue with this statement:
I don’t believe it is wise to only focus on what has been done (and how) from previous exploits. Malice can come in many forms. People who set their eyes on Drupal will find ways to exploit our community and processes, not necessarily replicate other attacks on other “supply chains”.
I do not think that we should only focus on other exploits. However, when the impetus of this proposal seems to be that the project adoption process is a major threat to the continued security of the Drupal ecosystem, I think it is prudent to point out:
- Historically, project adoption has not been a vector for supply chain attacks (AFAIK zero reported incidents in the many years the adoption process has been practised).
- Other vectors figure quite prominent in the supply chain attacks we know about in other ecosystems.
In other words: I think we need the perspective that is provided by our history other supply chain attacks to understand how serious a threat the project adoption process actually is.
And I still think the community will be better served by implementing mitigations that cover a broader range of vectors than just the project adaption process. I've already mentioned that IMHO, a more systematic review of code changes committed to a project should be more prominently featured as a method to mitigate supply chain attacks, no matter who it is that inject tainted code in the project.
Any bug reports go against the most recent dev version.
The message reported in the issue summary indicate that your site has not kept its environment up to date. That is a prerequisite for being able to install version 8.x-1.1-alpha3 of this module.
It is correct that you need to do a composer update --with-all-dependencies to get your environement updated.
This website uses English as the site language. Please respect that.
The 'confirmed' role is for users that contribute to this website. Examples are: Do a contributor task, help, out in issue queues by fixing issues, or provide support via text forums (see links below).
In this case, you've not contributed any content except this post, so there is no content to review. Postponing for now, after you have posted some content on Drupal.org you may want to add a comment to this issue to request a new review. Please visit the Become a confirmed user → page for information. That page also tells you what "limitations" mean.
Here is a list of resources that will assist you making helpful contributions:
IMHO, the peer review of the code committed to a project is much more important to discover supply chain attacks than the proposed highlighting the log of maintainer level changes.
Of course, implementing this highlighting wouldn't do any harm, but resources is always in short supply, and any benefit this proposed measure might bring will probably not be worth the expense of implementing it.
But if anyone wants to donate resources to implement what is sought here, please go ahead!
To understand the nature of supply chain attacks it may be relevant to look at this white paper about a recent successful supply chain attack that took place in the WordPress ecosystem: Supply Chain Attacks: A WordPress Case Study. For the record: No project ownership transfer was involved in the attack.
TL;DR: What happened was that AccessPress, a trusted supplier of WordPress plugins had their website compromised by the threat agent, and an obfuscated trojan was injected in the code distributed by this trusted supplier.
Other well-known supply chain attacks, such the SolarWinds and Colonial Pipeline, also did not involve any project ownership transfer, but involved the same MO as the attack on AccessPress: An already trusted supplier of software components to the targeted ecosystem is hacked and is then abused as vector to inject malware into the ecosystem.
My take on this is that the problem highlighted in this meta issue is of a theoretical nature, and does not reflect how actual supply chain attacks are conducted in the real world. To protect the community against supply chain attacks we need instead to focus on the MOs that matches how this type of attacks is typically orchestrated.
I understand that what you want "fix" the risk of supply chain attacks exploiting the project "adaption" process.
However, given that AFAIK, there has been exactly zero such attacks in the decade-long history of Drupal having allowed abandoned projects to be put under new management, what you're trying to "fix" is seems to be a hypothetical risk. And because the proposed "fix" shall be very disruptive to the Drupal ecosystem, breaking Drupal websites because projects that become unsupported will remain unsupported.
This is free and open source software. Some people here read code. A supply chain attack (if there ever is one) has a high likelyhood of beeing discovered by someone reading the code. The single such such incident I am aware of ( #3112841: Elfsight ecosystem modules collect site configuration data and site admin email without opt-in → — not related to the "adoption" process that is on-topic here) was discovered and the malware releases unpublished before the code saw any adoption.
My proposal is that we safeguard "adopted" modules against supply chain attacks by reviewing changes to the code (as documented in the commit history log) for some time after a new maintainer has been added and look for potential exploits. I sometimes do this as part of my work as a project ownership maintainer (in particular if the new maintainer has not much of an trust record in the community). However, it may be a good idea to organize a team of code reviewers to do this in a more systematic fashion.
-1 from me on this proposal.
IMHO, the following claim is false:
If there is no ability to "adopt" modules the majority of the supply chain attack risk disappears and the ecosystem is protected.
In a free software environment, a threat agent can do perpetrate a supply chain by introducing a new package into the ecosystem that contains some exploit. To tie this risk to to the ability to "adopt" abandoned modules is IMHO obfuscating the fact that a free software ecosystem that allows anyone to contribute is inherently vulnerable to supply chain attacks.
The principal argument for prohibiting the "adoption" of an abandoned module seems to be this one:
Wouldn't forking a module with a new maintainer be a better experience than silently passing hands to a new maintainer, at least in terms of security? […] The built up trust over a long period of time in the previous maintainer shouldn't immediately transfer to the new one.
The adoption process is not "silent" as stated. The process is transparent. A public issue must be created in the project's issue queue and stay there for at least two weeks. Anyone concerned about supply chain attacks should monitor the issue queue and recalibrate their trust in the project's team if they don't trust the new maintainer.
c_logeman writes:
I had exactly this situation where I was a co-maintainer for a D7 Module. A new project owner stepped in to claim just the namespace for a complete different approach for a D8 module and just closed all D7 Issue and removed me as a Co Maintainer.
As a project ownership maintainer, I am not familiar with the this specific incident. For the record: This is not how namespace transfers is supposed to work. As long as Drupal 7 is supported, a new owner who wants the namespace for a Drupal 10 project is not allowed to interfere with a still supported Drupal 7 branch of the project. If you had taken this incident up the site moderators in the Project Ownership issue queue, this would have been reversed. And of course, if you had monitored the project's issue queue, you could have objected to the namespace transfer request even before it took place.
IM(NS)HO, this proposal is addressing the problem from the wrong angle. Yes, there is a risk of a supply chain attack taking place is a Free Software ecosystem. I don't know about any actual exploits, so we may discuss how severe this problem is.
Letting a project stay abandoned because the team that once maintained it has moved on is harmful to the Drupal ecosystem, and projects becoming abandoned is a very real problem that we now mitigate by letting new people adopt them (following a well documented process). I am open to improving this process, but I honestly think that to prohibit the ability to adopt a project will be harmful, without really doing much to mitigate the risk of supply chain attacks in the Drupal ecosystem.
Setting status to "Needs work" based upon #6.
Yes, I saw your reply to VM.
The /tmp-directory must writeable by the web server, but thirs parties should no be able to overwrite index.php (or any other part of your code base). To stop it from happing again, you need to make sure those files are protected.
FYI: No features are "locked" for people that do not have the "confirmed" role. They are just subject to automatic spam filtering oversight.
Drupal themes are cascading, so the malicious ijected code may not be in your site's theme, but in the twig components that originate with from the Drupal core.
I am one of the people who oversees the Project Ownership Process (including the adoption of abandoned projects).
In the linked Slack conversation, there are a few references to various unfortunate incidents that is not very well documented and that I personally am not familiar with. My initial response is that this is hearsay and if the intent is to raise the concern about the security of the existing process and its flaws, alleged transgressions need to be better documented.
I am not saying that the current process is perfect and cannot be improved, I am just saying that the problems need to be more clearly documented in order for real progress to improve it be made.
In the issue summary, it is stated that:
the Drupal.org Project Adoption process poses a supply chain risk to the Drupal Ecosystem
That is a serious allegation. However, it is also stated up front in the Slack conversation:
None of these (to my knowledge) have yet resulted in a successfully targeted attack against site owners,
but adding that:
however I worry it could just be a matter of time till this does occur.
However, I think it need to be recognized that in a Free Software ecosystem, there is always a potential for a supply chain attack, and this potential exists whether there is in place some process for transfer of ownership of abandoned projects or not.
A threat agent wanting to perpetrate a supply chain attack against a Free Software ecosystem does not need to adopt and existing component (abandoned or not). Creating a brand new one and getting it hosted as part of the ecosystem will do equally well. I recall this issue about an actor that were suspected of doing this: #3112796: Mark Elfsight modules unsupported → (the malicious part was that PID was collected without diclosure or concent). (We ended up tagging the affected projects as "Unsupported" and pulling the releases.)
If we simply discontinue the Project Ownership Process, the problem is not going to go away. Without the process, these projects will just become adandoned projects, and their users will be looking for a replacement. However, since this is free software, a threat agent could just fork any abandoned code base, inject whatever malware they saw fit, and advertise the fork as a plug-in-replacement for the abandoned component, and perpetrate a supply chain attack against the part of community in need of said component.
The principal safeguard against supply-chain attacks is peer-review, and that goes for abandoned projects resurrected under new ownership, and for new and forked projects that is not subject to any process before being introduced to our ecosystem. However, as demonstrated by Ken Thompson in his famous Turing Award lecture: Reflections on Trusting Trust, this may not always be enough.
In the issue summary "Proposed solution" is left blank (so far). I shall review anything proposed in a timely manner, but IMHO, the problem of "supply chain attacks" is not in any way tied to our existing formal process for allowing abandoned projects to be adopted, but intrinsic to the nature of free software ecosystems, and to focus narrowly on the Project Ownership Process in order to solve this is just going to miss the mark.
If one examine this non-existing URL on your site: https://www.escofet.com/bogus.txt, one gets:
<!DOCTYPE html><html><head><title>404 Not Found</title></head><body><h1>Not Found</h1><p>The requested URL "https://www.escofet.com/bogus.txt" was not found on this server.</p><div style="position:absolute;left:-13257px;width:1000px;"><a href="https://dejta-svenska.com/">sex dejting</a> <a href="http://www.eskortbeylikduzu.com/" title="beylikdüzü escort">beylikdüzü escort</a> Кракен даркнет<a href="https://plumita.com/">Кракен даркнет</a> blacksprut <a href="http://www.foremny.eu/">blacksprut </a></div> </body></html>To me, it looks like the spam links are present in the twig template for the page (in this case a basi8c 404 error page. To locate the origin, search the twig templates for the site for the injected txt (e.g. "dejta-svenska", "eskortbeylikduzu", etc.
The cause of this is that your file system is not well enough protected and third parties are able to download files and overwrite your code base. If this is the case, your site's code base is wide open to all sorts of nasty injections and spam links are not the worst thing that can happen to the site.
Removed erroneous tagging. The reported site is now 404.
I have published the post.
It depends on what operating system and web server you use. If you use Apache2 on Debian/Ubuntu, it is usually located in the directory named /etc/apache2/sites-available.
What is set as the webroot in the site's web server configuration file?
You cannot embed screenshots hosted elsewhere. Instead, link to them.
No, you requested ownership by selecting component "ownership transfer".
Drupal has always been database-agnostic, and works equally well with mySQL and MariaDB. It will also work with PosgreSQL, MS SQLserver and Oracle.
Drupal has all the components available to let users create nodes with plans and schedules, and to send out reminders about scheduled events by email or by push notifications.
There is no benefit in linking to existing sites as examples,. Nobody will spend time to look at such sites to provide a free conversion-to-Drupal-analysis for you. Such links are often posted for SEO purposes (i.e. spam), and will summarily be redacted.
I have added alexb7217 as maintainer.
You cannot use the accelerated process for ownership transfer, only to be added as maintainer.
I'm a site moderator here, and I've noticed that you're again posting spam in the comments to the Drupal Paid services forum. If you keep on doing this, your account here will be blocked.
You've posted this in the issue queue of an abandoned Drupal 4 module and your support question is also irrelevant for that module. It is unlikely that you will get any help with your problem here.
To get support from the community, there are quite a few channels for communication. Please visit https://drupal.org/support, where there is an overview of places where you can go for support.
However, in most cases, the Post installation → forum is the first place to go to seek support.
The protocol → for becoming a co-maintainer says that when opening an issue, it is useful to contact the current project owner via the contact tab on their Drupal.org user profile page (and/or other means of contact that exists) to let them know about the issue you posted regarding maintainership. If you do this, please add the details (who, means of contact and when) to the issue summary.
However, David Castella does not have the Contact form enabled, and no longer seem to be active in the community. For this reason I'm going to add you as maintainer.
Did you dent a PM David Castella about this issue?
The protocol → for becoming a co-maintainer says that when opening an issue, it is useful to contact the current project owner via the contact tab on their Drupal.org user profile page (and/or other means of contact that exists) to let them know about the issue you posted regarding maintainership. If you do this, please add the details (who, means of contact and when) to the issue summary. This information is missing from the issue summary.
We need the community to review MR!16.
For the standard process, see: How to become project owner, maintainer, or co-maintainer → .
Step #6 says:
If the owner does not reply after two weeks, move the issue to the Drupal.org project ownership issue queue.
Please also see step #2:
use the Contact tab on the owner profile page to contact the project owner, asking to post a comment on the issue you posted.
The project's owner is ziomizar.
I've published the issue and have confirmed your account.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Project is unsupported.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming. I have revoked your role as "confirmed" user.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
Removed spurious tag. Please read the issue tag guidelines → .
Creating a huge number of these minor issues borders on spamming.
I have added you as co-maintainer
I have added you as co-maintainer.
I have added you as co-maintainer.
I have added you as co-maintainer.
I have added you as co-maintainer.
I have added you as co-maintainer.
I've published https://www.drupal.org/project/ai_auto_reference/issues/3447312#comment-... 🐛 Error: Call to a member function getTranslation() on null Active
When distributing recipes, are they GPL?
Yes. All contributed files that are derivative works of Drupal hosted on Drupal.org, are licensed under the GNU version 2 or later. This includes files that makes use of an API that is in the Drupal core.
See also the Licensing FAQ #1: https://www.drupal.org/about/licensing#drupal-license →
Is it possible to sell recipes?
Yes. However, you must distribute it under the GPL version 2 or later, so those you sell it to must be allowed to modify and redistribute it as well.
I have reviewed your posts and given you the 'confirmed' role.
Could you tell me how to proceed to upgrade a Drupal 7.99 site to Drupal10?
I have moved your question to a more appropriate forum.
Upgrading a (non-trivial) Drupal 7 website to Drupal 10 is hard, and I am unable to provide an exact recipe. I've not found a way to do an upgrade. What I've done is to rebuild the website as a new Drupal 10 website, and then migrate the content from the Drupal 7 website into this new Drupal 10 website.
Unassigning. We need another community member to review the patch.
Moved to Fixed.
We need reviews from people that are not the author of the MR.
Kmurg,
thank you for offering to help out maintaining this!
I've added you as maintainer.
Assigning.
Still does not follow the template linked in comment #10.
For instance, text is not manually wrapped to 80 columns.