Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NPM won't publish packages containing the word keygen

mamot.fr

Post reply on HN
Print view View original

221–230 of 269 posts

Re: NPM won't publish packages containing the word keygen

#221

Post by duskwuff »

insanitybit wrote: post #60
smashah wrote: post #30

This reminds me of the supply chain attack experts who's only solution seems to be blocking postinstall scripts.

That sounds completely different. Blocking the word 'keygen' accomplishes absolutely nothing and is clearly stupid. Blocking build scripts absolutely stops a major attack vector.

> Blocking the word 'keygen' accomplishes absolutely nothing and is clearly stupid.

The intent is almost certainly to stop a spam campaign which was using NPM package pages to host links to outside sites. Similar pages have been discussed on HN previously [1].

The fact that there was actual installable software involved was irrelevant to the attacker. All they were after was a way to put their content on a high-reputation domain -- and NPM was perfect for that.

[1]: https://news.ycombinator.com/item?id=35370728

Re: NPM won't publish packages containing the word keygen

#222

Post by arthur2e5 »

oefnak wrote: post #192
ezekg wrote: post #181

Earlier quoted context omitted.

I spent weeks on the typography and on choosing a font. Went through so many different styles. I ended up on Owners by MCKL [^0] because I personally like the ultra-wide font trend, and I liked its Text variant as well. Bummed to hear that others aren't a fan of it. Oh well, design is pretty subjective. And it may be over-designed. It was my first foray back into design since switching careers to programming about 10…

That wide font is on purpose?! No offense, but I was sure something went wrong with rendering the page.

It didn't quite register as a "display" font variant usually does for me either -- the only feature is the width (it's a nonfancy sans-serif, what do you expect) so it somehow just feels like it's been squished. Intellectually I know it's definitely not a simple scale-transformation and must have involved some curve work to make it look less off, but I just can't shake the feeling of having seen text getting run over by a truck.

Re: NPM won't publish packages containing the word keygen

#223

Post by _a_a_a_ »

0ct4via wrote: post #218
_a_a_a_ wrote: post #193

Earlier quoted context omitted.

Really isn't, it's about the same as calling a woman a cow.

Wrong. Usage varies, but "bint" more commonly is akin to "b*tch", and is used in a very coarse and derogatory manner. Love how you're trying to justify degrees of acceptable misogynist terms, though /s

Um? Here in the UK it's uncommon to hear it these days but it carries no special weight.

How come you're unwilling to spell the word bitch?

Re: NPM won't publish packages containing the word keygen

#224

Post by sBqQu3U0wH »

xavxav wrote: post #49
ezekg wrote: post #19

I run a business called Keygen [^0], and own the @keygen namespace on npm. We’re working on a Node SDK, so this isn’t good to hear. I’ll open up a discussion with them and see what we can do. [^0]: https://keygen.sh

Unrelated, but your homepage has very bad FPS using firefox on mac due to the animation. Once I manage to scroll it works quite well.

>mac

Sorry, that's what you get for not using a normal computer.

Re: NPM won't publish packages containing the word keygen

#225

Post by zelse »

Dylan16807 wrote: post #215
hinkley wrote: post #141

Earlier quoted context omitted.

At the dawn of the search engine age I was in Japan, and so I spent some time not being able to learn about shitake mushrooms, as was a common western spelling at the time (they are not shi-ta-ke mushrooms, they are in fact shi-i-ta-ke mushrooms, hence the spelling change, even though we still pronounce them wrong). You couldn’t say shit on the internet. I mean what the fuck.

"shi-i-ta-ke" is not very accurate. It's a long vowel, and the word has three syllables. But english mostly ignores long vowels, hence the alternate spelling.

It's funny, because in Old English ('Anglo-Saxon'), vowel and consonant length are both semantically important.

For those of you who want to have a better handle on the distinction, you can think of it as the sound having an extra 'beat', where a beat is the amount of time pronouncing that sound normally occupies.

