2018-10-27 08:23:45 +02:00
|
|
|
uploadpack.hideRefs::
|
|
|
|
|
This variable is the same as `transfer.hideRefs`, but applies
|
|
|
|
|
only to `upload-pack` (and so affects only fetches, not pushes).
|
|
|
|
|
An attempt to fetch a hidden ref by `git fetch` will fail. See
|
|
|
|
|
also `uploadpack.allowTipSHA1InWant`.
|
|
|
|
|
|
|
|
|
|
uploadpack.allowTipSHA1InWant::
|
|
|
|
|
When `uploadpack.hideRefs` is in effect, allow `upload-pack`
|
|
|
|
|
to accept a fetch request that asks for an object at the tip
|
|
|
|
|
of a hidden ref (by default, such a request is rejected).
|
|
|
|
|
See also `uploadpack.hideRefs`. Even if this is false, a client
|
|
|
|
|
may be able to steal objects via the techniques described in the
|
|
|
|
|
"SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
|
|
|
|
|
best to keep private data in a separate repository.
|
|
|
|
|
|
|
|
|
|
uploadpack.allowReachableSHA1InWant::
|
|
|
|
|
Allow `upload-pack` to accept a fetch request that asks for an
|
|
|
|
|
object that is reachable from any ref tip. However, note that
|
|
|
|
|
calculating object reachability is computationally expensive.
|
|
|
|
|
Defaults to `false`. Even if this is false, a client may be able
|
|
|
|
|
to steal objects via the techniques described in the "SECURITY"
|
|
|
|
|
section of the linkgit:gitnamespaces[7] man page; it's best to
|
|
|
|
|
keep private data in a separate repository.
|
|
|
|
|
|
|
|
|
|
uploadpack.allowAnySHA1InWant::
|
|
|
|
|
Allow `upload-pack` to accept a fetch request that asks for any
|
|
|
|
|
object at all.
|
|
|
|
|
Defaults to `false`.
|
|
|
|
|
|
|
|
|
|
uploadpack.keepAlive::
|
|
|
|
|
When `upload-pack` has started `pack-objects`, there may be a
|
|
|
|
|
quiet period while `pack-objects` prepares the pack. Normally
|
|
|
|
|
it would output progress information, but if `--quiet` was used
|
|
|
|
|
for the fetch, `pack-objects` will output nothing at all until
|
|
|
|
|
the pack data begins. Some clients and networks may consider
|
|
|
|
|
the server to be hung and give up. Setting this option instructs
|
|
|
|
|
`upload-pack` to send an empty keepalive packet every
|
|
|
|
|
`uploadpack.keepAlive` seconds. Setting this option to 0
|
|
|
|
|
disables keepalive packets entirely. The default is 5 seconds.
|
|
|
|
|
|
|
|
|
|
uploadpack.packObjectsHook::
|
|
|
|
|
If this option is set, when `upload-pack` would run
|
|
|
|
|
`git pack-objects` to create a packfile for a client, it will
|
|
|
|
|
run this shell command instead. The `pack-objects` command and
|
|
|
|
|
arguments it _would_ have run (including the `git pack-objects`
|
|
|
|
|
at the beginning) are appended to the shell command. The stdin
|
|
|
|
|
and stdout of the hook are treated as if `pack-objects` itself
|
|
|
|
|
was run. I.e., `upload-pack` will feed input intended for
|
|
|
|
|
`pack-objects` to the hook, and expects a completed packfile on
|
|
|
|
|
stdout.
|
|
|
|
|
+
|
Documentation: define protected configuration
For security reasons, there are config variables that are only trusted
when they are specified in certain configuration scopes, which are
sometimes referred to on-list as 'protected configuration' [1]. A future
commit will introduce another such variable, so let's define our terms
so that we can have consistent documentation and implementation.
In our documentation, define 'protected configuration' as the system,
global and command config scopes. As a shorthand, I will refer to
variables that are only respected in protected configuration as
'protected configuration only', but this term is not used in the
documentation.
This definition of protected configuration is based on whether or not
Git can reasonably protect the user by ignoring the configuration scope:
- System, global and command line config are considered protected
because an attacker who has control over any of those can do plenty of
harm without Git, so we gain very little by ignoring those scopes.
- On the other hand, local (and similarly, worktree) config are not
considered protected because it is relatively easy for an attacker to
control local config, e.g.:
- On some shared user environments, a non-admin attacker can create a
repository high up the directory hierarchy (e.g. C:\.git on
Windows), and a user may accidentally use it when their PS1
automatically invokes "git" commands.
`safe.directory` prevents attacks of this form by making sure that
the user intended to use the shared repository. It obviously
shouldn't be read from the repository, because that would end up
trusting the repository that Git was supposed to reject.
- "git upload-pack" is expected to run in repositories that may not be
controlled by the user. We cannot ignore all config in that
repository (because "git upload-pack" would fail), but we can limit
the risks by ignoring `uploadpack.packObjectsHook`.
Only `uploadpack.packObjectsHook` is 'protected configuration only'. The
following variables are intentionally excluded:
- `safe.directory` should be 'protected configuration only', but it does
not technically fit the definition because it is not respected in the
"command" scope. A future commit will fix this.
- `trace2.*` happens to read the same scopes as `safe.directory` because
they share an implementation. However, this is not for security
reasons; it is because we want to start tracing so early that
repository-level config and "-c" are not available [2].
This requirement is unique to `trace2.*`, so it does not makes sense
for protected configuration to be subject to the same constraints.
[1] For example,
https://lore.kernel.org/git/6af83767-576b-75c4-c778-0284344a8fe7@github.com/
[2] https://lore.kernel.org/git/a0c89d0d-669e-bf56-25d2-cbb09b012e70@jeffhostetler.com/
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-14 23:27:58 +02:00
|
|
|
Note that this configuration variable is only respected when it is specified
|
|
|
|
|
in protected configuration (see <<SCOPES>>). This is a safety measure
|
|
|
|
|
against fetching from untrusted repositories.
|
2018-10-27 08:23:45 +02:00
|
|
|
|
|
|
|
|
uploadpack.allowFilter::
|
|
|
|
|
If this option is set, `upload-pack` will support partial
|
|
|
|
|
clone and partial fetch object filtering.
|
|
|
|
|
|
upload-pack.c: allow banning certain object filter(s)
Git clients may ask the server for a partial set of objects, where the
set of objects being requested is refined by one or more object filters.
Server administrators can configure 'git upload-pack' to allow or ban
these filters by setting the 'uploadpack.allowFilter' variable to
'true' or 'false', respectively.
However, administrators using bitmaps may wish to allow certain kinds of
object filters, but ban others. Specifically, they may wish to allow
object filters that can be optimized by the use of bitmaps, while
rejecting other object filters which aren't and represent a perceived
performance degradation (as well as an increased load factor on the
server).
Allow configuring 'git upload-pack' to support object filters on a
case-by-case basis by introducing two new configuration variables:
- 'uploadpackfilter.allow'
- 'uploadpackfilter.<kind>.allow'
where '<kind>' may be one of 'blobNone', 'blobLimit', 'tree', and so on.
Setting the second configuration variable for any valid value of
'<kind>' explicitly allows or disallows restricting that kind of object
filter.
If a client requests the object filter <kind> and the respective
configuration value is not set, 'git upload-pack' will default to the
value of 'uploadpackfilter.allow', which itself defaults to 'true' to
maintain backwards compatibility. Note that this differs from
'uploadpack.allowfilter', which controls whether or not the 'filter'
capability is advertised.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03 20:00:10 +02:00
|
|
|
uploadpackfilter.allow::
|
|
|
|
|
Provides a default value for unspecified object filters (see: the
|
2021-04-09 13:27:52 +02:00
|
|
|
below configuration variable). If set to `true`, this will also
|
|
|
|
|
enable all filters which get added in the future.
|
upload-pack.c: allow banning certain object filter(s)
Git clients may ask the server for a partial set of objects, where the
set of objects being requested is refined by one or more object filters.
Server administrators can configure 'git upload-pack' to allow or ban
these filters by setting the 'uploadpack.allowFilter' variable to
'true' or 'false', respectively.
However, administrators using bitmaps may wish to allow certain kinds of
object filters, but ban others. Specifically, they may wish to allow
object filters that can be optimized by the use of bitmaps, while
rejecting other object filters which aren't and represent a perceived
performance degradation (as well as an increased load factor on the
server).
Allow configuring 'git upload-pack' to support object filters on a
case-by-case basis by introducing two new configuration variables:
- 'uploadpackfilter.allow'
- 'uploadpackfilter.<kind>.allow'
where '<kind>' may be one of 'blobNone', 'blobLimit', 'tree', and so on.
Setting the second configuration variable for any valid value of
'<kind>' explicitly allows or disallows restricting that kind of object
filter.
If a client requests the object filter <kind> and the respective
configuration value is not set, 'git upload-pack' will default to the
value of 'uploadpackfilter.allow', which itself defaults to 'true' to
maintain backwards compatibility. Note that this differs from
'uploadpack.allowfilter', which controls whether or not the 'filter'
capability is advertised.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03 20:00:10 +02:00
|
|
|
Defaults to `true`.
|
|
|
|
|
|
|
|
|
|
uploadpackfilter.<filter>.allow::
|
|
|
|
|
Explicitly allow or ban the object filter corresponding to
|
|
|
|
|
`<filter>`, where `<filter>` may be one of: `blob:none`,
|
2021-04-19 13:46:53 +02:00
|
|
|
`blob:limit`, `object:type`, `tree`, `sparse:oid`, or `combine`.
|
|
|
|
|
If using combined filters, both `combine` and all of the nested
|
|
|
|
|
filter kinds must be allowed. Defaults to `uploadpackfilter.allow`.
|
upload-pack.c: allow banning certain object filter(s)
Git clients may ask the server for a partial set of objects, where the
set of objects being requested is refined by one or more object filters.
Server administrators can configure 'git upload-pack' to allow or ban
these filters by setting the 'uploadpack.allowFilter' variable to
'true' or 'false', respectively.
However, administrators using bitmaps may wish to allow certain kinds of
object filters, but ban others. Specifically, they may wish to allow
object filters that can be optimized by the use of bitmaps, while
rejecting other object filters which aren't and represent a perceived
performance degradation (as well as an increased load factor on the
server).
Allow configuring 'git upload-pack' to support object filters on a
case-by-case basis by introducing two new configuration variables:
- 'uploadpackfilter.allow'
- 'uploadpackfilter.<kind>.allow'
where '<kind>' may be one of 'blobNone', 'blobLimit', 'tree', and so on.
Setting the second configuration variable for any valid value of
'<kind>' explicitly allows or disallows restricting that kind of object
filter.
If a client requests the object filter <kind> and the respective
configuration value is not set, 'git upload-pack' will default to the
value of 'uploadpackfilter.allow', which itself defaults to 'true' to
maintain backwards compatibility. Note that this differs from
'uploadpack.allowfilter', which controls whether or not the 'filter'
capability is advertised.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03 20:00:10 +02:00
|
|
|
|
upload-pack.c: introduce 'uploadpackfilter.tree.maxDepth'
In b79cf959b2 (upload-pack.c: allow banning certain object filter(s),
2020-02-26), we introduced functionality to disallow certain object
filters from being chosen from within 'git upload-pack'. Traditionally,
administrators use this functionality to disallow filters that are known
to perform slowly, for e.g., those that do not have bitmap-level
filtering.
In the past, the '--filter=tree:<n>' was one such filter that does not
have bitmap-level filtering support, and so was likely to be banned by
administrators.
However, in the previous couple of commits, we introduced bitmap-level
filtering for the case when 'n' is equal to '0', i.e., as if we had a
'--filter=tree:none' choice.
While it would be sufficient to simply write
$ git config uploadpackfilter.tree.allow true
(since it would allow all values of 'n'), we would like to be able to
allow this filter for certain values of 'n', i.e., those no greater than
some pre-specified maximum.
In order to do this, introduce a new configuration key, as follows:
$ git config uploadpackfilter.tree.maxDepth <m>
where '<m>' specifies the maximum allowed value of 'n' in the filter
'tree:n'. Administrators who wish to allow for only the value '0' can
write:
$ git config uploadpackfilter.tree.allow true
$ git config uploadpackfilter.tree.maxDepth 0
which allows '--filter=tree:0', but no other values.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03 20:00:17 +02:00
|
|
|
uploadpackfilter.tree.maxDepth::
|
2020-09-27 16:11:55 +02:00
|
|
|
Only allow `--filter=tree:<n>` when `<n>` is no more than the value of
|
upload-pack.c: introduce 'uploadpackfilter.tree.maxDepth'
In b79cf959b2 (upload-pack.c: allow banning certain object filter(s),
2020-02-26), we introduced functionality to disallow certain object
filters from being chosen from within 'git upload-pack'. Traditionally,
administrators use this functionality to disallow filters that are known
to perform slowly, for e.g., those that do not have bitmap-level
filtering.
In the past, the '--filter=tree:<n>' was one such filter that does not
have bitmap-level filtering support, and so was likely to be banned by
administrators.
However, in the previous couple of commits, we introduced bitmap-level
filtering for the case when 'n' is equal to '0', i.e., as if we had a
'--filter=tree:none' choice.
While it would be sufficient to simply write
$ git config uploadpackfilter.tree.allow true
(since it would allow all values of 'n'), we would like to be able to
allow this filter for certain values of 'n', i.e., those no greater than
some pre-specified maximum.
In order to do this, introduce a new configuration key, as follows:
$ git config uploadpackfilter.tree.maxDepth <m>
where '<m>' specifies the maximum allowed value of 'n' in the filter
'tree:n'. Administrators who wish to allow for only the value '0' can
write:
$ git config uploadpackfilter.tree.allow true
$ git config uploadpackfilter.tree.maxDepth 0
which allows '--filter=tree:0', but no other values.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03 20:00:17 +02:00
|
|
|
`uploadpackfilter.tree.maxDepth`. If set, this also implies
|
|
|
|
|
`uploadpackfilter.tree.allow=true`, unless this configuration
|
|
|
|
|
variable had already been set. Has no effect if unset.
|
|
|
|
|
|
2018-10-27 08:23:45 +02:00
|
|
|
uploadpack.allowRefInWant::
|
|
|
|
|
If this option is set, `upload-pack` will support the `ref-in-want`
|
|
|
|
|
feature of the protocol version 2 `fetch` command. This feature
|
|
|
|
|
is intended for the benefit of load-balanced servers which may
|
|
|
|
|
not have the same view of what OIDs their refs point to due to
|
|
|
|
|
replication delay.
|