It’s likely illegal. The administration would call it theft of service because it’s not authorized and they wouldn’t be wrong. I also don’t see why you would want to do it. You’re giving the IT department at your school complete access to your web history.
Binary supply-chain attacks are not “minor security issues”.
Yes they are. The binaries for Ventoy aren’t even updated from release to release. It’s not even evident how old they are. So crying about an attack that only matters if these binaries are bleeding edge is absolutely a minor issue. I don’t even understand how someone of sound mind and body could possibly believe otherwise.
Not having a security first posture on these kinds of attacks is how the xz event happened
No one is making the argument that security doesn’t matter. No one is pushing the idea that Ventoy is secure. I’m saying singularly and only that a supply chain attack is just about the dumbest goddamn angle possible to bitch about Ventoy because I could argue that Ventoy would be more vulnerable than it is now to a supply chain attack if the binary blobs are built and updated every time you build a bootable drive. It’s just a truly fucking insane argument that shows a lack of understanding of what a supply chain attack is. The built binaries may be vulnerable and it’s difficult to prove if they are or not, but if you update the binaries all the time they’re more (attack surface is larger) than if they’re only updated when absolutely necessary…
It’s just plain a poor argument and I’m tired of every armchair expert pretending that its not. People in high security environments aren’t using Ventoy. It’s just such a ridiculous argument.
The advantage of Ventoy is its ability to work in any environment and handle 99% of ISOs. Compiling the binaries at build time requires a mature development environment to be able to build these utilities… Your exponentially increasing the size and complexity of the project to solve a relatively minor security issue.
Ventoy is not the only way to create a bootable drive… If you don’t trust the blobs then don’t run the software.
Forking ventoy to add the complexity of building these utilities is only going to be available for *nix base environments so Windows users are pretty much shit out of luck. Your exponentially increasing the size of the project, it’s complexity, and simultaneously significantly narrowing its usability…
I said it before and I’ll say it again it’s such a bad fucking argument. It’s not mature software. It’s a literal confluence of hacks… And if you’re not comfortable with using it then don’t use it. It really is a huge security risk. But advocating that nobody use it is such stupid fucking thing.
Advocate that people understand the risks of using it but to just run around and scream about how nobody should be using it for any reason whatsoever until the maintainer closes the security hole that makes it run is pretty stupid.
There’s no way to emote it, but you know when those old Italian ladies spit at people to keep the evil away from themselves? I just did that in your general direction…
No. But the argument itself is so stupid to me.
Ventoy has never been a secure tool. People are making the argument that it should be, which is just nutty.
If you’re one of those people that grab random fuckin’ ISO’s from all over the internet to test em out, then no. You really shouldn’t use Ventoy. If you run official ISO from recognized sources, then realistically the risk is ever present, but minimal.
Like getting in a wreck on the way to the store to pick up milk. It’s always a possibility, but not many people would stand around and make the argument that you should stay home forever because you might get into an accident, which is basically the argument against Ventoy. It’s “we’ll, it’s a crazy useful tool, but you shouldn’t use it because something might happen.”
It’s just such a bad argument. Fact of the matter is, is that if there were a non-hacky as shit way to do what Ventoy does, it would be available right now. But it’s not… Because it’s really not.
The only way to avoid the issues that Ventoy employs is to not use ISOs and use something like netboot.xyz, which presents its own set of issues. How do you know you’re not being MITM from the iPXE environment? Like, sure. You can technically verify it, but how do you know for sure on the fly?
Like, if you sit down you can pick apart any software for being an insufferable gaping asshole of security vulnerabilities.
Because it has integrations for The Internet Archive: https://x0.at/Wny_.png
It says “local html” but I have a feeling it simply grabs a copy from the internet archive. I can’t even find where its storing these copies with it enabled.
There is. wget doesn’t follow recursive links by default. If it is, you’re using an option which is telling it to…
It does neither. It doesn’t create snapshots of pages at all… It’s a bookmark manager.
https://linkding.link/ is what you’re looking for.
Use the bookmarklet or FF/Chrome extension on a page and it saves it to your server to look at later. Add tags, folders, whatever. You can setup newly added links to be un-archived, and old links to be archived, or basically however you want.
That’s not a bug. You literally told wget to follow links, so it did.
restic restore --dry-run
Great work man. That’s really the only thing that I’ve found to gripe about. Other than that it was a simple setup and configuration. I particularly like that you hold my hand when changing things like the font. Such a subtle but cool change to add some individuality to it.
Great tool. I just pushed it to production for all my projects.
Doesn’t support docker host names, which is a bummer. You have to use IPv4/6 and the docker IP for services to work correctly. The service setup is also a bit weird. You can’t seem to delete a service once it’s been made. You can only “hide” it. So I just set this up, and mistyped an IP, and now I have a service with only 70% uptime because the first few pings failed due to the mistyped IP. (https://x0.at/ZvM1.png) There doesn’t seem to be a way to reset the uptime, or delete the monitor. You actually have to rename the service monitor to something random, and “hide” it, then remake your service like new.
Seems weird.
Nice dashboard though.
bookmarks
low on disk space
Goddamn boy, how many links you got? A million? lol
wget is the most comprehensive site cloner there is. What exactly do you mean by complex? Because wget works for anything static and public… If you’re trying to clone compiled source files, like PHP or something, obviously that’s not going to work. If that’s what you mean by “complex” then just give up, because you can’t.
wget.
Everything seems fine with 1.39.1. What’s the docker log say? Also which version?
Sure, you can also do this. But why not make it available to your network in addition to Jellyfin? What if you have a TV that doesn’t have access to the Jellyfin app? If it’s a private ZFS pool not on the network you’re fucked. If you share the media via a network share, you can always do any number of things to stream that media to your TV.
It gives you a ton more options up to and including just watching the media on your PC in your favorite media browser.
The biggest issue I have with Caddy and running ancillary services as some services attempt to utilize port 80 and/or 443 (and may not be configurable), which of course isn’t possible because Caddy monopolizes those ports. The best solution to this I’ve found is to migrate Caddy and my services to docker containers and adding them all to the same “caddy” network.
With your caddy instance still monopolizing port 80 and 443, you can use the Docker
exposeorportparameters to allow your containers to utilize port 80 and/or 443 from within the container, but proxify it on the host network. This is what my caddy config looks like;It works very well.