For D11, we're likely to refactor the ClamAV module as a plugin to the AntiVirus module → , where much of the logic will reside.
The ClamAV 4.x branch is very much pre-alpha (and depends on AntiVirus 2.x), but worth trying out in local developer environments and sharing feedback.
As D7 is deprecated, further features to the D7 branch are unlikely to be worked on.
This relates to configuration of the ClamAV service, rather than the Drupal moduke.
The 7.x branch is deprecated and isn't expected to have any further updates. Closing this ticket as part of the issue-queue clean-up.
The 7.x branch is deprecated and isn't expected to have any further updates. Closing this ticket as part of the issue-queue clean-up.
The 7.x branch is deprecated and isn't expected to have any further updates. Closing this ticket as part of the issue-queue clean-up.
The 7.x branch is deprecated and isn't expected to have any further updates. Closing this ticket as part of the issue-queue clean-up.
The 7.x branch is deprecated and isn't expected to have any further updates. Closing this ticket as part of the issue-queue clean-up.
The 7.x branch is deprecated and isn't expected to have any further updates. Closing this ticket as part of the issue-queue clean-up.
The 7.x branch is deprecated and isn't expected to have any further updates. Closing this ticket as part of the issue-queue clean-up.
I've published branch 2.x of the Antivirus → module and branch 4.x of ClamAv, which together should provide a D-11 compatible implementation.
It's refactored to use constraints, allow multiple scanners, and offer a more robust future-proof approach.
It would be possible to create a new field that shows dots instead of its value
It seems a feature that should be implemented on a contributed project
Agree – I wonder whether this has the full behaviours desired (or the seeds for this capability) https://www.drupal.org/project/view_password →
I've been given maintainership for the Antivirus module → , so we have a feasible route for developing in that direction.
The latest WIP is updated in GitHub:
- https://github.com/manarth/antivirus/
- https://github.com/manarth/clamav/
There's a lot of overlap in the principles used in the MR https://git.drupalcode.org/project/clamav/-/merge_requests/11/diffs#54a6... and the above, with some minor variations (use of plugins rather than container-tag definitions, to facilitate using plugin-forms for configuration).
I raised the issue in the Antivirus module → queue, 2 weeks ago.
The project is marked as "unsupported" and "no further development". The most recent commit for any branch is for the 7.x version, and is more than 10 years old.
The project owner does not appear to be active on Drupal.org any longer.
I'm happy to maintain the module, beginning with a D10 project release which is near completion, and which I believe to be aligned with the spirit and objectives intended by the original project creator.
It looks like the main branch of ClamAV is still using an unsigned 32bit value to calculate the chunk size – https://github.com/Cisco-Talos/clamav/blob/main/clamd/server-th.c#L830
I'd be extremely reluctant to change the pack definition from 32bit to 64bit without a thorough understanding of the root cause.
The switch between "N" (unsigned long (always 32 bit, big endian byte order) and "J" (unsigned long long (always 64 bit, big endian byte order) doesn't appear to fit with the ClamAV docs for INSTREAM.
https://linux.die.net/man/8/clamd
The format of the chunk is: '[length][data]' where [length] is the size of the following data in bytes expressed as a 4 byte unsigned integer
Could this be specific to a particular ClamAV version?
The next iteration is likely to use the new `#config_target` property, which may supercede some the of the COI capabilities.
As there's a fairlu major push to modernise the code, the COI principles may end up bundled into the `#config_target` behaviour.
Sounds like we should have a convo – I've also got work in progress, which perhaps includes a further level of abstraction and also explores a better implementation of seperation of concerns.
I'm attaching zips of the two relevant modules, but this is literally a day and a half on the new concept, so much left to consider.
Thank you for the nudge – tagged and released 1.0.0 :-)
https://www.drupal.org/project/http_client_logger/releases/1.0.0 →
Aggregation of the two patches above attached.
D10 also requires a patch to accommodate the change to PSR/Log version 3: see the change record at https://www.drupal.org/node/3284415 →
Closing, as versions of Drupal older than D9 are not supported.
Support for alternative backends is implemented in the D10-compatible release 1.0.0, which uses the Plugin API to extend support to alternative cache backends.
Versions of Drupal older than D9 are not supported.
The current supported version of Drupal is Drupal 10, and the D10 compatible release of this module is 1.0.0: https://www.drupal.org/project/cache_browser/releases/1.0.0 →
Older versions of Drupal are not supported.
Thank you, release 1.0.x for Drupal 10 is available at https://www.drupal.org/project/cache_browser/releases/1.0.0 →
See https://git.drupalcode.org/issue/cache_browser-3399035/-/tree/1.0.x for candidate Drupal 10 release.
This module is an API for Drupal to interact with the ClamAV scanner, but does not alter the behaviour of the scanner itself.
Issues/bugs which relate to the ClamAV scanner should be reported using ClamAV's bug reporting process, which is described here: https://docs.clamav.net/manual/Usage/ReportABug.html
Released as 1.0.0: https://www.drupal.org/project/content_audit/releases/1.0.0 →
The 7.x branch is not supported.
The 7.x branch is not supported.
It looks like image assets are also affected – we're using a patch from https://www.drupal.org/project/drupal/issues/2754273 🐛 Image styles fails with absolute path in $settings['file_public_path'] Needs work
- https://www.drupal.org/files/issues/2021-08-27/image_styles-new.patch →
Attached patch is one (incomplete) approach for mapping the asset path.
Updated patch with interface and missing FeedsItem implementation.
I've approached it in a slightly different direction, adding "presave" and "postsave" operations (callables) to the FeedsItem. This allows each target to provide and encapsulate its data and functionality needs in a generic way.
To elaborate Drew's comment with code, here's an example implementation.
if (isset($_SERVER['HTTP_CF_CONNECTING_IP'])) {
// If the CloudFlare header is contained in the X-Forwarded-For header, then
// all IP addresses to the right of that entry are reverse-proxies, which are
// additional to the value in $_SERVER['REMOTE_ADDR].
// E.g. <client> --- <CDN> --- <Varnish> --- <drupal>.
$client = $_SERVER['HTTP_CF_CONNECTING_IP'];
$ips = explode(', ', $_SERVER['HTTP_X_FORWARDED_FOR']);
if ($keys = array_keys($ips, $client)) {
$position = end($keys);
$reverseProxies = array_slice($ips, $position + 1);
$reverseProxies[] = $_SERVER['REMOTE_ADDR'];
$settings['reverse_proxy'] = TRUE;
$settings['reverse_proxy_addresses'] = $reverseProxies;
}
}