4 ms·

The headline doesn't really fit the issue. content: The names of private packages were accidentally exposed for a little over a week. The flaw has been found a

The headline doesn't really fit the issue. content: The names of private packages were accidentally exposed for a little over a week. The flaw has been found and fixed.

xPaw 5y ago
There's more: > vulnerability that would allow an attacker to publish new versions of any npm package using an account without proper authorization. > We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. However, the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package file.
- brazzledazzle 5y ago
  This seems like a much bigger deal. Disclosing private names is not ideal but I think you have to assume your namespace and package names will leak at some point. In my opinion you should prepare for this well ahead of time by ensuring your organization uses a unique namespace/org that matches your internal/private namespace/org and squat on it. This will prevent a supply chain attack where they take a leaked namespace/package, register it and publish packages with higher versions.
dang 5y ago
Ok, we've replaced the title with the relevant subheading from the article. Thanks! The main article title is such corpspeak that it would go against the site guidelines to use it—that sort of corporate press release title is typically misleading, linkbait, or both. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=corporate%20press%20release%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor... https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- ManuelKiessling 5y ago
  Call me old-fashioned, but I don’t like the subheading. This is not “security issues”. It was possible, for years, for anyone to upload anything for any package. For a package manager, this is THE security issue, all caps.
  - dang 5y ago
    Ok, I've dropped the plural. There is now only one.
the8472 5y ago
> The headline doesn't really fit the issue. Commitment to security = security was broken. It's similar to "we value your privacy" and or "announcements about the future of the project". Finest newspeak.

The headline doesn't really fit the issue. content: The names of private packages were accidentally exposed for a little over a week. The flaw has been found and fixed.

xPaw 5y ago

There's more: > vulnerability that would allow an attacker to publish new versions of any npm package using an account without proper authorization. > We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. However, the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package file.

brazzledazzle 5y ago
This seems like a much bigger deal. Disclosing private names is not ideal but I think you have to assume your namespace and package names will leak at some point. In my opinion you should prepare for this well ahead of time by ensuring your organization uses a unique namespace/org that matches your internal/private namespace/org and squat on it. This will prevent a supply chain attack where they take a leaked namespace/package, register it and publish packages with higher versions.

dang 5y ago

Ok, we've replaced the title with the relevant subheading from the article. Thanks! The main article title is such corpspeak that it would go against the site guidelines to use it—that sort of corporate press release title is typically misleading, linkbait, or both. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=corporate%20press%20release%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor... https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

ManuelKiessling 5y ago
Call me old-fashioned, but I don’t like the subheading. This is not “security issues”. It was possible, for years, for anyone to upload anything for any package. For a package manager, this is THE security issue, all caps.
- dang 5y ago
  Ok, I've dropped the plural. There is now only one.

the8472 5y ago

> The headline doesn't really fit the issue. Commitment to security = security was broken. It's similar to "we value your privacy" and or "announcements about the future of the project". Finest newspeak.