OK, stupid question, what is the thing this utility does that can't be achieved with scanning a physical pass with barcode or entering the details manually into a Google Wallet?
Because I don't see the.... utility if it?
Unless this achieves something specific I don't know.
I don’t know about Google Wallet, but for iOS Wallet, it is not possible to create a new entry there yourself as a normal user.
It has to be signed with a $99/yr certificate, so this thing does the signing for you. The utility is that whatever you created now lives with the rest of the passes in one place.
So yeah, in Google Wallet you can just add the loyalty card like that (scan the qr/bat ode or type the number), and then have it synchronised to your account (to have it available on your other phone for example).
Sure, not every kind of the pass can be added like this (not movie tickets or boarding passes), but all that matters.
The app looks very nice. Small suggestions: Show the price of the premium plan when not logged in. Many users may not entertain an app depending on the price, and logging in shouldn't be needed to see it.
Also the ability to halve recipes would be great, sometimes you just want to make less.
Generally, that's pretty much it. More advanced tools like Claude Code will also have context compaction (which sometimes isn't very good), or possibly RAG on code (unsure about this, I haven't used any tools that did this). Context compaction, to my understanding, is just passing all the previous context into a call which summarizes it, then that becomes to new context starting point.
This sounds nice in theory, but does it really solve the issue? I think that if no one's installing that package then no one is noticing the malware and no one is reporting that package either. It merely slightly improves the chances that author would notice a version they didn't release, but this doesn't work if author is not particularly actively working the compromised project.
These days compromised packages are often detected automatically by software that scans all packages uploaded to npm like https://socket.dev or https://snyk.io. So I imagine it's still useful to have those services scan these packages first, before they go out to the masses.
Measures like this also aren't meant to be "final solutions" either, but stop-gaps. Slowing the spread can still be helpful when a large scale attack like this does occur. But I'm also not entirely sure how much that weighs against potentially slowing the discovery as well.
Ultimately this is still a repository problem and not a package manager one. These are merely band-aids. The responsibility lies with npm (the repository) to implement proper solutions here.
No, it doesn't solve the issue, but it probably helps.
And I agree that if everyone did this, it would slow down finding issues in new releases. Not really sure what to say to that... aside from the selfish idea that if I do it, but most other people don't, it won't affect me.
a long enough delay would solve the issue for account takeovers, and bold attacks like this.
It would not solve for a bad actor gaining trust over years, then contributing seemingly innocent code that contains an exploitable bug with enough plausible deniability to remain on the team after it is patched.
Same for myself. Sinooé devices are extremely solid (at least the Zigbee ones I've used) and work perfectly with Home Assistant. Would highly recommend.
At a previous company, our intrasite was a bare custom domain, and the most reliable way to get there was to add a / at the end. This is likely browser dependent though
With jj, I often do this and use jj split -i, which opens an interactive editor (similar to git's interactive add/rebase) which I can select parts of the change to be split into a separate change/commit. This enables me to take a large piece of work, split it into individual chunks, and open PRs for each change.
reply