theamk

that works too

For personal services, even something as simple as HTTP basic auth on the webserver dramatically reduces the attack surface by blocking all probers and drive-by attacks.

I see no inherent problem with that, since it's a very good idea to run agent inside container/VM anyway. And if the only things agent can access is the docker container and /project directory? It can go wild inside.

The variable alone, however, is kinda suspicious - I'd do both variable and command-line flag, just for extra assurance.

(another idea might be to enforce docker, but I know some people run agents in VMs, so this won't work)

Those "teen riders" were shooting toy guns at the passer-by.

As someone who walks on the streets / uses public transport, Waymo was 100% in the right there. Wish all taxi services were like that.

Because of extra services. Unlike emails, which usually come with no guarantees or support, the money-sending services are protected. Even with something like EFT, consumers have 60 days in case of actual fraud or bank mistakes, and with credit cards, you are also protected from things like product non-delivery.

Those protections exist and cost money - both to pay for customer support handing those, as well as to reimburse customer when the original money cannot be found anymore.

(And related, this is one of the big problems with cryptocurrencies: most people are not happy to know that one typo / software bug means their money is lost forever. Those protections on regular baking are there for a reason.)

The language makes all the difference because defaults matter. As someone said once, you can write C in any language. You can even do a heartbleed in python - just create one big buffer, do your own allocator, and pass (buffer, index) everywhere instead of proper object.

But would anyone do this? No. If you are writing pool-based packet processor in Python, you'd deal in buffers (safe from overread), in C# you'd return Span/Memory (safe from overread) and only in C you'd return overread-prone raw pointer.

Not that you can blame programmers in this case - C simply lacks the facilities for safe memory access, such as bounded pointers or spans. And you can't really blame it on custom allocator - malloc() would have had the same problem.

No, they used a language where the preferred way to share memory is raw pointers. That is the problem.

Every language has a preferred way to deal with things. In C, it's raw pointers, which are very error prone. Other languages have something better. For example, if you were to implement custom allocator in C#, would you return raw pointer? Or maybe base array + offset pair? Of course not, you'd choose a Span or Memory, and those are not prone to buffer overruns.

> In my opinion, if you used Wikipedia, you should cite it [...] It's a really huge problem that people pull ideas from Wikipedia, attribute them to something like "paper 4"..

Your solution for using unreliable Wikipedia is to cite it. My solution (and the way I was taught) is to simply _never use it_ for stuff which goes into the paper.

If I wanted to claim something ("widgets are quux"), I might certainly _start_ with Wikipedia, just to make sure that my understanding is correct and that I am not wasting my time, but if I want to use this in the paper, I will need to move to primary sources, read them and ensure that there is a good evidence that widgets are indeed quux.

So now that I spent all that time reading primary sources, I'd certainly cite them and not Wikipedia - after all, primary sources are better, and a single citation is enough. And in the case the Wikipedia author was wrong, I will avoid a mistake.

By extension, if I am citing Wikipedia, this means I have not found/read any better sources, and that just shows that I am lazy or maybe those widgets are not quux at all. Any advisor/reviewer would immediately point to this mistake - "Why are you citing Wikipedia here? Find a better source or remove the claim"

And that's how the rule is made - it's not "Don't cite Wikipedia [put ideas unattributed instead]", it is actually "Don't cite Wikipedia [find a better source and cit it instead]".

(Although I agree that some lazy people do former rather than latter)

I think Heartbleed is close enough to memory safety to count. It was caused by memory allocator returning uninitialized memory and every memory safe language I know about does not allow this in best-practice code.

(And sure, there are escape hatches - like Python has "recv_into" that could be used to implement heartbleed if you are really inclined to - but this would not be a realistic python program. In python, even with buffer reuse, you'd be using memoryview or similar that can't have a heartbleed problem)

Isn't this directly against WP:NOR, specifically WP:TERTIARY? Every fact must be supported by reliable first-party source, and the idea's provenance is that source.

In the research, there are often long paths that lead to the ideas: lunch room conversation -> paper 1 -> web search on term seen -> paper 2 -> web search on another term seen -> wikipedia page -> another wikipedia page -> original source (paper 3) -> paper 3's citation list -> paper 4 -> fact for your own paper

We always cite only the very last item in the chain, paper 4. I'd might cite other papers I've seen, but only if they are relevant. I was taught that the tertiary sources, like encyclopedias, are never to be cited, unless they have original facts which cannot be traced to other sources.

Are there restrictive firewalls which block unknown HTTP/HTTPS but not Tor? I'd expect Tor to be blocked first.

(And then proxying via your home is much faster and safer. You can do websocket-based proxy, but even exposing ssh server on port 443 works in a lot of places!)

Can they? I believe SSH key bind the public key auth to the server identity, so this kind of MITM is impossible.

(Just don't turn on ForwardAgent)

    2>/dev/null && echo nopass || echo maybe) || echo none)"

Writing a longer command to get less details and shorter output - this is so LLM!

A human would simply run the two commands in sequence and parse errors on the remote side - this would have gave more information about unexpected errors.

This is May version. If you look at the twitter thread, the October version is different and looks much more "stock"