Why not instead remove 'panya' as a maintainer from legitimate packages that were unaffected? No recent or malicious versions of Stylus have been published (which generally is the case during a hijack) and no evidence that any were altered. Stylus is relied upon by several popular frameworks including Angular 12. Admins should have at least checked this before pressing the kill switch.
> Why not instead remove 'panya' as a maintainer from legitimate packages that were unaffected? No recent or malicious versions of Stylus have been published (which generally is the case during a hijack) and no evidence that any were altered.
Verifying that a package is unaffected can take some time. NPM may not know specifically when that package owner was compromised, or even if they've been a malicious actor the whole time, so the fact that there was no recent version isn't a guarantee of safety. Putting a security hold on the package in the meantime seems a reasonable approach.
> Stylus is relied upon by several popular frameworks including Angular 12. Admins should have at least checked this before pressing the kill switch.
That it's frequently downloaded also makes it more pressing to block if there's a reasonable chance that it contains malware.
> "even if they've been a malicious actor the whole time"
That is a sound argument, even if integrity of the package was to check out (if npm tracks this internally at all).
Better to adopt a PyPI-style approach of temporarily "quarantining" packages while investigating allegations of malware for big-scale projects. Instead npm pulled the plug outright stating: "This package contained malicious code and was removed from the registry..." (generic placeholder page), which is inaccurate and likely to cause panic.
https://www.npmjs.com/package/stylus
Is it true that if you install a Cyrillic keyboard in Windows it stops some of those malware from installing?
The theory is that they don't want to hack a site in their own country and end up getting a visit from Spetsnaz or get suicided.
I wouldn't call it a "not valid form of ID," when you can use them to board domestic flights, prove your age at establishments, and practically use it as an ID where they'd otherwise accept a driving license for ID.
If you look at Lloyd’s under the actual documents accepted they don’t list it there.
They even state that: “The Biometric Residence Permit card may not be accepted in all our online journeys. You may need to provide additional documentation.”
Both HSBC and Barclays don’t accept them, not even to pick up a card from a branch.
Good point, rather interesting they state "in all our online journeys," rather than in-person.
Anytime I've had to verify identity online for bank account opening, it entailed taking a photo of my ID which then goes through automated ID checks via Jumio or similar APIs.
"The biometric residence permit is proof of the holder’s right to stay, work or study in the UK. It can also be used as a form of identification (for example, if they wish to open a bank account in the UK).
https://assets.publishing.service.gov.uk/government/uploads/...
While there is minimal or no passport control within the CTA, for example when travelling between UK and Ireland, the expectation is that the passenger is a citizen of a country whose nationals would not normally require a visa to enter either.
This alone may not be sufficiently proven by an ID document like driving license, and some airlines will only accept passport for travel.
Having a long term residency visa in the UK, but an Indian passport for example, would not automatically qualify you for travel to Ireland without a separate visa, although lax checks within the CTA may, in theory, let you travel if no one looks hard enough and should an airline be satisfied with your UK driving licence alone (and assume you're either an Irish or British citizen).
The requirment is further complicated by the fact that some third country nationals holding either a used and valid UK or Irish short term (tourist) visa can travel to either countries without issues due to the British-Irish Visa Scheme/treaty, but the same courtesy wouldn't apply to a third country national with a (long term) UK BRP - they'd need a separate visa for Ireland.
Border checks or lack thereof in the CTA are a rather interesting subject matter.
The author here. The name eFile(.)com is bound to confuse some readers who may mistake it for IRS' e-file system/API. Probably why the company chose that brand name (SEO or whatever). IRS-authorised software providers (who need to apply and get certified https://www.irs.gov/e-file-providers/become-an-authorized-e-... ) include those who can have taxpayers use their software to e-file returns to the IRS. These also include Intuit's TurboTax.
Anyway, there's that and confusing domain names likes like e-file(.com) that have got nothing to do with the concerned efile(.com) or the IRS, hence that note.
Probable explanation for the mysterious hacks on Xfinity accounts despite having 2FA enabled:
2FA bypass allegedly circulating privately
"A researcher has told BleepingComputer that the attacks are being conducted through credential stuffing attacks to determine the login credentials for Xfinity attacks.
Once they gain access to the account and are prompted to enter their 2FA code, the attackers allegedly use a privately circulated OTP bypass for the Xfinity site that allows them to forge successful 2FA verification requests."
A good reason to give engineers PGP keys and turn on the "required code signing" feature on your org. Alas, security and productivity are perpetual odds.
Just a friendly reminder that both GH and GL now support using SSH keys for signing commits, and 1Password (and KeePassXC, FWIW) will safely store those SSH creds off-disk:
Note that your GPG key is discarded, and GitHub signs your commit itself with GitHub.com's own GPG key when anyone uses the GitHub UI to merge your PR.
All those "verified" buttons you see on a typical repo history tend to actually be for the GitHub.com signing key, which is shared by everyone. Your GPG signature is only used to convince GitHub to sign the final commit with its key.
It is possible to put your GPG signature on the merged commits, so that people can trust the commits came from you. That may be especially appropriate for security software. But you have to do the merges (or rebases as you prefer) outside GitHub for that, and push those merges directly to the main branch. That's what I do when I can, but it's not common practice. Many orgs require all merges to be done via GitHub, so end up with GitHub.com's shared signature on everything instead of their own.
Just wondering - would this meaningfully impact productivity beyond causing engineers to have to learn how to sign a commit (which would presumable take less than an hour, once)?
Actually generating a key and signing commits is pretty easy. I think the harder part would be ensuring all devs safely store the keys, rotate them regularly, etc.
Same thought here. The domain appears to be associated with Ningbo Sunning Software, a Chinese vendor and likely a Mediatek partner than anything Android.
Spotify is actually fine with librespot existing (funnily enough, one of the main reasons the old API is still around is that librespot uses it, lol). So, I doubt it will ever get DMCA'd.
Fwiw, npm appears to be restoring access to the project https://github.com/stylus/stylus/issues/2938#issue-325479314...