8 comments

  • alpineman2 hours ago
    &gt;&gt; high-impact npm accounts are now put into a read-only mode for 72 hours when they change their email or use a 2FA recovery code. This delay allows maintainers time to respond and recover the account before their account can be used to start an attack.<p>&#x27;what time shall we put here?&#x27;<p>&#x27;what&#x27;s the longest hangover you ever had?&#x27;<p>&#x27;let&#x27;s put 72 hours&#x27;
    • Waterluvian1 hour ago
      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.
      • datakan1 hour ago
        I don&#x27;t think so at all. People go on vacation all the time. This should be 30 days not 3.
        • Waterluvian1 hour ago
          That&#x27;s the usual runaway problem, right? Why not 60 then? People go on sabbaticals! etc etc.<p>I feel like the only way to be wrong for this class of problem is to believe that there&#x27;s a singular right answer. Just pick something reasonable (like how weekends are a fairly common thing, so don&#x27;t make it shorter than 48 hours). Start there, then see how much of an issue persists. No matter what, at scale you&#x27;ll find someone complaining that the number is too little, and people complaining that it&#x27;s too much. Eventually you just have to tell the complainers to deal with it.
          • datakan56 minutes 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.<p>Cyber attacks will frequently happen on a Friday just for this scenario, they anticipate no ones looking over the weekend.
            • tredre331 minutes ago
              And 365 days probably aligns with 100% of scenarios. It doesn&#x27;t mean it&#x27;s a good idea, because the longer the delay is the more downsides you also get.<p>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.
        • normie30001 hour ago
          It&#x27;s often not the maintainer that removes a poisoned release, it&#x27;s the npm security team&#x2F;tools. So unless the whole team takes a month off, we&#x27;re all safe.
  • summarybot56 minutes ago
    Github owns NPM. Github has unprecedented access to code analysis tools. Github can run static analysis on nearly everything. Introducing a cooldown period seems like the lowest tech solution to a technological problem I have seen in a longwhile.
  • skipants54 minutes ago
    One thing I don&#x27;t quite get is how trusted publishing is supposed to be more secure. It still allows publishing if they pwn your workflow.<p>Is it purely more secure because they can&#x27;t exfiltrate your secret keys to publish again?<p>I feel like if your workflow gets pwned you&#x27;d be rotating your keys anyways, so I&#x27;m not sure if the vendor lock-in is worth it.
    • pimterry18 minutes ago
      Trusted <i>staged</i> publishing helps a lot: you have to independently pwn the workflow _and_ then complete a separate 2FA flow as a maintainer. The workflow never sees any keys that can publish independently.
    • flyingshelf39 minutes ago
      Keys can be reused from anywhere. Trusted publishing means the attacker must trigger the specific workflow <i>on GitHub</i>, which is more difficult and leaves trace of actions on GitHub itself.
  • hncsiocp9x2 hours ago
    Been quietly thinking this for years
  • torment-nexus45 minutes ago
    [flagged]
  • DiabloD33 hours ago
    [flagged]
    • theF00l3 hours ago
      The job can require you to
      • DiabloD33 hours ago
        [flagged]
        • UqWBcuFx6NV4r2 hours ago
          These comments should be removed r from HN, because they in no way actually add to the conversation. They aren’t intelligent, they aren’t insightful, they aren’t actionable, and they don’t invite a genuine reply. All you’re saying is that you happen to not use these technologies yourself – something that I’m sure is only by happenstance – and that you feel superior for it.<p>This is a blog post by GitHub. what are you suggesting that these employees do? Simply ignore that they exist? Regardless of whether or not you use them, they still exist.
          • sieabahlpark1 hour ago
            [dead]
          • anon482932 hours ago
            &gt; This is a blog post by GitHub. what are you suggesting that these employees do? Simply ignore that they exist?<p>The buggy, insecure feature that is GitHub actions? Yes, preferably so.
        • x86a3 hours ago
          This is such a myopic take
        • baby_souffle2 hours ago
          GitHub actions doesn’t really make you a js shop
    • rho1383 hours ago
      &gt; Opting out of toxic ecosystems is a valid option<p>Quick, everyone break out the pitchforks for a valid analysis of a game! &#x2F;s
  • pluto_modadic2 hours ago
    the bare minimum award, for the only language and only registry where this regularly happens.