question: Release schedule, new release needed

[viplezer-well]

Hey Everyone!

I am wondering about the release schedule of this library; the current git history contains a dependabot fix for a high vulnerability in the validator dependency.

Wondering when that will be released as this high vulnerability is showing up in our codebase as well as a vulnerability and we have strict deadlines on tackling vulnerability issues.

We'd like to request a new patch version ASAP!

Thanks!

[viplezer-well]

opened a PR for a new release: #2661

[getTobiasNielsen]

This is just some friendly advice, but I don't see why dependabot or renovate bot would not be able to automatically upgrade the version, as it is with in the allowed range.

There might be a dependabot setting that you can change and get the updates that you are missing, and others much sooner.

[viplezer-well]

@getTobiasNielsen yes, we ended up introducing overrides/resolutions for our usages, but we'd prefer to see packages actually including and releasing versions with fixed dependencies. Maybe that's only a personal preference, but still. Anyway, we are considering class-validator as abandonware at this point.

[getTobiasNielsen]

I might be missing something, but I believe dependabot should be able to respect:

(class-validator package.json as of writing)
"dependencies": {
"@types/validator": "^13.15.3",
"libphonenumber-js": "^1.11.1",
"validator": "^13.15.22"
},

where ^13.15.22 also includes 13.15.26

There might be more places where dependabot could also gain these bumps in packages, and therefore fix more issues without needing manual overrides/resolutions. But I am open to the idea that I might be missing something?

[viplezer-well]

@getTobiasNielsen you are not missing anything or not being wrong at all. This transient dependency is easily updatable with npm/yarn commands (or overrideable if you want to see fixed dependencies as much as possible in your package.jsons - which we want here).

Two thoughts:

• Tilde and caret versioning in package.jsons leaves users vulnerable to supply chain attacks such as Shai-Hulud (if they are not committing lock files, which I did see earlier at places), so locked-down versioning could be advised - but that's just my opinion
• The fix PR was already merged two months ago. I've put together a release PR for a patch release a month ago. I tried to tag people who I saw contributing to this project in the past 3 months without any luck. I am pretty sure your intention is helpful, and you want to help me solve the situation and not advocate against releasing a new version. I just don't see why maintainers are not releasing already merged changes if everything got put together for that, thus I opened this issue.

As we have resolved our dependency issue in-house, we could close this easily, but I am still wondering about the release mechanism of this widely used project, which could be automated such as we can see at many other repositories.

[getTobiasNielsen]

Tilde and caret versioning in package.jsons leaves users vulnerable to supply chain attacks such as Shai-Hulud (if they are not committing lock files, which I did see earlier at places), so locked-down versioning could be advised - but that's just my opinion

No, you are right on this. My intent was to make sure that you wouldn't be "stuck" on those versions. But from your point of view, you want to eliminate the possibility of vulnerable transient dependencies being easier to introduce or reintroduce, by being able to pin a higher top level dependency. It makes perfect sense to me now.

Edit: I realized you also need to force lockFileMaintenance in the projects that are currently vulnerable if your release does not go out, which would leave more people vulnerable if not released. So it really makes it important that vulnerabilities are patched on the root dependency level, as you stated.