Alerting of Security vulnerabilities CVE with dependabot #2935

Open
opened 2023-05-03 12:56:42 +00:00 by Cellule · 3 comments

Recently this CVE was published
https://cdn.sheetjs.com/advisories/CVE-2023-30533

Swarm of people are being alerted about it and prompted to update to 0.19.3
However, since you no longer publish on NPM, people are starting to switch to install from your CDN.

I'm not looking to question why you're not publishing on NPM
This issue already kinda addresses it: #2667

My real serious concern is how will security tools like dependabot will now warn users of your library of future CVEs?
A lot of these tools rely greatly on NPM registry and standard installs in package.json, package-lock.json, yarn.lock, etc...

It's hard to know if my fear is founded or not and we'll only truly know when/if another CVE is reported on a version >0.19.3

But I want to make sure your team is aware of the concern and has at least some form of solution/work around in mind to ensure the safety of applications using your library.

Recently this CVE was published https://cdn.sheetjs.com/advisories/CVE-2023-30533 Swarm of people are being alerted about it and prompted to update to 0.19.3 However, since you no longer publish on NPM, people are starting to switch to install from your CDN. I'm not looking to question why you're not publishing on NPM This issue already kinda addresses it: https://git.sheetjs.com/sheetjs/sheetjs/issues/2667 My real serious concern is how will security tools like dependabot will now warn users of your library of future CVEs? A lot of these tools rely greatly on NPM registry and standard installs in package.json, package-lock.json, yarn.lock, etc... It's hard to know if my fear is founded or not and we'll only truly know when/if another CVE is reported on a version >0.19.3 But I want to make sure your team is aware of the concern and has at least some form of solution/work around in mind to ensure the safety of applications using your library.
Owner

All future advisories will be posted at https://cdn.sheetjs.com/advisories/

In the immediate term, you can watch this repo or subscribe to the release RSS feed (https://git.sheetjs.com/sheetjs/sheetjs/tags.rss) to keep up to date.

We will set up a RSS feed for security advisories.

Please report any issues involving third-party tooling with the respective vendors.

All future advisories will be posted at https://cdn.sheetjs.com/advisories/ In the immediate term, you can watch this repo or subscribe to the release RSS feed (https://git.sheetjs.com/sheetjs/sheetjs/tags.rss) to keep up to date. We will set up a RSS feed for security advisories. Please report any issues involving third-party tooling with the respective vendors.
Author

Sorry but this is a very backward way of thinking.
The whole ecosystem has been building over the past years to ensure proper communications and delivery of updates/security related alerts.

Your response is that everything we are used to is thrown out the window and it is our responsibility to actively watch your library for vulnerabilities?

Don't get me wrong, we are a serious company so we will likely have to abide by your provided solution whether we like it or not.

My real concern is for all the smaller/single devs out there that are likely to have their application become vulnerable because they simply cannot watch your special way of doing things.

In my opinion, you had a security flaw in your library, it is your responsibility to alert as many people as possible. One easy way to do this would be to publish security fixes to NPM.
If you only publish security fixes it would ensure proper deliverability of potential threat and you would become part of a healthier javascript ecosystem by making use of already established and time proven security mechanism.

Sorry but this is a very backward way of thinking. The whole ecosystem has been building over the past years to ensure proper communications and delivery of updates/security related alerts. Your response is that everything we are used to is thrown out the window and it is our responsibility to actively watch your library for vulnerabilities? Don't get me wrong, we are a serious company so we will likely have to abide by your provided solution whether we like it or not. My real concern is for all the smaller/single devs out there that are likely to have their application become vulnerable because they simply cannot watch your special way of doing things. In my opinion, you had a security flaw in your library, it is your responsibility to alert as many people as possible. One easy way to do this would be to publish security fixes to NPM. If you only publish security fixes it would ensure proper deliverability of potential threat and you would become part of a healthier javascript ecosystem by making use of already established and time proven security mechanism.

I 100% agree with everything Cellule said. it's really backwards to abandon an established system for reasons that were obviously not thought through.

Please Sheetjs team reconsider moving back to npmjs for the community edition. it will make the lives of thousands of developers much easier.

I 100% agree with everything Cellule said. it's really backwards to abandon an established system for reasons that were obviously not thought through. Please Sheetjs team reconsider moving back to npmjs for the community edition. it will make the lives of thousands of developers much easier.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: sheetjs/sheetjs#2935
No description provided.