On Monday 16 June 2008 Sheldon Hearn wrote:
> On Monday 16 June 2008 16:31:58 Philipp Marek wrote:
> > This would (in my default-debian case) mean:
> > - no asterisk
> > - no squid
> > - no logcheck
>
> [...]
>
> Perfect! Most of these may include sensitive information.
and should be versioned ...
> Some are, in my opinion, stupidly restricted, e.g.:
> > - no at.deny
I don't understand why squid.conf isn't readable - but that's just me, I
expect there's some sensible cause for that.
> But we're not going to change the world in a day. Assuming fsvs
> attracts enough users, those users could lobby package maintainers to
> relax where apropriate. In the meantime, we just need the best
> possible coping mechanism(s).
>
> So how best to cope? These points assume that fsvs is being used for at
> least /etc:
>
> 1) Allow "include", "ignore" or "gpg commit-pipe" as the action to take
> for files that are not world readable. I think a default of
> "gpg commit-pipe" would be more useful to more people for /etc.
Please note that only "include" and "ignore" are currently possible; using a
commit-pipe for files with !(mask & 001) would have to be special-coded, and
I'm not sure whether that's the best way.
Using some ignore pattern is one thing; changing behaviour because of some
bits something different.
BTW: if you have the private key available, you have no additional security;
if you don't, you'll be asked for the password on every "fsvs diff" and "fsvs
revert" - I don't think that's ok.
[ Of course, with some connection to gnome-keyring or kwallet and similar
(like svn now goes) would make that easier - AFAIK you can already use some
gpg-agent in KDE. ]
> 2) Either way, provide useful diagnostic output that indicates what's
> going on.
Do you mean something like "fsvs ignore-diag"?
> 3) This tilts me toward "/etc versioning as a separate fsvs-config"
> package. Otherwise, you end up with a conditional or extraneous
> dependency on gnupg that some users won't want.
That's right.
On Monday 16 June 2008 Peter Rabbitson wrote:
> And in my case I would like to version all of them *encrypted*.
...
> I myself am not interested in the ignore functionality at all - space is
> cheap, and any change of /etc is crucial.
But you shouldn't version *.bak etc, because that only clutters your
filesystem, repository and makes it harder to see actual changes.
> However since the same mechanism
> can be used to force encryption on everything that is not world-readable -
> well you have my persuasion :)
I don't think that the same mechanism (ignore patterns) can be used for
encryption.
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
