Open Source Software Community - it's about ethics in Code of Conducts

[mentally retarded user]

So you be sayin' they are Indian, but they are going further than simply editing the README.md

 

[0gh]

Do you believe security researchers are smart people? They must be, right? They find the most complex issues out there, they must be geniuses, right? No, they're glorified QA testers.



Thread begins here. https://x.com/halvarflake/status/1986682054273007816


He spends some time talking about security, pretty useless

But hey, he volunteers to write patches!

He even has a fix for two issues already

https://x.com/halvarflake/status/1986930123505881446

Reverse engineer has no idea how to use git??


Of course, it was all AI! The researcher just wasted everyone's time. Who could've imagined?

Security is important, but 99% of "researchers" are brainless. The FFmpeg bug for example could NEVER happen because that codec is only used for the first 20 frames of some obscure game. There would NEVER be an instance where you would just run this on a random video file, and there's probably like 10 people still playing that game today.

How much collective time was spent fixing random shit like this instead of improving software, I wonder?

A lot of CVEs are also
>if someone has access to your machine...
>if you run a shady file engineered in this exact way it could...
>if you happen to be in this very particular scenario and the next part in the memory is...

Yeah don't keep passwords unencrypted in the database, but if an attacker has to come down your chimney and stick a USB in your computer for it to work maybe you should mount a grate on it instead of putting locks on every single USB slot in your computer.

 

[General Zoider]

A lot of CVEs are also

most of the impressive CVEs were closed in the early 2000s and had thier fixes implemented fundamentally in all future software. Now all that's left are the "running this file with this program under x conditions will lead to privilege escalation"

 

[Hakase Shinonome]

Do you believe security researchers are smart people? They must be, right? They find the most complex issues out there, they must be geniuses, right? No, they're glorified QA testers.

>

 

[Consigliere]

businesses which rely on coreutils

RHEL (bigname) and derivatives (SME) are industry standard. Ubuntu never was and never will be standard for enterprise server infrastructure simply of how short their default support window is and the quality of their extended support window relative to its pricing.

RHEL offers 10 years of support for their releases by default plus 3 years of extended maintenance where ubuntu typically does 5 by default +5 extended maintenance for paid customers +2 legacy for corporate where you have to demand fixes from them. It also comes without any ham-fisted decisions inexperienced retards can approve and push through much to the displeasure and inconvenience of end clients.

 

[analrapist]

RHEL (bigname) and derivatives (SME) are industry standard.

They market themselves as "industry standard" but when you look at the platforms the industry has actually standardized on, things look quite different, at least from my stand point. I have not personally encountered a single organization running RHEL. My alma mater was Ubuntu. The Fortune 500 I worked for refused to touch RHEL. The Microsoft shop I worked at used whatever shipped, which involved Debian, Alpine, and a couple more esoterics. Any pros here whose companies actually run RHEL or derivatives?

At this point, given how much RedHat has pozzed the Linux neghole, I refuse to touch RedHat-upstream distroes.

 

[Consigliere]

The Fortune 500 I worked for refused to touch RHEL

Every German firm I worked for used RHEL or CentOS when it was a thing. RHCSA as far as I am aware is still an informal hard requirement for junior technicians.

At this point, given how much RedHat has pozzed the Linux neghole, I refuse to touch RedHat-upstream distroes.

You will use systemd and selinux and you will love it.

 

[nah]

But hey, he volunteers to write patches!

All maintainers should aggressively require including a patch to fix the issue and a test case at bare minimum. It has been virtually impossible to tell the difference between a contributor and a mooch for a long time; and with the ramp-up of lusers over the decades, the return of gatekeeping curmudgeons is necessary for any project's health.

 

[DavidS877]

Any pros here whose companies actually run RHEL or derivatives?

Yes. Most of my customers(Fortune 500) are primary RHEL. A couple are dipping their toes into Ubuntu, not sure if they're looking for paid support or not on those.

But more of what I'm seeing is the move to containers, either on-prem or in Teh Cloud(tm). The companies that use commercial software are seeing their vendors often move to containers only, from the old way where they would send VMWare images. The underlying container engine is usually Kubernetes but they're all over the map on what it's running on. Some roll their own entirely, some Rancher, some OpenShift, probably a few others.

 

