ESC meeting minutes have been published: ElasticSearch support planned to be dropped in v3.5

209 views
Skip to first unread message

lucamilanesio

unread,
Nov 10, 2021, 6:50:41 AM11/10/21
to Repo and Gerrit Discussion
Please see the ESC meeting minutes at [1], including the ElasticSearch support in core dropped from v3.5.x onwards [2].

Sven Selberg

unread,
Nov 10, 2021, 8:16:03 AM11/10/21
to Repo and Gerrit Discussion
On Wednesday, November 10, 2021 at 12:50:41 PM UTC+1 lucamilanesio wrote:
Please see the ESC meeting minutes at [1], including the ElasticSearch support in core dropped from v3.5.x onwards [2].


There's an 'l' missing in this link. Should be:
 

Luca Milanesio

unread,
Nov 10, 2021, 8:21:24 AM11/10/21
to Repo and Gerrit Discussion, Luca Milanesio

On 10 Nov 2021, at 13:16, Sven Selberg <sven.s...@axis.com> wrote:



On Wednesday, November 10, 2021 at 12:50:41 PM UTC+1 lucamilanesio wrote:
Please see the ESC meeting minutes at [1], including the ElasticSearch support in core dropped from v3.5.x onwards [2].


There's an 'l' missing in this link. Should be:

Thanks Sven, yes it was indeed missing :-)

Luca.

 

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/a711293e-5d19-4f30-bb98-c443e40ab063n%40googlegroups.com.

Sven Selberg

unread,
Nov 10, 2021, 8:26:23 AM11/10/21
to Repo and Gerrit Discussion
On Wednesday, November 10, 2021 at 2:21:24 PM UTC+1 lucamilanesio wrote:

On 10 Nov 2021, at 13:16, Sven Selberg <sven.s...@axis.com> wrote:



On Wednesday, November 10, 2021 at 12:50:41 PM UTC+1 lucamilanesio wrote:
Please see the ESC meeting minutes at [1], including the ElasticSearch support in core dropped from v3.5.x onwards [2].


There's an 'l' missing in this link. Should be:

Thanks Sven, yes it was indeed missing :-)

It seems like there's a discrepancy between what's deployed and what's merged.
If you look at the date in the link of the MoM it says "2021-10-06" but the document served shows the MoM for "2021-11-03".
This doesn't match how that document looks in git [1], and in git the Nov 3 MoM[2] have the correct path but it's not served from the homepage.

Luca Milanesio

unread,
Nov 10, 2021, 8:28:26 AM11/10/21
to Repo and Gerrit Discussion, Luca Milanesio, Sven Selberg

On 10 Nov 2021, at 13:26, Sven Selberg <sven.s...@axis.com> wrote:



On Wednesday, November 10, 2021 at 2:21:24 PM UTC+1 lucamilanesio wrote:

On 10 Nov 2021, at 13:16, Sven Selberg <sven.s...@axis.com> wrote:



On Wednesday, November 10, 2021 at 12:50:41 PM UTC+1 lucamilanesio wrote:
Please see the ESC meeting minutes at [1], including the ElasticSearch support in core dropped from v3.5.x onwards [2].


There's an 'l' missing in this link. Should be:

Thanks Sven, yes it was indeed missing :-)

It seems like there's a discrepancy between what's deployed and what's merged.
If you look at the date in the link of the MoM it says "2021-10-06" but the document served shows the MoM for "2021-11-03".
This doesn't match how that document looks in git [1], and in git the Nov 3 MoM[2] have the correct path but it's not served from the homepage.


Let me upload a fix.

Luca.



Luca.

 

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/a711293e-5d19-4f30-bb98-c443e40ab063n%40googlegroups.com.


--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

Sven Selberg

unread,
Nov 10, 2021, 8:30:09 AM11/10/21
to Repo and Gerrit Discussion
On Wednesday, November 10, 2021 at 2:28:26 PM UTC+1 lucamilanesio wrote:

