/tech/ - Technology★

To be fair, there are a lot of infosec people who do bug bounties for a living and all they do is specialize in a very specific thing (i.e. reflected XSS or remote file inclusion or CSRF or something like that) and they do it 100x over for the exact same issue (because people commonly make the same mistakes).

This thread just seems like an excuse to get mad at women.

It could be worse. There are some people who edit pronouns on github.

It's resume padding. Like the "kernel developers" who do nothing but fix grammar and spelling in documentation.

>>968921

This. You can be certain her skillset is shallow.

What does 'const' actually do? Is it like 'final' OCD in Java or it actually helps?

>>968920

>This thread just seems like an excuse to get mad at women.

>implying you need an excuse for that

>>968920

>This thread just seems like an excuse to get mad at women.

>One of two scholarships

>Two scholarships

>she gets half of those scholarships for doing literally nothing I, an uneducated, non-tech-savvy person could do and also having a vagina

Why should I not be angry?

>>968950

*couldn't

>>968928

Makes the compiler whine when you try to change the variable so you cast it to non-const and piledrive it into oblivion.

What if the linux foundation was topleling knowing somebody would toplel.

>>969284

This. More media coverage=more non tech people looking to get into tech only to realize you need a good understanding of what you're doing.

>>968920

what is your first paragraph even relating to? it's literally more work to find a bunch of CSRF and XSS vulns than to add a bunch of const to shit. and i agree, those infosec jobs where you just find a bunch of web vulns are retarded.

why are such people allowed to contribute to the kernel? learn how to program at school or some shit, not on the linux kernel. do cianiggers also get in this easy? just change some variable type somewhere claiming it's for performance when it really causes an RCE vuln?

>>968928

it's basically like 'final' OCD in Java

>>968920

Mundane problems and persistent bugs that are never fixed seem like more interesting territory:

http://steveloughran.blogspot.com/2016/07/gardening-commons.html

https://issues.apache.org/jira/browse/HADOOP-13287

>URLs break when Secret Key contains a slash, even if encoded.

>This whole thing was related to AWS-generated secrets. Those of us whose AWS secrets didn't have a "/" in this couldn't replicate the problem. Thus it was a configuration-space issue rather than something visible to all.

>There was a straightforward workaround, "generate new credentials", so it wasn't a blocker.

>That related issue, HADOOP-13287, is actually highlighting a regression caused by the fix for HADOOP-3733. In the process for allowing URLs to contain "/" symbols, we managed to break the ability to use "+" in them.

>The regression was caught because the HADOOP-3733 patch included some tests which played with the tester's real credentials. Fun problem: writing tests to do insecure things which don't leak secrets in logs and assert statements.

>HADOOP-13287 is not an example of "there are nearby problems" so much as "every bug fix moves the bug", something noted in Brook's "the mythical man month" in his coverage of IBM OS patches.

>And again, this is a c-space problem, it was caught because Chris had + in his secret.

>we had "/" in the secret is because the problem only arises if you put your AWS secrets in the URL itself, as s3a://AWSID:secret-aws-key@bucket

I think I'll try finding stuff like this soon to pad my resume and learn about some tools I've been using recently.