From: Michael J Gruber <git@drmicha•warpmail.net>
To: Matthias Andree <matthias.andree@gmx•de>
Cc: git@vger•kernel.org
Subject: Re: encrypted repositories?
Date: Fri, 17 Jul 2009 18:06:00 +0200 [thread overview]
Message-ID: <4A60A168.2060105@drmicha.warpmail.net> (raw)
In-Reply-To: <op.uw7wmbr41e62zd@balu.cs.uni-paderborn.de>
Matthias Andree venit, vidit, dixit 17.07.2009 17:14:
> Greetings,
>
> I have a rather special usage scenario.
>
> Assume you have a repository where you want to work on embargoed
> information, so that not even system administrators of the server you're
> pushing to can get a hold of the cleartext data.
>
> "Server" would be a central reference repository that I can push to.
> "Client" would by my working computer that has a clone of the crypted
> repo, and an unencrypted checkout of it. Perhaps the client would also
> need an unencrypted copy of the repo (for performance reasons, I'm not
> sure about that) that gets encrypted on the fly when pushing and decrypted
> when fetching.
>
> Examples of use might be press releases of upcoming products, written
> exams for students, whatever.
>
> Requirements:
> - "client" that is about to push must encrypt the data before pushing it
> to the server.
> - all data (including file names, log messages,
>
> Allowed restrictions:
> - "server" limited to bare repositories
> - initial version limited to symmetric encryption with pre-shared secret
>
> In a later step, some key management and asymmetric crypto would be
> useful, but that's not crucial now. In my current scenario, those who are
> working on the embargoed material would trust one another.
>
>
> How would one go about this from the user side? I sincerely doubt I have
> the resources (time!) to actually implement this in Git.
If the server can not decrypt anything then it can not serve anything,
at least not as a git server. Note that if you're really fussy about
security then you should not allow the server to see even the DAG (which
would be the case if you encrypt blobs only), which makes it impossible
to do any smart serving.
So, why not share some form of remote storage on which you have an
encrypted luks partition? That way you can even set up multiple access
keys and revoke them when necessary.
Michael
next prev parent reply other threads:[~2009-07-17 16:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-17 15:14 encrypted repositories? Matthias Andree
2009-07-17 16:06 ` Michael J Gruber [this message]
2009-07-17 20:22 ` Jakub Narebski
2009-07-17 16:30 ` Matthias Kestenholz
2009-07-17 19:38 ` Linus Torvalds
2009-07-17 20:22 ` John Tapsell
2009-07-17 20:40 ` Linus Torvalds
2009-07-17 20:42 ` Linus Torvalds
2009-07-18 19:09 ` encrypted repositories? with git-torrent? Thomas Koch
2009-07-20 12:13 ` Matthias Andree
2009-07-20 12:09 ` encrypted repositories? Matthias Andree
2009-07-20 13:48 ` Jakub Narebski
2009-07-21 8:30 ` Matthias Andree
2009-07-20 15:30 ` Jeff King
2009-07-21 8:25 ` Matthias Andree
2009-07-23 10:40 ` Jeff King
2012-08-02 14:52 ` J-S-B
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A60A168.2060105@drmicha.warpmail.net \
--to=git@drmicha$(echo .)warpmail.net \
--cc=git@vger$(echo .)kernel.org \
--cc=matthias.andree@gmx$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox