consuming it directly from Maven Central.
The bundle net.i2p.crypto.eddsa 0.3.0 contains bad OSGi metadata,
earlier it was repackaged in Orbit tweaking its mandatory dependency to
sun.security.x509 to an optional dependency.
This project seems to be orphaned, probably because Java 15 added
support for eddsa with JEP339 [1].
This repackaged bundle is no longer available after Orbit was renovated
[2] to consume the vast majority of bundles directly from Maven Central
without repacking them. Hence we have to workaround this (probably
false) mandatory dependency. For that export an empty dummy package
"sun.security.x509" to satisfy OSGi.
[1] https://openjdk.org/jeps/339
[2] https://github.com/eclipse-orbit/orbit-simrel/issues/15
Change-Id: I2267e15823ebce6cf1d448e1e16a129f703e0f80
File#getAbsoluteFile is non-nullable, so this check can never trigger.
Worse, getAbsoluteFile can throw an exception such as
InvalidPathException, and since this call isn't in the "try" block
that checks for that, the exception would then escape the getSession
call.
Noticed because the exception is being thrown in googlesource.com's
custom SshdSessionFactory, causing incoming ssh requests to fail
(noticed using internal tests).
Change-Id: I57f2d5e497ff678b17573f79827b6e1d9a6c9b9f
Signed-off-by: Jonathan Nieder <jrn@google.com>
The condition looks suspicious, as in case of
(hasElement==null && hasNext())
the check will generate a NPE
Change-Id: I267f9df6746393d72f5102bd5271441422550968
Support PKCS#11 HSMs (like YubiKey PIV) for SSH authentication.
Use the SunPKCS11 provider as described at [1]. This provider
dynamically loads the library from the PKCS11Provider SSH configuration
and creates a Java KeyStore with that provider. A Java CallbackHandler
is needed to feed PIN prompts from the KeyStore into the JGit
CredentialsProvider framework. Because the JGit CredentialsProvider may
be specific to a SSH session but the PKCS11Provider may be used by
several sessions, the CallbackHandler needs to be configurable per
session.
PIN prompts respect the NumberOfPasswordPrompts SSH configuration. As
long as the library asks only for a PIN, we use the KeyPasswordProvider
to prompt for it. This gives automatic integration in Eclipse with the
Eclipse secure storage, so a user has even the option to store the PIN
there. (Eclipse will then ask for the secure storage master password on
first access, so the usefulness of this is debatable.)
By default the provider uses the first PKCS#11 token (slot list index
zero). This can be overridden by a non-standard PKCS11SlotListIndex
ssh configuration entry. (For OpenSSH interoperability, also set
"IgnoreUnknown PKCS11SlotListIndex" in the SSH config file then.)
Once loaded, the provider and its shared library and the keys
contained remain available until the application exits.
Manually tested using SoftHSM. See file manual_tests.txt. Kudos to
Christopher Lamb for additional manual testing with a real YubiKey,
also on Windows.[2]
[1] https://docs.oracle.com/en/java/javase/11/security/pkcs11-reference-guide1.html
[2] https://www.eclipse.org/forums/index.php/t/1113295/
Change-Id: I544c97e1e24d05e28a9f0e803fd4b9151a76ed11
Signed-off-by: Thomas Wolf <twolf@apache.org>
This fixes all the javadoc warnings, stops ignoring doclint 'missing'
category and fails the build on javadoc warnings for public and
protected classes and class members.
Since javadoc doesn't allow access specifiers when specifying doclint
configuration we cannot set `-Xdoclint:all,-missing/private`
hence there is no simple way to skip private elements from doclint.
Therefore we check javadoc using the Eclipse Java compiler
(which is used by default) and javadoc configuration in
`.settings/org.eclipse.jdt.core.prefs` files.
This allows more fine grained configuration.
We can reconsider this when javadoc starts supporting access specifiers
in the doclint configuration.
Below are detailled explanations for most modifications.
@inheritDoc
===========
doclint complains about explicits `{@inheritDoc}` when the parent does
not have any documentation. As far as I can tell, javadoc defaults to
inherit comments and should only be used when one wants to append extra
documentation from the parent. Given the parent has no documentation,
remove those usages which doclint complains about.
In some case I have moved up the documentation from the concrete class
up to the abstract class.
Remove `{@inheritDoc}` on overriden methods which don't add additional
documentation since javadoc defaults to inherit javadoc of overridden
methods.
@value to @link
===============
In PackConfig, DEFAULT_SEARCH_FOR_REUSE_TIMEOUT and similar are forged
from Integer.MAX_VALUE and are thus not considered constants (I guess
cause the value would depends on the platform). Replace it with a link
to `Integer.MAX_VALUE`.
In `StringUtils.toBoolean`, @value was used to refer to the
`stringValue` parameter. I have replaced it with `{@code stringValue}`.
{@link <url>} to <a>
====================
@link does not support being given an external URL. Replaces them with
HTML `<a>`.
@since: being invalid
=====================
org.eclipse.jgit/src/org/eclipse/jgit/util/Equality.java has an invalid
tag `@since: ` due to the extra `:`. Javadoc does not complain about it
with version 11.0.18+10 but does with 11.0.19.7. It is invalid
regardless.
invalid HTML syntax
===================
- javadoc doesn't allow <br/>, <p/> and </p> anymore, use <br> and <p>
instead
- replace <tt>code</tt> by {@code code}
- <table> tags don't allow summary attribute, specify caption as
<caption>caption</caption> to fix this
doclint visibility issue
========================
In the private abstract classes `BaseDirCacheEditor` and
`BasePackConnection` links to other methods in the abstract class are
inherited in the public subclasses but doclint gets confused and
considers them unreachable. The HTML documentation for the sub classes
shows the relative links in the sub classes, so it is all correct. It
must be a bug somewhere in javadoc.
Mute those warnings with: @SuppressWarnings("doclint:missing")
Misc
====
Replace `<` and `>` with HTML encoded entities (`< and `>`).
In `SshConstants` I went enclosing a serie of -> arrows in @literal.
Additional tags
===============
Configure maven-javad0c-plugin to allow the following additional tags
defined in https://openjdk.org/jeps/8068562:
- apiNote
- implSpec
- implNote
Missing javadoc
===============
Add missing @params and descriptions
Change-Id: I840056389aa59135cfb360da0d5e40463ce35bd0
Also-By: Matthias Sohn <matthias.sohn@sap.com>
Bump the version numbers in pom.xml and in MANIFESTs, and in the bazel
WORKSPACE file. Update the target platforms. Remove work-arounds in
org.eclipse.jgit.ssh.apache that are no longer necessary.
The release notes for Apache MINA sshd are at [1].
[1] https://github.com/apache/mina-sshd/blob/master/docs/changes/2.10.0.md
Bug: 581770
Change-Id: Id27e73e9712b7865353c9b32b5b768f6e998b05e
Signed-off-by: Thomas Wolf <twolf@apache.org>
The previous implementation mixed nano seconds (elapsed) and milli
seconds (remaining) without conversion.
Change-Id: I9e1654afa47fa32c94808af3b2dd0418a372fb00
Check the key length before adding; the addition might overflow.
Change-Id: Icde7c92a5bb267fdd869d5a1c0842967ab1a7fd9
Signed-off-by: Thomas Wolf <twolf@apache.org>
Ensure that there is always a list of signature factories in public key
authentication. For keys loaded directly, Apache MINA sshd will use the
(always set) list from the SSH session by default, but for keys from an
SSH agent it won't and instead consider the list set locally on the
UserAuthPublicKey instance. Only that one is null by default, and then
Apache MINA sshd just uses the key type as signature type. Which for
RSA keys from an agent is the "ssh-rsa" signature, i.e., the deprecated
SHA1 signature.
Fix this by explicitly propagating the list from the session to the
UserAuthPublicKey instance if not set already.
Upstream issue is SSHD-1272.[1]
[1] https://issues.apache.org/jira/browse/SSHD-1272
Bug: 580073
Change-Id: Id7a783f19d06c9e7c8494b1fbf7465d392ffc366
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
When authentication fails, JGit produces an exception with an error
message telling the user that it could not log in (including the host
name). The causal chain has an SshException from Apache MINA sshd with
message "No more authentication methods available".
This is not very helpful. The user was left without any indication why
authentication failed.
Include in the exception message a log of all attempted authentications.
That way, the user can see which keys were tried, in which order and
with which signature algorithms. The log also reports authentication
attempts for gssapi-with-mic or password authentication. For
keyboard-interactive Apache MINA sshd is lacking a callback interface.
The way Apache MINA sshd loads keys from files, the file names are lost
in higher layers. Add a mechanism to record on the session for each
key fingerprint the file it was loaded from, if any. That way the
exception message can refer to keys by file name, which is easier to
understand by users than the rather cryptic key fingerprints.
Bug: 571390
Change-Id: Ic4b6ce6b99f307d5e798fcc91b16b9ffd995d224
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Parse the value from the ssh config and if set use it when connecting.
Change-Id: I85b44c9468a5027602375706612c46ea7a99b2bd
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
An SSH agent might contain keys that Apache MINA sshd cannot handle.
Pageant for instance can contain ed448 keys, which are not implemented
in OpenSSH or in Apache MINA sshd.
When an agent delivers such keys, simply skip (and log) them. That way,
we can work with the remaining keys. Otherwise a single unknown key in
the agent would break pubkey authentication.
Change-Id: I3945d932c7e64b628465004cfbaf10f4dc05f3e4
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Add parsing of the config. Implement the SSH agent protocol for adding
a key. In the pubkey authentication, add keys to the agent as soon as
they've been loaded successfully, before even attempting to use them
for authentication. OpenSSH does the same.
Bug: 577052
Change-Id: Id1c08d9676a74652256b22281c2f8fa0b6508fa6
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Win32-OpenSSH uses a named Windows pipe for communication. Implement
a connector for this mechanism using JNA. Choose the appropriate
connector based on the setting of the 'identityAgent' parameter.
Bug: 577053
Change-Id: I205f07fb33654aa18ca5db92706e65544ce38641
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
If an SSH agent is used but "IdentitiesOnly yes" is set, only those
keys from the agent that correspond to one of the keys explicitly given
via an IdentityFile directive are to be used.
Implement this by filtering the list of keys obtained from the agent
against the list of IdentityFiles, each entry suffixed with ".pub".
Load the public keys from these files, and ignore all other keys from
the agent. Keys without ".pub" file are also ignored.
Apache MINA sshd has no operation to load only the public key from a
private key file, so we have to rely on *.pub files.
Bug: 577053
Change-Id: I75c2c0b3ce35781c933ec2944bd6da1b94f4caf9
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Handle the 'none' value, and change the value to select Pageant to
something that looks like an absolute UNC path name to avoid it's
handled as an relative path name.
Bug: 577053
Change-Id: I4ccf047abbc1def50e2782319e4fa7c744069401
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Update version in root pom.xml, adapt code & manifests. Bump the
dependency in the bazel build.
Update Orbit to I20220105095044 to get Apache MINA sshd 2.8.0 and
regenerate all target platforms.
Bug: 577542
Change-Id: Iefc02ceda8a9b0683f49aa8059999a5486d1f322
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
SSHD-1231[1] may lead to exceptions when trying to authenticate first
with an RSA key that is rejected by the server. The upstream fix is a
one-liner but unfortunately didn't make it into Apache MINA sshd 2.8.0.
Incorporate the upstream fix in JGitPublicKeyAuthentication, and add
a test case for this.
[1] https://issues.apache.org/jira/browse/SSHD-1231
Bug: 577545
Change-Id: Ia744cd4aa569bccd937c855f3bb45c0116915bad
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Skip javadoc generation for test bundles.
Use character entities < and > for < and > outside of
code-formatted spans.
Change-Id: I66e1a1dc98881c61f93c9e5561c5513896b2ba01
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Since OpenSSH 7.8, the ProxyJump directive accepts the value "none"[1]
to override and clear a setting that might otherwise be contributed by
another (wildcard) host entry.
[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2869
Change-Id: Ia35e82c6f8c58d5c6b8040cda7a07b220f43fc21
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
According to Spotbugs, that's better practice. It's questionable
whether it makes a big difference, though, especially since the
hash is the cryptographically weak SHA1.
Change-Id: Id293de2bad809d9cc19230bd720184786dc6c226
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Once a factory supports different SSH agents on the same platform,
which is planned for Windows once we use Apache MINA sshd 2.8.0,
client code may need to have a way to specify which SSH agent shall
be used when the SSH config doesn't define anything.
Add a mechanism by which a ConnectorFactory can tell what Connectors
it may provide. Client code can use this to set the identityAgent
parameter of ConnectorFactory.create() to the wanted default if it
would be null otherwise.
A ConnectorDescriptor is a pair of strings: an internal name, and a
display name. The latter is included because client code might want to
communicate agent names to the user, be it in error messages or in some
chooser dialog where a user could define which of several alternative
SSH agents should be used as default. The internal name is intended to
be used in the IdentityAgent directive in ~/.ssh/config.
Also make the ConnectorFactory discovered via the ServiceLoader
accessible and overrideable. Provide static get/setDefault() methods,
similar to the SshSessionFactory itself.
Change-Id: Ie3d077395d32dfddc72bc8627e92b23636938182
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Apache MINA sshd has simpler API for reading directories, and it has a
functional interface suitable for us. So no need to use our own
interface, or to deal with low-level abstractions like CloseableHandle.
Change-Id: Ic125c587535670504983f157a696b41ed6a76bb7
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Add a simple SSH agent connector using JNA. Include com.sum.jna and
com.sun.jna.platform in the target platform.
JNA is used to communicate through Unix domain sockets with ssh-agent,
and if on Windows, to communicate via shared memory with Pageant.
The new bundle o.e.j.ssh.apache.agent is an OSGi fragment so that
the java.util.ServiceLoader can find the provided factory without
further ado in OSGi environments.
Adapt both maven and bazel builds to include the new bundle.
Manually tested on OS X, CentOS 7, and Win10 with Pageant 0.76. Tested
by installing JGit built from this change into freshly downloaded
Eclipse 2021-12 M1, and then doing git fetches via SSH with different
~/.ssh/config settings (explicit IdentityFile, without any but a key in
the agent, with no keys and a key in the agent and IdentitiesOnly=yes
(must fail)).
Bug: 541274
Bug: 541275
Change-Id: I34e85467293707dbad1eb44d1f40fc2e70ba3622
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Add interfaces Connector and ConnectorFactory. A "connector" is just
something that knows how to connect to an ssh-agent and then can make
simple synchronous RPC-style requests (request-reply).
Add a way to customize an SshdSessionFactory with a ConnectorFactory.
Provide a default setup using the Java ServiceLoader mechanism to
discover an ConnectorFactory.
Implement an SshAgentClient in the internal part. Unfortunately we
cannot re-use the implementation in Apache MINA sshd: it's hard-wired
to Apache Tomcat APR, and it's also buggy.
No behavior changes yet since there is nothing that would provide an
actual ConnectorFactory. So for Apache MINA sshd, the SshAgentFactory
remains null as before.
Change-Id: I963a3d181357df2bdb66298bc702f2b9a6607a30
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Explain in the JSch bundle that it is essentially unmaintained. Add
descriptions in both bundles explaining how to use it, or how to use
an alternate implementation.
Change-Id: Idaf46c33b14543279f78a55cb7c6bd42b06ee6b8
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
In Java 11 type arguments for anonymous subclasses can be inferred
and don't need to be specified. This resolves a number of compiler
warnings.
Change-Id: I55eff3babb7628aa0627085e65a1b45eb12c2cd3
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Since upstream changed the method profile to throw Exception it's not
necessary anymore to re-throw as IOException.
Change-Id: I31afab4f6e1a2f0feef79e6abced20d0ca1c493b
Since the introduction of the rsa-sha2-512 and rsa-sha2-256 signature
types, the key type for RSA is no longer automatically the signature
algorithm. We re-order the list for the host key proposal such that
keys we already have are preferred; this minimizes warnings about new
host keys. When doing so, put all of rsa-sha2-512, rsa-sha2-256, and
ssh-rsa at the front, in that order, not just ssh-rsa.
This ensures that we do prefer RSA keys if we already have an RSA host
key, but at the same time we still prefer the stronger signature
algorithms over the weaker and deprecated SHA1-based ssh-rsa signature.
It also helps avoid a bug found in some Github versions where the Github
SSH server uses a rsa-sha2-512 signature even though ssh-rsa was
negotiated.[1]
[1] https://www.eclipse.org/forums/index.php/t/1108282/
Bug: 574635
Change-Id: I0a49dcfa0c2c93f23118c983cd0bc9e5a467d886
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Make the used KEX algorithms configurable via the ssh config. Also
implement adding algorithms not in the default set: since sshd 2.6.0
deprecated SHA1-based algorithms, it is possible that the default set
has not all available algorithms, so adding algorithms makes sense.
This enables users who have to use a git server that only supports
old SHA1-based key exchange methods to enable those methods in the
ssh config:
KexAlgorithms +diffie-hellman-group1-sha1
There are two more SHA1 algorithms that are not enabled by default:
diffie-hellman-group14-sha1 and diffie-hellman-group-exchange-sha1.
KeyAlgorithms accepts a comma-separated list of algorithm names.
Since adding algorithms is now supported, adapt the handling of
signature algorithms, too. Make sure that definitions for the KEX
exchange signature (HostKeyAlgorithms) don't conflict with the
definition for signatures for pubkey auth (PubkeyAcceptedAlgorithms).
HostKeyAlgorithms updates the signature factories set on the session
to include the default factories plus any that might have been added
via the SSH config. Move the handling of PubkeyAcceptedAlgorithms
from the client to the JGitPubkeyAuthentication, where it can be done
only if pubkey auth is attempted at all and where it can store its
adapted list of factories locally.
Bug: 574636
Change-Id: Ia5d5f174bbc8e5b41e10ec2c25216d861174e7c3
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Update
- com.google.gson to 2.8.7.v20210624-1215
- javaewah to 1.1.12.v20210622-2206
- org.apache.sshd.osgi to 2.7.0.v20210623-0618
- org.apache.sshd.sftp to 2.7.0.v20210623-0618
- org.tukaani.xz to 1.9.0.v20210624-1259
- Apache MINA sshd to 2.7.0
- Remove work-arounds for problems resolved upstream since 2.6.0, and
adapt to upstream API changes.
- update DEPENDENCIES.
CQ: 23469
CQ: 23470
CQ: 23496
CQ: 23497
CQ: 23498
Bug: 574220
Change-Id: I898b216c3492f8488fbf25fa4b49f1250f86f3c8
Also-by: David Ostrovsky <david@ostrovsky.org>
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Apache MINA sshd doesn't log all values, but it'd be very helpful to
debug KEX problems.
Change-Id: I5a19023c929f39caccde489d51a6fdca711fe5ff
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Similar to git config file reading lock the file only when writing.
There may still be lock conflicts on writing, but those in the worst
case result in an entry not being added and thus being asked for later
again.
Because the OpenSshServerkeyDatabase and its HostKeyFiles may be (and
usually are) shared between different SSH sessions, we still need to
ensure in-process mutual exclusion.
Bug: 559548
Change-Id: I4af97628deff9eaac2520576917c856949f2680d
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Apache MINA sshd has an implementation of this, but it doesn't comply
to RFC 8308 [1] and it is buggy. (See SSHD-1141 [2].)
Add a simpler KexExtensionHandler and if the server sends extension
server-sig-algs, use its value to re-order the chosen signature
algorithms such that the algorithms the server announced as supported
are at the front.
If the server didn't tell us anything, don't do anything. RFC 8308
suggests for RSA to default to ssh-rsa, but says once rsa-sha2-* was
"widely enough" adopted, defaulting to that might be OK.
Currently we seem to be in a transition phase; Fedora 33 has already
disabled ssh-rsa by default, and openssh is about to do so. Whatever
we might do without info from the server, it'd be good for some servers
and bad for others. So don't do anything and let the user re-order via
ssh config PubkeyAcceptedAlgorithms on a case-by-case basis.
[1] https://tools.ietf.org/html/rfc8308
[2] https://issues.apache.org/jira/browse/SSHD-1141
Bug: 572056
Change-Id: I59aa691a030ffe0fae54289df00ca5c6e165817b
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
For RSA keys, there may be several configured signature algorithms:
rsa-sha2-512, rsa-sha2-256, and ssh-rsa. Upstream sshd has bug
SSHD-1105 [1] and always and unconditionally uses only the first
configured algorithm. With the default order, this means that it cannot
connect to a server that knows only ssh-rsa, like for instance Apache
MINA sshd servers older than 2.6.0.
This affects for instance bitbucket.org or also AWS Code Commit.
Re-introduce our own pubkey authenticator that fixes this.
Note that a server may impose a penalty (back-off delay) for subsequent
authentication attempts with signature algorithms unknown to the server.
In such cases, users can re-order the signature algorithm list via the
PubkeyAcceptedAlgorithms (formerly PubkeyAcceptedKeyTypes) ssh config.
[1] https://issues.apache.org/jira/browse/SSHD-1105
Bug: 572056
Change-Id: I7fb9c759ab6532e5f3b6524e9084085ddb2f30d6
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Apache MINA sshd 2.6.0 appears to use only the first appropriate
public key signature algorithm for a particular key. See [1]. For
RSA keys, that is rsa-sha2-512. This breaks authentication at servers
that only know the older (and deprecated) ssh-rsa algorithm.
With PubkeyAcceptedAlgorithms, users can re-order algorithms in
the ssh config file per host, if needed. Setting
PubkeyAcceptedAlgorithms ^ssh-rsa
will put "ssh-rsa" at the front of the list of algorithms, and then
authentication at such servers with RSA keys works again.
[1] https://issues.apache.org/jira/browse/SSHD-1105
Bug: 572056
Change-Id: I86c3b93f05960c68936e80642965815926bb2532
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Re-enable DSA, DSA_CERT, and RSA_CERT public key authentication.
DSA is discouraged for a long time already, but it might still be
way too disruptive to completely drop it. RSA is discouraged for
far less long, and dropping that would be really disruptive.
Adapt to the changed property handling. Remove work-arounds for
shortcomings of earlier sshd versions.
Use Orbit I20210203173513, which includes sshd 2.6.0. This also bumps
apache.httpclient to 4.5.13 and apache.httpcore to 4.4.14.
Change-Id: I2d24a1ce4cc9f616a94bb5c4bdaedbf20dc6638e
Signed-off-by: David Ostrovsky <david@ostrovsky.org>
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Make all transports request protocol V2 when fetching. Depending on
the transport, set the GIT_PROTOCOL environment variable (file and
ssh), pass the Git-Protocol header (http), or set the hidden
"\0version=2\0" (git anon). We'll fall back to V0 if the server
doesn't reply with a version 2 answer.
A user can control which protocol the client requests via the git
config protocol.version; if not set, JGit requests protocol V2 for
fetching. Pushing always uses protocol V0 still.
In the API, there is only a new Transport.openFetch() version that
takes a collection of RefSpecs plus additional patterns to construct
the Ref prefixes for the "ls-refs" command in protocol V2. If none
are given, the server will still advertise all refs, even in protocol
V2.
BasePackConnection.readAdvertisedRefs() handles falling back to
protocol V0. It newly returns true if V0 was used and the advertised
refs were read, and false if V2 is used and an explicit "ls-refs" is
needed. (This can't be done transparently inside readAdvertisedRefs()
because a "stateless RPC" transport like TransportHttp may need to
open a new connection for writing.)
BasePackFetchConnection implements the changes needed for the protocol
V2 "fetch" command (stateless protocol, simplified ACK handling,
delimiters, section headers).
In TransportHttp, change readSmartHeaders() to also recognize the
"version 2" packet line as a valid smart server indication.
Adapt tests, and run all the HTTP tests not only with both HTTP
connection factories (JDK and Apache HttpClient) but also with both
protocol V0 and V2. The SSH tests are much slower and much more
focused on the SSH protocol and SSH key handling. Factor out two
very simple cloning and pulling tests and make those run with
protocol V2.
Bug: 553083
Change-Id: I357c7f5daa7efb2872f1c64ee6f6d54229031ae1
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
If oldLine is null #updateModifiedServerKey shouldn't be called since it
would derefence it. Spotbugs raised this as problem
RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE. Fix it by checking if
oldLine is null before calling #updateModifiedServerKey.
Change-Id: I8a2000492986e52ce7dbe25f48b321c05fd371e4
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This reverts commit f802f06e7f.
I had misunderstood how protocol V2 works. This implementation only
works if the negotiation during fetch is done in one round.
Fixing this is substantial work in BasePackFetchConnection. Basically
I think I'd have to change back negotiate to the V0 version, and have
a doFetch() that does
if protocol V2
doFetchV2()
else
doFetchV0()
with doFetchV0 the old code, and doFetchV2 completely new.
Plus there would need to be a HTTP test case requiring several
negotiation rounds.
This is a couple of days work at least, and I don't know when I will
have the time to revisit this. So although the rest of the code is
fine I prefer to back this out completely and not leave a only half
working implementation in the code for an indeterminate time.
Bug: 553083
Change-Id: Icbbbb09882b3b83f9897deac4a06d5f8dc99d84e
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Make all transports request protocol V2 when fetching. Depending on
the transport, set the GIT_PROTOCOL environment variable (file and
ssh), pass the Git-Protocol header (http), or set the hidden
"\0version=2\0" (git anon). We'll fall back to V0 if the server
doesn't reply with a version 2 answer.
A user can control which protocol the client requests via the git
config protocol.version; if not set, JGit requests protocol V2 for
fetching. Pushing always uses protocol V0 still.
In the API, there is only a new Transport.openFetch() version that
takes a collection of RefSpecs plus additional patterns to construct
the Ref prefixes for the "ls-refs" command in protocol V2. If none
are given, the server will still advertise all refs, even in protocol
V2.
BasePackConnection.readAdvertisedRefs() handles falling back to
protocol V0. It newly returns true if V0 was used and the advertised
refs were read, and false if V2 is used and an explicit "ls-refs" is
needed. (This can't be done transparently inside readAdvertisedRefs()
because a "stateless RPC" transport like TransportHttp may need to
open a new connection for writing.)
BasePackFetchConnection implements the changes needed for the protocol
V2 "fetch" command (simplified ACK handling, delimiters, section
headers).
In TransportHttp, change readSmartHeaders() to also recognize the
"version 2" packet line as a valid smart server indication.
Adapt tests, and run all the HTTP tests not only with both HTTP
connection factories (JDK and Apache HttpClient) but also with both
protocol V0 and V2. Do the same for the SSH transport tests.
Bug: 553083
Change-Id: Ice9866aa78020f5ca8f397cde84dc224bf5d41b4
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Validate the extra headers and log but otherwise ignore invalid
headers. An empty http.extraHeader starts the list afresh.
The http.userAgent is restricted to printable 7-bit ASCII, other
characters are replaced by '.'.
Moves a support method from the ssh.apache bundle to HttpSupport in
the main JGit bundle.
Bug:541500
Change-Id: Id2d8df12914e2cdbd936ff00dc824d8f871bd580
Signed-off-by: James Wynn <james@jameswynn.com>
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Use a dedicated exception class to be able to detect this case in the
SshdSessionFactory and skip the generic SshException in that case.
Change-Id: I2a0bacf47bae82f154a0f4e79efbb2af2a17d0cf
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Matthias Sohn