I can't comment/review, I don't know if pinning is to prefer to plain versions.

I can't comment/review, I don't know if pinning is to prefer to plain versions.

My understanding is that pinning dependencies is preferred for OpenSSF, which I believe curl is signed up for. It's also better to pin to a hash rather than a tag because tags can be changed on Git.

I don't think it's adding much security but I think it's a best practice that doesn't add much, if any, friction with its use.

It's also better to pin to a hash rather than a tag because tags can be changed on Git.

... and we automatically adapt to the new one by advancing the pin? Or what kind of extra checks are done when the pin is updated?

How often is this changing, do we know? Does it risk becoming a nuisance?

"actions/checkout" is pinned to two different hashes which looks incorrect

... and we automatically adapt to the new one by advancing the pin? Or what kind of extra checks are done when the pin is updated?

How often is this changing, do we know? Does it risk becoming a nuisance?

Yes, this auto-advances by advancing the pin. It's not particularly spammy - given we've had this set up on curl-fuzzer for quite a while now and it's raised a handful of updates.

"actions/checkout" is pinned to two different hashes which looks incorrect

One is v2 and one is v4 - the update here is being handled by #13632

One is v2 and one is v4

So how does it know it is a pinned version of v2 and v4? Is the added comment in the yaml how it knows?

handled by #13632

can't we just merge that PR into this to reduce clutter?

One is v2 and one is v4

So how does it know it is a pinned version of v2 and v4? Is the added comment in the yaml how it knows?

I believe so.

handled by #13632

can't we just merge that PR into this to reduce clutter?

I don't think so. Once every instance of the dependency is on the same version then it becomes much less of a clutter problem.