[Creative Username]

All maintainers should aggressively require including a patch to fix the issue and a test case at bare minimum.

i'm not exactly opposed to the idea of bug reports in general. they can be valuable for less technical users to report bugs as long as they follow some simple criteria:

1. the bug is actually a bug
2. it is indeed a problem with the software it's being reported on
3. it can be readily reproduced by developers

there is, of course, a huge difference between informing the project that the software fucks up in a certain way, and being an egotistical fuckhead who thinks he's a Real Man™ and insists on dumping poorly-integrated llm slop on maintainers' heads
can't code? don't submit patches. that's what i think

another thing issue trackers are frequently used for is discussing the general design of the project or proposing a hypothetical way some new feature would work in a way that everybody likes. this is incredibly valuable because somebody can read these and then start out writing the initial skeleton of something most people will like as opposed to his own thing that might not be as good and has a bigger chance of ending up discarded. do note that this technique is quite vulnerable to extensive bikeshedding, so if you don't have any actually competent hackers around your issue tracker will just turn into a mini a&n

and with the ramp-up of lusers over the decades, the return of gatekeeping curmudgeons is necessary for any project's health.

agreed, but i think the issue of retarded drooling subhumans submitting the shittiest patches imaginable has been a thing since before there was a decent free kernel to run the gnu system on
it probably just happens a lot more these days and the lazy retards are lazy and retarded in different ways

 

[Angie Wormwood]

A lot of CVEs are also
>if someone has access to your machine...
>if you run a shady file engineered in this exact way it could...
>if you happen to be in this very particular scenario and the next part in the memory is...

Yeah don't keep passwords unencrypted in the database, but if an attacker has to come down your chimney and stick a USB in your computer for it to work maybe you should mount a grate on it instead of putting locks on every single USB slot in your computer.

Yeah, this is a problem. I've worked with a lot of security folks who boil their job down to "run Rapid7/Nessus/Qualys/etc. on a box and give results", then they either resist or give me a blank stare when I look into their results and find false positives or point out the CVEs have mitigation so nbd. I've worked with a lot of SAs, being one myself, and the number who have zero clue about security, and the inverse, security folks who know fuck-all about operating system stuff, is staggering.

It's why when I find an infosec person with a clue and they find out I can talk their language they get excited.

RHCSA as far as I am aware is still an informal hard requirement for junior technicians.

Maybe in Germany, but not here in Freedomland. I've only seen it for MSPs or the like where they use that as a selling point.

 

[prollyanotherlurker]

Maybe in Germany, but not here in Freedomland. I've only seen it for MSPs or the like where they use that as a selling point.

I'm pretty sure at least the US government is running RHEL. I'm sure there are a lot of others using it too.

If it was me I would just use debian probably, but idk.

 

[HootersMcBoobies]

da - only GNAT is active (1 impl). Prolog/Forth/COBOL - lmao. JS - ok, maybe node & bun are active, independent and compatible. ML - which ML? sh - not general purpose. Java - they are all downstream from openjdk.

