From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 7E3AF1388C0 for ; Wed, 24 Feb 2016 04:24:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A334B21C032; Wed, 24 Feb 2016 04:24:14 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 90C3021C01B for ; Wed, 24 Feb 2016 04:24:13 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aYQzj-00036D-C0 for gentoo-dev@lists.gentoo.org; Wed, 24 Feb 2016 05:24:11 +0100 Received: from ip98-167-165-199.ph.ph.cox.net ([98.167.165.199]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Feb 2016 05:24:11 +0100 Received: from 1i5t5.duncan by ip98-167-165-199.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Feb 2016 05:24:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Bug #565566: Why is it still not fixed? Date: Wed, 24 Feb 2016 04:24:06 +0000 (UTC) Message-ID: References: <56CC937C.3030805@gentoo.org> <56CCD4DC.3040509@gentoo.org> <56CCFE65.5050201@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip98-167-165-199.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT a52b404) X-Archives-Salt: 3194686c-daa4-4b28-81ec-11dffc041e28 X-Archives-Hash: 967233eff4812c15fe4230970169637e Rich Freeman posted on Tue, 23 Feb 2016 21:53:45 -0500 as excerpted: > In the degenerate case where nothing has changed, an rsync still needs > to walk the full tree and send a file list, while git just sends a > commit ID and terminates. Technicality: While I believe you're correct for pure rsync, AFAIK, portage (and presumably the others) and the gentoo mirrors use a hybrid rsync method, where first the timestamp file is compared, and if it hasn't changed the rsync itself doesn't occur. So for gentoo rsync you'd need to argue the single-file single-line single-commit change case, not the zero-change case. But your point stands. >> For one thing we can't expect users to keep an up to date copy of all >> gentoo developer's OpenPGP keys to verify each git commit, additionally >> this will cause issues with retirement and similar situations >> (certificate revocation, subkey rotations, expiries). > > Well, we could do something (eventually) to make tracking keys easier, > but I'll still buy that the thick manifests are more secure. Git commit > signatures are only bound to their contents with sha1. I get that > nobody has demonstrated a practical attack on that, but I think most > crypto experts wouldn't heartily endorse the design. Which is why I mentioned that there isn't a proper replacement for secure webrsync yet, so it'd have to stay around. But git, synced over a secure connection at least, is certainly not /worse/ than normal rsync, and it arguably has at least the potential to be far better. > Keep in mind that we do have git mirrors that include metadata/etc > hosted on Github. I know people have concerns with their software being > proprietary but as far as syncing goes it is just a mirror. I doubt > most of us audit all the distfiles mirrors we use to make sure they're > only using FOSS ftp/http servers and so on. This is why I don't have a problem syncing from github any more than I do from whatever rsync mirror, despite freedomware being a relatively high priority concern of mine in general. As long as the protocols are open and there's freedomware solutions available, whether a particular host I'm connecting to actually runs 100% freedomware isn't typically something I worry about... unless of course I'm the admin responsible for deciding what that host runs, in which case I'm unlikely to run anything /but/ freedomware on it (above BIOS/firmware level, anyway). > There really isn't any > reason that it couldn't be hosted on infra either, assuming they wanted > the extra load (and I don't see the point in it, since it is just a > mirror, and if it ever goes away it is trivial to just point the scripts > that generate it to push to some other mirror instead - > git itself is completely FOSS). I'd say doable, but wouldn't call it "trivial". Consider the difficulty the kernel had when bitkeeper pulled the rug out from under the Linux kernel, thus creating the need for git in the first place. The switch was doable, and eventually done (and like Linux itself, it ultimately became the world standard), but I wouldn't exactly call it "trivial". Of course in this case we're talking repo mirrors not repo software, but if gentoo's full rsync volume were to switch to git using github, and then github were to pull the rug out from under us... procuring and getting up and running that sort of hosting power on a week or even 90- day notice wouldn't be exactly "trivial", unless of course we suddenly have Trump's credit card or similar to charge it on! (Sorry, I'm following Nevada Republican caucus results 2nite as well, so it's Trump's CC, not Gates' or Ellison's or ...) > Again, I have nothing against devs maintaining rsync and changelogs, > and users making use of them. I just don't see it as the end of the > world if devs decide to stop taking care of them. Particularly when the basic changelog information is there, it's simply quibbling about chronological or reverse-chronological order we're doing now, and people who /really/ care about it by rights should be going straight to the git logs in the first place. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman