Default cooldown for everyone is basically introducing a beta period for all packages.
Dependabot version updates introduce default package cooldown
141–150 of 154 posts
Re: Dependabot version updates introduce default package cooldown
#142Re: Dependabot version updates introduce default package cooldown
#143Re: Dependabot version updates introduce default package cooldown
#144Earlier quoted context omitted.
Package them for Debian as well then?
Errm no? What kind of a solution is that?
I don’t know what’s up with this thread, for some reason people insist that language packages and distro packages are nearly the same.
There must be a lot of packages for languages that are useful that simply never make it into Debian stable. “Where’s the patch” really isn’t an answer for this.
Re: Dependabot version updates introduce default package cooldown
#145[dead]
Re: Dependabot version updates introduce default package cooldown
#146Earlier quoted context omitted.
Why not to create a separate list of verified package versions for most popular packages, AKA «stable» channel? Use stable channel for typical packages, use bleeding edge channel for some specific packages only.
> verified package versions Who is doing this verification?
Those with skin in the game.
Re: Dependabot version updates introduce default package cooldown
#147[deleted]
Re: Dependabot version updates introduce default package cooldown
#148I really hate dependabot making generic security people at work so pushy about updates updates updates. They seem to just be dogmatic about whatever dependabot says, forcing churn even when the documented issues are clearly not relevant. I’m not sure how to handle it politically. I’m convinced that updating so much more often is worse, not better.
I don't know if all ecosystems are as bad as node is, but the node ecosystem has terrible issue severity ranking which makes infosec squeamish for no reason. Every week or so there's a new High+ "vulnerability" that gets published against our dependencies and I have to go look at it to confirm that it's yet another case of "it's possible for someone to give this dev-only tool a bad regex that would cause the test run…
The direct vs transitive split helps a lot here. Most of that noise is transitive deps your app never actually calls with attacker-controlled input.
Re: Dependabot version updates introduce default package cooldown
#149Earlier quoted context omitted.
> language package managers are not [curated] Why not? Seems like exactly what is being asked for.
Curated by whom? If you want to curate a language package manager, there's nobody stopping you. Curation is a product that can trivially be built on top of an allow-by-default platform. If you want to make "NPM, except we've vetted all the packages", you can just do that, today, and you can even make use of all the OSS packages that already exist on NPM. Your hypothesis is that people want this, would value it if it…
> Anyone who hasn't thought deeply enough to answer this question doesn't have the privelige to say "just curate it, what's the problem?". Curation isn't that simple, as any distro package manager volunteer would tell you.
Your logic is self-defeating. How are distro volunteers going to know that you are interested in this topic if, by your logic, you don't have the privilege to ask them in the first place?
But I don't think that asking needs any privilege. I'm going to ask again: Why not? Or worded differently: What is stopping language package managers that is not at the same time stopping distro package managers?
Re: Dependabot version updates introduce default package cooldown
#150Earlier quoted context omitted.
I don't know if all ecosystems are as bad as node is, but the node ecosystem has terrible issue severity ranking which makes infosec squeamish for no reason. Every week or so there's a new High+ "vulnerability" that gets published against our dependencies and I have to go look at it to confirm that it's yet another case of "it's possible for someone to give this dev-only tool a bad regex that would cause the test run…
The direct vs transitive split helps a lot here. Most of that noise is transitive deps your app never actually calls with attacker-controlled input.
I don't think transitive definitionally means we can ignore it. Any input that I give to my direct dependencies could theoretically end up inside of its dependencies and I can't know that it doesn't without auditing the source.
The actual split is on which environments the dependency exists in and who can control inputs in those environments. For most private companies who aren't running CI on an open source repo, the dev/prod split is the operative one that determines what you can safely ignore.