3 ms·

@everyone in the industry, everywhere: Urgency is poison. Please, please put a foot in the door whenever you see anyone trying to push this kind of sh*t on yo

@everyone in the industry, everywhere: Urgency is poison. Please, please put a foot in the door whenever you see anyone trying to push this kind of sh*t on your users. Make one month's advance notice the golden standard. I see this pattern in scam mail (including physical) all the time: stamp an unreasonably short notice and expect the mark to panic. This scam works - and this is why legit companies that try this "in good faith" should be shamed for doing it. Actual alerts: just notify. Take immediate, preventive, but non-destructive action, and help the user figure out how to right it - on their own terms.

notmyjob 1y ago
Agree, but this example wasn’t even that aggressive in its urgency and op said they were merely ticking things off the todo, not feeling alarmed by the urgency. The problem is email as it’s used currently. The solution is to not use email.
- niwtsol 1y ago
  The email says accounts will start locking Sept 10th and it was sent Sept 8th - so a 48 hour urgency window or an account would be locked is urgency IMO
  - notmyjob 1y ago
    Fair enough, was just thinking about many low effort scams that have “EMERGENCY!!! ACT NOW!!!” in red boldface. This, by being slightly? less aggressive is actually less likely to trip my “this is phishing” detector. Obviously ymmv.
  - deleted 1y ago
    [deleted]
- naikrovek 1y ago
  > The solution is to not use email. and use what? instant message? few things lack legitimacy more than an instant message asking you to do something. Links in email are much more of a problem than email itself. So tempting to click. It's right there, you don't have to dig through bookmarks, you don't have to remember anything, just click. A link is seductive. the actual solution is to avoid dependencies whenever possible, so that you can review them when they change. You depend on them. You ARE reviewing them, right? Fewer things to depend on is better than more, and NPM is very much an ecosystem where one is encouraged to depend on others as much as possible.
  - rollcat 1y ago
    > the actual solution is to avoid dependencies whenever possible, so that you can review them when they change. If you're publishing your software: you can't "not" depend on some essential service like source hosting or library index. > You ARE reviewing them, right? Werkzeug is 20kloc and is considered "bare bones" of Python's server-side HTTP. If you're going to write a complex Python web app using raw WSGI, you're just going to repeat their every mistake. While at it: review Python itself, GCC, glibc, maybe Linux, your CPU? Society depends on trust.
  - notmyjob 1y ago
    Depends what you use it for. I don’t think email is a single thing in that regard. For example I’ve used it as a backup method for important files and also as 2 factor. Those are wholly different things that warrant different solutions. The majority of email volume is not person to person communication but part of some corporation/spammers/scammers business model who at best, like my bank, is using it to shift liability away from themselves onto consumers and at worst is attempting to defraud me of all I own. It’s still useful in business, maybe, but pretty sure teams/slack/… will win eventually.
- lelanthran 1y ago
  > The problem is email as it’s used currently. The solution is to not use email. No. The problem is unsigned package repositories. The solution is to tie a package to an identity using a certificate. Quickest way I can think off would be requiring packages to be linked to a domain so that the repository can always check incoming changes to packages using the incoming signature against the domain certificate.
  - cluckindan 1y ago
    And one pwned domain later, we are back in square one.
    - lelanthran 1y ago
      > And one pwned domain later, we are back in square one. 1. It's an extra step: before you pwn the package, you need to pwn a domain. 2. When a domain is pwned, the packages it signs can be revoked with a single command.
  - dabockster 1y ago
    That wouldn't work against a really sophisticated attacker. Especially for something that's clearly being maintained for free by one overworked person in their spare time (yet again). You'd need some kind of offline verification method as well for these widely used infrastructure libraries.
    - lelanthran 1y ago
      > That wouldn't work against a really sophisticated attacker. Nothing "really works" against a sophisticated hacker :-/ Doesn't mean that "defense in depth" does not apply. > You'd need some kind of offline verification method as well for these widely used infrastructure libraries. I don't understand why this is an issue, or even what it means: uploading a new package to the repository requires the contributor to be online anyway. The new/updated/replacement package will have to be signed. The signature must be verified by the upload script/handler. The verification can be done using the X509 certificate issued for the domain of the contributor. 1. If the contributor cannot afford the few dollars a year for a domain, they are extremely vulnerable to the supply chain attack anyway (by selling the maintenance of the package to a bad actor), and you shouldn't trust them anyway. 2. If the contributor's domain gets compromised you only have to revoke that specific certificate, and all packages signed with that certificate, in the past or in the future, would not be installable. As I have repeatedly said in the past, NPM (and the JS tools development community in general) had no adults in the room during the design phase. Everything about JS stacks feels like it was designed by children who had never programmed in anything else before. It's a total clown show.

