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 C99BA1389E2 for ; Wed, 17 Dec 2014 23:57:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 75342E083A; Wed, 17 Dec 2014 23:57:45 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E3EA2E07FA for ; Wed, 17 Dec 2014 23:57:44 +0000 (UTC) Received: from [10.0.31.246] (unknown [100.42.98.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 3E5873405EC for ; Wed, 17 Dec 2014 23:57:44 +0000 (UTC) Message-ID: <54921875.9020000@gentoo.org> Date: Wed, 17 Dec 2014 15:57:41 -0800 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] [RFC] Add 'emerge --sync-glsa' action and 'emaint sync-glsa' command References: <5491E7FD.2080203@gentoo.org> <20141217143255.387e52f5.dolsen@gentoo.org> In-Reply-To: <20141217143255.387e52f5.dolsen@gentoo.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Archives-Salt: f38873cf-2f93-4f80-8547-a39431d7688f X-Archives-Hash: 8b45cbc3059d3ef3a32a9f98ee258a12 On 12/17/2014 02:32 PM, Brian Dolbec wrote: > On Wed, 17 Dec 2014 12:30:53 -0800 > Zac Medico wrote: > >> Hi, >> >> For server deployments, it's common for administrators to want to use >> glsa-check for security vulnerabilities, without necessarily wanting >> to to do a full sync [1]. >> >> So, I propose that we add an 'emerge --sync-glsa' action and a >> corresponding 'emaint sync-glsa' command that will only sync the >> relevant metadata/glsa subdirectory of the relevant repository(s). >> Please respond if you agree or disagree with this proposal. >> >> [1] https://bugs.gentoo.org/show_bug.cgi?id=89641 > > I agree in principal, but you didn't say enough about your idea to be > able to say yes/no to it yet. Yeah, I need to explain the implementation ideas that were floating around in my head when I made the proposal. > I've read the bug comments. > > So, what you are saying for the above is set a very restrictive rsync > to just sync the glsa directory? > > So, with the new pluging-sync sytem in place, how do you propose we do > this? > > 1) Make a new emaint sync option which does the restriction and > appropriate sync module calls? > emaint sync --glsa & emerge --sync-glsa > > 2) emaint sync-glsa sounds like a modified copy of the sync module. > To me this is a poor idea. It would needlessly duplicate code. I was thinking that we could tag the repos containing glsas using an attribute in repos.conf, and teach the existing rsync module how to sync the glsas alone. > But what about the different sync types. How do we handle this in a > git repo instead of an rsync one? I was thinking that we would only need to implement this for the rsync repo, since that's the only one that includes the glsas. If there's some reason to implement it for other sync types in the future, then we can do it when the need arises. > > 3) if it is a separate repo, then the current emaint sync > module does not need __ANY__ modifications. > > emaint sync -r glsa <== would sync the repo named glsa no > matter what type of sync method is used. rsync, git, svn, > cvs,... > > Another advantage to a separate repo, for your use case that > they don't want the main repo to be synced, the new sync system > adds an "auto-sync" variable. "emerge --sync" will only sync > repos marked with it set to yes. So, if all they want is the > glsa's synced automatically, set only i'ts auto-sync to yes. > All other repos will have to be synced manually via the "emaint > sync --repo foo" command which does not look at the auto-sync > variable. Well, it sounds like you're introducing a new "repo" type that's different from a package repository. That's not really necessary if we take the approach that I've describe above. > Bottom line of this comes down to getting infra to create a standalone > repo for the glsa's. The current rsync tree could merge the gentoo and > glsa repos for backwards compatibility. For your use case, they set the > gentoo repo's rsync restriction to exclude the glsa's. And have the > separate glsa repo downloaded as it's own repository. With the gentoo > tree moving to git, then the git tree would not include the glsa's, so > the user would need to install the glsa tree as well. Note that we can even re-use the existing rsync tree if we take the "separate repo" approach, and simply configure the "separate repo" to sync from rsync://rsync.gentoo.org/gentoo-portage/metadata/glsa instead of rsync://rsync.gentoo.org/gentoo-portage. > Only code changes I see to portage, pkgcore (I know nothing about > paludis) are to look for the glsa's in the 2 possible locations. The > standalone glsa repo, failing that, backup to the gentoo tree. Well, is there anything wrong with the tagging the existing repo in repos.conf as I've described above? -- Thanks, Zac