It's easier if you take advantage of the one place English still distinguishes this: word boundaries.

Listen how you say, for example: Tibetan nitwit (you're holding the 'n' for two beats because your brain treats the distinction as important /when it's at a word boundary). You can do this with vowels too as an exercise, though they're a bit harder because English has a lot of vowels and finding good matches is a bit difficult.

Re: NPM won't publish packages containing the word keygen

#226

Post by true_religion »

0ct4via wrote: post #218
_a_a_a_ wrote: post #193

Earlier quoted context omitted.

Really isn't, it's about the same as calling a woman a cow.

Wrong. Usage varies, but "bint" more commonly is akin to "b*tch", and is used in a very coarse and derogatory manner. Love how you're trying to justify degrees of acceptable misogynist terms, though /s

You yourself imply there are different degrees to how acceptable the two terms are.

Why else do you spell out one word but censor the other?

Re: NPM won't publish packages containing the word keygen

#227

Post by smashah »

dns_snek wrote: post #196
smashah wrote: post #167

Earlier quoted context omitted.

"any chance"??? I can't square this circle of someone being paranoid about postinstall script but at the same time thinks the first chance to review dependency code is after doing a `npm i`. Check the git repo of the library you are installing beforehand if you're so paranoid about postinstall. And above that, never install any library for which the source is not readily available. This is the most basic first line o…

> Check the git repo of the library you are installing beforehand if you're so paranoid about postinstall. > And above that, never install any library for which the source is not readily available. Whether source is available or not is mostly irrelevant when you're potentially dealing with malicious code, you need to review artifacts that are being fetched from NPM since those can differ from source code on Github. A…

> ...NPM since those can differ from source code on Github.

True. How about people act their threat model? Instead of removing a feature for many users, just do whatever you need to do to be sure you're safe yourself?

In what other major situation is the solution to nuke a feature due to security concerns?

Afaik the main conversation about postinstall is around leeches complaining about political messages in their console and one or two other incidents

Re: NPM won't publish packages containing the word keygen

#228

Post by myself248 »

TheFreim wrote: post #209
ezekg wrote: post #61

Earlier quoted context omitted.

Our CLI already uses genkey as a command so unfortunately that's no bueno: keygen genkey Can't do genkey genkey. That's just weird...

I mean, you could just flip it around? genkey keygen

Sounds jankey...

Re: NPM won't publish packages containing the word keygen

#229

Post by DropInIn »

0ct4via wrote: post #218
_a_a_a_ wrote: post #193

Earlier quoted context omitted.

Really isn't, it's about the same as calling a woman a cow.

Wrong. Usage varies, but "bint" more commonly is akin to "b*tch", and is used in a very coarse and derogatory manner. Love how you're trying to justify degrees of acceptable misogynist terms, though /s

[flagged]

Re: NPM won't publish packages containing the word keygen

#230

Post by hunter2_ »

JohnFen wrote: post #185
hunter2_ wrote: post #165

Earlier quoted context omitted.

Ok, I'll bite. There is no way a merchant can learn a new card number other than from the cardholder, or from a thief who got it from the card/cardholder. Not from any upstanding entity. If you merely got a new expiration date, security code, etc. without also changing the card number, they could "follow" that by submitting a transaction without those extra pieces of information, at greater cost and risk to themselve…

Some banks have a service where if you use your card for ongoing regular payments and the card is replaced for any reason, the bank will allow those regular charges to continue on the new card when the service provider uses the old number. It's very convenient if that's what you want -- it means you don't have to go to all of the ongoing services to update your card immediately. But it does mean that you can't count…

Ah. So in that case, NPM is not learning a new card number, and probably isn't even aware of anything at all, given that the card issuer is simply accepting transactions (instead of declining them as this person expected) on the old card number.

NPM was in the wrong for continuing to place unwanted transactions, but they were not actively participating in this "follow" scheme so the blame stops short of that.

Post reply on HN