Dave Borowitz [Tue, 30 Jun 2015 01:05:11 +0000 (18:05 -0700)]
Store push certificates in refs/meta/push-certs
Inspired by a proposal from gitolite[1], where we store a file in
a tree for each ref name, and the contents of the file is the latest
push cert to affect that ref.
The main modification from that proposal (other than lacking the
out-of-git batching) is to append "@{cert}" to filenames, which allows
storing certificates for both refs/foo and refs/foo/bar. Those
refnames cannot coexist at the same time in a repository, but we do
not want to discard the push certificate responsible for deleting the
ref, which we would have to do if refs/foo in the push cert tree
changed from a tree to a blob.
The "@{cert}" syntax is at least somewhat consistent with
gitrevisions(7) wherein @{...} describe operators on ref names.
As we cannot (currently) atomically update the push cert ref with the
refs that were updated, this operation is inherently racy. Kick the can
down the road by pushing this burden on callers.
Chris Price [Tue, 7 Jul 2015 12:06:50 +0000 (13:06 +0100)]
Move `RepositoryTestCase.indexState` to parent class
The test helper method `indexState` in `RepositoryTestCase` is
very useful for writing tests, even in cases where we need to
do things like create more than one repository for a test and
thus we don't want to use the built-in `db` member variable that
exists in `RepositoryTestCase`. Since the method is static,
we can move it up to the parent class `LocalDiskRepositoryTestCase`,
where it can be used by tests that aren't a great fit for inheriting
directly from `RepositoryTestCase`.
Bug: 436200
Change-Id: I2b6de75c001d2d77ddb607488af246548784a67f Signed-off-by: Chris Price <chris@puppetlabs.com>
Dave Borowitz [Tue, 30 Jun 2015 00:26:57 +0000 (17:26 -0700)]
PushCertificateParser: Add method for parsing from a stream
We intend to store received push certificates somewhere, like a
particular ref in the repository in question. For reading data back
out, it will be useful to read push certificates (without pkt-line
framing) in a streaming fashion.
Dave Borowitz [Mon, 6 Jul 2015 19:19:42 +0000 (15:19 -0400)]
BaseReceivePack: Treat all LFs as optional
Discussion on the git mailing list has concluded[1] that the intended
behavior for all (non-sideband) portions of the receive-pack protocol
is for trailing LFs in pkt-lines to be optional. Go back to using
PacketLineIn#readString() everywhere.
For push certificates specifically, we agreed that the payload signed
by the client is always concatenated with LFs even though the client
MAY omit LFs when framing the certificate for the wire. This is still
reflected in the implementation of PushCertificate#toText().
Chris Price [Tue, 7 Jul 2015 11:30:06 +0000 (12:30 +0100)]
Use local variable in RepositoryTestCase.indexState
There is a signature of the test helper method `indexState`,
in `RepositoryTestCase`, that accepts a `Repository` object
as an argument. However, there was one line of code where
this variable was not being used, and the method was instead
referring to a member variable `db`. I believe this was
probably just an oversight in a previous refactor, and
that the correct behavior is to use the variable from
the argument list. This change also has the benefit
of making it possible to convert this method to a static
method, since it no longer relies on any state from the class.
Bug: 436200
Change-Id: Iac95b046dc5bd0b3756642e241c3637f1fad3609 Signed-off-by: Chris Price <chris@puppetlabs.com>
Jonathan Nieder [Tue, 30 Jun 2015 21:42:39 +0000 (14:42 -0700)]
Throw InvalidObjectIdException from ObjectId.fromString("tooshort")
ObjectId.fromString already throws InvalidObjectIdException for most
malformed object ids, but for this kind it previously threw
IllegalArgumentException. Since InvalidObjectIdException is a child of
IllegalArgumentException, callers that catch IllegalArgumentException
will continue to work.
Change-Id: I24e1422d51607c86a1cb816a495703279e461f01 Signed-off-by: Jonathan Nieder <jrn@google.com>
For loose objects an expiration date can be set which will save too
young objects from being deleted. Add the same for packfiles. Packfiles
which are too young are not deleted.
Bug: 468024
Change-Id: I3956411d19b47aaadc215dab360d57fa6c24635e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Dave Borowitz [Wed, 17 Jun 2015 17:12:22 +0000 (13:12 -0400)]
Add a separate type for the identity in a push certificate
These differ subtly from a PersonIdent, because they can contain
anything that is a valid User ID passed to gpg --local-user. Upstream
git push --signed will just take the configuration value from
user.signingkey and pass that verbatim in both --local-user and the
pusher field of the certificate. This does not necessarily contain an
email address, which means the parsing implementation ends up being
substantially different from RawParseUtils.parsePersonIdent.
Nonetheless, we try hard to match PersonIdent behavior in
questionable cases.
Dave Borowitz [Mon, 15 Jun 2015 20:50:22 +0000 (16:50 -0400)]
PushCertificateParser: include begin/end lines in signature
The signature is intended to be passed to a verification library such
as Bouncy Castle, which expects these lines to be present in order to
parse the signature.
Dave Borowitz [Mon, 15 Jun 2015 19:48:22 +0000 (15:48 -0400)]
PushCertificateParser: throw PackProtocolException in more cases
This is the subclass of IOException already thrown by
BaseReceivePack#recvCommands when encountering an invalid value on
the wire. That's what PushCertificateParser is doing too, so use the
same subclass.
Dave Borowitz [Mon, 15 Jun 2015 19:25:14 +0000 (15:25 -0400)]
Extract a class for signed push configuration
The default behavior is to read a repository's signed push
configuration from that repo's config file, but this is not very
flexible when it comes to managing groups of repositories (e.g. with
Gerrit). Allow callers to override the configuration using a POJO.
Dave Borowitz [Mon, 15 Jun 2015 18:54:13 +0000 (14:54 -0400)]
BaseReceivePack: fix reading cert lines in command loop
Add a missing continues to prevent falling through to the command
parsing section. The first continue happens when the command list is
empty, so change the condition to see whether we have read the first
line, rather than any commands.
Fix comparison to BEGIN_SIGNATURE to use raw line with newline.
a85e817d is a slightly breaking API change to classes that were
technically public and technically released in 4.0. However, it is
highly unlikely that people were actually depending on public behavior,
since there were no public methods to create PushCertificates with
anything other than null field values, or a PushCertificateParser that
did anything other than infinite loop or throw exceptions when reading.
Change-Id: I1d0ba9ea0a347e8ff5a0f4af169d9bb18c5838d2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Terry Parker [Fri, 12 Jun 2015 19:00:36 +0000 (12:00 -0700)]
Introduce PostUploadHook to replace UploadPackLogger
UploadPackLogger is incorrectly named--it can be used to trigger any
post upload action, such as GC/compaction. This change introduces
PostUploadHook/PostUploadHookChain to replace
UploadPackLogger/UploadPackLoggerChain and deprecates the latter.
It also introduces PackStatistics as a replacement for
PackWriter.Statistics, since the latter is not public API.
It changes PackWriter to use PackStatistics and reimplements
PackWriter.Statistics to delegate to PackStatistics.
Change-Id: Ic51df1613e471f568ffee25ae67e118425b38986 Signed-off-by: Terry Parker <tparker@google.com>
Jonathan Nieder [Wed, 10 Jun 2015 22:43:48 +0000 (15:43 -0700)]
Treat CloneCommand.setBranch(null) as setBranch("HEAD")
This method is documented to take a branch name (not a possibly null
string). The only way a caller could have set null without either
re-setting to a sane value afterward or producing NullPointerException
was to also call setNoCheckout(true), in which case there would have
been no reason to set the branch in the first place.
Make setBranch(null) request the default behavior (remote's default
branch) instead, imitating C git's clone --no-branch.
Change-Id: I960e7046b8d5b5bc75c7f3688f3a075d3a951b00 Signed-off-by: Jonathan Nieder <jrn@google.com>
Jonathan Nieder [Wed, 10 Jun 2015 22:43:27 +0000 (15:43 -0700)]
Treat CloneCommand.setRemote(null) as setRemote("origin")
A non-bare clone command with null remote produces a
NullPointerException when trying to produce a refspec to fetch against.
In a bare repository, a null remote name is accepted by mistake,
producing a configuration with items like 'remote.url' instead of
'remote.<remote>.url'. This was never meant to work.
Instead, let's make setRemote(null) undo any previous setRemote calls
and re-set the remote name to DEFAULT_REMOTE, imitating C git clone's
--no-origin option.
While we're here, add some tests for setRemote working normally.
Change-Id: I76f502da5e677df501d3ef387e7f61f42a7ca238 Signed-off-by: Jonathan Nieder <jrn@google.com>
Jonathan Nieder [Wed, 10 Jun 2015 20:59:48 +0000 (13:59 -0700)]
Handle null in ProgressMonitor setters
These commands' monitor fields can never be null unless someone passes
null to setProgressMonitor. Anyone passing null probably meant to
disable the ProgressMonitor, so do that (by falling back to
NullProgressMonitor.INSTANCE) instead of saving a null and eventually
producing NullPointerException.
Change-Id: I63ad93ea8ad669fd333a5fd40880e7583ba24827 Signed-off-by: Jonathan Nieder <jrn@google.com>
Dave Borowitz [Wed, 10 Jun 2015 00:23:03 +0000 (17:23 -0700)]
Rewrite push certificate parsing
- Consistently return structured data, such as actual ReceiveCommands,
which is more useful for callers that are doing things other than
verifying the signature, e.g. recording the set of commands.
- Store the certificate version field, as this is required to be part
of the signed payload.
- Add a toText() method to recreate the actual payload for signature
verification. This requires keeping track of the un-chomped command
strings from the original protocol stream.
- Separate the parser from the certificate itself, so the actual
PushCertificate object can be immutable. Make a fair attempt at deep
immutability, but this is not possible with the current mutable
ReceiveCommand structure.
- Use more detailed error messages that don't involve NON-NLS strings.
- Document null return values more thoroughly. Instead of having the
undocumented behavior of throwing NPE from certain methods if they
are not first guarded by enabled(), eliminate enabled() and return
null from those methods.
- Add tests for parsing a push cert from a section of pkt-line stream
using a real live stream captured with Wireshark (which, it should
be noted, uncovered several simply incorrect statements in C git's
Documentation/technical/pack-protocol.txt).
This is a slightly breaking API change to classes that were
technically public and technically released in 4.0. However, it is
highly unlikely that people were actually depending on public
behavior, since there were no public methods to create
PushCertificates with anything other than null field values, or a
PushCertificateParser that did anything other than infinite loop or
throw exceptions when reading.
Dave Borowitz [Wed, 10 Jun 2015 19:47:04 +0000 (12:47 -0700)]
Allow trailing newlines in receive-pack
C git's receive-pack.c strips trailing newlines in command lists when
present[1], although send-pack.c does not send them, at least in the
case of command lists[2]. Change JGit to match this behavior.
Add tests.
This also fixes parsing of commands in the push cert, which, unlike
commands sent in the non-push case, always have trailing newlines.
The new submodule layout where GITDIR of a submodule is located at
<parent-repo-GITDIR>/modules/<submodule-path> was only used during
clone. Teach SubmoduleAddCommand to use the new layout.
Bug: 469666
Change-Id: Ie97dc0607b71499560444616f362bccee9cce515 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Jonathan Nieder [Wed, 10 Jun 2015 21:48:21 +0000 (14:48 -0700)]
submodule test: Use config.unset instead of setting to null
Most relative-URL tests for SubmoduleInitCommand carry out the following
steps:
1. add a submodule at path "sub" to the index
2. set remote.origin.url in .git/config
3. configure .gitmodules, possibly using relative URLs, and see what
happens
resolveWorkingDirectoryRelativeUrl() is meant to test the fallback when
remote.origin.url is not set, to match C git which treats the URL as
relative to the cwd in that case. To do so, in step (2) it sets
remote.origin.url to null.
However, Config.setString when taking a null value does not actually
unset that value from the configuration --- it sets it to the empty
string. This means we are testing a behavior that C git never
supported. Use Config.unset instead.
Change-Id: I7af29fbbd333a2598843d62c320093c48b2ad972 Signed-off-by: Jonathan Nieder <jrn@google.com>
* changes:
Allow setting detail message and cause when constructing most exceptions
Use message from ServiceNotAuthorizedException, ServiceNotEnabledException
dumb HTTP: Clarify AsIsFilter by introducing req and res locals
Clarify description of ServiceNotAuthorizedException
Jonathan Nieder [Tue, 9 Jun 2015 22:54:52 +0000 (15:54 -0700)]
Revert "Config: Distinguish between empty and null strings"
This reverts commit 96eb3ee3976e7e9e3e118851fa614cce8a1f7d88, which
broke Gerrit tests that set a config value to 'null', serialize the
result, deserialize, and expect 'null' from Config.getString[1].
The intent of that commit was to make it possible to distinguish between
an absent and an empty config value, which we'll have to do with a new
method.
Revert the behavior change. Keep the tests from 428cb23f2de8, since
they test the behavior more precisely than the old tests did.
[1] https://gerrit-review.googlesource.com/68452
Change-Id: Ie8042f380ea0e34e3203e1991aa0feb2e6e44641 Signed-off-by: Jonathan Nieder <jrn@google.com>
Fredrik Medley [Fri, 29 May 2015 18:04:50 +0000 (20:04 +0200)]
UploadPack: Use reachable-sha1-in-want configuration
C git 2.5 supports setting the equivalent of
RequestPolicy.REACHABLE_COMMIT with uploadpack.allowreachablesha1inwant.
Parse this into TransportConfig and use it from UploadPack. An explicitly
set RequestPolicy overrides the config, and the policy may still be
upgraded on a unidirectional connection to avoid races.
Change-Id: Id39771a6e42d8082099acde11249306828a053c0 Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com>
Jonathan Nieder [Mon, 8 Jun 2015 17:47:15 +0000 (10:47 -0700)]
Add missing # to javadoc comment
Change-Id: I351cee0ba2e77e3360846ac0c5368da3a322725c Reported-by: Markus Keller <markus_keller@ch.ibm.com> Signed-off-by: Jonathan Nieder <jrn@google.com>
Jonathan Nieder [Fri, 5 Jun 2015 23:08:55 +0000 (16:08 -0700)]
Allow lookup of multiple exact refs in one shot
exactRef(ref1, ref2, ref3) requests multiple specific refs in a single
lookup, which may be faster in some backends than looking them up one by
one.
firstExactRef generalizes getRef by finding the first existing ref from
the list of refs named. Its main purpose is for the default
implementation of getRef (finding the first existing ref in a search
path). Hopefully it can be useful for other operations that look for
refs in a search path (e.g., git log --notes=<name>), too.
Change-Id: I5c6fcf1d3920f6968b8b97f3d4c3a267258c4b86 Signed-off-by: Jonathan Nieder <jrn@google.com>
Jonathan Nieder [Fri, 5 Jun 2015 21:14:55 +0000 (14:14 -0700)]
Introduce exactRef to read a ref whose exact name is known
Unlike getRef(name), the new exactRef method does not walk the search
path. This should produce a less confusing result than getRef when the
exact ref name is known: it will not try to resolve refs/foo/bar to
refs/heads/refs/foo/bar even when refs/foo/bar does not exist.
It can be faster than both getRefs(ALL).get(name) and getRef(name)
because it only needs to examine a single ref.
A follow-up change will introduce a findRef synonym to getRef and
deprecate getRef to make the choice a caller is making more obvious
(exactRef or findRef, with the same semantics as getRefs(ALL).get and
getRefs(ALL).findRef).
Change-Id: If1bd09bcfc9919e7976a4d77f13184ea58dcda52 Signed-off-by: Jonathan Nieder <jrn@google.com>
David Pletcher [Thu, 4 Jun 2015 18:48:32 +0000 (11:48 -0700)]
Restore checkObjectCollisions flag
I am developing an offline pack verification feature based on
PackParser. The birthday collision check is a prohibitive obstacle
to performance at scale because it interacts with the repository
to perform collision checks. This CL restores the checkObjectCollisions
flag that was removed in 9638e0aa87614a6fb4f109bbeac0cde3462b9769,
while changing the flag getter and setter to protected from public as a
precaution against misuse.
Change-Id: I363cd0c9de57c5e8659cdfe2d51b17823f4fe793 Signed-off-by: David Pletcher <dpletcher@google.com>
Make JGit make the same distinction. This is in line with the current
Javadoc of getString, which claims to return "a String value from the
config, null if not found". It is more reasonable to interpret "x ="
in the above example as "found" rather than "missing".
We need to maintain the special handling of a key name with no "="
resolving to a boolean true, but "=" with an empty string is still not
a valid boolean.
Return -1 from PackWriter.Statistics.getBitmapIndexMises() when no
bitmap indices were found, to differentiate it from the case where
the bitmap indices contained all of the want/have commits.
Change-Id: I78d4600b462c19f62b347217a0b2c19eaaf3a14b Signed-off-by: Terry Parker <tparker@google.com>
Jonathan Nieder [Tue, 2 Jun 2015 23:52:21 +0000 (16:52 -0700)]
Allow setting detail message and cause when constructing most exceptions
In particular, this means a RepositoryResolver, UploadPackFactory, or
ReceivePackFactory can set a detail message for
ServiceNotAuthorizedException or ServiceNotEnabledException with
information for the client about why access is not allowed.
Change-Id: I38e1798e1e9d09b5e75cefacd9d85f25729235a9 Signed-off-by: Jonathan Nieder <jrn@google.com>
Jonathan Nieder [Tue, 2 Jun 2015 23:40:23 +0000 (16:40 -0700)]
Use message from ServiceNotAuthorizedException, ServiceNotEnabledException
When sending an error response due to ServiceNotAuthorizedException or
ServiceNotEnabledException, usually we send a default message. In the
ServiceNotEnabledException case, we use
403 Git access forbidden
except in a dumb-HTTP-specific filter where we use the servlet
container's default 403 response:
403 Forbidden
In the ServiceNotAuthorizedException case, we use the servlet
container's default 401 response:
401 Unauthorized
There is one exception: a ServiceNotEnabledException when handling a
smart HTTP /info/refs request uses the message from the exception:
403 Service not enabled
Be more consistent by always using the message from the exception. This
way, authors of a RepositoryResolver, UploadPackFactory, or
ReceivePackFactory can provide a more detailed message when appropriate.
The defaults are
401 Unauthorized
403 Service not enabled
Change-Id: Id1fe1c2042fb96487c3671c1965c8a65c4b8e1b8 Signed-off-by: Jonathan Nieder <jrn@google.com>
Jonathan Nieder [Tue, 2 Jun 2015 23:13:16 +0000 (16:13 -0700)]
Clarify description of ServiceNotAuthorizedException
This exception's detail message states
Service not permitted
and according to the Javadoc it indicates that the current user does not
have access to the service. In practice, though, callers handle this
exception by presenting a '401 Unauthorized' response to the client,
meaning that the user is unauthenticated and should authenticate.
Clarify the documentation and detail message to match the practice.
The exception message is not used anywhere except logs. No
client-visible effect intended.
Change-Id: I2c6be9cb74af932f0dcb121a381a64f2ad876766 Signed-off-by: Jonathan Nieder <jrn@google.com>
projects / jgit.git / log