On 10 Nov 2021, at 13:26, Sven Selberg <sven.s...@axis.com> wrote:



On Wednesday, November 10, 2021 at 2:21:24 PM UTC+1 lucamilanesio wrote:

On 10 Nov 2021, at 13:16, Sven Selberg <sven.s...@axis.com> wrote:



On Wednesday, November 10, 2021 at 12:50:41 PM UTC+1 lucamilanesio wrote:
Please see the ESC meeting minutes at [1], including the ElasticSearch support in core dropped from v3.5.x onwards [2].


There's an 'l' missing in this link. Should be:

Thanks Sven, yes it was indeed missing :-)

It seems like there's a discrepancy between what's deployed and what's merged.
If you look at the date in the link of the MoM it says "2021-10-06" but the document served shows the MoM for "2021-11-03".
This doesn't match how that document looks in git [1], and in git the Nov 3 MoM[2] have the correct path but it's not served from the homepage.


Let me upload a fix.

Luca.

Thanks Luca!

/Sven

Luca Milanesio

unread,
Nov 10, 2021, 8:30:15 AM11/10/21
to Repo and Gerrit Discussion, Luca Milanesio, Sven Selberg

On 10 Nov 2021, at 13:28, Luca Milanesio <luca.mi...@gmail.com> wrote:



On 10 Nov 2021, at 13:26, Sven Selberg <sven.s...@axis.com> wrote:



On Wednesday, November 10, 2021 at 2:21:24 PM UTC+1 lucamilanesio wrote:

On 10 Nov 2021, at 13:16, Sven Selberg <sven.s...@axis.com> wrote:



On Wednesday, November 10, 2021 at 12:50:41 PM UTC+1 lucamilanesio wrote:
Please see the ESC meeting minutes at [1], including the ElasticSearch support in core dropped from v3.5.x onwards [2].


There's an 'l' missing in this link. Should be:

Thanks Sven, yes it was indeed missing :-)

It seems like there's a discrepancy between what's deployed and what's merged.
If you look at the date in the link of the MoM it says "2021-10-06" but the document served shows the MoM for "2021-11-03".
This doesn't match how that document looks in git [1], and in git the Nov 3 MoM[2] have the correct path but it's not served from the homepage.


Let me upload a fix.

Richard Christie

unread,
Nov 10, 2021, 9:57:30 AM11/10/21
to Repo and Gerrit Discussion
JFYI, the first link doesn't work (missing the "l")

Was there anything more said about the "Trojan Source" issue, there's been some worries going on around that internally for us.

Matthias Sohn

unread,
Nov 10, 2021, 10:27:15 AM11/10/21
to Richard Christie, Repo and Gerrit Discussion
On Wed, Nov 10, 2021 at 3:57 PM Richard Christie <richard....@arm.com> wrote:
JFYI, the first link doesn't work (missing the "l")

Was there anything more said about the "Trojan Source" issue, there's been some worries going on around that internally for us.

I filed an issue [1] to track this

 
On Wednesday, November 10, 2021 at 11:50:41 AM UTC lucamilanesio wrote:
Please see the ESC meeting minutes at [1], including the ElasticSearch support in core dropped from v3.5.x onwards [2].

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

Luca Milanesio

unread,
Nov 10, 2021, 11:43:29 AM11/10/21
to Repo and Gerrit Discussion, Luca Milanesio, Richard Christie, Matthias Sohn
The meeting minutes have been re-published at:

Apologies for the inconvenience caused.

Luca.

Clark Boylan

unread,
Nov 10, 2021, 12:10:50 PM11/10/21
to Luca Milanesio, Repo and Gerrit Discussion
On Wed, Nov 10, 2021 at 8:43 AM Luca Milanesio <luca.mi...@gmail.com> wrote:
>
> The meeting minutes have been re-published at:
> https://www.gerritcodereview.com/2021-11-03-esc-minutes.html
>

