4 ms·

A weekend plus a day to deal with things seems like a decent minimum duration when it’s somewhat arbitrary what the right number is.

datakan 3mo ago
I don't think so at all. People go on vacation all the time. This should be 30 days not 3.
- Waterluvian 3mo ago
  That's the usual runaway problem, right? Why not 60 then? People go on sabbaticals! etc etc. I feel like the only way to be wrong for this class of problem is to believe that there's a singular right answer. Just pick something reasonable (like how weekends are a fairly common thing, so don't make it shorter than 48 hours). Start there, then see how much of an issue persists. No matter what, at scale you'll find someone complaining that the number is too little, and people complaining that it's too much. Eventually you just have to tell the complainers to deal with it.
  - datakan 3mo ago
    There is a big difference between 3 days when someone may be sick or traveling and not looking and 30 which aligns better with 99% of scenarios this may be an issue with. 3 days is absurd. Even password apps with kill switches will default to 7 days. Cyber attacks will frequently happen on a Friday just for this scenario, they anticipate no ones looking over the weekend.
    - tredre3 3mo ago
      And 365 days probably aligns with 100% of scenarios. It doesn't mean it's a good idea, because the longer the delay is the more downsides you also get. Blocking a maintainer from pushing updates for a full month after changing their e-mail would be obviously absurd. So Github would have to add a way of enabling maintainers to super-uper-duper confirm the change and cut the delay short. Which is likely not currently possible, hence starting with a shorter delay.
- normie3000 3mo ago
  It's often not the maintainer that removes a poisoned release, it's the npm security team/tools. So unless the whole team takes a month off, we're all safe.
- Normal_gaussian 3mo ago
  It sounds like we should plot 'count of compromised repos' against 'time taken for maintainer to initiate a resolution', and pick something just after the inflection point.

datakan 3mo ago

I don't think so at all. People go on vacation all the time. This should be 30 days not 3.

Waterluvian 3mo ago
That's the usual runaway problem, right? Why not 60 then? People go on sabbaticals! etc etc. I feel like the only way to be wrong for this class of problem is to believe that there's a singular right answer. Just pick something reasonable (like how weekends are a fairly common thing, so don't make it shorter than 48 hours). Start there, then see how much of an issue persists. No matter what, at scale you'll find someone complaining that the number is too little, and people complaining that it's too much. Eventually you just have to tell the complainers to deal with it.
- datakan 3mo ago
  There is a big difference between 3 days when someone may be sick or traveling and not looking and 30 which aligns better with 99% of scenarios this may be an issue with. 3 days is absurd. Even password apps with kill switches will default to 7 days. Cyber attacks will frequently happen on a Friday just for this scenario, they anticipate no ones looking over the weekend.
  - tredre3 3mo ago
    And 365 days probably aligns with 100% of scenarios. It doesn't mean it's a good idea, because the longer the delay is the more downsides you also get. Blocking a maintainer from pushing updates for a full month after changing their e-mail would be obviously absurd. So Github would have to add a way of enabling maintainers to super-uper-duper confirm the change and cut the delay short. Which is likely not currently possible, hence starting with a shorter delay.
normie3000 3mo ago
It's often not the maintainer that removes a poisoned release, it's the npm security team/tools. So unless the whole team takes a month off, we're all safe.
Normal_gaussian 3mo ago
It sounds like we should plot 'count of compromised repos' against 'time taken for maintainer to initiate a resolution', and pick something just after the inflection point.