This is already a crazy take on its own, why would a fork have to describe their relation to the parent project front and center? Both the Readme and the comparison page link to the origin blog post [1] that describes the lineage clearly.
But even if there were some "ethical reason" to do this, I don't think Gitea is the right project to play up as a victim. Their homepage [2] doesn't mention that Gitea itself is a fork either. Their Readme does, but is this so much better?
You "need a plugin" in the sense that every component of maven is a "plugin". The core plugins give you everything you need to build a self-contained jar - if you wanted to, you don't even have to configure the plugins, if you want to write a long cli command instead.
You can create a native executable with GraalVM. Alternatively, if you want to keep the JVM: With the ongoing project Leyden, you can already "pre-train" some parts of the JVM warm-up, with full AoT code compilation coming some time in the future.
And going the other direction, if you want your C++ binaries to benefit from statistics about how to optimize the steady-state behavior of a long-running process, the analogous technique is profile-guided optimization (PGO).
GraalVM is terrible. Eats gigabytes of memory to compile super simple application. Spends minutes doing that. If you need compiled native app, just use Golang.
I used to be really excited about GraalVM but this, together with limitations in what Java code can run (reflection must be whitelisted - i.e. pain) made me run away from it. I do use Go, but my favourite substitute for Java is actually Dart. It can run as a script, compile to a binary or to a multiplatform "fast" format (a bit like a jar), and performance wise it's par on par with Java! It's faster on some things, a bit slower on other... but in general, compiling to exe makes it extremely fast to start, like Go. I think it even shares some Go binary creation tooling since both are made by Google and I remember when they were implementing the native compiler, they mentioned something about that.
I can use Wero just fine in my banking app. Can't try the app that's called Wero in the Play store because it just directs me to my banking app. But I can open it at least ...
Hack-backs are a topic that comes up every few months from government representatives here. There are two big problems I have with this:
- you don't know "who" you hit. The case in TFA is still rather simple (just send the "hack" as the response), but you will still most likely hit some residential proxy and nuke some random person instead of the responsible actor
- (this is not too related to TFA but a point in discussions about hack-backs on a state-actor level) unless you're doing a very simple "attack", you need to have some sort of vuln ready to perform any kind of hack-back. Which leaves the ethical dilemma that actors are now motivated to keep vulnerabilities available, thus making the world more unsafe. And once you have used your vulnerability, your "enemy" probably knows it as well.
> Legitimate use cases, including security research, web archiving, and search engine crawling, can be distinguished from credential scanning by scope and target: no valid automated process needs to probe arbitrary third-party servers for .env or .git files.
What about security researchers scanning for their research? What about scanners that notify you?
Hi, if you are still interested - I updated the post/paragraph and included:
Another approach would be not to make the files 1 TB in size, but only about 50 MB, while distributing them collectively. This would spread responsibility across many participants and reduce the individual burden of liability. If many users offered such files, automated scanners or bots would effectively end up cluttering themselves with useless data, without any single participant impacting the system to a degree that could be framed as deliberate destruction.
[...]
A possible safeguard for legitimate scanners would be to operate only within defined time limits or request quotas. In contrast, uncontrolled or unrestricted scanners would gradually overwhelm themselves with this distributed noise.
You are right. I am not satisfied with this sentence myself and will revise it. In its current form it sounds contradictory and nonsensical. However, I have not yet been able to identify a reliable demarcation criterion...
Insofar as the thing we're talking about here isn't exactly "hack-back" per se, but more like "booby trapping your honeypot", I think you might be able to make an argument analogous to the one that would apply as a booby-trap defense:
Namely, that if "common sense" is enough to prevent someone from suffering any injury from a booby trap even when they do trigger it, then it's not really a "booby trap" in the classical definition. It's just an object with dangerous edge-cases.
In the literal booby-trap case, you might picture, say... a garden hose.
It would be hard to imagine someone being harmed by "normal" use of a garden hose. Most ways to engage with it wouldn't result in any harm. You could turn it on, maybe get a bit wet or lashed if the hose whips around as it stiffens. Point it at yourself and use it to wash yourself clean. Maybe point it in your mouth and choke.
The only clear way to harm yourself with a garden hose, would be to put the hose in your mouth and then turn it on. And then to not remove the hose when you begin to feel very, very uncomfortable.
And that's very silly! Why would you do that? You could have stopped drinking from the hose at any time!
A garden hose has a dangerous edge-case: the water stream is infinite, and the hose fits in your mouth, and the internal stomach capacity of a human is finite. But it's an absurd dangerous edge-case. Nobody with common sense would encounter this edge-case. So a garden hose is not a booby trap. And an abandoned house with a garden house connected to a water supply, is not a booby-trapped house.
See what I'm getting at here?
You can give up and stop streaming (/ parsing / building-up-your-in-memory-ADT-from) an HTTP response that "just keeps going and going" at any time. And any vuln-scanning client programmed by someone with some common sense (e.g. a professional security researcher) would have that common sense built into it. So a 1TB .env-file HTTP response is not a booby trap.
And yet, of course, it will catch (and break) those "special" clients, built by people with no software-engineering common sense, i.e. script kiddies. But it's not your fault that some people have built deranged software that goes around wrapping its mouth around strangers' garden hoses!
Besides the fact that 99% of the general population won't be able to understand this, a $5€ wrench says that you show me proof of the correct private key (either by you showing me the letter you received, me being present when you set it up, or however it is set up)
Don't worry, our minister for economic affairs and energy will make sure that we will stop this solar madness and return to good old clean and green gas /s
(she worked and lobbied for the gas sector before joining the current government)
I only add the ones where its proved its AI, fe. if it has SynthID or some users found obvious AI mistakes. I have adding proof on the roadmap, but it's a bit tidious and there's no point in making it without a traffic.
But even if there were some "ethical reason" to do this, I don't think Gitea is the right project to play up as a victim. Their homepage [2] doesn't mention that Gitea itself is a fork either. Their Readme does, but is this so much better?
[1]: https://forgejo.org/2022-12-15-hello-forgejo/ [2]: https://about.gitea.com/
reply