On 11 Feb 2009, at 11:23 pm, Andreas Rottmann wrote:
Hi!
I'm considering switching to ugarit (from a home-made C program
driving
afio/tar/gpg) for my backup needs (a few Linux boxes), and would
really
appreciate:
- GPG support (e.g. generate a random AES key/IV, and store it,
encrypted via GPG, in the archive). This would do away with the need
to store the AES key in plaintext in a config file.
True, but there'd need to be something *equivalent* to the AES key
still in the config file, even if that is just details of where to
find a GPG key that can decrypt an AES key stored in the archive...
...would you prefer an option to prompt for a key on the console when
opening an archive?
(I already have a plan for plaintext passphrases, I just need to
figure out a nice way to make 256-bit ones - Tiger hashes will produce
128 or 192 bit keys from passphrases, but not 256-bit ones).
- .ugarit-ignore file support (as already on the list of planned
features); this is in fact the itch I scratched with my custom-made
backup tool, as I couldn't find a backup solution that offered that
feature.
Yeah! I'm mulling that a bit after a conversation that came up with
Peter Bex on IRC.
My original idea was just to make it an ignore file, to not archive
certain things. But Peter raised the idea of filters such as magically
archiving an SVN repository as just a file that's the result of an
"svnadmin dump" on the repository and before/after commands, such as
checkpointing a database before dumping it. However, such tricks would
depend on being able to trust the rule files, while just supporting
'ignore' wouldn't; even if you run the commands as the UID of the user
owning the rules file, they could fail to terminate and thus halt the
snapshot.
So my current thinking is to have "dangerous" and "safe" operations in
the rules files, and dangerous operations would only be performed if
the rules file was owned by a user in a trusted list, which defaults
to the UID that ran ugarit. Dangerous operations would, in general,
involve running an arbitrary wrapper closure to handle the object that
matched, with procedures provided in the namespace that create
closures to provide filtering and before/after shell command
execution, with some support (to be determined) for running the
commands as specified users (just punt that job to sudo?).
For now, though, I can proceed with basic ignore functionality, but
I'll need to leave my options open for the more advanced stuff :-)
Keep up the good work!
;-)
Regards, Rotty
ABS
--
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog: http://www.snell-pym.org.uk/?author=4
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
