#--min-release-age

1 messages · Page 1 of 1 (latest)

bronze furnace
#

Thread!

#

@oak salmon I have been thinking about the zero-day/vulnerability story for "get latest" as a feature, I don't know if we should consider "get latest" as a security feature. If people are doing what we're expecting them to do, which is pin versions in applications, then that feature /shouldn't/ be a security feature right?

oak salmon
#

But people don't do that

bronze furnace
#

I need to do more thinking and writing and probably data collection about it, but it seems counterintuitive to me.

oak salmon
#

Or at least a lot of people don't do that

bronze furnace
#

/Some/ people don't do that, but I guess my mental model for people who aren't doing that are people who aren't deploying applications?

oak salmon
#

In my anecdotal experience of working in finance companies there are lots of people deploying applications by randomly pip installing into production

bronze furnace
#

Right, but in your mental model do you believe these same users would also be using dependency cooldowns?

#

opt-in ones, via pip?

#

IMO this matters for sure if we're switching it to a default somewhere.

oak salmon
#

Possibly someone would set it as a global pip conf, yeah

bronze furnace
#

Hmm, yeah my profiles of "how people use pip" are all over the place. Because there's folks that probably don't ever run upgrade and have one environment and that's the environment.

#

Like this only matters if you're running pip install on a fresh environment over and over again, so like, Docker but not with lock files.

oak salmon
#

Right, the spectrum of use is big, and I'm a little less concerned about users who know how to use lock files and have everything pinned, because they likely can put some thought into what cooldown period makes sense for them, but that's my personal take and I appreciate there are others

bronze furnace
#

Just to give more bounds to the value I consider useful at all is minimum 3 days, because weekends exist and most of the easy to spot malware is "gone" within 24 hours.

oak salmon
#

That seems fair

#

The other issues is I write the note about picking up security vulnerabilities, but I don't actually explain how you can install security fixes without exposing yourself to supply chain issues, because the answer is "it's complicated"

#

Which also makes me nervous about giving an example of a long cooldown

bronze furnace
#

It is really complicated. I do think it would be a net improvement if nearly all users had a 1 day dependency cooldown on when installing from PyPI, that's where I'm at mentally right now. Zero-days are a thing, but if we're evaluating the value of "stopping attacks like LiteLLM" versus "delaying accidental patching by ~negligent users" it feels like the former is more valuable.

#

And when I say negligent, I mean the leaders not staffing security-expertise and time to learn properly not the people writing pip install.

coral drum
#

I think people who use lock files probably aren’t the ones likely to be using this feature?

#

Presumably they have some process they’re using to regularly bump those lock files

#

I guess in theory they could be manually re-locking, and then they could use the relative timer? But tbh the relative timer seems like a feature that is most useful for people who aren’t locking

oak salmon
#

I'm doing exactly that! I have a pylock.toml that gets updated by manually kicking off a script that applies all sorts of constraints that aren't expressible via a regular pyproject.toml, and I've currently set a one day cooldown on it. I'm not suggesting though many people