On Thu, 2016-03-31 at 11:17 -0400, Colin Walters wrote:
On Thu, Mar 24, 2016, at 07:08 AM, Alexander Larsson wrote: +* We need to copy the remote config, because the remote configuration is not inherited from the parent repo. It looks to me like the code supported this once upon a time, but this has bit-rotted. Are you interested in re-instating this?Yeah, makes sense.
Done: https://github.com/ostreedev/ostree/pull/236
* There is some magic knowledge about the repo format when the summary cache is copied to the summary file location. Kinda ugly, but works.The GPG issues are interesting. Are you thinking that adding a key would be a privileged op too?
Configuring remotes would be something only root would be able to do. The only operation that the privileged helper would do is pull/update a pre-configured remote with some option set, that has a gpg key and signed commit+summary. One way of doing this is to run "remote add" as root. Another is to support a remotes.d style config that is installed via host-os packages.
3) We have to create a temporary remote to pull in the final results into the real repo. It would be nice if we could pull from the "real" remote, but supply a custom url for that particular pull operation. Then we didn't have to do that.One thing I've been thinking about adding is support for "alternates" like https://git-scm.com/docs/gitrepository-layout I think this use case could fit into it?
The use of a parent repo is similar to the alternatives, but it only supplies the objects. For a pull to work in the unprivileged repo it need to also pick up the remote url and gpg configuration from the system repo. Thus the patches above. The custom url is for the final part, where we integrate the local (untrusted) repo into the system repo. We need it to have the same branch name (verified by the signed summary) and gpg config. But ideally we should be able to do this pull without destructive updates to the system repo like adding a new remote for the untrusted user repo. I've attached a patch that lets you do this via: git pull --url=local-repo-url remote-name With that (and the inherit-parent-config work) the attached script does essentially what I want the trusted helper to do. I'm not super excited by the --url part, and especially how it uses a kind of hack with -- mirror to allow the same ref to be in the repo with the real origin:ref so we can verify it. But, its the best I could think of. Got any other approaches?
Attachment:
0001-Add-support-for-using-a-custom-url-whan-pulling.patch
Description: Text Data
Attachment:
setup-repo.sh
Description: application/shellscript