CMS后端【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址https://gitcode.com/GitHub_Trending/wa/wagtail点击查看免费下载Wagtail 4.1.8 是 4.1 Long Term SupportLTS系列在 2023 年 9 月 28 日发布的维护版本其发布说明记录了唯一一项维护变更——放宽 Pillow 依赖约束以便站点可以使用包含安全修复的 Pillow 新版本。本文以这份发布说明为骨架梳理 LTS 维护策略下的版本节奏并深入 Wagtail 图像处理模块Pillow → Willow → Wagtail images的源码实现说明为什么一次依赖放宽对生产站点如此关键以及升级时应如何验证。一、版本概览一次典型的 LTS 维护发布根据官方发布说明 docs/releases/4.1.mdWagtail 4.1 于 2022 年 11 月 1 日发布并被指定为 Long Term SupportLTS版本。LTS 系列的维护承诺是在下一个 LTS 版本发布之前通常约 12 个月持续提供用于修复安全问题与数据丢失问题的维护更新。这正是 4.1.8 这类小版本存在的意义——它不引入新功能只保证 LTS 用户能安全、稳定地运行。从发布说明 docs/releases/4.1.8.md 可以看到本次发布仅包含一条 Whats new 记录类型为 Maintenance维护Additionally update Pillow dependency to allow use of versions with security fixesDan Braghis结合 CHANGELOG.txt 中相邻版本的记录可以还原这次发布在版本时间线上的位置版本日期核心内容4.1LTS2022-11-01首个 LTS 版本发布4.1.72023-09-27Relax Willow dependency to allow use of current Pillow versions with security fixes4.1.82023-09-28Additionally update Pillow dependency to allow use of versions with security fixes4.1.92023-10-19修复 CVE-2023-45809通过管理后台批量操作视图泄露用户名值得注意的细节是4.1.7 与 4.1.8 仅相隔一天且都指向同一目标——让 LTS 用户能够使用包含安全修复的 Pillow 版本。这说明在 2023 年 9 月下旬Pillow 的某个安全修复版本已经发布而 Wagtail 的依赖约束尚未放开用户即使升级 Pillow 也会被 pip 的版本解析拒绝因此需要连续两个维护版依次放宽 Willow 与 Pillow 的上限约束。二、本次变更的核心Pillow 依赖约束放宽1. 为什么依赖约束会成为安全瓶颈Wagtail 通过setup.py与 pyproject.toml 声明运行依赖。在 pip 安装时依赖解析器会严格遵循版本区间约束如果约束写死为Pillow9.1.0,10那么即使 Pillow 发布了包含安全修复的 10.x 版本pip install也会拒绝安装导致修复永远无法进入生产环境。从 CHANGELOG.txt 的历史记录可以完整看到这条依赖约束的演进脉络4.1.82023-09-28Additionally update Pillow dependency to allow use of versions with security fixes—— 正是本文讨论的这次放宽5.0.32023-09-25Update Pillow dependency to 9.1.05.0 系列后期Update Pillow dependency to allow 10.x, only include support for 9.1.0更新的维护记录Remove upper bound on Pillow dependency彻底移除上限。也就是说4.1.8 处于一个从受限到逐步放开的关键节点它没有直接移除上限而是额外更新Additionally update了约束允许安装包含安全修复的 Pillow 版本——这既是安全响应也保持了 LTS 系列谨慎克制、不做破坏性变更的发布风格。2. 当前仓库中的依赖状态参考作为对照当前仓库的 pyproject.toml 中图像依赖已演进为dependencies [ ... Pillow9.1.0, Willow[heif]1.11.0,2, ... ]可以看到Pillow 下限保持9.1.0与 5.0.3 的记录一致且不再有上限同时引入了 Willow 作为图像抽象层。这是 4.1.8 之后数年依赖治理的延续结果也印证了放宽约束这一方向最终被贯彻到底。三、Pillow 在 Wagtail 图像处理中的角色一条完整的依赖链要理解这次依赖更新为何重要需要先看清 Wagtail 图像处理的底层架构。Wagtail 并没有直接在整个代码库中到处调用 Pillow而是采用了两层封装Pillow底层图像处理引擎提供 JPEG/PNG/GIF 编解码与安全校验 ↓ Willowwagtail 的图像抽象库统一不同后端 API支持 SVG 等额外格式 ↓ wagtail.images页面/文档模型、上传校验、rendition 渲染从源码中可以找到这条链路的直接证据wagtail/images/fields.py 中的to_python方法明确注释道覆写 Django 的ImageFielduse Willow instead of Pillow as the image library in order to enable SVG support使用 Willow 替代 Pillow 作为图像库以支持 SVG并通过willow.Image.open(file)打开上传文件wagtail/images/models.py 中ImageFileMixin/AbstractRendition等模型大量使用willow.Image.open(...)、willow.auto_orient()、willow.crop(...)、willow.resize(...)等 API 完成 rendition 生成wagtail/images/checks.py 的from willow.image import Image用于系统检查。而 Willow 本身是构建在 Pillow 之上的例如测试代码 wagtail/images/tests/test_models.py 直接引用了from willow.plugins.pillow import PillowImagewagtail/images/tests/test_image_operations.py 中也有对willow.plugins.pillow.PillowImage.save_as_avif的 patch。因此Pillow 的每个安全修复最终都会经由 Willow 传导到 Wagtail 的所有图像上传、校验与渲染路径。这也是 4.1.7 与 4.1.8 需要先放宽 Willow、再放宽 Pillow双层放开的根本原因两层约束中任何一层卡住安全版本都装不进去。四、安全修复的落点上传校验与像素炸弹防护Pillow 历史上多次因图像解码器特别是 PNG、JPEG的越界读写、解压炸弹decompression bomb等问题发布安全修复。在 Wagtail 侧这些风险集中体现在图像上传校验环节对应的实现位于 wagtail/images/fields.pycheck_image_file_sizefields.py按文件字节大小校验可通过设置max_upload_size为None关闭超过上限抛出file_too_large校验错误。check_image_file_formatfields.py校验文件内部实际格式与扩展名一致防止通过伪装扩展名上传 PSD 等危险文件。check_image_pixel_sizefields.py这是与 Pillow 安全机制直接相关的一环。它调用f.image.get_size()获取像素尺寸并显式捕获 Pillow 抛出的两类异常except ( PILImage.DecompressionBombWarning, PILImage.DecompressionBombError, ) as e: # Pillow issues a warning for MAX_IMAGE_PIXELS, and raises an error # for twice that value. Warnings can be turned into errors with a # filter, so check the exception for accuracy. pil_max PILImage.MAX_IMAGE_PIXELS if isinstance(e, PILImage.DecompressionBombError): pil_max * 2 max_pixels_count min(self.max_image_pixels or pil_max, pil_max) raise ValidationError( self.error_messages[file_too_many_pixels] % { num_pixels: _(unknown number), max_pixels_count: max_pixels_count, }, codefile_too_many_pixels, ) from None这里直接依赖了 Pillow 的MAX_IMAGE_PIXELS常量及其警告/报错两级阈值机制超过软限制MAX_IMAGE_PIXELSPillow 发出DecompressionBombWarning超过两倍则抛出DecompressionBombError。Wagtail 将这两种情况统一转换为上传校验错误阻止超大像素图像进入系统——这正是针对解压炸弹攻击的防御。Pillow 的安全修复版本往往会调整、补充这类解码保护逻辑因此允许使用含安全修复的 Pillow 版本直接增强了这一防线的有效性。对应的测试用例位于 wagtail/images/tests/test_admin_views.py其中用数据驱动的形式验证了 Pillow 软/硬阈值与 Wagtail 自定义像素上限的组合行为例如(None, 20, (5, 10), default, 40), # Two times the Pillow soft limit (None, 20, (2, 11), error, 20), # Pillow soft limit becomes hard limit (10, 4, (3, 3), default, 8), # Pillow hard limit pixels Wagtail limit可见安全相关的校验逻辑是被测试显式覆盖的升级 Pillow 后这些测试可以作为回归验证的依据。五、渲染路径Pillow 通过 Willow 驱动的 rendition 生成图像上传校验之外Pillow 还深度参与页面图片的 rendition 渲染。在 wagtail/images/models.py 的Filter.run方法models.py中可以看到完整流程with self.get_willow_image(image, source) as willow: original_format willow.format_name # Fix orientation of image willow willow.auto_orient() # Transform the image transform self.get_transform( image, (willow.image.width, willow.image.height) ) willow willow.crop(transform.get_rect().round()) willow willow.resize(transform.size) # Apply filters for operation in self.filter_operations: willow operation.run(willow, image, env) or willow # Determine output format (bmp→png, heic→jpeg, unanimated gif→png 等) ...渲染管线中的get_willow_image上下文管理器models.py统一通过willow.Image.open(source)打开源文件auto_orient、crop、resize等操作在底层均由 Willow 调度到 Pillow 实现。也就是说任何一次{% image %}模板标签调用、任何一张上传图片的缩略图生成都在运行时触碰 Pillow 的解码/编码代码路径。如果部署环境中的 Pillow 存在已知安全漏洞攻击者可能通过精心构造的图片在渲染时触发反之升级到含安全修复的 Pillow 版本后整条渲染链也随之获得保护。这正是 4.1.8 依赖更新对生产站点最直接的收益。六、升级到 4.1.8 的实践建议作为 LTS 维护版4.1.8 的升级路径非常平滑——它不含破坏性变更核心动作就是让依赖解析器接受新版 Pillow确认当前基线项目应处于 Wagtail 4.1.x 系列LTS。从 4.1.7 升级到 4.1.8 通常只需更新版本号并重新安装依赖pip install wagtail4.1.8 pip install --upgrade Pillow具体安装方式取决于项目使用的虚拟环境与依赖管理工具如 requirements.txt 或 poetry。验证依赖解析安装完成后检查 Pillow 实际版本确认 pip 已按放宽后的约束安装了包含安全修复的版本且无依赖冲突警告。回归图像功能重点回归上传与渲染两条路径——上传各格式图片JPEG/PNG/GIF/SVG验证校验逻辑文件大小、像素上限、格式匹配正常生成各规格 rendition确认auto_orient、裁剪、缩放与格式转换结果符合预期。仓库中的测试套件如 wagtail/images/tests/test_admin_views.py 与 wagtail/images/tests/test_image_operations.py可视为官方对这些行为的标准验证。留意后续版本从 CHANGELOG.txt 可见紧接其后的 4.1.9 修复了 CVE-2023-45809管理后台批量操作视图泄露用户名属于安全修复版本LTS 用户应尽快跟进确保同时覆盖图像依赖与后台信息泄露两条安全线。小结Wagtail 4.1.8 是一个小而关键的 LTS 维护版它没有新功能却通过放宽 Pillow 依赖约束打通了安全修复版本进入生产环境的通道。结合 wagtail/images/fields.py 中的像素炸弹校验、wagtail/images/models.py 中的 rendition 渲染管线可以清楚地看到 Pillow 在 Wagtail 图像上传与渲染两条核心路径上的安全分量。对 4.1 LTS 用户而言升级到 4.1.8 并在其后跟进 4.1.9是当时维持站点安全基线最直接的操作。赞分享CMS后端【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址https://gitcode.com/GitHub_Trending/wa/wagtail点击查看免费下载相关推荐ClickHouse v25.3.14.14-lts 补丁发布解析LTS 分支回移植修复与构建依赖更新全解ClickHouse v25.3.14.14 lts 补丁发布解析LTS 分支回移植修复与构建依赖更新全解 本篇基于 ClickHouse 仓库中的官方变更记数据库OLAP列式数据库大数据实时分析数据分析Node.js 24.14.1 KryptonLTS安全发布全解析8 个 CVE 修复、依赖更新与升级校验指南Node.js 24.14.1 KryptonLTS安全发布全解析8 个 CVE 修复、依赖更新与升级校验指南 本篇文章基于 nodejs.org 官前端文档PouchDB 7.1.1 发布解析一次以 Bug 修复与依赖更新为核心的维护性版本PouchDB 7.1.1 发布解析一次以 Bug 修复与依赖更新为核心的维护性版本 PouchDB 7.1.1 是 7.x 系列中一个以稳定性为目标的维护性数据库数据同步上一篇5分钟快速上手LangGraph构建智能Agent的完整指南下一篇如何通过开源H5可视化编辑器实现企业级零代码开发平台创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CMS后端【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址https://gitcode.com/GitHub_Trending/wa/wagtail点击查看免费下载Wagtail 4.1.8 是 4.1 Long Term SupportLTS系列在 2023 年 9 月 28 日发布的维护版本其发布说明记录了唯一一项维护变更——放宽 Pillow 依赖约束以便站点可以使用包含安全修复的 Pillow 新版本。本文以这份发布说明为骨架梳理 LTS 维护策略下的版本节奏并深入 Wagtail 图像处理模块Pillow → Willow → Wagtail images的源码实现说明为什么一次依赖放宽对生产站点如此关键以及升级时应如何验证。一、版本概览一次典型的 LTS 维护发布根据官方发布说明 docs/releases/4.1.mdWagtail 4.1 于 2022 年 11 月 1 日发布并被指定为 Long Term SupportLTS版本。LTS 系列的维护承诺是在下一个 LTS 版本发布之前通常约 12 个月持续提供用于修复安全问题与数据丢失问题的维护更新。这正是 4.1.8 这类小版本存在的意义——它不引入新功能只保证 LTS 用户能安全、稳定地运行。从发布说明 docs/releases/4.1.8.md 可以看到本次发布仅包含一条 Whats new 记录类型为 Maintenance维护Additionally update Pillow dependency to allow use of versions with security fixesDan Braghis结合 CHANGELOG.txt 中相邻版本的记录可以还原这次发布在版本时间线上的位置版本日期核心内容4.1LTS2022-11-01首个 LTS 版本发布4.1.72023-09-27Relax Willow dependency to allow use of current Pillow versions with security fixes4.1.82023-09-28Additionally update Pillow dependency to allow use of versions with security fixes4.1.92023-10-19修复 CVE-2023-45809通过管理后台批量操作视图泄露用户名值得注意的细节是4.1.7 与 4.1.8 仅相隔一天且都指向同一目标——让 LTS 用户能够使用包含安全修复的 Pillow 版本。这说明在 2023 年 9 月下旬Pillow 的某个安全修复版本已经发布而 Wagtail 的依赖约束尚未放开用户即使升级 Pillow 也会被 pip 的版本解析拒绝因此需要连续两个维护版依次放宽 Willow 与 Pillow 的上限约束。二、本次变更的核心Pillow 依赖约束放宽1. 为什么依赖约束会成为安全瓶颈Wagtail 通过setup.py与 pyproject.toml 声明运行依赖。在 pip 安装时依赖解析器会严格遵循版本区间约束如果约束写死为Pillow9.1.0,10那么即使 Pillow 发布了包含安全修复的 10.x 版本pip install也会拒绝安装导致修复永远无法进入生产环境。从 CHANGELOG.txt 的历史记录可以完整看到这条依赖约束的演进脉络4.1.82023-09-28Additionally update Pillow dependency to allow use of versions with security fixes—— 正是本文讨论的这次放宽5.0.32023-09-25Update Pillow dependency to 9.1.05.0 系列后期Update Pillow dependency to allow 10.x, only include support for 9.1.0更新的维护记录Remove upper bound on Pillow dependency彻底移除上限。也就是说4.1.8 处于一个从受限到逐步放开的关键节点它没有直接移除上限而是额外更新Additionally update了约束允许安装包含安全修复的 Pillow 版本——这既是安全响应也保持了 LTS 系列谨慎克制、不做破坏性变更的发布风格。2. 当前仓库中的依赖状态参考作为对照当前仓库的 pyproject.toml 中图像依赖已演进为dependencies [ ... Pillow9.1.0, Willow[heif]1.11.0,2, ... ]可以看到Pillow 下限保持9.1.0与 5.0.3 的记录一致且不再有上限同时引入了 Willow 作为图像抽象层。这是 4.1.8 之后数年依赖治理的延续结果也印证了放宽约束这一方向最终被贯彻到底。三、Pillow 在 Wagtail 图像处理中的角色一条完整的依赖链要理解这次依赖更新为何重要需要先看清 Wagtail 图像处理的底层架构。Wagtail 并没有直接在整个代码库中到处调用 Pillow而是采用了两层封装Pillow底层图像处理引擎提供 JPEG/PNG/GIF 编解码与安全校验 ↓ Willowwagtail 的图像抽象库统一不同后端 API支持 SVG 等额外格式 ↓ wagtail.images页面/文档模型、上传校验、rendition 渲染从源码中可以找到这条链路的直接证据wagtail/images/fields.py 中的to_python方法明确注释道覆写 Django 的ImageFielduse Willow instead of Pillow as the image library in order to enable SVG support使用 Willow 替代 Pillow 作为图像库以支持 SVG并通过willow.Image.open(file)打开上传文件wagtail/images/models.py 中ImageFileMixin/AbstractRendition等模型大量使用willow.Image.open(...)、willow.auto_orient()、willow.crop(...)、willow.resize(...)等 API 完成 rendition 生成wagtail/images/checks.py 的from willow.image import Image用于系统检查。而 Willow 本身是构建在 Pillow 之上的例如测试代码 wagtail/images/tests/test_models.py 直接引用了from willow.plugins.pillow import PillowImagewagtail/images/tests/test_image_operations.py 中也有对willow.plugins.pillow.PillowImage.save_as_avif的 patch。因此Pillow 的每个安全修复最终都会经由 Willow 传导到 Wagtail 的所有图像上传、校验与渲染路径。这也是 4.1.7 与 4.1.8 需要先放宽 Willow、再放宽 Pillow双层放开的根本原因两层约束中任何一层卡住安全版本都装不进去。四、安全修复的落点上传校验与像素炸弹防护Pillow 历史上多次因图像解码器特别是 PNG、JPEG的越界读写、解压炸弹decompression bomb等问题发布安全修复。在 Wagtail 侧这些风险集中体现在图像上传校验环节对应的实现位于 wagtail/images/fields.pycheck_image_file_sizefields.py按文件字节大小校验可通过设置max_upload_size为None关闭超过上限抛出file_too_large校验错误。check_image_file_formatfields.py校验文件内部实际格式与扩展名一致防止通过伪装扩展名上传 PSD 等危险文件。check_image_pixel_sizefields.py这是与 Pillow 安全机制直接相关的一环。它调用f.image.get_size()获取像素尺寸并显式捕获 Pillow 抛出的两类异常except ( PILImage.DecompressionBombWarning, PILImage.DecompressionBombError, ) as e: # Pillow issues a warning for MAX_IMAGE_PIXELS, and raises an error # for twice that value. Warnings can be turned into errors with a # filter, so check the exception for accuracy. pil_max PILImage.MAX_IMAGE_PIXELS if isinstance(e, PILImage.DecompressionBombError): pil_max * 2 max_pixels_count min(self.max_image_pixels or pil_max, pil_max) raise ValidationError( self.error_messages[file_too_many_pixels] % { num_pixels: _(unknown number), max_pixels_count: max_pixels_count, }, codefile_too_many_pixels, ) from None这里直接依赖了 Pillow 的MAX_IMAGE_PIXELS常量及其警告/报错两级阈值机制超过软限制MAX_IMAGE_PIXELSPillow 发出DecompressionBombWarning超过两倍则抛出DecompressionBombError。Wagtail 将这两种情况统一转换为上传校验错误阻止超大像素图像进入系统——这正是针对解压炸弹攻击的防御。Pillow 的安全修复版本往往会调整、补充这类解码保护逻辑因此允许使用含安全修复的 Pillow 版本直接增强了这一防线的有效性。对应的测试用例位于 wagtail/images/tests/test_admin_views.py其中用数据驱动的形式验证了 Pillow 软/硬阈值与 Wagtail 自定义像素上限的组合行为例如(None, 20, (5, 10), default, 40), # Two times the Pillow soft limit (None, 20, (2, 11), error, 20), # Pillow soft limit becomes hard limit (10, 4, (3, 3), default, 8), # Pillow hard limit pixels Wagtail limit可见安全相关的校验逻辑是被测试显式覆盖的升级 Pillow 后这些测试可以作为回归验证的依据。五、渲染路径Pillow 通过 Willow 驱动的 rendition 生成图像上传校验之外Pillow 还深度参与页面图片的 rendition 渲染。在 wagtail/images/models.py 的Filter.run方法models.py中可以看到完整流程with self.get_willow_image(image, source) as willow: original_format willow.format_name # Fix orientation of image willow willow.auto_orient() # Transform the image transform self.get_transform( image, (willow.image.width, willow.image.height) ) willow willow.crop(transform.get_rect().round()) willow willow.resize(transform.size) # Apply filters for operation in self.filter_operations: willow operation.run(willow, image, env) or willow # Determine output format (bmp→png, heic→jpeg, unanimated gif→png 等) ...渲染管线中的get_willow_image上下文管理器models.py统一通过willow.Image.open(source)打开源文件auto_orient、crop、resize等操作在底层均由 Willow 调度到 Pillow 实现。也就是说任何一次{% image %}模板标签调用、任何一张上传图片的缩略图生成都在运行时触碰 Pillow 的解码/编码代码路径。如果部署环境中的 Pillow 存在已知安全漏洞攻击者可能通过精心构造的图片在渲染时触发反之升级到含安全修复的 Pillow 版本后整条渲染链也随之获得保护。这正是 4.1.8 依赖更新对生产站点最直接的收益。六、升级到 4.1.8 的实践建议作为 LTS 维护版4.1.8 的升级路径非常平滑——它不含破坏性变更核心动作就是让依赖解析器接受新版 Pillow确认当前基线项目应处于 Wagtail 4.1.x 系列LTS。从 4.1.7 升级到 4.1.8 通常只需更新版本号并重新安装依赖pip install wagtail4.1.8 pip install --upgrade Pillow具体安装方式取决于项目使用的虚拟环境与依赖管理工具如 requirements.txt 或 poetry。验证依赖解析安装完成后检查 Pillow 实际版本确认 pip 已按放宽后的约束安装了包含安全修复的版本且无依赖冲突警告。回归图像功能重点回归上传与渲染两条路径——上传各格式图片JPEG/PNG/GIF/SVG验证校验逻辑文件大小、像素上限、格式匹配正常生成各规格 rendition确认auto_orient、裁剪、缩放与格式转换结果符合预期。仓库中的测试套件如 wagtail/images/tests/test_admin_views.py 与 wagtail/images/tests/test_image_operations.py可视为官方对这些行为的标准验证。留意后续版本从 CHANGELOG.txt 可见紧接其后的 4.1.9 修复了 CVE-2023-45809管理后台批量操作视图泄露用户名属于安全修复版本LTS 用户应尽快跟进确保同时覆盖图像依赖与后台信息泄露两条安全线。小结Wagtail 4.1.8 是一个小而关键的 LTS 维护版它没有新功能却通过放宽 Pillow 依赖约束打通了安全修复版本进入生产环境的通道。结合 wagtail/images/fields.py 中的像素炸弹校验、wagtail/images/models.py 中的 rendition 渲染管线可以清楚地看到 Pillow 在 Wagtail 图像上传与渲染两条核心路径上的安全分量。对 4.1 LTS 用户而言升级到 4.1.8 并在其后跟进 4.1.9是当时维持站点安全基线最直接的操作。赞分享CMS后端【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址https://gitcode.com/GitHub_Trending/wa/wagtail点击查看免费下载相关推荐ClickHouse v25.3.14.14-lts 补丁发布解析LTS 分支回移植修复与构建依赖更新全解ClickHouse v25.3.14.14 lts 补丁发布解析LTS 分支回移植修复与构建依赖更新全解 本篇基于 ClickHouse 仓库中的官方变更记数据库OLAP列式数据库大数据实时分析数据分析Node.js 24.14.1 KryptonLTS安全发布全解析8 个 CVE 修复、依赖更新与升级校验指南Node.js 24.14.1 KryptonLTS安全发布全解析8 个 CVE 修复、依赖更新与升级校验指南 本篇文章基于 nodejs.org 官前端文档PouchDB 7.1.1 发布解析一次以 Bug 修复与依赖更新为核心的维护性版本PouchDB 7.1.1 发布解析一次以 Bug 修复与依赖更新为核心的维护性版本 PouchDB 7.1.1 是 7.x 系列中一个以稳定性为目标的维护性数据库数据同步上一篇5分钟快速上手LangGraph构建智能Agent的完整指南下一篇如何通过开源H5可视化编辑器实现企业级零代码开发平台创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
