> This release contains a critical security workaround that affects Linux systems that use the musl libc and PAM disabled.

But that there's nothing about it on their security page.

Even if it's not technically a bug in their code, the fact that they've made a "critical" release to address it suggests that it should probably be listed on the security page as well. But maybe (hopefully) they just haven't updated the security page yet.

It's not perfect, but the UK NCSC has a load of guidance for individuals and small businesses that's a hell of a lot more approachable than the NIST document:

https://www.ncsc.gov.uk/section/advice-guidance/self-employe...

Five years of guaranteed updates, with an option to pay for another five years ticks the box for accreditors and the like.

The much vaguer Debian policy that a release will be supported for some undetermined period based on how frequently they release, and then get some kind of volunteer-based LTS support for a couple of years after that, and then maybe further through some third-party ELTS program is a much harder sell.

I'd love a world without advertising, but it's never going to happen. But a world without profile-targeted advertising could.

If the actions of these advertising companies are harmful, then everyone should be protected from them, not just one demographic that is considered to be more vulnerable.

And if they're not harmful, then in what sense are kids "vulnerable" to them and need protecting?

No one is arguing that Claude can't stick an image onto a PDF. But that is not the same thing as signing a contract.

They can be used by someone to sign a contract, but they cannot sign a contract themselves because they're just tools.

I could write dozen lines of bash that finds for PDFs, pastes an image into them and emails it to someone. That doesn't mean that bash can sign contracts.

Claude isn't. It's a tool, that isn't capable of signing a contract any more that Adobe Acrobat or Photoshop is.

OP used it as a tool to sign the contract. The question would be whether they did so knowingly and intentionally, if not then whether that invalidates the contract.

Very few people are going to invest that much effort when they're trying to do the company that they're reporting to a favour.

But the last couple of decades have shown us that huge numbers of developers aren't even following basic and free secure development practices, let alone pouring money into expensive scanning tools.

Sometimes even when the testing has been completely offline - I know people who have downloaded some software, carried out testing against a local copy of it, and then faced legal threats when they tried to report serious security vulnerabilities to the vendor.

It's one of the reasons that some researchers don't bother trying to talk to the vendors and just go straight to full disclosure, or if they do report to vendors they do so anonymously. But if you have to pay, that's creating a link back to yourself which makes the latter much harder.

Given that most websites only ever use a handful of methods (even once you account for REST APIs using PUT, PATCH and DELETE now), and that list very rarely changes, the WAF developers tend to look at this question from the opposite angle: when you know there are only half a dozen widely used methods, why would you allow anything else by default?

Practically speaking, there is zero chance that the USA would extradite someone to Iran, even if they weren't currently at war with them. Whether they did anything about it would probably depend on exactly what the situation was - there's a big of difference between targeted IRGC or defence systems and ransomwaring an Iranian hospital or scamming random citizens.

Where they'd probably get you is if you tried to monetise it, and get stolen/extorted cryptocurrencies (or whatever) into your bank account. But that could easily fall under tax evasion laws rather than computer misuse ones, because they'd be a lot easier to prove in court.