If you wanna get an abuse address, resolve to the IP and query RIPE for the abuse mail. Every RIPE member needs to specify an abuse address and what they specify is the source of truth for their AS. No need to query a crowdsourced hearsay service.
I did not know of this service until now, so any correct result it has for any of my domains is a matter of coincidence.
I've used it for decades and don't recall a time whereby a hit has not been accurate, whereas abuse contacts listed on RIPE and all of the other registries are hit and miss, if they exist.
In addition anyone who has listed their domains there probably knows what they're doing, and won't demand a CAPTCHA, an essay or an account to report abuse.
I may have missed the part where the author reported these to github but they're not going to be removed it nobody actually reports them. What a lot of effort put in to seemingly give up at a crucial final step.
apt "pinning" is the process you're looking for. This allows you to prevent reinstallation of snapd and prefer other sources for packages, e.g. Firefox from Mozilla's PPA.
So Ubuntu doesn't provide apt packages so if I want to use apt I have to muck around with PPAs? I don't want to have to add a PPA for every software I install. This is why Debian is better for my use case -- all I have to do is apt install and boom I have the Debian package installed. All this works out of the box on a Debian installation.
Sorry, but this is not true. It's claimed you can use pinning, but at least on my installation, it didn't work no matter what documentation I followed. There was literally no way to stop it from silently switching to the Firefox snap. Well, installing Linux Mint fixed it, but that's not really the same thing.
Before paying up, keep in mind the bait-and-switch played on people with version one. Anyone without a Steam account is stuck with an old version when it required a Steam account after launch.
Unfortunate but not exactly deceptive, because the developer did provide a free Steam key for whoever bought the game in other platforms. I for example got one from my initial itch.io purchase. I did have been told that such requests were rare enough due to the low sales on other platforms IIRC, which is probably why it's no longer available elsewhere.
I wasn't made aware that I'd eventually be required to use a third-party store to use what I paid for. Since I don't use steam I no longer have what I paid for.
I think the exact version of shapez.io you and I bought elsewhere never went away, only the future versions would be available in Steam, so while you may feel like it you should be able to play the game itself.
>Before paying up, keep in mind the bait-and-switch played on people with version one. Anyone without a Steam account is stuck with an old version when it required a Steam account after launch.
I'm not sure what the problem is that you're describing.
I'm glad they are sticking to the core, because the complexity, fragility and corner cases all make that 1% a worse experience for people who trust it to work reliably. In addition, of the out-of-scope suggestions I've seen, most are actually miles away from being available are completely inappropiate, or are so full of corner cases that they're right to be refused.
On the plus side, the source is all there and it's easy to compile, so that 1% shouldn't be difficult to fill by someone with a little knowledge.
Background: Syncthing is an open source automatic file synchronisation project. As such it needs permissions for full access to a device's filesystem. Since Feb 2024 Google Play has been rejecting updates to the app because it requests this permission, but without any sensical reason. The maintainer who handles this has repeatedly re-submitted with clear reasoning, but has no option but to cease requesting reviews as a result of repeated insubstantial rejections.
Sync in background can be achieved using Storage Access Framework APIs, where Syncthing can get access to directory trees without requesting any special extra permissions - that's right, no need for READ_EXTERNAL_STORAGE or the one I'm guessing the OP uses, MANAGE_EXTERNAL_STORAGE.
The API is available since Android 4.4. The requirement to use it instead of asking for access to all documents, private photos, personal data and other data on the phone is there from Android 10 (that's 4 years now).
It's telling that the author isn't actually saying why they're rejecting him - I bet they're telling him the app doesn't need access all private photos just to sync a directory and that the app should use the API that's been mandated 4 years ago. There's even a fork that does exactly that and is published just fine.
> It's telling that the author isn't actually saying why they're rejecting him
Have you ever tried to publish apps on the play store? They often don't give you a reason that it fails, you're just left to keep trying different things randomly until it works, and then later fails again when you changed nothing... there is a documented history of this happening to many projects.
I know several FOSS projects that do not have the knowledge/time/desire to implement SAF support, and for some projects it doesn't make much sense or might be invasive to the user experience, and their play store versions have since been stuck at old versions and they just moved on to F-Droid and other appstores.
Yes, I've been doing this for a long time now and I've also helped convert several apps to the new SAF framework when the restrictions came out. I've also helped many companies and people with these kind of issues and in most cases it's been self-inflicted.
The policy there was always very clear - you need to use SAF unless you're building something that absolutely function with it (these are pretty much exclusively file explorers).
Syncthing can use SAF, the author just refuses to according to their bugs. This counts as "self-inflicted" and I'm not sure why they think they can complain their way out of it.
The author of Syncthing-fork has actually said they've had similar problems with Google and believe it's only a matter of time before their app is locked in a similar way - so much so that they are planning to surrender their Play developer account:
In other GitHub Issues (I don't have the tab open, they might have closed it) the author discusses using that permission but says they are not able to because the Storage Access Framework is only available for Java/Kotlin apps, where syncthing is written in go.
When I use Syncthing-Fork, it uses the Android storage system to request access to the specific folders it syncs too. Does the OG SyncThing not have this? Is that somehow still not sufficient?
I've been using OG Syncthing from the Play Store for a long time but was just looking through F-Droid and noticed this Syncthing-Fork and then I see this comment about it. Looks interesting. You recommend it?
FWIW, I just checked and the only permission I have granted to SyncThingFork is "notifications".
I think it optimistically requests all, but I can testify that it works fine without granting it all storage access. I just had to create/select a subdir in my SyncThingFork directory.
I don't really know how the restricted storage access works. Maybe it's that if /another/ app has already claimed a directory, that SyncThing needs more permissions to be able to sync it? But that seems unlikely, just speculating.
From someone who I think works for GitHub: "We think that GHSA-78xj-cgh5-2h22 still has potential, albeit low, security impact. We believe it makes sense to keep the advisory but to lower the severity to low."
~ $ whois -h whois.abuse.net ftp.bit.nl
[email protected] (for bit.nl)
reply