I noticed you only respond to comments that are positive (or neutral). The majority (and the most insightful) comments here are negative, but you seem to ignore them.

can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum

can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum

As Eric has correctly stated above, we believe iwd (Intel Wireless Daemon), or rather the ell library it relies on (Embedded Linux Library) is the only relatively widespread user space application relying on it.

Isn't the better argument to ask whether there'd be benefit if all those things did?

A lack of adoption isn't apriori a good argument against an interface, and serious bugs can happen anywhere.

My personal opinion for a while has been that crypto operations should be in the kernel so we can end the madness that is every application shipping it's own crypto and trust system which has only gotten worse since containers were invented.

> My personal opinion for a while has been that crypto operations should be in the kernel so we can end the madness that is every application shipping it's own crypto and trust system which has only gotten worse since containers were invented.

There’s a valid argument here but I think that’d devolve into the DNSSec trap without both a very well-designed API and a stable way to ship updates for older kernels. If people can’t get good user experience or have to force kernel upgrades to improve security, most applications will avoid it. Things like Chrome shipping their own crypto mean that they can very quickly ship things like PQC without waiting years or having to deal with issues like kernel n+1 having unrelated driver or performance issues which force things into a security vs. functionality fight.

Which does sort of loop around to the issue of Linux not having a stable ABI as a feature I suppose which would be one way to implement it with long term compatibility on kernel modules.

But the Chrome example also highlights the problem: Chrome might ship it, but vanishingly little software is ever going to upgrade and we've got an explosion of statically linked languages now.

If Linux does that, I really hope it can be done in a standardized way that doesn't make porting to *BSD more difficult than it already might be. Standards are a good thing.

> A lack of adoption isn't apriori a good argument against an interface

I mean it kind of is (perhaps not a priori, but why is that relavent?). If something is not being used, its not meeting needs, so its just increasing attack surfaces without benefit.

is CONFIG_CRYPTO_USER_API needed for hw acceleration for cryptsetup (dm-crypt) disk encryption ?

No, dm-crypt just calls the kernel's crypto code directly.

I completely agree with you. The only thing I would add is, that prediction markets are not necessarily oracles for predicting the future. They can just as well be used for hedging: imagine, hypothetically I really do not want Trump to win. I can bet on Trump, not because I want or expect him to win, but to hedge my position (perhaps my business would suffer if Trump wins)

It's always possible. But I haven't seen anything that would imply this to be the case so far in all the years I've been reading this.

> a noticeable amount of LLM output sounds like I’m getting answers from a millennial reddit user

LLM was trained on data from the whole internet (of which reddit is a big part). The result is a composite of all the text on the internet.

you can configure Alt+Left to go up level

how would that help? either they check the returned boxes or they don't. sending back 1 shoe does not fools the inspection

An empty shoebox is so much lighter than a full shoebox that the odds of triggering someones sense of this being fishy are way higher I guess.

It matters less if it's actually true than if someone trying to pull off the scam thinks it might be. The only way to find out if that hole exists in the system is either to have an insider tell you that it would, or to try it out...

Oh, and to add further to the nonsense: the product description technically doesn't say that what you're buying is a pair of shoes. So a sufficiently automated system might mistake a single shoe for a legitimate product. It's absurd, but not impossible to see how you might end up there.

Package: chromium Version: 138.0.7204.49-1~deb12u1

I am experiencing very weird and suspicious issue on debian 12.

For context, I am using grsecurity + RBAC, which gives me the possibility to see what files each program wants to access. My issue is not caused by RBAC. but RBAC brought my attention to this issue.

SO, I have upgraded chromium browser to: 138.0.7204.49

and suddenly when chromium starts, in addition to trying to access the usual files in my home, such as ~/.config/chromium or ~/.cache , it now tries to access sensitive folders on my system:

~/.ssh/ ~/.gnupg/ ~/.dbus/ /boot/

(while ~/.dbus is not as immediately alarming as the others, Chromium accessing this when it didn't before is still a change in behavior that deserves scrutiny)

this never happened before. I am sure, because the RBAC rules that I am using would have alerted me.

this is highly suspicious and potentially a serious security issue !

this issue was originally reported on chromium 138, fixed in next version, and now it's back in version 140.0.7339.80

Is it a problem with the Debian package or upstream?

I assume upstream. Hard to imagine that Debian would be adding this "feature" themselves.