| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: I2eccac9b3dfedf0baa03616b7af455c0ec7768d3
|
|
|
|
| |
Change-Id: I5eda0539314629c0f5900775dd4e5de0bf4e7de5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Change-Id: Iffcd0fbd7 has involuntarily triggered the
creation of a new HTTP Session for every invocation a Git-over-HTTP
request.
All came from the mistake of tracing the HTTP session instead
of the Gerrit session in the audit record.
The HTTP Servlet API specs say that any attempt to access
the current session of an incoming request would result
in the creation of a brand-new session.
The session involuntarily created also had an expiry time
equal to zero, which prevented the session housekeeper
to reclaim them later on, even though they were unused.
The consequence of creating an empty session for every
Git-over-HTTP request isn't immediately tangible, because
the session is empty and doesn't occupy a significant
amount of memory. However, longer-term, the in-memory
hashtable that records all the sessions, each one using
750 bytes on average, will be causing the overload
of the JVM heap and the crash of the process because of
lack of available memory.
Use the correct Gerrit session-id, retrieving
from the Provider<WebSession> the proper session, if active
and logged in, and make sure in tests that no HTTP sessions
are created as a result of a Git-over-http request.
Bug: Issue 13858
Change-Id: I8c086fed54b196c3f46fa88ac78c127784524d30
|
|
|
|
|
|
|
|
|
|
| |
79d24d4 Make PermissionBackend#ForRef authoritative
Introduced a regression where InternalUsers where not taken into
consideration when checking READ permission.
Bug: Issue 13786
Change-Id: I3f18507f65044ac96321c1efecf1f2688f36859f
(cherry picked from commit 23ff2cfc8ffc00ad3d6e2c752d63394957c8720d)
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
* stable-2.14:
Set version to 2.14.22
Workaround Gitiles bug on All-Users visibility
Validate Gerrit changes on stable-2.15 with Jenkins
Change-Id: I1839c9aebbbe14544464e07025fbd96d576dd5bf
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* stable-2.14-2020-11.notedb-refs-tags:
Set version to 2.14.22
Workaround Gitiles bug on All-Users visibility
Validate Gerrit changes on stable-2.15 with Jenkins
Also, set target version to 2.14.23-SNAPSHOT.
Change-Id: I400d374a5950c95d9abfedc8a6ff07a6b4864b66
|
| | |
| | |
| | |
| | | |
Change-Id: Id3c767d04411ac7551e7016a37136a77e4ae8118
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Gitiles has special FilteredRepository wrapper that
allows to carefully hide refs based on the project's ACLs.
There is however an optimisation that skips the filtering
in case a user has READ permissions on every ACLs patterns.
When the target repository is All-Users, the optimisation
turns into a security issue because it allows seeing everything
that belongs to everyone:
- draft comments
- PII of all users
- external ids
- draft edits
Block Gitiles or any other part of Gerrit to abuse of this
power when the target repository is All-Users, where nobody
can be authorised to skip the ACLs evaluation.
Cover the additional special case of the All-Users project
access with two explicit positive and negative tests,
so that the security check is covered.
Bug: Issue 13621
Change-Id: Ia6ea1a9fd5473adff534204aea7d8f25324a45b7
(cherry picked from commit 45071d6977932bca5a1427c8abad24710fed2e33)
(cherry picked from commit 1be1d6ff45f18c978fd21e5c7d437d0a1351d7d8)
|
| |/
| |
| |
| |
| | |
Change-Id: I35c47ba60c08e8d5d1f767672b5e83b7d29fea1b
(cherry picked from commit 1346eab23259f8dc4adec9cb098e2f818c9cf79d)
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* stable-2.15-2020-11.notedb-refs-tags:
Set version to 2.15.22-SNAPSHOT
Set version to 2.15.21
Workaround Gitiles bug on All-Users visibility
Set version to 2.15.21-SNAPSHOT
Set version to 2.15.20
Fetch JGit documentation from the archive site
Remove generation for c.g.gwtexpui.* JavaDoc
Make PermissionBackend#ForRef authoritative
Validate Gerrit changes on stable-2.15 with Jenkins
Fix tests for stable-2.15 branch
Change-Id: I91db12c2c627550b2e897ccb4d7e27ee760cd32d
|
| | |
| | |
| | |
| | | |
Change-Id: I1ed863213d9946b77ae558d52094731db10ff721
|
| | |
| | |
| | |
| | | |
Change-Id: I3e3eb891d717169f912a20e7de948cea1f47fab3
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Gitiles has special FilteredRepository wrapper that
allows to carefully hide refs based on the project's ACLs.
There is however an optimisation that skips the filtering
in case a user has READ permissions on every ACLs patterns.
When the target repository is All-Users, the optimisation
turns into a security issue because it allows seeing everything
that belongs to everyone:
- draft comments
- PII of all users
- external ids
- draft edits
Block Gitiles or any other part of Gerrit to abuse of this
power when the target repository is All-Users, where nobody
can be authorised to skip the ACLs evaluation.
Cover the additional special case of the All-Users project
access with two explicit positive and negative tests,
so that the security check is covered.
Bug: Issue 13621
Change-Id: Ia6ea1a9fd5473adff534204aea7d8f25324a45b7
(cherry picked from commit 45071d6977932bca5a1427c8abad24710fed2e33)
|
| | |
| | |
| | |
| | | |
Change-Id: I3f5c762fda9d47da21685ca12b0f6c80032a3be2
|
| | |
| | |
| | |
| | | |
Change-Id: I83a8ece5ace5da608b3377461c572399b70962d0
|
| | |
| | |
| | |
| | | |
Change-Id: I8e78f5064fda7c2ff73134f6ac3d681c6be2e7d1
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The JavaDoc for com.google.gwtexpui.* cannot be generated
because the source files are not accessible anymore.
Failing to generate the JavaDocs caused the Gerrit build to
fail with 'No source files for package com.google.gwtexpui...'.
Change-Id: Ie36e650962636813d8f9f615e495a980b7280420
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This change fixes a misconception that leads to data being accessible
through Gerrit APIs that should be locked down.
Gerrit had two components for determining if a Git ref is visible to a
user: (Default)RefFilter and PermissionBackend#ForRef (ex RefControl).
The former was always capable of providing correct results for all refs.
The latter only had logic to decide if a Git ref is visible according to
the Gerrit READ permissions. This includes all refs under refs/heads as
well as any other ref that isn't a database ref or a Git tag. This
component was unware of Git tags and database references. Hence, when
asked for a database reference such as refs/changes/xx/yyyyxx/meta the
logic would allow access if the user has READ permissions on any of the
ref prefixes, such as the default "read refs/* Anonymous Users".
That is problematic, because it bypasses documented behavior [1] where
a user should only have access to a change if they can see the destination
ref. The same goes for other database references.
This change fixes the problem. It is intentionally kept to a minimally
invasive code change so that it's easier to backport it.
Add tests to assert the correct behavior. These tests would fail before
this fix. We have included them in this change to be able to backport
just a single commit.
[1] https://gerrit-review.googlesource.com/Documentation/access-control.html
Change-Id: Ice3a756cf573dd9b38e3f198ccc44899ccf65f75
|
| | |
| | |
| | |
| | | |
Change-Id: I35c47ba60c08e8d5d1f767672b5e83b7d29fea1b
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
Add the 'manual' tag to wct test_suite templates,
so it is excluded from bazel test //...
(cherry picked from commit ae42cd00bdfa8a34e75c563b62f0151a561cc82b)
Change-Id: Idc62df90e90e6000fa0792799a3997580fc6b011
|
| |
| |
| |
| |
| | |
Bug: Issue 12869
Change-Id: I47008477622bf3fa75508a3e2fe6e4f9026d13a7
|
|\|
| |
| |
| |
| |
| |
| |
| |
| | |
* stable-2.14:
Bazel: Add always pass test to avoid boilerplate in the CI
Set version to 2.14.22-SNAPSHOT
Set version to 2.14.21
Change-Id: I390d34f458a99d5b0e9bfb1d59dda28c08e8a810
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We don't know whether or not all plugins have test rules, so running a
generic command:
$ bazelisk test plugins/{name}/...
can lead to no tests found outcome, in which case Bazel will return exit
code 4 that needs to be checked to differentiate from test failure (exit
code 1). To avoid those checks, pass the virtual test that will always
succeed:
$ bazelisk test //tools/bzl:always_pass_test plugins/{name}/...
See also this upstream issue for this suggested workaround: [1].
[1] https://github.com/bazelbuild/bazel/issues/11465
Change-Id: Ideab64674482400cc48fad55f7ed9f8085909b84
(cherry picked from commit d69773ceb5c84cfcf13749b2f555bf92d22e6f71)
(cherry picked from commit 938db887d803889e34a1adfd762c259eadcdd6a3)
|
| |
| |
| |
| | |
Change-Id: I3aac9a69297982709b213284d919655848c6132a
|
| |
| |
| |
| | |
Change-Id: Idf4299b5e754e21c17314735981baa851061a626
|
| |
| |
| |
| | |
Change-Id: Ia6aa8dd0fbc17f09329f7efe40bfa41a6e3f793b
|
| |
| |
| |
| | |
Change-Id: I9c1b41bcb134b799fb8508514b66a7a4a83a65ca
|
| |
| |
| |
| | |
Change-Id: I77f11f9cc80a68f3ec63520fa6d12f0a70afc2f9
|
|\|
| |
| |
| |
| |
| |
| |
| | |
* stable-2.14:
Deny access over HTTP for disabled accounts
Bazel: Consistently use bazelisk during publishing of artifacts
Change-Id: I16c6c00e61ef39cc27f40da1ac1822e419eb2f2c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When an account is disabled by the Gerrit admin through the set-account
command, it should not be enabled to perform any further authentication
or other actions.
Allowing a disabled account to continue operating in Gerrit until his
session expiration would be a security risk.
Bug: Issue 12717
Change-Id: I4cbad70bb3c83a1916f0d6939c5ccbbe7c734619
|
| |
| |
| |
| |
| | |
Change-Id: I1e3d7ceaf7908f3b53a5b11a257aa752eaec066e
(cherry picked from commit 9c7428264769e9c211c0cf23a2d6ec9406be791b)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We don't know whether or not all plugins have test rules, so running a
generic command:
$ bazelisk test plugins/{name}/...
can lead to no tests found outcome, in which case Bazel will return exit
code 4 that needs to be checked to differentiate from test failure (exit
code 1). To avoid those checks, pass the virtual test that will always
succeed:
$ bazelisk test //tools/bzl:always_pass_test plugins/{name}/...
See also this upstream issue for this suggested workaround: [1].
[1] https://github.com/bazelbuild/bazel/issues/11465
Change-Id: Ideab64674482400cc48fad55f7ed9f8085909b84
(cherry picked from commit d69773ceb5c84cfcf13749b2f555bf92d22e6f71)
|
|\|
| |
| |
| |
| |
| |
| | |
* stable-2.14:
Fix Postgresql JDBC driver leaking memory
Change-Id: I0288a1d32e2e49c28f4acc82d4e51f403bb9e88c
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
* stable-2.13:
Fix Postgresql JDBC driver leaking memory
Change-Id: I4e35aaa2908788c8fbe22eaf07aba9355b52f67b
|
| | |\
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* stable-2.12:
Fix Postgresql JDBC driver leaking memory
Change-Id: I34530c9736f471d67ac761cb591443202b597e5a
|
| | | |\
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* stable-2.11:
Fix Postgresql JDBC driver leaking memory
Change-Id: Ie4c0ff60f098fbc606aba56a027ff8a0884e3a5d
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Older versions of Postgresql JDBC driver rely on finalize() methods in
order to avoid leaking unclosed database objects. Given finalize
methods are unpredictable (no guarantee about prompt execution, if at
all), in some high load environments this could lead to a memory leak
with millions of JDBC objects pending finalization.
Newer versions of the Postgresql JDBC driver removed the use of finalize
methods to avoid this kind of issues.
Also provides an implementation of setQueryTimeout.
Bug: Issue 4848
Change-Id: Ia143f1df1d8e41686362fd76b9bc82e0046f9894
(cherry picked from commit 80476a51df8361814e9cd5d91ceb60e8bf41cae5)
|
| | | | |
| | | | |
| | | | |
| | | | | |
Change-Id: I4a2782eb23f4b32f0b0fc030c1fc1e47d4dc2794
|
| | | | |
| | | | |
| | | | |
| | | | | |
Change-Id: I7a910c14f11da786c6e5c3c22b22e539136b0772
|
| | | | |
| | | | |
| | | | |
| | | | | |
Change-Id: Id7156e79e4cd55f97008b362df698bb31b898206
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
On very big sites (300,000 accounts) it is not sufficient to only run
pack refs. Full gc should be run every 100k accounts and at the end
of the migration to leave the All-Users repository in a good shape.
Change-Id: Ic0bcce93f557b93c24185df3fbd84d036269669d
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This reverts commit ad52c7ad48cab1418c055f65b730437ee97c8329.
Reason for revert: There was a principal refactoring in connection
management in schema migration process, so that polling the database
connection with dummy SQL statement in Schema 146 is not needed any
more.
Change-Id: Ib5b2c1a946b35c9a5e8adef01fe45ecd046b4308
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In some schema migrations pure database schema update machinery was
misused for long running migrations that entirely unrelated to database
schema upgrades. Most notably Schema_144 that migrating external ids to
NoteDb and Schema_146 where all accounts were migrated from ReviewDb to
NoteDb. How the code is currently organized, that approach only works
for small to medium gerrit installation sites with couple of thousands
users.
This change adjusts the schema update connection management and pass
in schema factory instead ReviewDb instance to the schema migration
process. That way it is possible to open two new connections for each
schema migration step:
1. migrate data
2. bump new schema version
As the consequence of this refactoring big sites shouldn't run into
wait timeout exception during schema migration process.
Bug: Issue 12637
Change-Id: I9bbdd9a09898c4ef23362853c654a39934c3967c
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fire dummy select statement to prevent hitting wait timeout in database
server.
The problem is not that easy to see and can only occur for very big
gerrit installation sites with ca. 300,000 accounts. Schema 146 is only
scanning the accounts from the database at first step and then migrating
those accounts from ReviewDb to NoteDb without any database activity.
Depending on the size of gerrit installation site, this migration can
take from minutes to many hours.
Even though the default wait timeout in MySQL server is 8 hours, many
sites substantially descreased that value so that instead of document
that problem and enforcing gerrit administrators to increase wait
timeout value, fire dummy SQL select statement per batch chunk of 1000
acounts. That would mean, that for 300,000 accounts the 300 SQL
statements would be fired.
Bug: Issue 12637
Change-Id: I4138ad1f85e92aef6d06aa87a0a0d2bc1a5341cb
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It verifies behaviour of 'visibleto' predicate for Gerrit 2.15.
Bug: Issue 12606
Change-Id: I7e172ef9a6864fde7153e2ce7106663238d99a4d
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* Update plugins/replication from branch 'stable-2.15'
to 1850413298125a857b61d31510ccb22c0dfafc1e
- ReplicationQueue: Check nulls in firePendingEvents
After a sudden reboot (for unknown reason) Gerrit at startup couldn't
load because of NullPointerException. There is a possibility that
stored event was null at that point. Extra logging added to handle null
events.
Change-Id: I72f34d8def6e0246196cd865f33f6e795b21664b
- Log stack trace when an error occur while deleting event
This will help figuring out root cause of failure to delete event file.
Change-Id: I2f9774c3daf19a04f6b04414ba8145c99bb6e0fe
(cherry picked from commit b62f006b1350180de0af02c82fb18fb290a2548f)
- Append LF to the json string of persisted replication event
Change-Id: I83ed3f37071125018bf23f6dcd137ef819ef3559
(cherry picked from commit 5e91925cfd391898e8e33fd149b9e1a115dafee4)
- Change default for the replicateOnStartup to false
Now that replication events are persistent and non-finished replications
rescheduled after plugin restart the replicateOnStartup feature becomes
less important. We can change the default value for this option to
false.
Change-Id: I237d8d8514e01b8786b7db9f39bead4eb475a0a4
(cherry picked from commit 807790f7d4058235a19b2a766e84628168b64ae6)
- Don't lose ref-updated events on plugin restart
When a ref-updated event is received, persist the event in the directory
defined by the replication.eventsDirectory. When the updated ref is
replicated deleted the persisted event.
If replication queue is non-empty and plugin gets stopped, ref updates
will not be replicated and, therefore, the persisted events will not get
deleted. When the plugin starts it will schedule replication for all
persisted events and delete them.
This change provides two benefits:
* no ref-updated events are lost on plugin restart
* eliminate need for the replicateOnStartup=true setting which schedules
replication of all refs for all projects and typically creates a humongous
replication queue on every plugin restart.
Change-Id: Ieacd084fabe703333241ffda11c8b6c78cced37a
(cherry picked from commit bdaea910694dd5a3474dbc051b298aaee9d77950)
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* Update plugins/download-commands from branch 'stable-2.15'
to c80d8fec81c3f9530ed07f83bc09fd73629522cd
- Set SSH default port to 22
If nothing is configured, the advertised ssh address is *:29418, and it
is translated to host:29418.
If sshd.listenAddress is configured without a port, then the advertised
address is host:29418.
If it is configured with port 22, the advertised address is host, without
the port.
The logic in SshScheme assumed that "no port" is 29418, which is
incorrect.
Change-Id: I8b4717a1f5765272b4c3bd7683750ae8fd12a4d5
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In case of lock failure there is no hint on what commit has caused it.
This change adds ref log message, which is "commit:" + subject line
of commit message or "commit: meta data update" in case of no commit
message, to the exception message.
Also extract the exception message creation to a separate method, so
that the same info is available when update fails for other reasons.
Change-Id: I5686e079853807ba88dae6d8ccf184eb81b50013
|
|\| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* stable-2.14:
Bazel: Remove deprecated tls_enabled option
Change-Id: Ibdd5ff445bf26b6dcd319e37b08a649fd857f7f3
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This option was flipped in context of:[1] and is now enabled per
default. When running gerrit build with remote execution strategy,
this warning is issued:
WARNING: Option 'tls_enabled' is deprecated: No-op. See #8061 \
for details.
[1] https://github.com/bazelbuild/bazel/issues/8061
Change-Id: I6d77f08e483157f955e82abe0bae848075a7040e
|