How do you compare? What trusted channel do you use to retrieve the real public key?

Public keys go over untrusted channels. That's why they're public.

I'm not confident you understand how crypto works.

You do realize the entire threat model here is a house of cards perched atop someone else's software hosted on someone else's hardware all of which you implicitly trust and discard in favor of some unlikely cloak and dagger interception scheme.

Public keys can go over channels that an attacker can read. They cannot go over channels that an attacker can modify. (Which would include the SSH connection itself, until such time as you’ve verified the key through a trustworthy channel.)

A public key is useless without the private key. Which the attacker in this unlikely scenario doesn't have.

So you login the first time and they either match, or they don't. If they don't you start over. The end.

Ignore the fact that most people will probably use the box to host a poorly coded vulnerable service anyway.

If you’re being MITM’d, they’ll also match, because you’ll end up connected to an environment of the attacker’s choosing.

> in favor of some unlikely cloak and dagger interception scheme

someone who definitely understands how crypto works, describing the most basic possible MITM

It's not happening by chance, there is a bug somewhere.

From what I skimmed the package should just call to the js runtime's crypto.randomUUID(). I think it should always be properly seeded.

I think it is extremely unlikely that the runtime has a bug here, but who knows? What js runtime do you use?

Another way to phrase this is that guarantees can impose constraints that are overly limiting.

Having said that, the parallel with ML seems to be bit of a stretch. What exact high level guarantee is given up by being probabilistic?

How is the battery life? Rechargeable sure is nice, but the older models lasted forever on 4 AAAs (at least my TI-83). That's one aspect that would justify the low processing power for today's standards for portable computing devices.

This seems to be sloppy wording, with the intent of "we only offer the bounty under these terms". Maybe my interpretation is too charitable.

I do not speak for MSFT, but last time I spoke with MSRC indeed they would be happy to receive your vulnerability report even if you did not wish to participate in any particular bug bounty program.

I wonder if "if you contact us... you automatically agree" stands in court. That's just ridiculous.

Reader, it does not.

I wouldn't. This is very specialized to the type of the elements.

Some languages, such as C++, allow for specialisation via templates and compile time evabulation (constexpr). It would be possible to detect when the size of the data type matches one of the integer types, is a POD, is comparable via memcmp, etc to use SIMD optimised algorithms.

It is looking like C++ 26 will get compile time reflection, which would make things like this even more feasible.

1. You still need std::launder in that case.

2. It doesn't initialize the object that is implicitly created, even if the storage has initialized chars.

The paper that introduced the implicit lifetime mechanism suggests that std::launder is not required: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p05....

And they are legally required to license the play to do that, if it's still in copyright.

Only to perform it, not learn it.

And LLMs perform when you prompt them.

I feel uneasy about this after the xz story.