Gitea 1.17.0 is released – includes package registry support
blog.gitea.io
blog.gitea.io
A typical open-source project is written by its users; if you want a feature, contribute, don't demand. The project can (but not always does!) choose tools that are best in long term and fit the problem domain better, even if they require time to get started / involved, and longer to get an MVP out the door.
Go checks both boxes: it lets move fast, but also is a reasonable long-term choice. I used to shy away from Go-based projects, but after 1.18 I have to admit that Go becomes acceptably pleasant to use!
Quite a bit of work must have gone in, look forward to hearing how support/compatibility varies
Could also be because I used a low powered OrangePi...
Also https://github.com/go-gitea/gitea/pull/17688
"I want to use a regex to filter for valid mail addresses"
"There is a function for that why not use that?"
"Invisible unicode characters!"
"That's not a problem in automatic mail verification"
*ignore everyone*
*push*
*pull*
I don't understand why so many developers do so many stupid things with emails. Sure, there's some trivial validation you can do that makes sense - make sure it matches (.+)@(.+), make sure the domain part exists, etc.
But far too many sites do extra 'validation' using weird restrictive regex, and it prevents you from using valid email addresses - things like restricting chars so I can't use '+', or so I can't use a one char local part, or a one char domain, or a newer TLD that doesn't fit some dodgy regex they copied from a random stack overflow comment...
I really wish that developers would just do really simplistic checks - eg make sure it has an @ in it and something either side, and then just send a validation email as part of their signup flow. If you do it as the first step in the flow, you validate control of the email address and you ensure you don't end up with junk accounts on your system where someone typo'd their email and will never be able to activate it.
edit: the really stupid thing is that it takes considerably more effort to add this restrictive and usually wrong validation than it does to do it right :(
With every restriction, the space of possible passwords becomes smaller.
Just 16 chars, you must use a number, a special character, but not any of these few of course...
Just give it a length of 255 and people can use arbitrary sentences as passwords, which they remember!
Then teach them to add some slight variants to them, like replacing a char by a number, adding commas etc.
Instead we get "passwordless"
Which is a much better solution.
I will stay with passwords that only a quantum computer can break :)
To elaborate a bit more, as we are already off topic:
Biometric traits are a big nono for me.
And another device just shifts the password problem to said device (same for email account instead of device). Once someone has access to the device (secured via one password) they have access to everything.
So a normal trade in convenience for security.
Passwords are solved for me, apart from idiotic rulesets on the other end.
oauth with google isn't the only option. There are oodles of oauth providers out there, and you can even set up your own.
> Biometric traits are a big nono for me.
Nobody is talking about biometrics but you.
> And another device just shifts the password problem to said device
Passwordless doesn't mean 2fa, and even if you _are_ talking about another device, the other device doesn't have to require a password.
> (same for email account instead of device).
They're not the same actually, not at all. Firstly passwordless doesn't imply access to another _device_, (and even in the case of WebAuthn it doesn't even imply access to another service). The most common case of Oauth allows for the service provider to trust any number of providers, who may or may not require a password. It can be a hardware key, it can be a private key in software that a restricted process has access to, or yes it can be a password.
> Once someone has access to the device (secured via one password) they have access to everything.
If someone has access to your device and password, it doesn't matter if you use unique passwords for everything, pretty much every service in existence will happily let you reset your password with access to the original email account.
> So a normal trade in convenience for security.
Hard disagree here. My biggest risk vector is third party websites insecurely handling credentials and leaking them. If they require passwords, my password gets leaked, which means I need unique passwords per site, which in turn means I'm going to rely on software to manage those credentials for me. If I'm relying on software to manage those credentials for me, isn't it _more secure_ to reduce the possibility of human error, clipboard scraping, incorrect file permissions on my local uncencrypted file of passwords (because if it's encrypted I need a password for this too, right?)
If someone has access to my password they either got it by torture, a non or insufficient hashed store on the other end or by breaking encryption.
A simple dongle that may not even need a password, is easier to get.
2FA can make sense, passwordless does not.
The risk of 3rd party screwing up, doesn't go away, it's just shifted to another 3rd party, which again, you have to trust.
I use a different email address with a unique password for anything that's important and where another person having access could harm me. Forums and such are not a part of that.
So let's agree to disagree. I'll stay with passwords for everything that's important and for most things that are really important, apart from banking that is, I don't even have a 3rd party involved.
I get your point, but the above pretty much illustrates why I ditched Yubikey and now go with 2fa-app on my mobile.
No need to store passwords, you can securely have one password for all sites. You lose the ability of rotating it if it gets stolen, but it's unlikely to get stolen if you never enter it anywhere else.
Or keyloggers, shoulder-surfing, phishing, etc etc.
At this point, it just sounds like you don't want to like anything that's not passwords.
Shoulder-surfing isn't a problem for me, phishing worked when I was 12 and the internet was new, keyloggers... Yup, possible, although unlikely given the choice of my OS.
But alas, I digress and indeed it became personal, so let's stop it here, as I am not interested in personal discussions on the internet.
I made a PR here : https://gitea.com/go-chi/binding/pulls/12 which uses the stdlib net/mail (which is rfc5322 compliant) for validation
Closed as it allows utf-8
if _, err := otherUtil.DisallowUnicode(fmt.Sprintf("%v", fieldValue)); err != nil {
...
}
Of course, I get the feeling that the developers just don't want to support "odd" e-mail addresses, because it doesn't affect them personally. They might be using just firstname.lastname@provider.com, or somenickname@provider.com, instead of using tags (+), slashes or other such symbols. Ergo, they might not care, at least when there are other issues that need to be solved and worked on - this gets de-prioritized.
The gitea guys wanted to move a lot faster and in the process neglected quite a bit of code review and product planning. Apparently this continues to this day as evidenced by the PR you linked.
The second reason is that GitLab's minimal resource requirements[0] are just overkill compared to OneDev[1] which can run in a single container with an embedded database.
[0] https://docs.gitlab.com/ee/install/requirements.html [1] https://code.onedev.io/projects/162/files/main/pages/run-as-...
You have to run your own CI runners, but if you can self-host GitLab that ought to be no problem ;)
I agree though, it's very resource heavy - my personal instance has 8G RAM and 4 vCPUs and only two people use it. It has that much RAM because without it, it would randomly fail (usually during/after package upgrades).
Gitlab is a capable software (albeit slow and prone to security issues especially with enterprise features) and it is what most people right now are used to and that's why we offer it, but for personal use gogs, gitea or onedev (or many other solutions I won't even try to list) are way better. I run gitea on my 2G RAM VPS next to a dozen other services. I would need double or triple the resources to run gitlab alone.
onedev I did not know about, and looks exceptionally tempting on that basis.
It also means I can do things like automatically rebuild containers nightly/weekly to get security updates.
You can see a feature comparison for the different GitLab tiers including our free tier here: https://about.gitlab.com/pricing/gitlab-com/feature-comparis...
You will also notice the tiers for which a feature is available are listed on the docs page for that feature.
The gogs maontainer was unreachable for many month multiple times and the gitea fork os very active. It implements features I care about and even though they move fast and break configs the problems are documented and I had only a few minor problems over the years, a few of them werent even their fault.
So I'm a happy gitea user even when there are things I dislike.
Basically... They're working on it
I would avoid using it if at all possible. You do not want your source code on a platform opened by those notorious for stealing intellectual property.
you are mistaking gitea for "gitee."