Closed (fixed)
Project:
Drupal.org customizations
Version:
7.x-3.x-dev
Component:
User interface
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
10 Mar 2017 at 23:31 UTC
Updated:
29 Mar 2017 at 21:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
drummThe current draft adds a warning to the top of the page:
And puts “Use at your own risk!” first and in bold below:
Comment #3
drummComment #5
gregglesAre there some tags to use to get a visual review?
Comment #6
hestenetI don't know if anyone currently follows these tags, but I added a few.
That said, I think the design actually is looking pretty good and using the new warning style from documentation guides is a good idea.
I wonder if we should use that same style in the lower section where the shield icon is? Or maybe that would look too busy.
Comment #7
drummI’m sneaking an addition to the covered with shield text, addition emphasized:
That was generally true before; now we want to be clear there’s a per-project element.
Comment #9
drummSome repetition so the messages can be associated with each other is good. We have the same text (except for s/the/Drupal’s/) and orange color now. I didn’t want to fully repeat the message; and the
note-warningstyle is quite heavy. One thing I’d like to repeat is the shield-! icon, but I didn’t see a way to quickly fit that in.This can always be changed as-needed.
Comment #11
drummThis has been deployed. https://www.drupal.org/project/field_collection is a good example.
Comment #12
tim.plunkettWhat happens for a module that has stable releases for one version of Drupal but not the other?
EDIT: https://www.drupal.org/project/paragraphs is an example, it gets no big warning, hm.
Comment #13
drummThat case only gets the “Stable releases for this project are covered …” message and solid shield icons in the download table. We’re also working on making this information available in core so you can see your specific situation: #2766491: Update status should indicate whether installed contributed projects receive security coverage
Comment #14
Taco PotzeAs mentioned to the DA on Twitter as well, this warning is rather hurting our distro project page https://www.drupal.org/project/social
Building this distro took us over a year. The new warning are scary people away from the project now and we can't (nor want) rush towards a 1.x.. (we are now at beta13).
We are fulltime working on this project with 2 teams. The platform is 'stable' although not covered yet.
Since other distros as https://www.drupal.org/project/brainstorm_profile with only a beta1 don't get this scare, we are considering releasing a bs D7 release just to get rid of it. I don't think that is the way we want to go.
I get why we want to push people out of beta, but these changes are making a heavy impact and might people turning away from using, experimenting and contributing to projects in beta. Is that really the way we want to go?
Thanks for your attention!!
Comment #15
drummProjects with a full release, like 8.x-1.0 or 8.x-2.1, get security advisories for resported vulnerabilities. brainstorm_profile released 7.x-1.0 last year, https://www.drupal.org/project/brainstorm_profile/releases/7.x-1.0. Projects with full D7 or D8 releases were grandfathered in to continue security advisory coverage. Details from implementing that are at #2787165: Add security advisory coverage field to projects.
The process for projects to opt-in is any maintainer of the project can edit the project page. They will either be able to check “Opt into security advisory coverage”, or there will be help text explaining what is required. The biggest requirement is for a maintainer to have been vetted through the project application process, https://www.drupal.org/project/projectapplications. You may already have someone vetted on your team.
We do want Drupal end users to be aware that non-covered projects that haven't reached a full release may have potentially serious security issues fixed outside of the Drupal Security Team process. Security issues may be fixed without announcement; or disclosed in public issue queues without a fix.
Comment #16
mrf commentedWas this reverted after the initial rollout? I'm not seeing this message anymore.
I am also concerned about Tim's comment in #12. Any project that has ever had a full release gets to avoid this message, whereas a project like admin_menu which has NEVER had a full release but is safely installed on over 500k sites gets a big warning.
I feel like a message this glaring will push maintainers to release a 1.0, no matter what state their module is currently in. The Drupal community, especially contrib, has never had a clear standard about what alpha beta and RC mean. Core has finally codified this for its own releases, but contrib is still the wild west.
I know that part of the pushback from the drupal security team on opening up project applications was fear of greatly increasing their workload. I feel like this change will lead to a much larger jump in the number of 1.0 modules they have to deal with than any worries about brand new modules from brand new contributors.
I do not want to discount the Drupal security team and the EXTREMELY hard work they have done so well for years, but I do not want to fall into the trap of overstating the service they provide to the community and setting false expectations for users about the overall security of a module they download.
We are stamping shields and failing to display this dire warning message on thousands of modules that have never been actively reviewed for security issues purely based on those modules age and how long their maintainers have been part of the community.
Comment #17
drummNo, I see it on https://www.drupal.org/project/bad_judgement.
This particular message is not about 1.0 or not. It is shown if the project has not opted into coverage in general.
In addition to the release-specific information in the download table, we’re also working on #2766491: Update status should indicate whether installed contributed projects receive security coverage so your site can show you its specific coverage.
Comment #18
mrf commentedCan non-1.0 projects opt in to security coverage manually?
Comment #19
drummYes, it is agreeing to the policy in general. Most importantly, working with the security team if you are contacted. Then on top of that, there is still the only full releases are covered rule.
Comment #20
mrf commentedMaybe an announcement about the need to check this checkbox can go out to the module maintainers e-mail list?
I feel like the communication behind this rollout has been lacking, we went from the creation of this issue to the rollout in less than a week, when changes like these typically take months or years.
Comment #21
drummSee the parent issue: #2666584: [Community Initiative Proposal] Project Applications Process Revamp
We are drafting a post to broadly communicate the changes.