Corriere.it and greasemonkey

Today I googled for a greasemonkey script to hide ads on the corriere.it home page, just to see if I'm the only one scratching that itch.
It seems that another user has solved it, and his solution is also more complete:

http://userscripts.org/scripts/show/5168

Popular posts

How to automatically import a ZFS pool built on top of iSCSI devices with systemd

When using ZFS on top of iSCSI devices one needs to deal with the fact that iSCSI devices usually appear late in the boot process. ZFS on the other hand is loaded early and the iSCSI devices are not present at the time ZFS scans available devices for pools to import. This means that not all ZFS pools might be imported after the system has completed boot, even if the underlying devices are present and functional. A quick and dirty solution would be to run  zpool import <poolname> after boot, either manually or from cron. A better, more elegant solution is instead to hook into systemd events and trigger zpool import as soon as the devices are created.
Read more

Opengrep quickstart

Since I could not find a quickstart to run opengrep with the full set of rules from their fork I thought I'd document what I found out. Setup Download the opengrep binary from github and make it executable with chmod +x . Clone the rules repo: git clone git@github.com:opengrep/opengrep-rules.git and clean it up to make it usable to opengrep: cd opengrep-rules rm -rf ".git",".github",".pre-commit-config.yaml", "elixir", "apex" find . -type f -not -iname "*.yaml" -delete rm -rf .github rm -rf .pre-commit-config.yaml Ensure opengrep can load the rules with: opengrep_manylinux_x86 validate . The same can be done for custom rules maintained in a separate repository. AFAIU Multiple repositories can be specified by repeating -f option as needed, see below. We are now ready to scan a repo, from the repo root directory run: opengrep_manylinux_x86 scan \   -f <path_to>/opengrep-rules \   --error \   --exclude-rule=VAL some ti...
Read more

On supplychain attacks and dependency cooldowns

After the recent npm attacks  there have been many recommendations to leverage dependency cooldown as an additional mitigating factor. Dependency cooldown works by instructing the package manager to ignore releases that are younger than a certain threshold. The reasoning is that a vulnerable package will eventually be detected (and removed) in less time than the threshold, therefore preventing the attack. This, combined with dependency pinning (including transitive dependencies!), is a very powerful tool, but introduces an issue for anyone using internal dependencies. For those the cooldown will have the undesired side-effect of blocking internal dependency updates which might contain urgent fixes. I haven't checked all package managers, but I did check some of the most popular languages. Also, cooldown is not supported everywhere and sometimes is supported with noteworthy exceptions. Nodejs Use or switch to pnpm and use a combination of minimumR...
Read more