Handling secrets in a secure yet shared mechanism #1

New issue

Open

opened 2025-03-15 10:25:56 +00:00 by renken · 1 comment

renken commented

2025-03-15 10:25:56 +00:00

Owner

I don't have much experience with this so I need to do some research first. On top of my head I can think of the following solutions.

Securing secret data

SQLite with AES-256 encryption

+ SQLite is very stable and is available everywhere.
+ Both querying and insertion uses standard SQL.
- Relational database therefore requiring you to define a proper hierarchy e.g., name, type (text, blob, file), type_dependent_info.. etc. Which is much more hassle compared to having just using a file system.

KeepassXC

+ Secure by design.
+ Similarly to SQLite, one file to share is enough for everything.
- keepassxc-cli isn't made for this kind of use case I think.
- Not sure if attachments and so on are supported by the CLI even.

Encrypted directory

See https://wiki.archlinux.org/title/ECryptfs.

? Never done this before
+ Part of the Linux kernel.
++ Nothing to change on my end since I already have a secrets directory.
? Quality of the utilities
? Reading passphrase from a file/stdin instead of passing it as an argument

I think I'm leaning towards this one so far.

Private repository on Forgejo

+ Very straightforward, very simple.
+ ACL work already done by Forgejo.
- I'm doomed if someone bypasses it. Of course, I'd need to give them the passphrase as well but them having access to encrypted data is already bad enough. However, in reality, it should give me enough time to update all secret files for it to no longer be valid?

What's the fuss about Vault... etc? It seems to complicated for my use case but worth checking nonetheless.
How well do these tools integrate with a templating engine? I still need to figure that out in a separate issue, see #2.

I don't have much experience with this so I need to do some research first. On top of my head I can think of the following solutions. # Securing secret data ## SQLite with AES-256 encryption * \+ SQLite is very stable and is available everywhere. * \+ Both querying and insertion uses standard SQL. * \- Relational database therefore requiring you to define a proper hierarchy e.g., `name`, `type` (text, blob, file), `type_dependent_info`.. etc. Which is much more hassle compared to having just using a file system. ## KeepassXC * \+ Secure by design. * \+ Similarly to SQLite, one file to share is enough for everything. * \- `keepassxc-cli` isn't made for this kind of use case I think. * \- Not sure if attachments and so on are supported by the CLI even. ## Encrypted directory See https://wiki.archlinux.org/title/ECryptfs. * ? Never done this before * \+ Part of the Linux kernel. * ++ Nothing to change on my end since I already have a `secrets` directory. * ? Quality of the utilities * ? Reading passphrase from a file/stdin instead of passing it as an argument *I think I'm leaning towards this one so far.* # Sharing secret data ## Private repository on Forgejo * \+ Very straightforward, very simple. * \+ ACL work already done by Forgejo. * \- I'm doomed if someone bypasses it. Of course, I'd need to give them the passphrase as well but them having access to encrypted data is already bad enough. However, in reality, it should give me enough time to update all secret files for it to no longer be valid? --- * What's the fuss about Vault... etc? It seems to complicated for my use case but worth checking nonetheless. * How well do these tools integrate with a templating engine? I still need to figure that out in a separate issue, see #2.

renken commented

2025-03-15 12:16:23 +00:00

Author

Owner

Actually, would it make sense to have two source packages.

The current source package that includes pretty everything except for secrets. This means that secrets are not part of the generated Debian packages. However, a symlink will exist.
Another Debian package that is generated using the private repository which sets itself up on /usr/share/shione/secrets/files and includes all the necessary secrets.

This would also make it easier for other people to use this project without having to re-build it themselves. They simply need to build their own secrets Debian package and install it beforehand.

Example:

$ ls -l /etc/wireguard
private.key -> /usr/share/shione/secrets/files/etc/wireguard/private.key
public.key -> /usr/share/shione/secrets/files/etc/wireguard/public.key
wg0.conf -> /usr/share/shione/secrets/files/etc/wireguard/wg0.conf

This also means that all files can be generic and not shione-specific except for /usr/share/shione I suppose...

The downside to this is that the secrets package has to manage file permissions accordingly which is annoying and requires duplicating work.

Actually, would it make sense to have two source packages. 1. The current source package that includes pretty everything except for secrets. This means that secrets are not part of the generated Debian packages. However, a symlink will exist. 2. Another Debian package that is generated using the private repository which sets itself up on `/usr/share/shione/secrets/files` and includes all the necessary secrets. This would also make it easier for other people to use this project without having to re-build it themselves. They simply need to build their own secrets Debian package and install it beforehand. Example: ```console $ ls -l /etc/wireguard private.key -> /usr/share/shione/secrets/files/etc/wireguard/private.key public.key -> /usr/share/shione/secrets/files/etc/wireguard/public.key wg0.conf -> /usr/share/shione/secrets/files/etc/wireguard/wg0.conf ``` This also means that all files can be generic and not shione-specific except for `/usr/share/shione` I suppose... The downside to this is that the secrets package has to manage file permissions accordingly which is annoying and requires duplicating work.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: renken/shione#1

No description provided.