you're right, and those companies are traitors. But even then, I'm pretty sure they can't buy data enmasse to target a large number of americans without reason, but they could get around it by saying it's "just analysis of data", but they can only get around it that way because the judges are bought and paid for. When it suits them they interpret the constitution in the spirit it was written, when it doesn't according to the specific letters. The wording is clear on this:
"""
The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.
"""
It doesn't matter how the right of the people to be secure against searches and seizures is implemented. If the government manages to cause that, they're in violation. For other amendments it is written with wording like "congress shall not" indicating the restriction is on the government, preventing it from doing specific things. In this case, any violation of search and seizure is unlawful.
I'm more interested in the general question rather than the specifics of this situation, which I'm sure is now incredibly common. I know it looked at those implementations because I asked it to, and therefore I will credit those projects when I release this library. In general though, people do not know what other material the agents looked at in order to derive their results, therefore they can't give credit, or even be sure that they are technically complying with the relevant licenses.
That's assuming you do system upgrades through paru/yay. However, you may not want to upgrade the packages you've obtained from the AUR and so you upgrade using pacman. That may cause the updated libalpm to become incompatible with the installed yay/paru.
Iirc it was to force the extra step necessary for the user to acknowledge that the AUR can bootstrap malware if used blindly.
This seems to be a relatively consistent discussion surrounding AUR helper development; for example, adding UX to incentivise users to read PKGBUILDs, lest the AUR becomes an attractive vector for skids.
No one wants the AUR to become NPM, and the thing that will incentivise that is uneducated users. Having the small barrier of not having helpers in the main repos is an effective way of accomplishing that.
Assume they mean having to recompile the AUR package they were trying to install using yay.
If users mental model is mostly "yay is like pacman but can also install packages from AUR the same way" wihout thinking deeper about the difference then I think it using it is very risky and that you should just stick to pacman + git/makepkg. Only consider helpers once that's become second nature and routine. Telling people to "just yay install" is doing them a disservice. An upgrade breaking the system isn't even that bad compared to getting infected with malware due to an old package you were using being orphaned and hijacked to spread malware or getting a bad copycat version due to a typo.
I think EndeavourOS is doing users a disservice if they provide sth like yay preinstalled and ready to use out of the box. It isn't installing packages from a shared repo: It's downloading code from arbitrary locations and running it on your machine in order to produce a package. Being able to read and understand shell script (PKGBUILD) is kind of a prerequisite to using it safely.
The go standard library has an implementation of ed25519 although I did not find ed448 it also has some NIST curves. There are a few libraries that do ed448 like one from cloudflare.
To test a Claude Skill for analyzing cryptographic implementations of cryptographic side-channels ([1] see constant-time-analysis), I had Claude vibe-code an Ed448 implementation.
This includes:
1. The Ed448 signature algorithm
2. The Edwards448 elliptic curve group (which could conceivably be used for ECDH)
3. The Decaf448 prime-order group (a much better target for doing non-EdDSA things with)
I've been putting off reviewing it and making the implementation public (as it was an exercise in "is this skill a sufficient guard-rail against implementation error" more than anything), but if there's any interest in this from the Go community, I'll try to prioritize it later this year.
(I'm not publishing it without approval from the rest of the cryptography team, which requires an internal review.)
Your instructions to comment on your blog are incredible, come talk to you face to face. If I didn't live on the other side of the country it would be meaningful to tell you what it meant to me in person.
reply