For SSH specifically (ssh user@host "command with args") I've written this workaround pseudoshell that makes it easy to pass your argument vector to execve unmolested.

https://crates.io/crates/arghsh

Note that at least in python, you can use "shlex.quote" instead - it's in stdlib and does not need any extra tools.

    >>> import subprocess
    >>> import shlex
    >>> subprocess.run(['ssh', 'host', shlex.join(['ls', '-la', 'a filename with spaces'])])
    ls: cannot access 'a filename with spaces': No such file or directory

works nested, too

    >>> layer2 = ['ls', '-la', 'a filename with spaces']
    >>> layer1 = ['ssh', 'host1', shlex.join(layer2)]
    >>> layer0 = ['ssh', 'host0', shlex.join(layer1)]
    >>> subprocess.run(layer0)

(I am not sure if Rust has equivalent, but if it does not, it's probably easy to implement.. Python version is only a few lines long)

Wrong! SSH is very much the worst: it uses the user's login shell, not sh -c. So if the user's login shell isn't POSIX compatible, it still fails!

   >>> subprocess.run(["fish", "-c", shlex.join(["echo", "this isn\\'t working"])])
   fish: Unexpected end of string, quotes are not balanced
   echo 'this isn\'"'"'t working'

Well, you gotta draw the line somewhere, right? You can ssh into all sort of weird places, like native windows machines, or routers which expose their own shell, and you cannot expect them to be as usable as the regular ones.

The systems with non-POSIX non-interactive shell are firmly in the "special" category. If a user decided to set their _non_interactive_ shell to fish - they know they are heading for trouble and should not be surprised. I would not worry about such users in my scripts for example.

Please correct me if I'm am wrong, but POSIX doesn't define a non-interactive or interactive shell, it only defines a login shell. You can't "set your non-interactive shell", only "set your login shell". OpenSSH could easily have decided to "join all arguments with spaces and pass them to sh -c", which would also have been a bad decision for the reasons listed in this article, but instead chose the even more esoteric choice of using the login shell, even when running non-interactive commands.

> I am not sure if Rust has equivalent

Not in the standard library, but there are packages.

This just confirms my habit of switching to python as soon as a shell script reaches any level of complexity

Great, but I would've been happier if I'd had some dead simple dependency tracking 10 years ago. Just enough to create metabug functionality with. Like Bugzilla, Trac, Mantis etc have sported for at least two deades. I've always wondered why Github didn't have such basic functionality. (No, just the ability to reference other issues is not enough; I want to get an email for the metabug when all blocking issues are resolved).

I'm running LineageOS, rooted, with MicroG' Safetynet emulation (of sorts?). So a build signed with userdebug keys.

Some banking apps just work - two with warning on first launch, and one just doesn't care at all.

Two refuse to run and I have an old unrooted phone for them. Resulting in me being a good customer of those three banks that are not fussy.

So try and see, perhaps things just work!

Even if you enforce SSL-only on inbound mail, you're still vulnerable to the downgrade attack (or rather: the "prevent upgrade to TLS attack") - someone can MITM, and the sender will be speaking non-SSL to the MITMer, who'll speak SSL to you. To you things would look fine. Enter MTA-STS, with which the sending mail server can deduce that no, things are not OK.

Or are you saying you're not doing STARTLS at all and servers delivering mail to you have to do an SSL handshake before getting to speak SMTP to you? I'm quite surprised if that's compatible with the wider SMTP world.

MTA-STS is still vulnerable to MITM. If someone can tamper with DNS queries, it's useless. It's also apparently useless for the first message because the policy will not be in cache and only fetched afterwards.

We could have added a field so that when a server announces that they support STARTTLS, they can say that this fact should be cached for X days.

    250-AUTH LOGIN PLAIN
    250-STARTTLS
    250-STARTTLS-CACHE-90-DAYS

The vulnerability of the first message is a real concern, MTA-STS is not perfect. But it looks like the easiest to deploy tool that can strengthen security for a very large number of messages.

One challenge for your suggestion is that the mail server is often run by a different organization, on a different domain from the receiving address. The HTTPS web server, on the other hand, has a TLS certificate for the mta-sts subdomain of the receiving address. This gives confidence that the MTA-STS policy is set by the receiving domain, not the receiving mail server.

I think the use case is ad-hoc, as described on the page. I think the author may know about syslog, but this ad-hoc approach is useful when something such as syslog is not set up correctly and you can't fix it right there and then. This allows you to investigate and fix some bug over the weekend without having to involve others or other bureaucratic domains.

Yes - basically I encountered all of the example situations on the page and knocked up the initial version in a day or so (originally for the "PHP API" scenario specifically). I did add some extra features like setting your own namespace/logging key and controlling visibility, but in the end they didn't really match the use case - "one person doing ad hoc debugging in an unfamiliar environment" - so I stripped them out.

One can resolve "localhost" (even via an upstream resolver) to an arbitrary IP address. At least on my Linux system "localhost" only seems to be specially treated by systemd-resolved (with a cursory attempt I didn't succeed in getting it to use an upstream resolver for it).

So it's not a rock-hard guarantee that traffic to localhost never leaves your system. It would be unconventional and uncommon for it to, though, except for the likes of us who like to ssh-tunnel all kinds of things on our loopback interfaces :-)

The sweet spot of security vs convenience, in the case of browsers and awarding "secure origin status" for .internal, could perhaps be on a dynamic case by case basis at connect time:

- check if it's using a self-signed cert - offer TOFU procedure if so - if not, verify as usual

Maaaaybe check whether the connection is to an RFC1918 private range address as well. Maybe. It would break proxying and tunneling. But perhaps that'd be a good thing.

This would just be for browsers, for the single purpose of enabling things like serviceworkers and other "secure origin"-only features, on this new .internal domain.

> One can resolve "localhost" (even via an upstream resolver) to an arbitrary IP address. At least on my Linux system "localhost" only seems to be specially treated by systemd-resolved (with a cursory attempt I didn't succeed in getting it to use an upstream resolver for it).

The secure context spec [1] addresses this-- localhost should only be considered potentially trustworthy if the agent complies with specific name resolution rules to guarantee that it never resolves to anything except the host's loopback interface.

[1] https://w3c.github.io/webappsec-secure-contexts/#localhost

localhost is pretty special in that it's like the only domain typically defined in a default /etc/hosts.

You may be able to replace some of your curl+shell with Hurl — https://hurl.dev/#also-an-http-test-tool .

Why should someone bother to do this, if they already know and have a handle on cURL's syntax?

Compared to curl, you can:

- chain requests passing data from a request to another,

- add tests on every responses: body, headers, certificates, etc... You can use JSONPath or XPath for example,

- there is some sugar syntax to construct request bodies (GraphQL body is annoying with curl, JSON etc...),

- there is some sugar syntax for retrying requests on asserts, delaying requests etc..

Under the hood, Hurl uses libcurl so a lot of curl's options are exposed through Hurl (and we benefit of a lot of curl features like HTTP/3, IPV4/IPV6 etc... and speed and reliability of course!).

(I'm one of the maintainers)

From the first three lines of the linked-to paragraph:

> Hurl can run HTTP requests but can also be used to test HTTP responses. > Different types of queries and predicates are supported, from XPath and JSONPath on body response, to assert on status code and response headers.

Then the page that PHP outputs is still HTML.

So... let's assume many users do this, and let's assume Google factors in the opening rate into the transactional-email-likeness score, and that transactional-email-senders become widely aware of this...

Then senders' incentive will become to make the subject line into clickbait for the content, so that you'll open the message. So instead of subjects like "Order placed", "Order paid", "Order shipped", "Order out for delivery" you'll get uniform subjects along the lines of "IMPORTANT UPDATE TO YOUR ORDER". You will lose efficiency getting through your emails, and over time the metric will lose its indicativeness. Everybody loses.