Thank you for putting this together. Wanted to clarify on the scoped
credentials topic. This came out of a brainstorm around how to make
HTTP credentials easier to use. Currently the vast majority of our
users use SSH to push to Gerrit, and I think that works great for
those users. I think we're happy to continue to use SSH as the primary
method here (I know this is my personal preference).

Don't want to give the impression this is a hard requirement for us.
We'd like to continue to be able to use SSH for most of our users, and
maybe we can improve things for those where SSH does not work
(typically for firewall reasons). Happy to consider other ideas as
well.

Clark

Richard Christie

unread,
Nov 11, 2021, 4:35:26 AM11/11/21
to Repo and Gerrit Discussion
The idea of scoped credentials, potentially separate from a user account and with a max TTL on them is something we would be quite interested in too. JFrog do something similar to this in Artifactory.

Or just the possibility of having multiple user http tokens (again ideally with max TTL) so that it is possible to rotate them in accordance with security policy. Currently this is quite hard for system accounts that may be accessing through CI as you can never be sure there isn't a job running somewhere with the older credential still "active" at the point you cycle.

Having (say) just two tokens would allow say, daily rotation with a 2 day time to live making sure that all uses of the "older" were almost certainly expired by that point.

It is something that can already be done by ssh since you can have multiple ssh public keys, but there is a general movement away from ssh towards https within engineering for flows these days.

Luca Milanesio

unread,
Nov 11, 2021, 11:06:58 AM11/11/21
to Repo and Gerrit Discussion, Luca Milanesio, Richard Christie

On 11 Nov 2021, at 01:35, Richard Christie <richard....@arm.com> wrote:

The idea of scoped credentials, potentially separate from a user account and with a max TTL on them is something we would be quite interested in too. JFrog do something similar to this in Artifactory.

Or just the possibility of having multiple user http tokens (again ideally with max TTL) so that it is possible to rotate them in accordance with security policy. Currently this is quite hard for system accounts that may be accessing through CI as you can never be sure there isn't a job running somewhere with the older credential still "active" at the point you cycle.

Having (say) just two tokens would allow say, daily rotation with a 2 day time to live making sure that all uses of the "older" were almost certainly expired by that point.

I agree that it would be useful indeed. Having HTTP secure keys (with TTL and limited scope) is paramount for having a robust and secure Git/HTTPS communication between the CI system and Gerrit.
I believe that could be achieved with a plugin: if you (or anyone else) have interest in writing one, I can setup a brainstorming session and we can kickstart the project.

I would be happy to contribute / review / participate in the development.


It is something that can already be done by ssh since you can have multiple ssh public keys, but there is a general movement away from ssh towards https within engineering for flows these days.

SSH keys are less secure though, because you cannot scope them to individual commands / features.
Also, if anyone would eavesdrop the key, he could potentially set an HTTP password and then use that for invoking any REST-API and do anything he wants with it.

I believe we need something better, more robust and secure.

Luca.


On Wednesday, November 10, 2021 at 5:10:50 PM UTC clark....@gmail.com wrote:
On Wed, Nov 10, 2021 at 8:43 AM Luca Milanesio <luca.mi...@gmail.com> wrote:
>
> The meeting minutes have been re-published at:
> https://www.gerritcodereview.com/2021-11-03-esc-minutes.html
>

Thank you for putting this together. Wanted to clarify on the scoped
credentials topic. This came out of a brainstorm around how to make
HTTP credentials easier to use. Currently the vast majority of our
users use SSH to push to Gerrit, and I think that works great for
those users. I think we're happy to continue to use SSH as the primary
method here (I know this is my personal preference).

Don't want to give the impression this is a hard requirement for us.
We'd like to continue to be able to use SSH for most of our users, and
maybe we can improve things for those where SSH does not work
(typically for firewall reasons). Happy to consider other ideas as
well.

Clark

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

Richard Christie

