It should appear as encrypted iroh traffic. Depending on how radicle handles things, this could make it difficult to identify versus other applications using iroh. If needed, they could add noise or dummy traffic in the future for further obfuscation.
They may be overselling, but I’ve had good experiences using apps built on it.
I don't think the consumer ecosystem is mature yet.
Adding a cert to my Android phone was a huge pain in the ass. Most homelab apps like Jellyfin don't support it. The homelab space is so buck broken it assumes i don't have a public IP address to just expose things without going through the convoluted VPN setup.
Not sure what you consider "no good" alternatives. jeanp413.open-remote-ssh[0] has worked flawlessly. It's the first or second search hit in the extension manager for "ssh". It's a fork of Microsoft's previous extension before the proprietarized it.
I very much dislike this extension because it uses a built-in ssh client that is far from feature complete and does a lot of reinventing the wheel. Microsoft's extension uses the system ssh binary, as does https://open-vsx.org/extension/aergic/zygos-vscodium which I much prefer. After discovering the latter, I uninstalled VSCode and have fully moved to VSCodium.
I needed to temporarily move off 20TB from my NAS and bought a Hetzner storage box.
I wanted to encrypt the data before sending it so i went with the borg ssh mount. Long story short, borg failed a couple of times due to https://github.com/borgbackup/borg/issues/7672, i resumed it per documentation and got 2gb of silently corrupted data. There was no way to do data integrity checks due to broken pipes and there was no option to resume the job from the previous point either. I couldn't afford to go with the s3, backblaze wasn't an option due to placing trust into their proprietary client doing the encryption and i got majorly screwed in the end.
That issue happens when the repo is corrupted? That's not the cause of the failure then.
Also you must have been unaware of Backblaze B2? It doesn't have a proprietary client, and it launched 11 years ago only a couple months after attic was forked to create borg.
>Motivated by our success in developing this solution, we try to use it to backup the homelab with its 10 Docker containers. But later we find out from logs on the individual machines that backups are failing. The reason being that many Docker containers like to create root-owned files, and if you’re not careful you can create a cronjob running as the default user.
The ideal setup is rootless Podman and having all your containers not even be able to create root-owned files.
It would also be great if services did their own database dumps. Immich does this and it's such a relief to just be able to copy over its volume for backup purposes.
Unfortunately we don't live in an ideal world and so much of the software both doesn't dump it's own databases, and is incapable of running in a rootless container.
If you weigh the probability of a privesc from your backup with full access to the volumes, against the probability that the software you run has a CVE, which one is worse?
This is one of those things I consciously chose to ignore in my setup. Maybe it will come back to bite me in the future, sure. Or maybe I will learn a better approach that pushes my frontier of convenience-security forward.
Yeah it feels it can be risky to "make the backup also dump the databases, and give it full filesystem permissions on our Docker volumes", depending on what binaries get the root privileges.
What I do is having a minimal systemd timer under root that only calls restic for backing up files (with some additional systemd seucurity restrictions). App-dependent backup logics, like dumping databases, are done by user/container-level cronjobs separately.
Oh, i left the wrong quotation whereas i intended to reply to another message. Throughout the blogpost you're quality matching and comparing encoders based on objective metrics whereas it'd be more telling to get the crowd subjective comparisons. I think it's pretty evident that most codecs benchmaxx to the point of objective metrics being useless.
Ah, no worries! I can't speak for Iris and Aperture, but both "tune IQ" modes in SVT-AV1 and libaom had extensive human evaluations to make sure they weren't accidentally being benchmaxxed at the expense of subjective quality.
>Maybe a lossless re-encoding of my website JPEGs to gain 20% size is not worth the 33%
I was unpleasantly surprised when jxl's reference encoder dropped critical exif tags for no reason whatsoever from my personal archives. Turns out their lossless preset wasn't really lossless.
And then webp to JXL conversion also produced different viewing experience results as ffmpeg's webp decoder wasn't handling ICC correctly.
I'm now very cautious of any "lossless" re-encodes.
>There is no update the GitHub issue for 2 weeks except for deleting a comment by the reporter yesterday.
Yeah, i was very confused by that, especially after they invited them to post publicly/privately. They love controlling the public communications when it comes to researchers. I remember ryrona, a guy who found VPN leaks, being censored for no reason whatsoever in their public GitHub issue tracker.
Original author here. I want to separate the technical work from the communication style. At one point I accidentally wrote Daniel's name as "Danielle." His entire response to one of my technical comments was simply, "That is not my name." I apologized, corrected the comment, and also made a point of acknowledging the quality of his work.
I think it was good that this exchange was later deleted, but it would have been better if the interaction had not gone in that direction in the first place. He appears to do strong technical work, and I do not want to diminish that. At the same time, some of his communication can come across as unnecessarily dismissive, confrontational, or unprofessional. That makes already difficult technical discussions harder than they need to be.
The amount of time I need to spend maintaining my Forgejo instance this year, even after accounting for this RCE, has been less than the amount of time GitHub has been degraded or unavailable this year.
That doesn't match my experience at all. I had a Foregjo instance on a Raspberry Pi, and maybe it's typical SD card issues, but the number of times that Forgejo has crashed because it locked its own database and couldn't continue and the number of times repos I mirror from GitHub just mysteriously stop syncing is quite probably the same number of times GitHub has been down this year.
Bruh sorry, stop running any RW services off an SD card, it has always been terrible and unfortunately it will remain terrible, you can buy a used SFF with >5x the compute and a sata ssd for the same price as a raspberry pi alternatively put an nvme hat on it
This vulnerability, which doesn’t affect my installation, would take approximately 5 minutes to patch if it did. With that exception, my server will have had approximately 99.999% uptime over the last several years.
It would take a boatload of such events to equal the opex of GitHub hosting. That’s not an excuse to run amok, but it’s far from tipping the scales in GitHub’s cost favor.
Wouldn't most users considering or using Forgejo also have considered (or used) self-hosted Gitlab which would have the same opex / security costs (and much higher hardware requirements)?
How? QUIC is easy to fingerprint and flow classificate:
https://datatracker.ietf.org/doc/html/rfc9000#section-12.1
Speaking of bold claims, Iroh, just like Radicle, are overselling themselves:
>iroh's QUIC multipath implementation automatically switches between Wi-Fi, cellular, ethernet, LAN, LoRa, HaLow, Tor, Bluetooth—or bring your own transport.
The thing is, QUIC multipath isn't standardized.
reply