Mark 9.5.5 as security release, or create GitHub Advisory entry for it?

[HonkingGoose]

Material for MkDocs 9.5.5 includes a security fix:

Updated Pillow to 10.2 to mitigate security vulnerabilities

Does this version of Material for MkDocs needs to be marked as fixing a security problem somehow? For example, by creating a entry in the GitHub Advisory database, or marking it as a security release in the security tab of the repository?

The reason I'm asking is that bots like Dependabot and Renovate prioritize showing security updates to users. This means that users of those tools will probably update sooner.

I don't know how bad the security problem is. So I'll let the maintainers decide if the Material for MkDocs package needs a security advisory.

• build(deps): bump pillow version 10.2 for fix security vulnerability #6689
• GitHub Docs, Browsing security advisories in the GitHub Advisory Database
• Renovate repository, security advisory example, note how it says which versions are affected, and which versions have the fix

[squidfunk]

I'm not sure, but please note that the dependency that was bumped is an optional dependency, which is only needed for image processing. I don't think that bots will consider optional dependencies, so I'm not sure there's any upside.

[HonkingGoose]

Looks like you use Pillow for the optimize plugin, which is a Insider-only feature for now:

• Material for MkDocs, pillow dependency listed for optimize plugin

Dependency bots like Dependabot and Renovate can't read any mkdocs.yml config file ofcourse. 🙃

I think it's safest to mark it as a security problem, and in the security description say how to check if you're affected. Maybe something like this:

Affected versions: <9.5.5
Patched versions: >=9.5.5

How to check if you're affected:

This security advisory only affects users who have enabled the optimize plugin (plugins.optimize).

Check your mkdocs.yml config file to see if you have enabled the optimize plugin.
Read the Material for MkDocs manual, enabled plugins optimize to see what a enabled config looks like.

I noticed that this PR has links to a few upstream GitHub Security Adivisories. It's a good idea to link to those as well:

• build(deps): bump pillow version 10.2 for fix security vulnerability #6689

I'll let you decide what to do. I just wanted to make sure you considered this. 😄

[squidfunk]

We're going to do this for the next security bump we're doing, because Material for MkDocs and MkDocs are build-time dependencies, so the code in question is never run in a user-facing environment anyway. However, probably embarrassingly, I've never marked a release to fix a vulnerability on GitHub yet. How do I do that?

[HonkingGoose]

We're going to do this for the next security bump we're doing, because Material for MkDocs and MkDocs are build-time dependencies, so the code in question is never run in a user-facing environment anyway.

I'll leave that judgement to you. 😄

However, probably embarrassingly, I've never marked a release to fix a vulnerability on GitHub yet. How do I do that?

I think I found the relevant GitHub Docs. It looks like you can do the work from within the Security tab in the squidfunk/mkdocs-material repository.

About repository security advisories

You can use repository security advisories to privately discuss, fix, and publish information about security vulnerabilities in your repository.

GitHub Docs, about repository security advisories

Creating the repository security advisory

You can create a draft security advisory to privately discuss and fix a security vulnerability in your open source project.

GitHub Docs, creating a repository security advisory

[squidfunk]

Thanks, we'll think of it when we bump something because of a CVE the next time.