From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Matthias Andree" Subject: Re: encrypted repositories? Date: Tue, 21 Jul 2009 10:30:13 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: "Linus Torvalds" , git@vger.kernel.org To: "Jakub Narebski" X-From: git-owner@vger.kernel.org Tue Jul 21 10:30:27 2009 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1MTAjy-0006N3-EY for gcvg-git-2@gmane.org; Tue, 21 Jul 2009 10:30:26 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753540AbZGUIaT (ORCPT ); Tue, 21 Jul 2009 04:30:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753187AbZGUIaS (ORCPT ); Tue, 21 Jul 2009 04:30:18 -0400 Received: from mail.gmx.net ([213.165.64.20]:48803 "HELO mail.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752827AbZGUIaR (ORCPT ); Tue, 21 Jul 2009 04:30:17 -0400 Received: (qmail invoked by alias); 21 Jul 2009 08:30:16 -0000 Received: from g227137121.adsl.alicedsl.de (EHLO mandree.no-ip.org) [92.227.137.121] by mail.gmx.net (mp050) with SMTP; 21 Jul 2009 10:30:16 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX198fsJrV998nmDF8HDXoToxdEtuhENS7lt9/GkThx BdNNlJCMUUCuSn Received: from merlin.emma.line.org (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 648D094BB0; Tue, 21 Jul 2009 10:30:14 +0200 (CEST) In-Reply-To: User-Agent: Opera Mail/9.64 (Linux) X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Am 20.07.2009, 15:48 Uhr, schrieb Jakub Narebski : > "Matthias Andree" writes: > >> On a more general note, is someone looking into improving the http:// >> efficiency? Perhaps there are synergies between my plan of (a) >> encryption and (b) more efficient "dumb" (http/rsync/...) protocol >> use. > > There was idea about improving http:// efficiency, but it was via > crating git-over-HTTP aka. "smart" HTTP server, i.e. you would have to > have DAG exposed, like for git:// and ssh:// > > > On the other hand for http:// server need only "dumb" web server, and > additional metadata generated by git-update-server-info. It is client > who does "walking" the DAG, so all data including server metadata can > be encrypted, and decrypted on-the-fly by client. Fine by me, and seems to be some "minimal disclosure to server". > I don't know though what information leakage you would get from > existence of loose objects and packfiles, and their sizes. Probably > negligible... Dunno. Given that it's just a collection of object sizes, you can't tell from the SHA1 if the object in question is tree, tag, blob, or commit. I'm really not after on-the-fly delta re-compression on the server-side for crypto stuff. I'm more thinking along the lines of zsync/bsdiff/xdelta (http://zsync.moria.org.uk/ for the least-known) - but zsync can't work on encrypted data. Perhaps encrypting the diffs could work, but then what's the difference to using the http:// and update-server-info related material and combining that with client-side on-the-fly (de/en)cryption? -- Matthias Andree