When pushing to an HTTP server using the C git client, I observed a
certificate lacking a pushee field. Handle this gracefully in the
parser.

Change-Id: I7f3c5fa78f2e35172a93180036e679687415cac4

The old one didn't take an argument; the new one includes the field
name.

Change-Id: I175dc75dcdd05ba6fdec315c04c79550cfdc2342

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.

Change-Id: I70de313b1ae463407b69505caee63e8f4e057ed4

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().

[1] http://thread.gmane.org/gmane.comp.version-control.git/273175/focus=273412

Change-Id: I817231c4d4defececb8722142fea18ff42e06e44

Change-Id: I25f3a5582a45dd0ec8f78f5daf74c2203797a184

Change-Id: Ic0156a7d65d99881ef27801fcce7754594c436f0

Add test for this case in both the enabled and disabled cases.

Change-Id: If9d12192a2dc9f9dd1eac9844b5a7b0edadc0b34

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.

Change-Id: I37714ce7372ccf554b24ddbff56aa61f0b19cbae

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.

Change-Id: I22097bead2746da5fc53419f79761cafd5c31c3b

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.

Change-Id: I1d323909ffe70757ea56e511556080695b1a0c11

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.

Change-Id: Ib8f33e75daa0b2fbd000a2c4558c01c014ab1ce5

- 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.

Change-Id: I5382193347a8eb1811032d9b32af9651871372d0

Reference equality (!= or ==) cannot be used to check for
String equality. String objects are not necessarily interned
to the same instance.

Use .isEmpty() since the function only cares about an empty
string and does not need to test a specific string value.

Change-Id: If530cb59666a8196d57d2348c893706a517ea541

Change-Id: I319ee4e99462598bf6a934b1efc7939bc4b057a5

This was missed in change I249869cadb2d55aef016371b9311b8583591b9cf

Change-Id: I19c9d4c04b6aa92b9e04c192dee70775d6985b58
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Push certificates ("git push --signed") have been part of
git-core since version 2.2.0 (released Nov 26 2014). We also
want to support that feature.

This is not complete and is lacking the actual functionality
to validate the signature for now.

Change-Id: I249869cadb2d55aef016371b9311b8583591b9cf
Signed-off-by: Stefan Beller <sbeller@google.com>