Readit News logoReadit News
yrro commented on Microsoft admits it 'cannot guarantee' data sovereignty   theregister.com/2025/07/2... · Posted by u/rntn
yrro · a month ago
I would like to hear Amazon answer the same question under oath.

https://aws.eu/

yrro commented on Stdio(3) change: FILE is now opaque   undeadly.org/cgi?action=a... · Posted by u/gslin
severino · a month ago
Forgive my ignorance in this topic, but if "stdio.h" itself includes "bits/types/struct_FILE.h", is anything preventing me from accessing the individual elements of FILE as they are defined in the latter header file?
yrro · a month ago
It looks like FILE is not opaque in glibc. Create a translation unit that includes <stdio.h> & declares a FILE variable and it compiles fine. For comparison, create a translation unit that declares your own struct (but does not provide a definition) and declares a variable of the same type, and you'll get a "storage size of 'x' isn't known" error when compiling.
yrro commented on Libxml2's "no security embargoes" policy   lwn.net/SubscriberLink/10... · Posted by u/jwilk
fredilo · 2 months ago
> The maintainer could just write a wrapper around malloc that crashes on failure and replace all calls with the wrapper. It seems like an easy fix. Because almost no software can run where there is no heap memory so it makes no sense for the program to continue.

So could the reporter of the bug. Alternatively, he could add an `if(is null){crash}` after the malloc. The fix is easy for anyone that has some knowledge of the code base. The reporter has demonstrated this knowledge in finding the issue.

If a useful PR/patch diff was provided with the reporter, I would have expected it to be merged right away.

However, instead of doing the obvious thing to actually solve the issue, the reporter hits the maintainer with this bureaucratic monster:

> We'd like to inform you that we are preparing publications on the discovered vulnerability.

> Our Researchers plan to release the technical research, which will include the description and details of the discovered vulnerability.

> The research will be released after 90 days from the date you were informed of the vulnerability (approx. August 5th, 2025).

> Please answer the following questions:

>

> * When and in what version will you fix the vulnerability described in the Report? (date, version)

> * If it is not possible to release a patch in the next 90 days, then please indicate the expected release date of the patch (month).

> * Please, provide the CVE-ID for the vulnerability that we submitted to you.

>

> In case you have any further questions, please, contact us.

https://gitlab.gnome.org/GNOME/libxml2/-/issues/905#note_243...

The main issue here is really one of tone. The maintainer has been investing his free time to altruistically move the state of software forward and the reporter is too lazy to even type up a tone-adjusted individual message. Would it have been so hard for the reporter to write the following?

> Thank you for your nice library. It is very useful to us! However, we found a minor error that unfortunately might be severely exploitable. Attached is a patch that "fixes" it in an ad-hoc way. If you want to solve the issue in a different way, could we apply the patch first, and then you refactor the solution when you find time? Thanks! Could you give us some insights on when after merging to main/master, the patch will end up in a release? This is important for us to decide whether we need to work with a bleeding edge master version. Thank you again for your time!

Ultimately, it is a very similar message content. However, it feels completely different.

