| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Add a job to run a build with Java 7.
The job currently only runs on Linux.
In order to run on Java 7, an old Ant version is downloaded and
installed. We use moxie+ant for this, so we build with moxie.
|
|
|
|
|
| |
Currently that is Ubuntu 18.04 and Windows Server 2019.
https://help.github.com/en/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners
|
|
|
|
|
| |
We cannot build with Ant on GitHub since the provided Ant
version does not run on Java 7.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
I actually don't know if it is needed for the manager and fedclient,
but right now I'm going with better safe than sorry.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Adjust the version of JaCoCo down to 0.8.4 and the version
of parboiled-java up to 1.3.1. They need to match because both
use ASM. This combination has the same dependency on ASM: 7.1.
And it seems to work, at least the docs get generated and the
`moxie test` doesn't fail building the report anymore.
|
|
|
|
|
|
|
|
|
| |
With the feature of passwords getting automatically
upgraded to a hashed version, the default `admin`
password in the test-users file will get stored
as MD5 hashed during test execution. Commit this
change, so that the file isn't always showing up
as changed.
|
| |
|
|
|
|
| |
Running `moxie test` will crash under Java 11 with JaCoCo 0.7.8.
|
|\
| |
| | |
Two fixes: broken links to docs and preferred language selection
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Due to a wrong comparison, when loading the preferred locale in the
user preferences page, in cases like `zh_CN` or `de_DE` the wrong
locale would be chosen.
As with too many things, the code is duplicated on the `UserPage`
and the `EditUserPage`. And they differ. So extract the choosing of
the preferred language for display into a method in the (more up-to-date)
`UserPage` and call that from the `EditUserPage`.
|
|/
|
|
|
|
|
|
| |
If, for example, an external site links to a docs page or a specific
doc page, and the branch that link points to is no longer existing,
an internal error happens due to a NPE.
The NPE is guarded against and a No Docs page is returned.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Renames `static final` variables according to convention to be in all
upper case. That makes it easier to see that in an `equals` comparison
the final variable should come first as it will not trigger a NPE.
Also strip parameters from the URL when extracting the repository
name from it. Parameters can not be part of a repository name, and
this way an empty repository name can be detected.
Fixes #1092
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SshDaemonTest would fail under Windows. That is because JGit looks
at the `GIT_SSH` environment variable. If it is set, the tool the variable
is pointing to is used for the SSH connection. This is a problem when
it is set to "Plink" under Windows, because Plink will not recognize the
server key and will not find it in the registry, cached as a known host.
Since a test can/should not add the key to the registry but simply wants
to ignore it, but there is no way to tell Plink to do so, the tests would
fail.
This patch filters the `GIT_SSH` environment variable from JGit's
`SystemReader`, so that the internal SSH client is used.
|
|\
| |
| |
| |
| |
| |
| | |
Update dependencies MINA to 2.0.21 and SSHD to 1.2.0
Update SSHD to fix an issue with hmac-sha2-512. This resolves problems with clients that prefer SHA-512 over SHA-256.
This also updates the dependency on SLF4J to the latest version, as the updated dependency on MINA did also bring in higher SLF4J versions.
|
| | |
|
| | |
|
| | |
|
|/
|
|
| |
This includes a fix in MINA to a CVE.
|
|
|
|
|
|
|
|
| |
To support the new PBKDF2 password hashing, the Bouncy Castle provider
needs to be updated to a version that supports PBKDF2 with HMAC SHA265.
The current version doesn't have PBKDF2WithHmacSHA265, and neither does
Java 7, so that under Java 7 it can not be used. This update enables
the new password hashing under Java 7, too.
|
|
|
|
|
| |
Currently the tests cannot run as no Redis is available. Needs to be
fixed at some time.
|
|
|
|
|
| |
They will need to be called with the classpath and main class now,
instead of simply using the Jar.
|
|\
| |
| | |
Added javax.activation dependency
|
| |
| |
| |
| |
| | |
Update the dependency to the recommended JAF stand-alone
com.sun.activation:javax.activation:1.2.0
|
| |
| |
| |
| | |
thanks to this dependency, one can start gitblit with java 9 without using deprecated internal module --add-modules java.activation
|
| |
| |
| |
| |
| |
| |
| |
| | |
When GitBlit server did not start properly, is running but couldn't
start the `PluginManager`, then stopping the server via the `--stop`
argument on the command line resulted in a NullpointerException.
Which left the server running. Now this is prevented and the server
will actually shut down.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The (moxie and other) Launcher do not work with Java 9 and later anymore.
It used to dynamically extend the classpath, misusing an internal
interface of the `URLClassLoader`. This is no longer possible since Java 9,
which closed that path and does not offer any way to dynamically extend
the classpath during runtime.
So the choice is between providing one large Jar with everything in it,
providing a Jar that has the Jars in `ext` listed explicitly in its
manifest, and specifying the classpath on the command line where
the `ext` directory can be added and all contained jar files will
be put on the classpath.
The motivation for the Launcher class was to be able to simply drop
new jar files into a directory and they will be picked up at the
application start, without having to specify a classpath. We opt
for solution three here. This way jar files can still be dropped
into the ext directory, albeit the directory needs to be added to
the classpath on the command line. Unfortunately using a wildcard
is not possible in the manifest file. We change the calls in the
script files accordingly. This seems like a good compromise,
since no one will run the application manually typing the whole
commandline anyway.
This also does away with the splash screen, by the way. Again,
doesn't seem like a big loss, as I don't think it was ever shown
for the Authority.
Personally, I am not convinced that it is the best way, because
I don't really think that the use case of dropping whatever jar
files into the `ext` directory is a valid one that happened a lot.
This does not yet fix the client programs, which still use a
Launcher. Maybe for them a all-in-one Jar is a better solution.
Fixes #1262
Fixes #1294
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With three versions about to be supported right now
it is getting more important to know which Java version is
used when building and testing Gitblit, and which Java
version is used to run Gitblit.
So have the Moxie build report the javac version, and the
JVM version that Moxie is running on. These might be
different.
The `GitBlitServer` will print the Java version and vendor,
so that it gets visible if a user would paste a log output
for analysis.
|
| | |
|
| |
| |
| |
| |
| | |
This uses the Trusty (14.04) image since that in the only one
where all three JDKs are available.
|
|\ \ |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Integrate the `PasswordHash` class and subclass in the user
and password editing and authentication. Replaces the old code and
the previous `SecurePasswordHashingUtils` class.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Integrate the work of pingunaut to add support for PBKDF2 password
hashing. A new class `PasswordHashPbkdf2` is added, which builds
on his `SecurePasswordHashUtils` class, but makes it a subclass
of `PasswordHash`. This will replace the original class when
integrating the new PasswordHash way into GitBlit.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Instead of having to deal with the implementation details of hashing
and verifying passwords in multiple places, have a central unit
be responsible for it. Otherwise we need to edit three different places
when adding a new hashing scheme.
With this class adding a new hashing scheme just requires creating a
new subclass of `PasswordHash` and registering its type in the enum
`PasswordHash.Type`.
The rest of the code will use a common interface for all hashing
schemes and doesn't need to be changed when a new one is added.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Addresses #1166
|
| | | |
|