Fujitsu built a COBOL.NET compiler in the mid 2000s to allow for migrating COBOL code from various old COBOL implementations onto windows servers. There are a lot of COBOL implementations. Almost all of them are not open source. For Javascript, Bun, Node and Deno are all in heavy use (although you can argue Deno/Node both use V.

Yeah, this is a problem. I've worked with a lot of security folks who boil their job down to "run Rapid7/Nessus/Qualys/etc. on a box and give results", then they either resist or give me a blank stare when I look into their results and find false positives or point out the CVEs have mitigation so nbd. I've worked with a lot of SAs, being one myself, and the number who have zero clue about security, and the inverse, security folks who know fuck-all about operating system stuff, is staggering.

Security teams are generally incompetent. I already ranted about them in another thread, so I'll cross-quote it:

Cybersecurity class? The most bullshit IT profession out there. Has anyone worked in a single company where the IT security team wasn't horrifically incompetent? They almost never have a single developer. One security team tried to offer me a job because they literally had no one to write scripts, and were manually reviewing threat logs. Another company tried to push us to use Red Hat Enterprise over our current VM distros because the security was apparently better if you pay for overpriced IBM shitware. They also mandated Crowdstrike/Falcon, because they were retarded.

I am not surprised at all this was in a security class. Anyone decent at it is not working in any official capacity and just makes money off of bug bounties and real software development.

 

[Consigliere]

US government is running RHEL

US public sector is running whatever as they don't require vendor-specific certificates. Instead they want a multivendor generalized CompTIA certificate. US DoD wants Security+/CySA+ for example.

 

[Cuckoman]

RHEL (bigname) and derivatives (SME) are industry standard. Ubuntu never was and never will be standard for enterprise server infrastructure simply of how short their default support window is and the quality of their extended support window relative to its pricing.

RHEL offers 10 years of support for their releases by default plus 3 years of extended maintenance where ubuntu typically does 5 by default +5 extended maintenance for paid customers +2 legacy for corporate where you have to demand fixes from them. It also comes without any ham-fisted decisions inexperienced retards can approve and push through much to the displeasure and inconvenience of end clients.

RHEL also employs a very large number of kernel and userspace maintainers.
You can hate RedHat an IBM if you want, but if you are a large customer and have a support contract with RHEL and have a kernel issue. Chances are that the guy eventually helping you sort it out is the maintainer for that kernel subsystem.

Ubuntu, do they even have actual engineers? You have an issue and eventually you get to talk to Ravi in Bangalore that wants to run you through his script "have you tried rebooting? Is power plugged in?

I have honestly never heard about an actual big company having a support contract with canonical. It sounds like a serious waste of money to me.

IBM/RHEL is expensive and you can have legitimate issues with some business practises but their paid, and expensive, support is unmatched.


$ cat MAINTAINERS |grep -i redhat|wc -l
140
$ cat MAINTAINERS |grep -i ibm|wc -l
127
$ cat MAINTAINERS |grep -i ubuntu|wc -l
1
$ cat MAINTAINERS |grep -i canonical|wc -l
5

(And when you see and think, five maintainers, not bad. Have a look at what parts of the kernel tree they are maintainers for. This is not to shame them or the work they do, it is to illustrate the wast difference in in-house experteese between the two.)

 

[DavidS877]

You can hate RedHat an IBM if you want, but if you are a large customer and have a support contract with RHEL and have a kernel issue. Chances are that the guy eventually helping you sort it out is the maintainer for that kernel subsystem.

The "eventually" is the problem, you have to get through 30 layers of "Please saar to be sending us SOS Report". You mean the one I attached when I opened the case because I'd know you'd ask? My rule is I should be able to fix the problem before RH does or I'm not doing my job correctly. It's more fun when you open the support request with "Here's the SOS Report. Here's the kernel patch. Please to be sending to someone competent." And it does finally hit the kernel 6 months later.

 

[Ferryman]

Security is important, but 99% of "researchers" are brainless. The FFmpeg bug for example could NEVER happen because that codec is only used for the first 20 frames of some obscure game. There would NEVER be an instance where you would just run this on a random video file, and there's probably like 10 people still playing that game today.

Security "research" is an invented profession that has no real merit to its existence. Maybe it meant something 10 or 15 years ago, but now it is simply an academic masturbation ring. Your average junior pentester can outpace most corporate or other self-proclaimed "researchers" in vulnerability detection, assessment and triage by orders of magnitude, faggots like this guy just refuse to accept that simple truth and continue to ride their undeserved high horse. Joanna Rutkowska, the founder of the QubesOS project, is a great example of a real security researcher. Even freaks like Francis Rowe are hundreds of times the "security researchers" these people claim to be.

Thread begins here. https://x.com/halvarflake/status/1986682054273007816

The most baffling thing about this specific guy is that he's not some random jeet updating github readmes, but someone with a very long standing career in cybersecurity. His real name is Thomas Dullien, and some of his exploits range from working for Google to hosting Black Hat Briefings seminars, both of which are, by all metrics, very prestigious achievements for a cybersecurity professional. After reading one of his papers regarding the nature of security vulnerabilities and an attempt to provide a theoretical exploit classification framework, I can confidently say that this man is a snake oil salesman. His writing is the sort of bloated buzzword salad that plagues most of modern academia, complex for complexity's sake and so that the author can jerk himself off over how smart he sounds.

Maybe in Germany, but not here in Freedomland. I've only seen it for MSPs or the like where they use that as a selling point.

Can confirm. RHEL and SUSE are the two big names in a lot of EU institutions. As far as certs go CCNA, Sec+ and RHCSA for sysadmin, especially in fin/tech or govt.

 

[Creative Username]

Security "research" is an invented profession that has no real merit to its existence. Maybe it meant something 10 or 15 years ago, but now it is simply an academic masturbation ring. Your average junior pentester can outpace most corporate or other self-proclaimed "researchers" in vulnerability detection, assessment and triage by orders of magnitude, faggots like this guy just refuse to accept that simple truth and continue to ride their undeserved high horse. Joanna Rutkowska, the founder of the QubesOS project, is a great example of a real security researcher. Even freaks like Francis Rowe are hundreds of times the "security researchers" these people claim to be.

the only true way to have a secure computer is to consciously design every part of it to be secure, every step of the way. this goes from the lowest-level security features (the operating system) up to completely safe interfaces for programs and libraries (and remember, never trust anybody's input more than you absolutely have to) and even up to system configuration defaults (it's good to fail safe) and up to admins (they need to know not to do retarded things) and users (the hardest part a lot of the time, they sure love falling for <NEW GAME> CRACK NO WEERUS.exe)
much like certain other elegance-derived qualities in software (e.g. simplicity, size, complexity, robustness, and speed) it is sometimes completely impossible to add security to some programs or systems in a satisfactory way. this is because the people who were writing it were either too retarded to think about security or they were thinking about security in an incredibly skewed manner that isn't useful in practice

Maybe it meant something 10 or 15 years ago

that's a very low estimate, i would bet at least 25 years ago

His real name is Thomas Dullien, and some of his exploits range from working for Google to hosting Black Hat Briefings seminars, both of which are, by all metrics, very prestigious achievements for a cybersecurity professional.

his real name is jason hall, and some of his exploits range from working for blizzard to making 2 indie games with his 20+ years of gamedev experience

His writing is the sort of bloated buzzword salad that plagues most of modern academia, complex for complexity's sake and so that the author can jerk himself off over how smart he sounds.

it's amazing what you can do with fancy box plots or whatever and complicated slang
technologically illiterate niggers fall for it every time. when can we finally have the "if you can't readily explain your entire academic career to a random ditch digger you are FUCKING STUPID" revolution

 

[Cuckoman]

The "eventually" is the problem, you have to get through 30 layers of "Please saar to be sending us SOS Report". You mean the one I attached when I opened the case because I'd know you'd ask? My rule is I should be able to fix the problem before RH does or I'm not doing my job correctly. It's more fun when you open the support request with "Here's the SOS Report. Here's the kernel patch. Please to be sending to someone competent." And it does finally hit the kernel 6 months later.

That is not unique to IBM/RedHat but how support works across the whole industry.

If you are a very important customer with a big support contract, you get escalated to these people very quickly.
If you are not a very big and very important customer, you might get escalated to them eventually, or never, or the problem might be fixed when someone else, more important than you, complains.

But the value that ibm/redhat adds is that IF you are big then you WILL be escalated to someone like this quickly, if you are not you MIGHT, maybe.

If you are a customer to canonical you will NEVER be escalated to someone like this because they don't exist at canonical.

If I escalate an issue to Google regarding my personal gmail account, I do not expect anyone to ever look at the issue.
If my employer reports an issue to gmail I know google will have an engineer working to help us right away. That is just how it is. You get what you pay for.

 

[DavidS877]

If you are a very important customer with a big support contract, you get escalated to these people very quickly.

The problem is that these are usually Fortune 100 companies with large expanses of RedHat. The escalation is still "eventually". They just don't seem to care any more.