6 ms·

There were many positive changes, but what the fuck happens with all the breakages? Reserving usernames and such. Also https://github.com/go-gitea/gitea/pull/1

There were many positive changes, but what the fuck happens with all the breakages? Reserving usernames and such. Also https://github.com/go-gitea/gitea/pull/17688 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* Meanwhile https://github.com/go-gitea/gitea/issues/19852 https://github.com/go-gitea/gitea/issues/19852 is still open

foepys 4y ago
I witnessed the split of gogs and gitea and while the maintainer of gogs was indeed rarely active and merged PRs very slowly, they at least examined the code and made a proper review with suggestions. 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.
- BlackLotus89 4y ago
  I used gogs before gitea and when it split I watched for a few months and then switched. 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.
- mvelbaum 4y ago
  This, and the many trivial CVEs that were discovered in Gitea made me look for alternatives. I think that right now the best free and OSS solution is https://github.com/theonedev/onedev https://github.com/theonedev/onedev. It even has CI/CD built-in which is cool!
  - maxloh 4y ago
    Why not Gitlab?
    - mvelbaum 4y ago
      I'm using this for personal projects, so I'd prefer a free solution. GitLab has a self-hosted version but it's not clear what's available and what requires a license. 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 https://docs.gitlab.com/ee/install/requirements.html [1] https://code.onedev.io/projects/162/files/main/pages/run-as-docker-container.md https://code.onedev.io/projects/162/files/main/pages/run-as-...
      - minimaul 4y ago
        FWIW, GitLab has an entirely OSS community edition, and you can run the enterprise edition just without licenses - I do this personally. 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).
        BlackLotus89 4y ago
        An open core model is just bad. Gitlab shows advertisements for features it does not offer and if you want to integrate an already existing feature you won't be able to mainline it. 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.
        4y ago
- rambojazz 4y ago
  I agree with this too. I witnessed the split too and feel exactly the same. Interestingly, NotABug have not switched to Gitea and is still running Gogs.
KronisLV 4y ago
Seems like someone wanted to use the standards compliant functionality for validating e-mails: 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 But it was closed, because Gitea does not want to support with certain Unicode characters: Closed as it allows utf-8 Isn't the proper solution there to just add an additional validation afterwards, AFTER using the standard functionality, something like: if _, err := otherUtil.DisallowUnicode(fmt.Sprintf("%v", fieldValue)); err != nil { ... } Why close the pull request outright instead of just requesting that an additional validation against a set of disallowed characters be implemented? 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.
- jeltz 4y ago
  Agreed, I really do not get why this PR was merged. It seems pretty obvious to me that the proper solution is to add a check for disallowed Unicode characters.
minimaul 4y ago
I read those links and it just makes me sad. 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 :(
- OtomotO 4y ago
  The same is true for passwords. 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"
  - stavros 4y ago
    > Instead we get "passwordless" Which is a much better solution.
    - OtomotO 4y ago
      For the dystopian cyberpunk future where a few companies rule the world, yup. 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.
deleted 4y ago
[deleted]
rambojazz 4y ago
locked and limited conversation

foepys 4y ago

I witnessed the split of gogs and gitea and while the maintainer of gogs was indeed rarely active and merged PRs very slowly, they at least examined the code and made a proper review with suggestions. 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.

BlackLotus89 4y ago
I used gogs before gitea and when it split I watched for a few months and then switched. 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.
mvelbaum 4y ago
This, and the many trivial CVEs that were discovered in Gitea made me look for alternatives. I think that right now the best free and OSS solution is https://github.com/theonedev/onedev https://github.com/theonedev/onedev. It even has CI/CD built-in which is cool!
- maxloh 4y ago
  Why not Gitlab?
  - mvelbaum 4y ago
    I'm using this for personal projects, so I'd prefer a free solution. GitLab has a self-hosted version but it's not clear what's available and what requires a license. 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 https://docs.gitlab.com/ee/install/requirements.html [1] https://code.onedev.io/projects/162/files/main/pages/run-as-docker-container.md https://code.onedev.io/projects/162/files/main/pages/run-as-...
    - minimaul 4y ago
      FWIW, GitLab has an entirely OSS community edition, and you can run the enterprise edition just without licenses - I do this personally. 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).
      - BlackLotus89 4y ago
        An open core model is just bad. Gitlab shows advertisements for features it does not offer and if you want to integrate an already existing feature you won't be able to mainline it. 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.
        4y ago
rambojazz 4y ago
I agree with this too. I witnessed the split too and feel exactly the same. Interestingly, NotABug have not switched to Gitea and is still running Gogs.

KronisLV 4y ago

Seems like someone wanted to use the standards compliant functionality for validating e-mails: 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 But it was closed, because Gitea does not want to support with certain Unicode characters: Closed as it allows utf-8 Isn't the proper solution there to just add an additional validation afterwards, AFTER using the standard functionality, something like: if _, err := otherUtil.DisallowUnicode(fmt.Sprintf("%v", fieldValue)); err != nil { ... } Why close the pull request outright instead of just requesting that an additional validation against a set of disallowed characters be implemented? 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.

jeltz 4y ago
Agreed, I really do not get why this PR was merged. It seems pretty obvious to me that the proper solution is to add a check for disallowed Unicode characters.

minimaul 4y ago

I read those links and it just makes me sad. 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 :(

OtomotO 4y ago
The same is true for passwords. 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"
- stavros 4y ago
  > Instead we get "passwordless" Which is a much better solution.
  - OtomotO 4y ago
    For the dystopian cyberpunk future where a few companies rule the world, yup. 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.

deleted 4y ago

[deleted]

rambojazz 4y ago

locked and limited conversation