ddworken

I actually made a CLI tool (https://github.com/ddworken/hishtory) that automatically binds to Control+R to support both history searching and AI queries (by prefixing queries with `?`).

Here's the prompt engineering I did: https://github.com/ddworken/hishtory/blob/master/shared/ai/a...

I'll also plug my project [0] as another alternative that supports syncing (similar to Autumn) and also has a number of powerful customization features (e.g. custom columns to collect arbitrary metadata with each command, like the git remote) and an AI shell command generator.

[0]: https://github.com/ddworken/hishtory

If you're interested in something more actively maintained, and with cross-machine syncing, two recent alternatives are:

* github.com/ddworken/hishtory * github.com/ellie/atuin

Disclaimer: I'm the maintainer of the first one.

Ah, thank you commenting on this! This is absolutely unintentional and was the fault of a missing comment in the bash script (that I didn't notice because I generally use zsh). See https://github.com/ddworken/hishtory/commit/72ff95ab8b23c3be... and if you run `hishtory update` it should be all fixed.

Yup exactly! This way you'll never again lose a history entry.

Yes! See the `hishtory redact` command to do exactly this.

Yes! Though they'll have a single shared history log since there is no way to distinguish between them.

See https://github.com/ddworken/hishtory/blob/master/backend/web...

Also, Github pro tip: Press `t` when on any github repo to bring up fuzzy matching that can be used to easily find any specific file.

Actually the install script is in the repo! See https://github.com/ddworken/hishtory/tree/master/backend/web...

+1 to prefixing with a space. hiSHtory supports this out of the box so that anything prefixed with a space isn't recorded (even if your shell doesn't do that by default!). And if you do ever mess up, `hishtory redact` can be used to delete history entries.

Agreed! I'll make sure to get this implemented ASAP. :)

See https://github.com/ddworken/hishtory/issues/6 for info on how to disable control-R and how to uninstall. And sorry about this, I agree that a cleaner way to uninstall is needed and will get this implemented soon!

Though keep in mind that all history entries are end to end encrypted, so even with syncing enabled, your shell history isn't accessible to the backend.

See https://github.com/ddworken/hishtory/issues/4

This isn't supported quite yet, but is the next item on the road map.

It just adds to it, your standard shell history is still there and completely unaffected by this tool. And if you prefer using your native shell's control-r you can also do that.

> if I delete something using `hishtory redact` does it delete it from my native shell history too

It does not (though if you think it should, please open an issue and I'm happy to add this!)

> Also just a heads up, I find the demo gif to be unintelligibly fast.

Ah thanks! Updating.

In addition, hiSHtory also supports fish for anyone who uses fish!

If you'd rather `go install` it, that works too! The advantage of this is that it doesn't require users to have go installed. And if you look at the script, all it does is call an API to determine the latest pre-built version for the current OS and install it.

Yup exactly! And you can even collect other custom metadata to make it easier to jump write back to where you were.

Ah, I hadn't come across Atuin before! They're pretty similar, but I think one significant advantage of hiSHtory is the "Custom Columns" support where you can populate custom columns with the output of an arbitrary shell script. For example, you can use this to collect the current git branch as an additional column.

Ah very cool! One advantage of hiSHtory over this is that hiSHtory also supports Linux (since it isn't bound to iCloud sync).

Though you could have a repository on Github that contains a subdirectory that is a malicious bare Git repo. So doing:

``` git clone github.com/foo/bar cd bar/subdir/ ```

is unsafe with a Git PS1. See https://offensi.com/2019/12/16/4-google-cloud-shell-bugs-exp...

You can also use the --rewrite flag to automatically patch those files. This will remove the class that leads to the vulnerability and is generally a safe change.

This tool will recursively unpack wars and ears.

One of the benefits of this tool is that you can run it across a folder or even an entire disk to check all jars on the disk. So if a Node app does somehow pull in java, by scanning the entire disk this tool should be able to detect if the pulled in java code contains log4j.

One other notable candidate for essentially "solving" XSRF is SameSite cookies:

https://web.dev/samesite-cookies-explained/

SameSite cookies are supported in Safari and IE11, so they're potentially a better candidate, but there are still come caveats (see here for some of them: https://security.stackexchange.com/questions/234386/do-i-sti...).

In the web, requests are made in either `cors` mode or `no-cors` mode. In `cors` mode, the `Origin` header is sent in the request. So yes, in `cors` mode the server could reject the request based on the `Origin` header. But in `no-cors` mode (the default if you do something like `<img src='...'>`) the `Origin` header isn't set, so CORS doesn't help defend against any attacks.

While I don't know anything specific about RedLeaf, I highly doubt that it is completely immune to Spectre. Spectre fundamentally stems from how modern CPUs are designed and the current understanding is that there is no way to fix Spectre. If you're curious, see the paper "Spectre is here to stay: An analysis of side-channels and speculative execution" [0]. Even on fully up to date OSs with the latest version of Chrome, Spectre is still exploitable (see [1]).

[0]: https://arxiv.org/abs/1902.05178 [1]: https://security.googleblog.com/2021/03/a-spectre-proof-of-c...

What do you mean by "drop it"? I guess I could imagine that a CPU would allow a specific process to disable speculative execution. That could be an interesting feature though I'm skeptical that any real world applications would actually want to opt-out of speculative execution if it makes things drastically.

Fundamentally, Spectre is a class of bugs that arises from how modern CPUs are designed. It isn't just an Intel bug, an x86 bug, or a JS bug. CPUs that perform speculative execution after a branch prediction are generally expected to be vulnerable. And as I understand it (I'm a security person, not a CPU designer) branch prediction is a very important optimization that is responsible for a lot of the advances in CPU performance over the years. So if CPU designers dropped branch prediction, they'd be trading off a lot of speed for security.

Not yet! But soon. :) See Project Fission [1]. Currently if you're using Beta or Nightly you can toggle it on and I believe it is getting very close to being ready to ship.

[1]: https://wiki.mozilla.org/Project_Fission