This patch is a week old, so hopefully you have already updated.
GitLab seems to have glaring security holes quite often. Surely this is in part because of the open source codebase and their bug bounty program, which incentivizes researchers to look for these flaws. I’m still baffled sometimes. I’ve read about a lot of > 9.0 CVEs while maintaining our GitLab instance, there was a 10 only three weeks ago. Thankfully our instance isn’t public.
Ehh their engineering simply seems to be subpar. I’ve read some of the CVEs and if they followed best practices the issues should’ve never happened. It doesn’t inspire confidence.
I read some of the discussion over CVE-2023-7028. It sounds like they were reading a list of emails for password reset and if one matched the account they sent the reset email to all of them.
In my mind it is an extremely low bar that programmers not mix unauthorized input with account data. It simply should not have been possible to send an account secret to anything other than emails present in the database, full stop.
IDK, I appreciate the transparency and I would have been safe from that attack because I always use 2FA. But this is not a viable product for hosting code if their coding practices allow something like that through.
Yep, exactly my thoughts. Unfortunately very few developers really think (about related but not completely adjacent code) when they implement stuff (and that’s when they are even “allowed to” by the task requirements) and even fewer have true knowledge of security and common pitfalls and whatnot to avoid such issues.
And even when you have those you still need good practices and code reviews where the rest of the slip ups is caught.
You’re correct. And I don’t think we are armchair coding. We know proper security is so hard that even experienced developers can write code vulnerable to something like a timing attack. But sending secure data to unvalidated input isn’t a minor slip up that could happen to anyone. They are either unaware of or not bothering with good practices.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
This patch is a week old, so hopefully you have already updated.
GitLab seems to have glaring security holes quite often. Surely this is in part because of the open source codebase and their bug bounty program, which incentivizes researchers to look for these flaws. I’m still baffled sometimes. I’ve read about a lot of > 9.0 CVEs while maintaining our GitLab instance, there was a 10 only three weeks ago. Thankfully our instance isn’t public.
Via cron. \yawn
Ehh their engineering simply seems to be subpar. I’ve read some of the CVEs and if they followed best practices the issues should’ve never happened. It doesn’t inspire confidence.
I read some of the discussion over CVE-2023-7028. It sounds like they were reading a list of emails for password reset and if one matched the account they sent the reset email to all of them.
In my mind it is an extremely low bar that programmers not mix unauthorized input with account data. It simply should not have been possible to send an account secret to anything other than emails present in the database, full stop.
IDK, I appreciate the transparency and I would have been safe from that attack because I always use 2FA. But this is not a viable product for hosting code if their coding practices allow something like that through.
Yep, exactly my thoughts. Unfortunately very few developers really think (about related but not completely adjacent code) when they implement stuff (and that’s when they are even “allowed to” by the task requirements) and even fewer have true knowledge of security and common pitfalls and whatnot to avoid such issues.
And even when you have those you still need good practices and code reviews where the rest of the slip ups is caught.
You’re correct. And I don’t think we are armchair coding. We know proper security is so hard that even experienced developers can write code vulnerable to something like a timing attack. But sending secure data to unvalidated input isn’t a minor slip up that could happen to anyone. They are either unaware of or not bothering with good practices.
It’s because ruby is terrible