From: Taylor Blau <me@ttaylorr.com>
To: git@vger.kernel.org
Subject: [TOPIC 1/8] Bundle URIs
Date: Thu, 29 Sep 2022 15:19:30 -0400 [thread overview]
Message-ID: <YzXvwv/zK5AjhVvV@nand.local> (raw)
In-Reply-To: <YzXvMRc6X60kjVeY@nand.local>
# Bundle URIs (Stolee)
- Unlike packfile URIs, includes refs, does not need to be delta-ed
against what server sends
- Doc checked into Documentation/technical
- URI can be provided by user at CLI or advertised by server
- Most users won't experience anything if they git-clone, but it will
only benefit the git hosting providers. It will allow them to offload
data to CDNs, being closer to the client.
- With bundle files you can download them and start of from there and
fetch the objects you're missing in a regular manner.
- Jrnieder: Packfile URIs and Bundle URIs are trying to achieve the same
thing. How can we duplicate efforts? E.g. how can we prevent the
client from leaking information to a possibly untrusted server?
- Stolee: Are you want to provide a way to provide authentication?
- Jrnieder: Analogy to the web - you don't want to leak information to
websites you don't trust. The security model is pretty complicated, we
don't want to replicate things like same origin policies.
- Stolee: So, e.g. the server provides a hash of the content expected at
the bundle URI and the client can verify? We wanted to explicitly
avoid that because we don't want the server and bundle provider to
need to know anything about each other.
- Jrnieder: Compare to packfile URIS - Packfile URIs are only advertised
for the server, so the security model is mostly the same as a
"regular" fetch/clone
- Jonathantanmy: Another difference: the objects in bundles must be
associated with refs, you can't just have e.g. large objects.
Packfiles can contain arbitrary objects.
- Stolee: Let's talk about the security model more on the mailing list
- Ævar: We're also open for a breakout session on this topic
next prev parent reply other threads:[~2022-09-29 19:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-29 19:17 Notes from the Git Contributor's Summit, 2022 Taylor Blau
2022-09-29 19:19 ` Taylor Blau [this message]
2022-09-29 19:19 ` [TOPIC 2/8] State of SHA-256 transition Taylor Blau
2022-09-29 19:20 ` [TOPIC 3/8] Merge ORT timeline Taylor Blau
2022-09-29 19:20 ` [TOPIC 4/8] Commit `--filter`'s Taylor Blau
2022-09-29 19:21 ` [TOPIC 5/8] Server side merges and rebases Taylor Blau
2022-09-29 19:21 ` [TOPIC 6/8] State of sparsity work Taylor Blau
2022-09-29 19:21 ` [TOPIC 7/8] Speeding up the connectivity check Taylor Blau
2022-09-29 19:22 ` [TOPIC 8/8] Using Git securely in shared services Taylor Blau
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YzXvwv/zK5AjhVvV@nand.local \
--to=me@ttaylorr.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).