notmyjob 1y ago

Agree, but this example wasn’t even that aggressive in its urgency and op said they were merely ticking things off the todo, not feeling alarmed by the urgency. The problem is email as it’s used currently. The solution is to not use email.

niwtsol 1y ago
The email says accounts will start locking Sept 10th and it was sent Sept 8th - so a 48 hour urgency window or an account would be locked is urgency IMO
- notmyjob 1y ago
  Fair enough, was just thinking about many low effort scams that have “EMERGENCY!!! ACT NOW!!!” in red boldface. This, by being slightly? less aggressive is actually less likely to trip my “this is phishing” detector. Obviously ymmv.
- deleted 1y ago
  [deleted]
naikrovek 1y ago
> The solution is to not use email. and use what? instant message? few things lack legitimacy more than an instant message asking you to do something. Links in email are much more of a problem than email itself. So tempting to click. It's right there, you don't have to dig through bookmarks, you don't have to remember anything, just click. A link is seductive. the actual solution is to avoid dependencies whenever possible, so that you can review them when they change. You depend on them. You ARE reviewing them, right? Fewer things to depend on is better than more, and NPM is very much an ecosystem where one is encouraged to depend on others as much as possible.
- rollcat 1y ago
  > the actual solution is to avoid dependencies whenever possible, so that you can review them when they change. If you're publishing your software: you can't "not" depend on some essential service like source hosting or library index. > You ARE reviewing them, right? Werkzeug is 20kloc and is considered "bare bones" of Python's server-side HTTP. If you're going to write a complex Python web app using raw WSGI, you're just going to repeat their every mistake. While at it: review Python itself, GCC, glibc, maybe Linux, your CPU? Society depends on trust.
- notmyjob 1y ago
  Depends what you use it for. I don’t think email is a single thing in that regard. For example I’ve used it as a backup method for important files and also as 2 factor. Those are wholly different things that warrant different solutions. The majority of email volume is not person to person communication but part of some corporation/spammers/scammers business model who at best, like my bank, is using it to shift liability away from themselves onto consumers and at worst is attempting to defraud me of all I own. It’s still useful in business, maybe, but pretty sure teams/slack/… will win eventually.
lelanthran 1y ago
> The problem is email as it’s used currently. The solution is to not use email. No. The problem is unsigned package repositories. The solution is to tie a package to an identity using a certificate. Quickest way I can think off would be requiring packages to be linked to a domain so that the repository can always check incoming changes to packages using the incoming signature against the domain certificate.
- cluckindan 1y ago
  And one pwned domain later, we are back in square one.
  - lelanthran 1y ago
    > And one pwned domain later, we are back in square one. 1. It's an extra step: before you pwn the package, you need to pwn a domain. 2. When a domain is pwned, the packages it signs can be revoked with a single command.
- dabockster 1y ago
  That wouldn't work against a really sophisticated attacker. Especially for something that's clearly being maintained for free by one overworked person in their spare time (yet again). You'd need some kind of offline verification method as well for these widely used infrastructure libraries.
  - lelanthran 1y ago
    > That wouldn't work against a really sophisticated attacker. Nothing "really works" against a sophisticated hacker :-/ Doesn't mean that "defense in depth" does not apply. > You'd need some kind of offline verification method as well for these widely used infrastructure libraries. I don't understand why this is an issue, or even what it means: uploading a new package to the repository requires the contributor to be online anyway. The new/updated/replacement package will have to be signed. The signature must be verified by the upload script/handler. The verification can be done using the X509 certificate issued for the domain of the contributor. 1. If the contributor cannot afford the few dollars a year for a domain, they are extremely vulnerable to the supply chain attack anyway (by selling the maintenance of the package to a bad actor), and you shouldn't trust them anyway. 2. If the contributor's domain gets compromised you only have to revoke that specific certificate, and all packages signed with that certificate, in the past or in the future, would not be installable. As I have repeatedly said in the past, NPM (and the JS tools development community in general) had no adults in the room during the design phase. Everything about JS stacks feels like it was designed by children who had never programmed in anything else before. It's a total clown show.