unread,
Nov 11, 2021, 12:20:28 PM11/11/21
to Repo and Gerrit Discussion
First time trying to use this new web-form for inline replies, apologies if it comes out terribly…

On Thursday, November 11, 2021 at 4:06:58 PM UTC lucamilanesio wrote:

On 11 Nov 2021, at 01:35, Richard Christie <richard....@arm.com> wrote:

The idea of scoped credentials, potentially separate from a user account and with a max TTL on them is something we would be quite interested in too. JFrog do something similar to this in Artifactory.

Or just the possibility of having multiple user http tokens (again ideally with max TTL) so that it is possible to rotate them in accordance with security policy. Currently this is quite hard for system accounts that may be accessing through CI as you can never be sure there isn't a job running somewhere with the older credential still "active" at the point you cycle.

Having (say) just two tokens would allow say, daily rotation with a 2 day time to live making sure that all uses of the "older" were almost certainly expired by that point.

I agree that it would be useful indeed. Having HTTP secure keys (with TTL and limited scope) is paramount for having a robust and secure Git/HTTPS communication between the CI system and Gerrit.
I believe that could be achieved with a plugin: if you (or anyone else) have interest in writing one, I can setup a brainstorming session and we can kickstart the project.

I would be happy to contribute / review / participate in the development.

We may look at this in future. Internally we use HashiCorp's Vault for a lot of secret management, and we're experimenting with a plugin there which (at least it claims) manages some of this with Artifctory automatically. Having the backend support in gerrit to do something similar would be useful… Given our planning cycles though, it would be unlikely to get any attention before April.
 

It is something that can already be done by ssh since you can have multiple ssh public keys, but there is a general movement away from ssh towards https within engineering for flows these days.

SSH keys are less secure though, because you cannot scope them to individual commands / features.
Also, if anyone would eavesdrop the key, he could potentially set an HTTP password and then use that for invoking any REST-API and do anything he wants with it.

I believe we need something better, more robust and secure.

I'm not really in favour of ssh but just to play "devil's advocate" here:
Actually one could do this the way we do at the moment for ssh for host access using x509 extensions. This
- obviates needing a public key in the remote end's "authorized_keys" file; and thus into Gerrit's public key store
- Allows a max ttl on the key (based on the certificate expire time)
- Allows you to restrict the ssh command that is being run, and indeed *any* other parameters that one might normally give as a "-o" option to ssh or in the ssh config.

We again use HashiCorp Vault as our (m)TLS trust provider here. Clients get their public keys signed by Vault. On the host, the server checks the public key signature on the preloaded Vault CA root file (so no need for dynamic connection to Vault) and then allows or not. 

I know at one point gerrit did allow the use of the local opensshd rather than its own stack here, so it could be done that way. However AFAIK Gerrit's own ssh daemon doesn't support this - or at least I cannot find anything in the documentation as to where you would pass the trusted CA root.

However if you enabled this you could then offload all the permissions to your CA signing authority (Vault, in our case) which then uses RBAC to decide who is allowed to do what by cutting the appropriate certificate with the relevant runes for Gerrit. So for example (blue-sky thinking)
- per project (repository) use
- read vs write
- api calls
- allowed refs
- "user" the ssh key is acting on behalf of

 Just some thoughts!

Han-Wen Nienhuys

