Release issueshttps://lab.civicrm.org/dev/release/-/issues2021-04-09T01:51:15Zhttps://lab.civicrm.org/dev/release/-/issues/16We should not be auto-generating 5.xx.beta1.mysql.tpl files2021-04-09T01:51:15ZcolemanwWe should not be auto-generating 5.xx.beta1.mysql.tpl filesI'm pretty sure these `beta1` files are getting auto-generated by the releaser. They have their ~~pros and~~ cons.
**Cons**
- Generating them before they're actually needed causes people testing the RC to miss out on the upgrade steps (...I'm pretty sure these `beta1` files are getting auto-generated by the releaser. They have their ~~pros and~~ cons.
**Cons**
- Generating them before they're actually needed causes people testing the RC to miss out on the upgrade steps (the empty step is created, the site upgrades to RC, it registers `xx.beta1` as having been run, then someone adds some actual content to the step, the site upgrades to a later version of the same RC, but the upgrade code thinks it's already run).
- Extra noise during the upgrade process with empty steps doing nothing
**Pros**
- Can't think of any.5.37.0https://lab.civicrm.org/dev/release/-/issues/245.69.1 critical error: Undefined array key "crmSearchTasks" in "ext/search_ki...2024-02-01T22:42:39ZDmitry Smirnov5.69.1 critical error: Undefined array key "crmSearchTasks" in "ext/search_kit/search_kit.php" on line 61```
PHP Warning: Undefined array key "crmSearchTasks" in ext/search_kit/search_kit.php on line 61
PHP Warning: Trying to access array offset on value of type null in ext/search_kit/search_kit.php on line 61
PHP Fatal error: Uncaught T...```
PHP Warning: Undefined array key "crmSearchTasks" in ext/search_kit/search_kit.php on line 61
PHP Warning: Trying to access array offset on value of type null in ext/search_kit/search_kit.php on line 61
PHP Fatal error: Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in ext/search_kit/search_kit.php:61
```https://lab.civicrm.org/dev/release/-/issues/235.68.1 failed to upgrade DB from 5.53.0: DB Error: constraint violation2024-01-15T11:30:51ZDmitry Smirnov5.68.1 failed to upgrade DB from 5.53.0: DB Error: constraint violationAfter successfully upgrading our staging CiviCRM from 5.53.0 to 5.68.1, upgrade of production instance failed as follows:
```
[Error: Backfill civicrm_mailing_event_queue (6 => 500005)]
Error Field Error Value
Type DB_Error
Code -3
Mess...After successfully upgrading our staging CiviCRM from 5.53.0 to 5.68.1, upgrade of production instance failed as follows:
```
[Error: Backfill civicrm_mailing_event_queue (6 => 500005)]
Error Field Error Value
Type DB_Error
Code -3
Message DB Error: constraint violation
Mode 16
UserInfo UPDATE civicrm_mailing_event_queue q INNER JOIN civicrm_mailing_job job ON job.id = q.job_id SET q.mailing_id = job.mailing_id, q.is_test=job.is_test WHERE q.id >= 6 AND q.id <= 500005 AND q.mailing_id IS NULL [nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`wordpress-civicrm`.`civicrm_mailing_event_queue`, CONSTRAINT `civicrm_mailing_event_queue_ibfk_1` FOREIGN KEY (`mailing_id`) REFERENCES `civicrm_mailing` (`id`) ON DELETE SET NULL)]
DebugInfo UPDATE civicrm_mailing_event_queue q INNER JOIN civicrm_mailing_job job ON job.id = q.job_id SET q.mailing_id = job.mailing_id, q.is_test=job.is_test WHERE q.id >= 6 AND q.id <= 500005 AND q.mailing_id IS NULL [nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`wordpress-civicrm`.`civicrm_mailing_event_queue`, CONSTRAINT `civicrm_mailing_event_queue_ibfk_1` FOREIGN KEY (`mailing_id`) REFERENCES `civicrm_mailing` (`id`) ON DELETE SET NULL)]
Civi\Core\Exception\DBQueryException: DB Error: constraint violation in /usr/share/php/PEAR.php on line 944
- DB_Error: DB Error: constraint violation in unknown on line unknown
```
That's on PHP-8.2, Debian 12 "Bookworm", Mariadb 10.9.3.
Please advise.https://lab.civicrm.org/dev/release/-/issues/225.68.1 Bundled non-embeddable font in "ext/greenwich" ?2024-01-15T11:29:37ZDmitry Smirnov5.68.1 Bundled non-embeddable font in "ext/greenwich" ?Debian's __lintian__ (utility) raised the following warning:
> `truetype-font-prohibits-installable-embedding` (preview/print only) `[ext/greenwich/extern/bootstrap3/assets/fonts/bootstrap/glyphicons-halflings-regular.ttf]`
> This pack...Debian's __lintian__ (utility) raised the following warning:
> `truetype-font-prohibits-installable-embedding` (preview/print only) `[ext/greenwich/extern/bootstrap3/assets/fonts/bootstrap/glyphicons-halflings-regular.ttf]`
> This package installs a TrueType font with restrictive license terms. The font does not permit installable embedding, as defined by the TrueType standard.
> Please refer to https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6OS2.html for details.
I don't fully understand implications, or whether this file is even being used. Please advise.https://lab.civicrm.org/dev/release/-/issues/21year typo2023-12-09T05:01:31Zjofranzfranz@systopia.deyear typo`Jan 3, 2023` in https://lab.civicrm.org/dev/release/-/blob/master/README.md`Jan 3, 2023` in https://lab.civicrm.org/dev/release/-/blob/master/README.mdeileeneileenhttps://lab.civicrm.org/dev/release/-/issues/20Configure dependabot to always target the RC2023-02-08T03:11:21ZDaveDConfigure dependabot to always target the RCThis maybe belongs in infra. Not sure.
Dependabot is almost always making security-related PRs. But it does it against master, so we end up manually recreating and then deleting the original, which angers dependabot (not really since it...This maybe belongs in infra. Not sure.
Dependabot is almost always making security-related PRs. But it does it against master, so we end up manually recreating and then deleting the original, which angers dependabot (not really since it's a robot, but it posts a response). There is https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#target-branch, but the civi naming for branches doesn't make it easy to target the RC.
It may be more trouble than it's worth just for this, but branch-naming the RC so that it can be targeted more easily would be useful elsewhere too.https://lab.civicrm.org/dev/release/-/issues/19ESR Workflow: Post full suite of resources at start of cycle2023-01-13T18:46:04ZtottenESR Workflow: Post full suite of resources at start of cycleBackground / Motivation
-----------------------
Every 6 months, we designate a version for extended security support. When there's a new security release, the ESR version is posted to Gitlab (`esr/core`, `esr/packages`, `esr/drupal-8`, ...Background / Motivation
-----------------------
Every 6 months, we designate a version for extended security support. When there's a new security release, the ESR version is posted to Gitlab (`esr/core`, `esr/packages`, `esr/drupal-8`, and so on -- collectively, the `esr/*` projects).
If you are sysadmin who wants to be _prepared_ for future security updates, then you would look to `esr/*` and do a trial-run. Make sure you have access/credentials. Make sure you can find the spot for the releases. Make sure you're targeting the right version. Make sure your tools (like `composer`) are configured to pull from there.
However, if there hasn't been a security release, then there may not be anything published on `esr/*`. This interim period invites some confusion. On one hand, there's no security-release to publish -- so the regular security-release scripts don't apply. On the other hand, if you want to be ready, then you need something to look at. The result is that we improvise during the interim.
Goal
----
Whenever we start new ESR cycle, immediately publish to `esr/*`. Include sufficient resources that enable the sysadmins to do a "dress rehearsal" (downloading/install using the exact same procedure as for a security fix). For example, suppose we're discussing v5.51 which started its extended support circa Aug 3. Here are some materials that you might expect to find (circa Aug 3):
* In the main repo, the tarballs for the `5.51.x` releases
* In each repo, the branch (`5.51-esr`).
* In each repo, the tags for specific patch releases (`5.51.x` or `5.51.x+esr`).
* In each repo, package-registry entries for each release (`5.51.x` or `5.51.x+esr`).
* In the main repo, links for the documentation interim changes (release announcements/notes for 5.51, 5.50, 5.49, 5.48, 5.47, 5.46)
Questions
----------
Are there other resources that you expect in this period?
If 5.51 starts public-support in July and starts extended-support in August... then... when should 5.51 become available in `esr/*`? Start of July? Start of August?
(If 5.51 is published to `esr/*` in July, then it will overlap with the tail-end of 5.45. Would it be confusing to see both during July?)https://lab.civicrm.org/dev/release/-/issues/18Scheduling/workflow for security updates of dependencies2022-04-29T08:58:12ZtottenScheduling/workflow for security updates of dependencies# Synopsis
The workflow for *first-party/in-house* security updates and the workflow for *third-party/upstream* security updates are qualitatively different
The question of this issue is: Do we keep one general policy/schedule for both...# Synopsis
The workflow for *first-party/in-house* security updates and the workflow for *third-party/upstream* security updates are qualitatively different
The question of this issue is: Do we keep one general policy/schedule for both kinds of security issues, or do we have a more nuanced policy that distinguishes between them?
# Background
CiviCRM's policy for scheduling/workflow on security updates has a few key elements:
* Report and discuss vulnerabilities privately
* Release updates on a designated release window (the first/third Wed of each month)
* Make an effort to pre-announce (often 1-4 weeks in advance)
Those bullets are based on the premise that we control the process for disclosure/development/etc. This is true and appropriate for the common case where the security vulnerability originates in code maintained directly by CiviCRM.
But there is another common case: *dependencies* ("libraries", "packages", "subpackages", etc) used by CiviCRM and maintained by another group. These break the bullet-points from above:
* The purpose of upstream's public advisory is *to notify people like us*. The issue is necessarily public when we get the information.
* There are several different upstreams. Their release scheduling is (on the whole) fluid - some have release-windows; some don't; some make pre-announcements; some don't; each of those policies may change over time.
* The vulnerability is public. Delaying the release (in service of a pre-announcement/spin-up period) exacerbates the risk exposure. We don't want our scheduling to add extra exposure.
The security updates of a dependency affect CiviCRM in a few ways. Anyone reading this probably has some understanding already. But just to be complete, those effects include:
* Dependency-updates require some correlated change in how we use that dependency. In the best case, that just means metadata (eg `composer.json`, `composer.lock`) - but it can also be much more involved. It varies case-by-case.
* Several artifacts need to be republished when a dependency changes (notably the tarballs/zipballs for WP/D7/BD/J - but also any images published via docker, etc).
# Proposal
Security fixes _that have been previously published by an upstream vendor_ should be assimilated through CiviCRM's public development channels (Gitlab/Github/Mattermost/etc). The process should closely match the process for patch-releases that fix recent-regressions:
* Like a regular patch-release...
* Any patches/PRs should be submitted to the RC's public queue.
* After approving the RC PR, then backport to stable/ESR. (Only backport if we believe it to be "likely" exploitable.)
* Discussion about testing, `r-run`, compatibility, etc can happen in the public PR.
* We do not need to assign a CIVI-SA-* identifier or write an "advisory" record.
* In addition, there are extra bits...
* We'll send a mailblast when the stable/ESR updates are published.
* Release notes should highlight the "Security" issue as distinct from any other "Bug fix" issues. They should link to upstream's advisory (in addition to the usual Github/Gitlab links for Civi).
* In the public media, don't discuss how to specifically exploit the vulnerability. If that requires discussion, go to private Mattermost (`security` and/or direct-message). The public PR may have general claims (eg "I have successfully exploited this on my local system"; or "Alice, Bob, and Carol discussed on security channel - and all felt it is probably exploitable.")
* Backports for stable and ESR will be done in parallel. (They may be done by different people).
All other security issues (ie *first-party vulnerabilities; unpublished third-party vulnerabilities; uninvestigated vulnerabilities*) should continue through the current (private) workflows.
We should update https://civicrm.org/security to indicate this distinction.
# Rationale
* If a black hat is motivated enough to monitor CiviCRM's issue/PR queue for heads-up about CiviCRM vulnerabilities, then they can just as easily monitor the official release feeds for `dompdf`, `ckeditor`, etc.
* Github's "dependabot" is already likely to post public PRs when there's a published vulnerability affecting a CiviCRM dependency.
* Pro-active contributors will find it natural to raise these issues publicly (because they're already public).
* This change should reduce typical turn-around-time / duration-of-exposure for this type of issue. (*Compare: 2 weeks vs 0-3 days*)
* Routing dependency-updates through the private security medium adds noise to the private tracker without adding much security benefit.
# Other thoughts
Microsoft made "Patch Tuesday" famous. But they generally own all their dependencies.
Drupal has landed on "third Wed" as their release-window. However, they appear to make an exception when a third-party library publishes outside their preferred schedule (ex: https://www.drupal.org/sa-core-2022-006).
If we relax the scheduling on dependency updates, then we don't need to keep 1st Wed on the books. CiviCRM-specific fixes could be like Drupal -- strictly third Wed.
Anecdotally, I feel upstream announcements land on a weekday (esp Tue/Wed/Thu) -- and this lines up the interest of deployers. We could lean into this (eg dependency updates only happen on weekdays).
Note: Backdrop's release-window is _any Wed_. AFAICS, WordPress, Joomla, and PHP don't have formal release-windows. Based on skimming advisories, Joomla has a strong Tue bias. WP+PHP float around. (Between them, I skimmed ~20 prior releases, and there was only one that landed on a weekend.)https://lab.civicrm.org/dev/release/-/issues/17The version numbers for core-extensions should match core-proper.2021-05-17T19:27:11ZtottenThe version numbers for core-extensions should match core-proper.https://lab.civicrm.org/dev/release/-/issues/15Remove/Stop offering D6 releases on https://civicrm.org/download2020-05-06T15:05:55ZhomotechsualRemove/Stop offering D6 releases on https://civicrm.org/downloadWe're still publishing, whether through an error or through an oversight, Drupal 6 releases despite no longer supporting D6 and publishing a D6 tarball that doesn't work on D6 (No PHP 3.x support in CiviCRM).
Can we remove this source ...We're still publishing, whether through an error or through an oversight, Drupal 6 releases despite no longer supporting D6 and publishing a D6 tarball that doesn't work on D6 (No PHP 3.x support in CiviCRM).
Can we remove this source of confusion.
Discussion: https://chat.civicrm.org/civicrm/pl/quje115ipbfhbe5pjkzn84zsurbgmbgmhttps://lab.civicrm.org/dev/release/-/issues/14Document the process for pulling or skipping/missing releases2020-03-16T09:44:26ZhomotechsualDocument the process for pulling or skipping/missing releasesWhen we skip or pull a release we should have a policy that dictates followup notifications/communications.
Recent examples include 5.23 (WordPress) 5.23.1 (Joomla) and the remove/release of one of the earlier 5.x.x versions. We should ...When we skip or pull a release we should have a policy that dictates followup notifications/communications.
Recent examples include 5.23 (WordPress) 5.23.1 (Joomla) and the remove/release of one of the earlier 5.x.x versions. We should have a standard, transparent, open communication policy that announces these decisions and the reasons as soon as practicably possible after the decision is taken.
Currently there is no policy on this and the communication is spotty/unreliable. I'm willing to put my "money where my mouth is" on this and I'll volunteer to write short blog posts when this happens if it's useful - so I don't mind putting in the effort - I'd just like us to debate and agree a coordinated policy on this!https://lab.civicrm.org/dev/release/-/issues/13Please consider using CVE identifies for security issues2020-01-03T14:13:55ZDmitry SmirnovPlease consider using CVE identifies for security issuesInstead of vendor identifiers (e.g. `CIVI-SA-2019-24`) please consider using standard CVE identifies for security issues.
Here is some reasoning from the Debian Security Team:
> The good thing on having a CVE id for the vulnerabilities...Instead of vendor identifiers (e.g. `CIVI-SA-2019-24`) please consider using standard CVE identifies for security issues.
Here is some reasoning from the Debian Security Team:
> The good thing on having a CVE id for the vulnerabilities is helping
> other vendors to track the issues properly 'cross-vendor' in an unique
> way. If every upstream would use individual identifiers to track their
> vulnerabilities, this makes the work of downsteams security teams much
> harder. Nowdays MITRE has improved a lot on their processes on
> assigning CVEs, and good filled reports at https://cveform.mitre.org/
> get fastly assigned a CVE respectively (this somehow depends though on
> how good the report is done). I know some upstreams did in past make
> frustrating experiations, and do not want to try that out again.
See also [Debian Upstream Guide](https://wiki.debian.org/UpstreamGuide).
Thank you.https://lab.civicrm.org/dev/release/-/issues/125.20: open source compliance: non-free 'vendor/togos/gitignore'2020-01-07T08:34:12ZDmitry Smirnov5.20: open source compliance: non-free 'vendor/togos/gitignore'Release management should exercise more care in regards to Open Source compliance of the sub-vendored re-distributed components.
For instance, in release 5.20 `vendor/togos/gitignore` is a non-free component due to absence of licensing ...Release management should exercise more care in regards to Open Source compliance of the sub-vendored re-distributed components.
For instance, in release 5.20 `vendor/togos/gitignore` is a non-free component due to absence of licensing and copyright information.
https://github.com/TOGoS/PHPGitIgnore/issues/1https://lab.civicrm.org/dev/release/-/issues/11Security Releases - Update pre-release communications workflow2022-11-03T21:49:24ZtottenSecurity Releases - Update pre-release communications workflow__Synopsis__: This issue aims to organize discussion about security-releases and the practice of giving a *pre-release announcement* or *heads-up*. The aim is to produce greater clarity/consistency in the final policy without producing a...__Synopsis__: This issue aims to organize discussion about security-releases and the practice of giving a *pre-release announcement* or *heads-up*. The aim is to produce greater clarity/consistency in the final policy without producing a significant on-going admin work.
__Considerations__:
* Security releases have greater urgency than typical releases.
* Consumers of these releases often have distinct/independent deployment processes (the costs of which vary widely). Consequently, the heads-up can be quite useful in arranging capacity in advance.
* The heads-up can also be used ill - helping blackhats arrange capacity to exploit vulnerabilities before they're widely fixed.
* Mandating a fixed time-frame for a headsup would likely increase the turn-around time on security issues, and the current regimen already encourages poor turn-around time.
* The broader industry has examples where (a) security releases have adhoc scheduling, (b) security releases have specific/advanced notices, and (c) security releases have a "window" policy but no specific notices.
__Approaches__:
* __(:one:) Status quo__:
* __What__: Formally, the [current policy](https://civicrm.org/security) treats the first+third Wednesday as windows in which we *may* do security releases, and there is no *formal* policy of giving heads-up. However, there are informal practices of (a) sending heads-up to `civicrm-dev@` and random MM channels (b) preferring third Wed over first Wed.
* __Pro__: The informality and obscurity of the announcements feels like it mitigates the concern about blackhats using this information systematically. (That may or may not be true.)
* __Con__: It fosters an *expectation* of announcement, even if there is no *guarantee* of announcement.
* __(:two:) Kill the informal headsup__:
* __What__: Retain the current window policy, but stop the informal practice of sending heads-up.
* __Pro__: Consistent behavior. Less admin overhead. No false expectations.
* __Con__: Harder for downstream to mobilize.
* __(:three:) Formalize with one medium for headsup__:
* __What__: Update the public policy to say that we give a headsup. Specify one medium for announcements - it will *only* and *always* go to the "Security Notifications" mailing list.
* __Pro__: More reliable and more fair
* __Con__: Easier for blackhats to mobilize.
* __Issue__: Should sort out the edge-case where "we have a security patch that's ready to go, but that only came a couple days before the window, so we have to choose to choose lesser evil of... waiting an extra 2-3 weeks for another window or giving short/limited/no notice.
__Meta__
* If additional proposals are made, please give them an identifying code; and, if possible, include a summary in the description of this issue.
* Related: [Security Releases - Update post-release communications workflow](https://lab.civicrm.org/dev/release/issues/10)https://lab.civicrm.org/dev/release/-/issues/10Security Releases - Update post-release communications workflow2019-11-27T23:11:00ZtottenSecurity Releases - Update post-release communications workflow__Synopsis__: When a new security release goes out, one may wish to notify as many users as possible. This requires communications across several different media. The aim of this issue is to define a smoother workflow for improved consis...__Synopsis__: When a new security release goes out, one may wish to notify as many users as possible. This requires communications across several different media. The aim of this issue is to define a smoother workflow for improved consistency.
__Target Media__:
The communications about a recent release may hit the following media:
* `chat.civicrm.org` (public groups) - "Town square", "dev", "product-maintenance"
* `chat.civicrm.org` (private groups) - "security", "ESR", "mergers"
* `latest.civicrm.org` - Versions listing (which feeds `civicrm.org/download` and in-app notices)
* `sourceforge.net` - Default download
* `civicrm.org` - Security advisories
* `civicrm.org` - Blog
* `civicrm.org` - "Security Notifications" mailing list
* `twitter.com` - `@civicrm` account
* `facebook.com` - CiviCRM group
__Considerations__:
* The broad communications for monthly-releases and security-releases are similar, but security-releases have the higher bar because they are more urgent, leading to more time-sensitivity and a longer list of media. Consequently, if we solve security-releases, then our monthly-releases can follow a simpler subset of the workflow.
* The list of media has tended to grow over time.
* The people who post to each medium has varied overtime.
* The knowledge/access of posting in different media are spread among different people.
* The best documents to refer people to are generally (a) the blog article and/or (b) the release-notes.
* The document [any-announce.md](https://lab.civicrm.org/dev/release/blob/master/doc/any-announce.md) proscribes some particular steps. It is slightly out-of-date, and includes a range of tasks which have (for at least... 5 years?) been split among different people.
* Today, the emotional experience of getting announcements is a bit like this: *You sign up for 3 channels, and then you don't see a notice on whichever one is your favorite, and someone tells you that you need to signup for more.*
* Today, the emotional experience of sending announcements is a bit like this: *You post a message to 5 channels, and then someone says that you didn't post to a 6th channel that you don't personally use.*
* It is conceivable to use a smaller list of feeds (like `latest.civicrm.org` and `release-notes`) to populate more channels automatically. This would require case-by-case technical implementation. Alternatively, for media where automation has poor cost/benefit, we can have a person responsible for each medium. This would likely create some lag (b/c it's hard to precisely coordinate timing across multiple continents). Any style of contribution (*automating a medium or standing sentry for a medium*) is useful.
__Proposal :one:__:
1. Team organization
1. There is a private MM group for people involved with release communications.
2. Rename the current `mergers` group to `releasers` or `release-team` or somesuch -- since this is a more accurate reflection of how the group works.
3. In the the GL project `dev/release`, add a wiki page with a list of media and the party responsible for each medium. Anyone added to this list must also be added to MM.
4. The MM channel has sticky link at the top to the wiki page.
2. For post-release communications, the workflow goes as follows:
1. Tarball and tag information goes up to `download.civicrm.org`, `sf.net`, `latest.civicrm.org`. The release is live.
2. The person who uploads then sends a notification to all `releasers` that the release is live.
3. Each person who signed up for release-comm's gets the ping and does thing their thing.
__Meta__
* If additional proposals are made, please give them an identifying code; and, if possible, include a summary in the description of this issue.
* Related: [Security Releases - Update pre-release communications workflow](https://lab.civicrm.org/dev/release/issues/11)https://lab.civicrm.org/dev/release/-/issues/9Automatically tag the drupal-8 repository2019-11-22T21:42:52ZbgmAutomatically tag the drupal-8 repositoryWhen new CiviCRM releases are published, the main core+cms repositories are tagged for that version. Except Drupal8.
This can complicate the version tracking when one wants to track the core version (tag) + CMS version (currently only b...When new CiviCRM releases are published, the main core+cms repositories are tagged for that version. Except Drupal8.
This can complicate the version tracking when one wants to track the core version (tag) + CMS version (currently only branches are available).
Ex: https://github.com/civicrm/civicrm-drupal-8/pull/23https://lab.civicrm.org/dev/release/-/issues/8D8 composer installation method for ESR versions2021-09-21T21:01:40ZjackrabbithannaD8 composer installation method for ESR versionsSince only those folks that chip in and pay into the ESR problem have access to the CiviCRM ESR tarballs, there should be a composer based method that will always provide "the latest ESR release" ..
IDK how this can be done. Will CiviCR...Since only those folks that chip in and pay into the ESR problem have access to the CiviCRM ESR tarballs, there should be a composer based method that will always provide "the latest ESR release" ..
IDK how this can be done. Will CiviCRM need a private packagist account that people that pay into the ESR can use to composer require the ESR version?
If CT ends up not providing a ESR composer method ... Skvare may provide a how-to for how to :
1) install the latest ESR version, and a process for updating the ESR version ...
Target for this should be ESR 5.13, which I believe will be the next ESR?https://lab.civicrm.org/dev/release/-/issues/7Publish the zetamailcomponents-mail fork on Packagist?2019-04-04T12:29:07ZbgmPublish the zetamailcomponents-mail fork on Packagist?Follow-up to https://lab.civicrm.org/dev/drupal/issues/36: since we cannot un-fork, can we publish our fork on Packagist?
This would help simplify the composer workflow, assuming we could then run `composer require civicrm/zetacomponent...Follow-up to https://lab.civicrm.org/dev/drupal/issues/36: since we cannot un-fork, can we publish our fork on Packagist?
This would help simplify the composer workflow, assuming we could then run `composer require civicrm/zetacomponents-mail` instead of having to edit the `composer.json` file manually.tottentottenhttps://lab.civicrm.org/dev/release/-/issues/6Produce CiviCRM-Drupal8 tarballs2020-09-30T12:15:58ZbgmProduce CiviCRM-Drupal8 tarballsWhat needs to be done so that we can publish official CiviCRM-Drupal8 tarballs?
> "So I still think that it will be at least a two stage process....one is the drupal module...you could have that downloadable from civicrm.org, but to be ...What needs to be done so that we can publish official CiviCRM-Drupal8 tarballs?
> "So I still think that it will be at least a two stage process....one is the drupal module...you could have that downloadable from civicrm.org, but to be compliant with Drupal standards, it would also be nice for the civicrm project page to have the d8 drupal module" -- @jackrabbithanna
> "What we're missing infrastructure wise, is the build process to a composer package that puts civicrm-core and civicrm-packages together as per that gist" -- @jackrabbithanna
> "A one-step drupal 8 composer install for D8 seems to be where we should end up." @MikeyMJCO
> "yep their could be a composer.json int he drupal module that requires the combined civicrm-core + civicrm-packages .. OR people could download the module and run the composer require independently, and place it in the right place" [...] "that all will get itself sorted pretty quick once the gist steps are available from one composer require" -- @jackrabbithannahttps://lab.civicrm.org/dev/release/-/issues/5Deprecate use of MD5Sums - Switch to SHA hashes or another mechanism to verif...2018-11-21T03:40:11ZhomotechsualDeprecate use of MD5Sums - Switch to SHA hashes or another mechanism to verify download integrity & publish on CiviCRM.orgCurrently each Civi release on Source Forge is accompanied by an MD5SUMS file to verify the integrity of the download.
[CiviCRM 5.1.2 on SourceForge](https://sourceforge.net/projects/civicrm/files/civicrm-stable/5.1.2/)
Due to the ease...Currently each Civi release on Source Forge is accompanied by an MD5SUMS file to verify the integrity of the download.
[CiviCRM 5.1.2 on SourceForge](https://sourceforge.net/projects/civicrm/files/civicrm-stable/5.1.2/)
Due to the ease of conducting MD5 [collision attacks](https://en.wikipedia.org/wiki/Collision_attack) and the fact that MD5 hashing is considered insecure for file download verification - CiviCRM should consider a switch to GPG or SHA Checksum verification options - and have these published on CiviCRM.org rather than residing solely on SourceForge.