291–300 of 460 posts
Are there any package managers that have something like a min-age setting. To ignore all packages that were published less than 24 or 36 hours ago? I’ve run into similar issues before, some package update that broke everything, only to get pulled/patched a few hours later.
Earlier quoted context omitted.
It's not reasonable to expect every software in existence to work with a compatible set of dependencies. So no, the distro can't supply all the libraries. What happens is that distro developers spend their time patching the upstream so it works with the set included on the distro. This has some arguable benefits to any user that wants to rebuild their software, at the cost of random problems added by that patching th…
> It's not reasonable to expect every software in existence to work with a compatible set of dependencies. So no, the distro can't supply all the libraries. That is not what it's being asked. As a developer, you just need to provide the code and the list of requirements. And maybe some guide about how to build and run tests. You do not want to care about where I find those dependencies (Maybe I'm running you code as…
From whom? You seem to be talking only about upstream developers.
Earlier quoted context omitted.
There's no guarantee that software/library vX.Y.Z packaged by distro A will be identical in behavior to one packaged by distro B. Sure, distro maintainers have all sorts of guidelines, but in reality, mistakes happen, and there can be incompatibilities between the version a developer has been testing against, and one the end user is using. Relying on feature flags is a pie in the sky solution, and realistically devel…
But why do you care that much about how the user is running your code? Maybe my laptop is running Alpine and I patches some libraries to support musl and now some methods are NOP. As the developer, why does it matter to you? You would want me to have some chroot or container installation for me to install a glibc based system so that you can have a consistent behavior on every computer that happens to run your code?…
Again, this matters a lot to smaller projects and teams. Larger projects have the resources to offer extended support for various environments and deployment procedures, but smaller ones don't have this luxury. A flood of support requests can lead to exhaustion, demotivation, and burnout, especially in open source projects and those without a profitable business model. Charging for support wouldn't fix this if the team simply doesn't have the bandwidth to address each request.
Are there any package managers that have something like a min-age setting. To ignore all packages that were published less than 24 or 36 hours ago? I’ve run into similar issues before, some package update that broke everything, only to get pulled/patched a few hours later.
Especially after the fakerjs (and other) things.
Are there any package managers that have something like a min-age setting. To ignore all packages that were published less than 24 or 36 hours ago? I’ve run into similar issues before, some package update that broke everything, only to get pulled/patched a few hours later.
I just use .npmrc with save-exact=true + lockfile + manual updates, you can't be too careful and you don't need to update packages that often tbh. Especially after the fakerjs (and other) things.
Many of those supply chain attacks are detected within the first few hours, I guess nowadays there are even some companies out there, that run automated analysis on every new version of major packages. Also contributors/maintainers might notice something like that quickly, if they didn't plan that release and it suddenly appears.
this is just hilarious. Script kiddies just graduated to prompt kiddies
Earlier quoted context omitted.
I actually loathe those progress trackers. They break emacs shell (looking at you expo and eas). Why not print a simple counter like: ..10%..20%..30% Or just: Uploading… Terminal codes should be for TUI or interactive-only usage.
Carriage returns are good enough for progress bars, and seem to work fine in my emacs shell at least: % echo -n "loading..."; sleep 1; echo -en "\rABORT ABORT"; sleep 1; echo -e "\rTerminated" works fine for me, and that's with TERM set to "dumb". (I'm actually not sure why it cleared the line automatically though. I'm used to doing "\rmessage " to clear out the previous line.) Admittedly, that'll spew a bunch of stu…
They are supposed to do things like ul utility does, but neither BSD more nor less handle when a CR is emitted to overstrike the line from the beginning. They only handle overstriking characters with BS.
most handles overstriking with CR, though. Your output appears as intended when you page it with most.
In theory for each package one could:
* npm install pkg
* npm pack pkg
* npm publish --registry=https://verdaccio.company.com
* set .npmrc to "registry=https://verdaccio.company.com/ when working with the actual app.
...this way, one could vet packages one by one. The main caveat I see is that it’s very inconvenient to have to vet and publish each package manually.
It would be great if Verdaccio had a UI to make this easier, for example, showing packages that were attempted to install but not yet vetted, and then allowing approval with a single click.
Periodic reminder to disable npm install scripts. npm config set ignore-scripts true [--global] It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script. I know this isn't a silver bullet solution to suppl…
Before anyone puts the blame on Nx, or Anthropic, I would like to remind you all what actually caused this exploit. The exploit was caused by an exploit, shipped in a package, that was uploaded using a stolen "token" (a string of characters used as a sort of "usename+password" to access a programming-language package-manager repository). But that's just the delivery mechanism of the attack. What caused the attack to…
One thing that's weirdly precarious is how we still have one big environment for personal computing and how it enables most malware. It's one big macOS/Windows/Linux install where everything from crypto wallets to credential files to gimmick apps are all neighbors. And the tools for partitioning these things are all pretty bad (and mind you I'm about to pitch something probably even worse). When I'm running a few Win…