unread,
Nov 11, 2021, 1:17:16 PM11/11/21
to Richard Christie, Repo and Gerrit Discussion
On Thu, Nov 11, 2021 at 6:20 PM Richard Christie
<richard....@arm.com> wrote:
>> SSH keys are less secure though, because you cannot scope them to individual commands / features.
>> Also, if anyone would eavesdrop the key, he could potentially set an HTTP password and then use that for invoking any REST-API and do anything he wants with it.
>>
>> I believe we need something better, more robust and secure.
>
>
> I'm not really in favour of ssh but just to play "devil's advocate" here:
> Actually one could do this the way we do at the moment for ssh for host access using x509 extensions. This
> - obviates needing a public key in the remote end's "authorized_keys" file; and thus into Gerrit's public key store
> - Allows a max ttl on the key (based on the certificate expire time)
> - Allows you to restrict the ssh command that is being run, and indeed *any* other parameters that one might normally give as a "-o" option to ssh or in the ssh config.
>
> We again use HashiCorp Vault as our (m)TLS trust provider here. Clients get their public keys signed by Vault. On the host, the server checks the public key signature on the preloaded Vault CA root file (so no need for dynamic connection to Vault) and then allows or not.
>
> I know at one point gerrit did allow the use of the local opensshd rather than its own stack here, so it could be done that way. However AFAIK Gerrit's own ssh daemon doesn't support this - or at least I cannot find anything in the documentation as to where you would pass the trusted CA root.

you're talking about x509 and mTLS CAs, but I assume these are just
normal SSH certificates? Gerrit as of 3.4 (?) has migrated to Apache's
Mina SSHD which supports certs, see

https://github.com/apache/mina-sshd/blob/20d4e44454d8812ec0f012c795a2c7a27c17f348/sshd-common/src/main/java/org/apache/sshd/common/config/keys/OpenSshCertificate.java

presumably, it wouldn't be hard to make Gerrit distinguish reads and
writes (through the command processed,
git-receive-pack/git-upload-pack) and wire up a CA.

> However if you enabled this you could then offload all the permissions to your CA signing authority (Vault, in our case) which then uses RBAC to decide who is allowed to do what by cutting the appropriate certificate with the relevant runes for Gerrit. So for example (blue-sky thinking)
> - per project (repository) use
> - read vs write
> - api calls
> - allowed refs
> - "user" the ssh key is acting on behalf of

more fine grained permissions are harder to do because you have to
wire the permissions from the entry point through to the handlers, but
general distinctions (which repo, read vs write) which are enforced on
the outer layer seem feasible.

--
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--

Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Teng Long

unread,
Nov 13, 2021, 12:15:29 AM11/13/21
to lucamilanesio, Repo and Gerrit Discussion
It’s sad to hear about the elasticsearch (I will call ES for short in this context) will be deprecated soon. Alibaba use ES to auto-scale the Reversed indexes of 5 large Gerrit Clusters and they are working well.

I totally understand and agree the decision of that, it will be plenty of time for us to care about the solution or replacement if we want to upgrade to v3.5x.

Thanks
-Dyrone

lucamilanesio <luca.mi...@gmail.com>于2021年11月10日 周三下午7:50写道：
--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

lucamilanesio

unread,
Nov 14, 2021, 8:29:24 AM11/14/21
to Repo and Gerrit Discussion
On Friday, November 12, 2021 at 9:15:29 PM UTC-8 dyron...@gmail.com wrote:
It’s sad to hear about the elasticsearch (I will call ES for short in this context) will be deprecated soon. Alibaba use ES to auto-scale the Reversed indexes of 5 large Gerrit Clusters and they are working well.

I totally understand and agree the decision of that, it will be plenty of time for us to care about the solution or replacement if we want to upgrade to v3.5x.

The plan is to remove the support in Gerrit core (see [3]) and allow ElasticSearch (or other implementations, like OpenSource or Solr) to be plugged as libModule (see [4]).
That means that if you want, you can stay on ElasticSearch using [4] or, if you wish, you can migrate to a different indexing backend.

Hope that clarifies and explains how things will work in the future.

Luca.

Teng Long

unread,
Nov 15, 2021, 7:12:53 AM11/15/21
to lucamilanesio, Repo and Gerrit Discussion
Make sense.

I appreciate the explanation, It seems appropriate and from a deep
consideration of the situation.

Thanks.

-Teng Long (Dyrone)

lucamilanesio <luca.mi...@gmail.com> 于2021年11月14日周日 下午9:29写道：
> To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/b6db8b5b-a993-4650-a907-5082f0644bebn%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages