extern/hishtory
1
0
Fork 0
mirror of https://github.com/ddworken/hishtory.git synced 2025-02-16 18:41:03 +01:00
Code Issues Packages Projects Releases Wiki Activity

Delete unused variable + clean up README

Browse Source
This commit is contained in:
David Dworken 2022-09-24 01:13:25 -07:00
parent de943af423
commit 92cec3a87c
2 changed files with 12 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
README.md
View File

@ -1,8 +1,6 @@
# hishtory: Better Shell Hishtory
`hishtory` is a better shell history. It stores your shell history in context (what directory you ran the command it, whether it succeeded or failed, how long it took, etc). This is all stored in a local SQLite DB and e2e encrypted while synced to local SQLite DBs running on all your other computers. All of this is easily queryable via the `hishtory` CLI. This means from your laptop, you can easily find that complex bash pipeline you wrote on your server, and see the context in which you ran it.
`hishtory` is written in Go and uses AES-GCM for end-to-end encrypting your hishtory entries while syncing them. The binary is reproducibly built and [SLSA Level 3](https://slsa.dev/) to make it easy to verify you're getting the code contained in this repository.
`hishtory` is a better shell history. It stores your shell history in context (what directory you ran the command it, whether it succeeded or failed, how long it took, etc). This is all stored in locally and end-to-end encrypted for syncing to to all your other computers. All of this is easily queryable via the `hishtory` CLI. This means from your laptop, you can easily find that complex bash pipeline you wrote on your server, and see the context in which you ran it.
## Getting Started
@ -12,7 +10,7 @@ To install `hishtory` on your first machine:
curl https://hishtory.dev/install.py | python3 -
```
At this point, `hishtory` is already persisting your shell history. Give it a try with `hishtory query` and see below for more details on the advanced query features.
At this point, `hishtory` is already managing your shell history. Give it a try with `hishtory query` and see below for more details on the advanced query features.
Then to install `hishtory` on your other computers, you need your secret key. Get this by running `hishtory status`. Once you have it, you follow similar steps to install hishtory on your other computers:
@ -39,9 +37,7 @@ Now if you run `hishtory query` on first computer, you can automatically see the
| `hishtory query service before:2022-02-01` | Find all commands containing `service` run before February 1st 2022 |
| `hishtory query service after:2022-02-01` | Find all commands containing `service` run after February 1st 2022 |
For true power users, you can query via SQL via `sqlite3 ~/.hishtory/.hishtory.db`.
In addition, `hishtory export` dumps all commands to stdout separated by a single line. This can be useful for certain advanced use cases.
For true power users, you can even query in SQLite via `sqlite3 ~/.hishtory/.hishtory.db`.
### Enable/Disable
@ -53,7 +49,7 @@ If you want to temporarily turn on/off hishtory recording, you can do so via `hi
### Updating
To update `hishtory` to the latest version, just run `hishtory update` to transparently download and apply the latest update.
To update `hishtory` to the latest version, just run `hishtory update` to securely download and apply the latest update.
### Multi-Shell Support
@ -61,30 +57,29 @@ To update `hishtory` to the latest version, just run `hishtory update` to transp
## Design
The `hishtory` CLI is written in Go. It hooks into the shell in order to track information about all commands that are run (specifically in bash this is done via `trap DEBUG` and overriding `$PROMPT_COMMAND`). It takes this data and saves it in a local SQLite DB managed via [GORM](https://gorm.io/). When the user runs `hishtory query`, a SQL query is run to find matching entries in the local SQLite DB.
The `hishtory` CLI is written in Go. It hooks into the shell in order to track information about all commands that are run. It takes this data and saves it in a local SQLite DB managed via [GORM](https://gorm.io/). This data is then encrypted and sent to your other devices through a backend that essentially functions as a one-to-many queue. When you run `hishtory query`, a SQL query is run to find matching entries in the local SQLite DB.
### Syncing Design
When `hishtory` is installed, it generates a random secret key. Computers that share a history share this secret key (which is manually copied by the user). It deterministically generates three additional secrets from the secret key:
When `hishtory` is installed, it generates a random secret key. Computers that share a history share this secret key (done via having the user manually copy the key). It then generates two additional secrets:
1. `UserId = HMAC(SecretKey, "user_id")`
2. `DeviceId = HMAC(SecretKey, "device_id")`
3. `EncryptionKey = HMAC(SecretKey, "encryption_key")`
2. `EncryptionKey = HMAC(SecretKey, "encryption_key")`
3. `DeviceId = randomUuid()`
At installation time, `hishtory` registers itself with the backend which stores the tuple `(UserId, DeviceId)` which represents a one-to-many relationship between user and devices. In addition, it creates a `DumpRequest` specific that a new device was created and it needs a copy of the existing bash history.
At installation time, `hishtory` registers itself with the backend which stores the tuple `(UserId, DeviceId)` which represents a one-to-many relationship between user and devices. In addition, it creates a `DumpRequest` to signify that a new device was created and it needs a copy of the existing bash history.
When a command is run:
1. `hishtory` encrypts (via AES-GCM with `EncryptionKey`) the command (and all the metadata) and sends it to the backend along with the `UserId` to persist it for. The backend retrieves a list of all associated `DeviceId`s and stores a copy of the encrypted blob for each device associated with that user. Once a given device has read an encrypted blob, that entry can be deleted in order to save space (in essence this is a per-device queue, but implemented on top of postgres because this is small scale and I already am running a postgres instance).
2. `hishtory` checks for any pending `DumpRequest`s, and if there are any sends a complete (encrypted) copy of the local SQLite DB to be shared with the requesting device.
2. `hishtory` checks for any pending `DumpRequest`s. If it finds one, it sends a complete (encrypted) copy of the local SQLite DB to the requesting device.
When the user runs `hishtory query`, it retrieves all unread blobs from the backend, decrypts them, and adds them to the local SQLite DB.
## Security
Hishtory is designed to ensure that the backend cannot read your shell history. This is achieved by:
`hishtory` is written in Go and uses AES-GCM for end-to-end encrypting your hishtory entries while syncing them. The binary is reproducibly built and [SLSA Level 3](https://slsa.dev/) to make it easy to verify you're getting the code contained in this repository.
1. Encrypting history entries with a secret key that the backend never sees
2. Using [SLSA](https://slsa.dev/) to support secure updates that guarantee that you're running the code contained in this repo
This all ensures that the minimalist backend cannot read your shell history, it only sees encrypted data.
If you find any security issues in hishtory, please reach out to `david@daviddworken.com`.

1
client/data/data.go
View File

@ -21,7 +21,6 @@ import (
const (
KdfUserID = "user_id"
KdfDeviceID = "device_id"
KdfEncryptionKey = "encryption_key"
)