Suppose you are a maintainer without that much motivation left, and you get hit with such a message. You will feel like the reporter is an asshole. (I'm not saying he is one.) Do you really care, if he gets powned via this bug? It takes some character strength on the side of the maintainer to not just leave the issue open out of spite.

yrro · 2 months ago
If I received an email like that I'd reply with an invoice.
yrro commented on Writing a basic Linux device driver when you know nothing about Linux drivers   crescentro.se/posts/writi... · Posted by u/sbt567
amelius · 2 months ago
Does this provide protection against opening then device from two processes at the same time?
yrro · 2 months ago
Does O_EXCL work with linux USB devices?
yrro commented on New Linux udisks flaw lets attackers get root on major Linux distros   bleepingcomputer.com/news... · Posted by u/smig0
belorn · 2 months ago
Could someone describe what 'allow_active' privileges is on Linux?
yrro commented on New Linux udisks flaw lets attackers get root on major Linux distros   bleepingcomputer.com/news... · Posted by u/smig0
hedora · 2 months ago
The GP doesn't understand the vulnerability:

https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt

Instead of using something standard like environment variables, pam has a special "pam_env" that contains facts about the user session that it apparently trusts. Users can override pam_env settings by writing to hidden file in ~.

So, this exploit chain is more accurately described as "yet another example of utilities inventing new, obscure configuration mechanisms for security-critical settings, allowing policy flaws to remain undetected for a long time".

Running security configuration options through a special snowflake IPC mechanism (instead of keeping them in a file where they could actually be inspected by humans) would only make things worse.

yrro · 2 months ago
> For some reason, instead of only applying its contents to the user environment for the child process like any sane person would do, they are trusting its values for the library calls in the privileged parent itself.

The only safe way to use pam_env's `user_readenv` parameter is as the final rule of `type=session`. This behaves as you'd expect, affecting the child process only.

It appears that openSUSE enables the option for other rule types (auth and/or account), in which case it affects the parent process as well. Oops!

For the record, user_readenv has been disabled since:

    commit 4c430f6f8391555bb1b7b78991afb20d35228efc
    Author: Tomas Mraz <tm@t8m.info>
    Date:   Mon Oct 11 14:24:30 2010 +0000
    
        Relevant BUGIDs:
        
        Purpose of commit: bugfix
        
        Commit summary:
        ---------------
        2010-10-11  Tomas Mraz  <t8m@centrum.cz>
        
                * modules/pam_env/pam_env.c: Change default for user_readenv to 0.
                * modules/pam_env/pam_env.8.xml: Document the new default for user_readenv.
... PAM 1.1.3. And it's been deprecated for a while, to be removed in a future release entirely.

yrro commented on Show HN: Unregistry – “docker push” directly to servers without a registry   github.com/psviderski/unr... · Posted by u/psviderski
politelemon · 2 months ago
Considering the nature of servers, security boundaries and hardening,

> Linux via Homebrew

Please don't encourage this on Linux. It happens to offer a Linux setup as an afterthought but behaves like a pigeon on a chessboard rather than a package manager.

yrro · 2 months ago
Well put, but it's a shame this comment is the first thing I read, rather than comments about the tool itself!
yrro commented on Debian bookworm live images now reproducible   lwn.net/Articles/1015402/... · Posted by u/bertman
flkenosad · 5 months ago
Question: is Perl the only runtime the Debian build process relies on?
yrro · 5 months ago
Any packages with "Essential: yes" (run 'apt list ~E' to see them) are required on any Debian system. Additionally, the 'build-essential' pulls in other packages that must be present to build Debian packages via its dependencies: https://packages.debian.org/sid/build-essential
yrro commented on A note on the USB-to-PS/2 mouse adapter that came with Microsoft mouse devices   devblogs.microsoft.com/ol... · Posted by u/luu
kragen · 5 months ago
yrro · 5 months ago
That's a great site. Finally I think I understand WTF Lenovo mean by "IPMI over Keyboard Controller Style (KCS) Access"
yrro commented on A love letter to the CSV format   github.com/medialab/xan/b... · Posted by u/Yomguithereal
aorth · 5 months ago
Someone filed a bug report on a project I work on, saying that it was a security vulnerability that we don't prefix cell values with a single quote (') when the cell content contains certain values like an equal sign (=). They said this can cause Excel to evaluate the content and potentially run unsafe code.

I responded that this was Excel's problem, not ours, and that nobody would assign a CVE to our product for such a "vulnerability". How naive I was! They forwarded me several such CVEs assigned to products that create CSVs that are "unsafe" for Excel.

Terrible precedent. Ridiculous security theater.

yrro · 5 months ago
The next version of CVSS needs to add a metric for these kind of bullshit non-vulnerabilities so that we can ignore them at source.

u/yrro

KarmaCake day2525August 10, 2013View Original