Question: Proposal to define a strict value for aud claim in the private_key_jwt?

Thanks for the +1.

I agree that the proposed API does not solve all problems but if Android provides then others might follow.
For the web case we go for universal links and assetlinks.
 URL
 URL
Which enable app-clips and instant apps, and also app-web-credential-sharing.
To get rid of ip2msisdn we have operatorTokens (best thing since sliced bread) defined in GSMA TS.43
 URL

No solution for everything or use case but we are getting there if MNO work together and build an ecosystem for all of us

Proposal to define a strict value for aud claim in the private_key_jwt
**Problem description**
Referring to the CIBA specs, the `aud` claim of the `private_key_jwt` can be any of the 3 options mentioned below.
The proposal is to prevent reuse of the `private_key_jwt` at other endpoints.

**Possible evolution**
Enforce the `aud` claim of the `private_key_jwt` to be the URL of the respective endpoint (as a string) at which the assertion is received, it must not be an item in an array.
The URLs of the endpoint can be populated from the OpenID Provider's `/.well-known/openid-configuration` with the following metadata:
- token_endpoint
- backchannel_authentication_endpoint

Example: If the endpoint at which the assertion is being received is the backchannel_authentication_endpoint, the Relying Party will populate the `aud` claim of the `private_key_jwt` to be the URL of the backchannel_authentication_endpoint as per the OpenID Provider's `/.well-known/openid-configuration`.

**Alternative solution**
N.A

**Additional context**
OIDC profile is being defined for CAMARA

From my point of view, it is not a good idea to limit the value of the `aud` claim to that of the endpoint to which the request is made. The CIBA specification is clear (Issuer Identifier, Token Endpoint URL, or Backchannel Authentication Endpoint), and forcing implementations to deviate from the standard by rejecting requests they should accept could jeopardize existing integrations.

If replay attacks are to be avoided, there are better mechanisms, such as the `jti` claim to prevent reuse of the token.

@garciasolero
The concern is that the same signed JWT can be interchangeably use between the three endpoints:

- /bc-authorize
- /token
- /authorize

/token endpoint should be more secured as it allows `client_credentials` with scope.
The `aud` claim can be seem similarly as a scope for access.

Proposed CAMARA OIDC - client-authentication profile states

Please clarify on this point.

image

@mhfoo How about the text in this commit?

 URL

## Client Authentication

This CAMARA document allows one client authentication method, private_key_jwt, as defined in OIDC OIDC Client Authentication

OIDC Client Authentication defined the following about the audfield:

 REQUIRED. Audience. The aud (audience) Claim. Value that identifies the Authorization Server as an intended audience. The Authorization Server MUST verify that it is an intended audience for the token. The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.

This document defines that for OIDC Authorization Code Flow and OAuth2 Client Credentials Grant the audience MUST be the URL of the Authorization Server's Token Endpoint. This document defines that for OIDC CIBA the audience MUST be the Backchannel Authentication Endpoint.

I think it is better to separate the use cases because some involve different types of JSON Web Tokens (JWTs). On one hand, we have the request object parameter, and on the other hand, we have the client assertion for authentication.

- Request Object by value in `/authorize` request: It must be the Authorisation Server Issuer Identifier URL (RFC9101):

- Client assertion for authentication in server-server requests: I think there could be some confusion here, and certain standards, such as CIBA, are proposing solutions to ensure interoperability. I think setting it up similar to CIBA could be the solution: Authorisation Server Issuer Identifier, Token Endpoint URL or Requested Endpoint URL. So the table you suggested would look like this:

| Invoking Endpoint \ Audience | issuer | token endpoint | bc-authorize endpoint | any other endpoint|
| ------------------------------- | ------- |-----------------|------------------------|--------------------|
| /token | Accept | Accept | Reject | Reject |
| /bc-authorize | Accept | Accept | Accept | Reject |

The `aud` claim requirements for authorization servers in the FAPI profile are: issuer, token endpoint, or the endpoint URL (as I suggested above). I'm not sure why the client requirements section restricts sending only the issuer (and as a string, not in an array) when authorization servers are expected to accept the other values. In my opinion, I would include the requirements for the authorization server.

The section on clients is a "should", so clients can still use the other allowed values in FAPI 2.0 security.

The current text in #121 is this:

This document defines that for OIDC CIBA the audience MUST be the Backchannel Authentication Endpoint.

In other words, the aud is always the url the request is sent too. Which seems to be a simple rule, which is somewhat more secure than additionally allowing the "issuer" as well.

| Invoking Endpoint \ Audience | issuer | token endpoint | bc-authorize endpoint | any other endpoint|
| ------------------------------- | ------- |-----------------|------------------------|--------------------|
| /token | Reject | Accept | Reject | Reject |
| /bc-authorize | Reject | Reject | Accept | Reject |

Please suggest "better" text if you think that is needed.

Suggested text aligned with what the CIBA standard and the FAPI profile state:

_To facilitate interoperability, the Authorization Server MUST accept its issuer identifier, the token endpoint URL, or the URL of the endpoint at which the assertion was received as values of the audience claim._

@AxelNennker @garciasolero

The current text in URL is this:

In other words, the aud is always the url the request is sent too. Which seems to be a simple rule, which is somewhat more secure than additionally allowing the "issuer" as well.

| Invoking Endpoint \ Audience | issuer | token endpoint | bc-authorize endpoint | authorize endpoint | any other endpoint | mulitple endpoints |
|--------|--------|--------|--------|--------|--------|--------|
| /token | Reject | Accept | Reject | Reject | Reject | Reject |
| /bc-authorize | Reject | Reject | Accept | Reject | Reject | Reject |
| /authorize | Reject | Reject | Reject | Accept | Reject | Reject |

Agree with Axel's statement above. The
aud
 claim should not be an array.

The signed Object Request RFC 9101 is a signed JWT and it is communicated in the public domain over the Internet when performing the Auth Code flow.

The signed JWT maybe used to invoke the /token /bc-authorized endpoints by a bad actor, as mentioned in Cross-JWT Confusion.

The above proposal is leaving the API Consumer to secure the Operator's endpoint. As an Operator, we should secure our endpoints with restrictions.

Another approach is to issue different
client_id
 for the same backend application when performing auth code flow and CIBA flow.

Bank XYZ will use client_id A for auth code flow, client_id B for CIBA flow. client_id A will not be accepted for CIBA flow, client_Id B will not be accepted for auth code flow.

1)
Regarding the following two sections:

@mhfoo Please do not add even more options to the mix.

2) Not sure why write about 9101. Yes, that is also a signed JWT, and there also can be a mixup-attack.
Does your text after "The signed Object Request..." help with the solution if you assume that we assume that more concrete aud values are more secure?

# To summarize this issue's discussion:
Specifying single, specific values for aud depending on the use-case and end point improves security.
Doing that might possibly be bad for interoperability. Even though I am one of the editors of the CIBA standard I do not agree with the interoperability argument. Specifying the correct aud string is simple and I believe that clients are not overburdened with this task. While at the same time, we prevent mixup attacks.

You might challenge the "simple"-argument, but I think the other proposals (key management) are too complicated and implementing the aud-requirement discussed here is indeed simple.

# Some examples for aud value in various implementations:
The example seem to use the endpoint url which agrees existing text.

- URL

- URL

- URL

- URL

- URL

| Invoking Endpoint \ Audience | issuer | token endpoint | bc-authorize endpoint | authorize endpoint | any other endpoint | mulitple endpoints |
|--------|--------|--------|--------|--------|--------|--------|
| /token | Reject | Accept | Reject | Reject | Reject | Reject |
| /bc-authorize | Reject | Reject | Accept | Reject | Reject | Reject |
| /authorize | Reject | Reject | Reject | Accept | Reject | Reject |

@garciasolero can TEF live with this table? As I said, I thing that using the endpoint url is not obstacle for client developers and provides better security.

@AxelNennker

As I mentioned earlier, we should clearly separate the audiences for these endpoints because they have their own requirements: `token` and `bc-authorize` endpoints deals with client assertions for authentication, while the `authorize` endpoint deals with request objects.

In relation to the audience claim within a client assertion, we suggest what CIBA standard or FAPI profile define: to accept the issuer, the token endpoint and the endpoint URL as valid audiences to ensure interoperability.

CIBA:

FAPI:

Of course, you can simplify the possible values and, for example, accept only the endpoint URL. However, this would affect already deployed solutions that follow the CIBA standard. Therefore, we suggest that the profile should allow authorization servers to accept these three values and recommend using the endpoint URL to clients.

---
Regarding what would happen if we support RFC9101 by passing request objects by value, the standard already specifies what the value of the audience should be:

In relation to your concern about the use of a JWT issued for a request object in authorize flow as a client authentication JWT, the RFC9101 already suggests a way to mitigate this by avoiding the `client_id` as `sub` value within the request object:

@AxelNennker

Does your text after "The signed Object Request..." help with the solution if you assume that we assume that more concrete aud values are more secure?

Regarding the above question, it is related to #128.

The following is the proposed text for PR #121 under OIDC Authorization Code Flow section.

The OIDC Authorization Code Flow is defined in OpenID Connect, incorporating RFC 9101, Passing a Request Object by Value.

We are not making progress with this issue.

I changed the text regarding `client authentication and the aud values` to RECOMMEND instead of MUST.

The AZ still MUST ensure that it is the intended audience. The document, as always following the principle of no repeating the obvious, does not mention that fact because the standards are clear and no clarification is needed.

## Client Authentication

This CAMARA document allows **one** client authentication method, `private_key_jwt`, as defined in OIDC
OIDC Client Authentication

This document RECOMMENDS that for OIDC Authorization Code Flow and OAuth2 Client Credentials Grant the audience SHOULD be the URL of the Authorization Server's Token Endpoint.
This document RECOMMENDS that for OIDC CIBA the audience SHOULD be the Backchannel Authentication Endpoint.

Proposal to protect the /authorize endpoint for the Authorization Code Flow (Auth Code Flow) - RFC9101
**Problem description**
The /authorize endpoint is not protected, and the following undesired scenarios are security concerns.

1. A bad actor can perform a DDoS attack with multiple Operator SIM cards on the Operator /authorize endpoint; this is an internal mobile network route without traversing the Internet.

2. Aggregators are using mobile apps to query different operator /authorize endpoints to discover (at no cost) which operator the SIM card belongs too.

**Possible evolution**
Proposal to have a one-time use token to prevent abuse of this un-protected endpoint on AuthServer.
The App Backend will need to obtain this one-time use token from the AuthServer and pass it to the Device App and then use it against the /authorize endpoint.

1. The one-time use token will be validated at the Auth Service, and therefore protecting the downstream network nodes.
2. The one-time use token will be associated with an Application Backend for charging purposes.

**Alternative solution**
N.A

**Additional context**
NumberVerification subproject issue 71

Please refer to the following sequence diagrams. The interactions in blue is the proposed method.

Standalone Open Gateway
Proposal

Federated Open Gateway
Simple Federated Proposal

In our view, it is unnecessary to introduce additional flows beyond those that already exist. Instead, we recommend using the mechanisms provided by the OAuth standard itself. Our proposal to mitigate this issue is to force the application to pass the request object parameter by value in the authorize request of the authorization code flow, as described in RFC9101.

By using a signed JWT, we prevent requests that are not generated by the application. Additionally, we would need to require that the JWT contains the `jti` (to prevent the JWT from being replayed) and `exp` parameters.

For applications, the integration cost would not be high because they would already be generating signed-JWTs to authenticate server-to-server requests using `private_key_jwt`.

@garciasolero Thanks for the proposal to mitigate this issue by forcing the application backend to pass the request object parameter by value in the authorize request of the authorization code flow, as described in RFC9101.

The request object will be a signed JWT containing the auth code flow request payload.

This will mitigate point 1. of the problem statements

@garciasolero
The point of relying on the `jti` value alone when the signed JWT is from a third party, is not sufficient.
It should be a combination of at least `jti` + `iss` + `exp`.

Point 2 of the problem statements is related to a "trusted" aggregator using error codes to decode behaviours of the number verification flow.

Example:
If this endpoint response successfully with a redirect 302, the SIM card belongs to this operator.
If this endpoint response with an error, the SIM card may not belong to this operator.

@mhfoo,

Yes, you are right. In my comment, I focused on a few fields. Obviously, it should also include the most typical ones: `iss`, `aud`, or `iat`.

Regarding point 2, in the aggregation model for number verification, the entity responsible for routing the request to the correct operator is the aggregator based on the IP address of the request using the TelcoRouting service. Therefore, it should not be the case that the SIM card does not belong to the operator, and if it were to happen, it would be an exceptional case related to synchronisation issues in the TelcoFinder translation tables.

@garciasolero

Is there any specification of TelcoRouting service?
Who will be responsible for it in terms of maintenance?
Will every Telco expose API for exporting Public IP Pools records or what is the idea?

Our current practice is that every Telco shares us IP Pools so we are able to do the routing on our side locally very easy and fast. Like using GeoIP Database with Telco resolution level. On that way there is no need for any additional external call which slow down the flow.

@ab-ip
This question should be handled in GSMA Open Gateway

@garciasolero

Point 2 in this problem description is not about routing. Please refer to the following diagram for illustration of this problem statement.

Number Verify Issue drawio

In the above diagram, assume the Operators are standalone (not federated).

The aggregator:
- has all the /authorize endpoints for Operator A, B, C,
- has an SDK deployed in the mobile application which can query a list of provided /authorize endpoints.

From this setup, the aggregator can determine the operator of the SIM card which is providing the mobile data connection, when the correct /authorize endpoint returns a 302 Location with an auth code in the query string.
The aggregator/mobile application does not need to continue with the auth code flow for number verify to determine the mobile number. The aggregator just needs to know the operator of the SIM card which the end customer is using.

This usage of the /authorize endpoint should be prevented.

@mhfoo

The case you mentioned is too expensive for Clients/Aggregators to use Trial-and-Error method to resolve Telco. It takes to much time and increases flow duration, which is something nobody wants.

There are many other (easier and faster) ways right now to do this:
1. Clients can use IP to ASN resolution to find the Telco user belongs to.
2. In case of SDK it is also available to read MCCMNC of the SIM.

That is why TelcoRouting service based on IP address is mandatory. Telco Public IP Pools should be publicly available and shared with Clients and Aggregators. The best approach will be to have separate API (under CAMARA) for export/synchronization of IP Pools, so that Clients and Aggregators can do synchronization of IP Pools with all Telcos in a unique way.

If you want to prevent Clients/Aggregators not to misuse /auth endpoint you can simple apply business model which will define ratio between /auth endpoint (Auth Code result) and other CAMARA API endpoints. Eg. if there is more then 20% of Auth Code result then API calls, then Client needs to pay some fee for that gap.

I would like you to explain the request `#9` in the sequence diagram of your solution. It appears that an `Authorization` header needs to be sent in the OAuth code flow, but that is not specified in the standard.
I would also like to know how the sequence diagram would look if the SIM does not belong to the operator.

In the current solution, using an endpoint restricted by signed requests according to RFC9101, if the aggregator were to use authorization as a method to determine whether a SIM belongs to an operator (at no cost in order to reduce requests to TelcoFinder), the operator could detect abuse and deactivate their credentials.

@ab-ip

See URL
This is under the Open Gateway Repo. This API provides both the static and dynamic routes; shared between telco finders of operators and aggregators.

@garciasolero

Agreed to drop this method as shown in `#9`. The signed request according to RFC9101 will be a better solution.

Are you referring to any of the following scenarios:
a) federated scenario, route to partner operator or
b) when the telco finder is unable to resolve the source Internet facing IP address?

a) federated scenario, route to partner operator or
b) when the telco finder is unable to resolve the source Internet facing IP address?

I am referring to what the flow would be if an operator received a request from a SIM that does not belong to it, regardless of whether there is an aggregator in front of it or not.

@garciasolero

Federated Architecture-Network Auth Service drawio

For the standalone Open Gateway, currently there is no route from the Internet to reach /authorize endpoint. Only the operator's SIM card can reach the internal /authorise endpoint. Blue dash path.

In the federated model, the Internet facing /authorize endpoint should only accept requests from partner / federated operators' CGNAT Internet IP address. A) We may assess this security posture of whitelisting partner CGNAT IP addresses and block the rest of the traffic. Pink dash path.

During the client onboarding process, the client will provide a redirect_uri.
B) If the /authorize endpoint observed source IP address (from a CGNAT) cannot be resolved in the operator's Telco Finder, the response will be the failure redirect_uri (with a newly defined error code), following OIDC Authorization Code Flow and OAuth 2.0 This is a graceful failure for the client.

What are your thoughts on this?

Provided a diagram for review NumberVerification issues 93

@garciasolero @jpengar

@ab-ip

Please consider +1 this Android feature request, which would allow client's mobile applications to get the operator's openid configuration
 URL

@AxelNennker +1 vote from my side.
This feature (API) is fine and useful, but unfortunately it won't solve Web use cases (but only App) and coverage issue will stay as well.
Having(knowing) OIDC Auth Endpoints does not mean that user can reach endpoint and be identified at the specific moment.
When we talk about Seamless Auth the crucial part (for Service Providers/App Devs) is to know that it is possible to handle (resolve/identify) specific user.
In order to determinate this possibility it is required to know that user is on Cellular(Mobile) Connection of specific (supported) Carrier. The best and easiest way to do this is definitely by IP address resolution.
You can check how IPification do it for last 4 years with many partners (including 60+ Carriers and 100+ Service Providers)

@AxelNennker The following is the proposed text for PR URL under OIDC Authorization Code Flow section.

----------------------

The OIDC Authorization Code Flow is defined in OpenID Connect and incorporates RFC 9101, Passing a Request Object by Value.

I suggest to move this issue or it resolution to the next version because I think incorporating this now would open up a longer discussion and I would like to get PR #121 soon.

Please add your comment whether we should mandate implementation of 9101 and that clients must us it

There are different solutions described as options to address the DDOS attack of the authZ server.
1. Solution 1 (non standard): app server requests one-time token from authZ server (protected by API gateway throttling features), one-time token is used by device on auth code request
2. Solution 2: RFC 9101: pass request object by value in the authorize request of the auth code flow
a. This requires that a key exchange happens upfront between the potential client device and the CSP, such that the client could use the private_key_jwt for singing.

Regarding solution 2:
We think that RFC 9101 does not solve not DDOS attack issues. (even though it addresses confidentiality and integrity issues). A malicious client will still be able to send “signed” authcode requests. Ericsson does not support making RFC 9101 mandatory.
RFC 9101 should not be made mandatory now.

Regarding solution 1:
This is non-standard and thus is not (yet) endorsed by Ericsson.

We recommend traditional API end point protection solutions (e.g. a firewall) on top of the AuthZ server to protect the AuthZ server from being overloaded.

In addition: there was a prior discussion in NumberVerification workgroup about securing the authorization end point sating: "GSMA have just approved a spec "ASAC.01-Seamless Authenticator subsystem enhancement for TS.43 Operator Token" which also deals with the security of the authorize endpoint… It may be a good idea to align with that initiative." - and the suggestion to align to this document in ICM. So we should not make a different solution mandatory now.

@Elisabeth-Ericsson

The RFC9101 was never a proposal to address DDoS attacks. That specification was proposed to avoid processing requests that do not come from authenticated clients. In other words, it aims to mitigate the processing of fraudulent requests that could lead to increased costs, such as queries to TelcoFinder.

Similarly, one-time tokens do not solve the DDoS problem, as the request still reaches the API Gateway and must be processed to check whether the token has been used before or not.

In addition to Fabio's comment, RFC9101was also proposed as a solution to avoid the potential PII leakage problem raised by Vonage in the past, as mentioned at URL

In any case, as mentioned in the 5 June WG meeting, RFC9101 was proposed by Telefónica as a possible solution to some of the issues raised in #128 and #138 for consideration by the WG. As discussed, if the WG decides to support RFC9101, it would be necessary to mandate its implementation/use to both, clients and operators. Otherwise, if clients could choose not to use it, we would not be addressing the concerns raised here.

**From Telefonica's point of view, we are fine with not mandating the implementation and support of RFC9101 for the time being. We propose to close this issue and leave RFC9101 support out of the scope of the next Fall24 meta-release. And revisit it in the future if necessary.**

As agreed in the June 19 WG meeting call, we exclude RFC 9101 from the scope of the next meta release, also considering the time constraints. It is recommended that the issue be closed for now and reopened in the future if necessary.

For the first Solution, OAuth2 has a specification standard 'RFC 9126: OAuth 2.0 Pushed Authorization Requests" by extending JAR with `request_uri`. I think it can be a solution for provide confidential, integrity and available (DDoS issue) for the authorization endpoint.


Question: Tree-sitter: use parse-trees to trigger multiline or singleline completions?

Closing this tracking issue since the remaining issues are low priority, and we can review them separately. I added them to the eng tracking board.

Tree-sitter: use parse-trees to trigger multiline or singleline completions
Currently, we decide which completion (multi vs. single) to trigger based on hardcoded block start symbols and a couple of regexes. We can use tree-sitter to categorize completion triggers and use them instead of the current approach for supported languages.

Examples:
* Function signature + open parens => generate full function body (even for long functions)
* Struct definitions => line by line (see how this affects CAR)

Let's consider this issue closed by:
1. URL
2. URL

The follow-up work will be tracked here: URL

Tracking issue: tree-sitter based completion intents (syntactic triggers)
A tracking issue for the tree-sitter-based completion intent work based on RFC 848: Tree-sitter-powered intent detection for Cody:

[tasklist]
### Completion Intents
- [x] URL
- [ ] URL
- [x] URL
- [ ] URL
- [ ] URL
- [ ] URL
- [x] URL

[tasklist]
### UPD
- [x] Use completion intent info to track CAR more granularly in Looker. Update the existing queries/logic if needed.
- [x] Pending the disable-streaming-truncation experiment results, consider leveraging intent information to expand the token limit for function/class declaration completion intents.
- [x] Analyze the results of the `syntactic-triggers` experiment where we switched multiline completions to singleline for type/struct/interface declaration intents. If this change positively affects CAR, make this a default behavior.
- [x] Make javascript completion intent queries more precise

### After GA Tasks:

[tasklist]
### After GA


Question: Should the excel file questionnaire prefix contain the suffix ccs01?

When I use this file as input, no files are generated, because there's no questionnaire or dataset prefix columns present.

Can I assume these columns will be present, and that this file is not correctly formatted?

[sws_covid_pq1_all_mappings_wip.xlsx
](url)

Should the excel file questionnaire prefix contain the suffix ccs01?
The QV output has _ccs01 appended to the questionnaire column, but it doesn't append it in the TQ output. Both should be questionnaireprefix_ccs01.

So should the _ccs01 be included in the Excel and used as is, or will it be appended automatically to both outputs?

"So should the _ccs01 be included in the Excel and used as is, or will it be appended automatically to both outputs?"

You tell me! I can modify the code so _ccs01 gets appended automatically to both outputs, that's not difficult. If it's difficult/fiddly to modify whatever process generates the Excel file so that _ccs01 is in the questionnaire prefix column, we can just modify the code.

Would it be trivial to include the _ccs01 suffix in the relevant columns in the Excel file?

Okay so it will be slightly easier for us if we didn't need to add the _ccs01 to the Excel, it's not onerous, but it might be easier for the studies to understand if it didn't include that.

SO can we go with the script appending the _ccs01 please?

So in that case, I think it's only the TQ output which needs updating to append the _ccs01, as the QV already has this.

It also means the filename of the output can just be the questionnaire prefix as is in the Excel file and the ccs01 won't need removing #14

I've pushed up a commit which adds _ccs01 to the values in the questionnaire prefix column in tq.txt

Names of exported files
The DV and TV now contain the dataset names in the filenames, as there could be more than one, for consistency, can we include the questionnaire prefix in the name (-ccs01) for the QV and TQ files?

Do you mean, that for the QV and TQ files, we should generate a file for every unique questionnaire prefix, and the title of those files should be a concatenation of the questionnaire prefix,'-ccs01', and '_qv.txt' , e.g. heaf_17_fup_4-ccs01_qv.txt?

Why do you have (-ccs01) in the opening message on this issue? That's confusing me.

Ah sorry it wasn't clear it was meant to be like minus the ccs01 which I think was in the excel files, but may not need to be see #15

I think I've implemented what you asked for, the qv and tq data are now in files named after the questionnaire prefixes. If there are multiple unique values for questionnaire prefixes in the input Excel file, there will be a text file generated for each one.


Question: go mod download 404 Not Found for private module?

@umputun and others: this should be fixed at head and on `release-branch.go1.13`. Could someone with access to a private GitLab subgroup please try a build from `release-branch.go1.13` and confirm?

go mod download 404 Not Found for private module
### Go version

1.23.1

### Output of `go env` in your module/workspace:

shell
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/grbit/.cache/go-build'
GOENV='/home/grbit/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/grbit/ssd/go/pkg/mod'
GONOPROXY='gitlab.com/nextpax,bitbucket.org/nextpaxcom'
GONOSUMDB='gitlab.com/nextpax,bitbucket.org/nextpaxcom'
GOOS='linux'
GOPATH='/home/grbit/ssd/go'
GOPRIVATE='gitlab.com/nextpax,bitbucket.org/nextpaxcom'
GOPROXY=' URL
GOROOT='/home/grbit/.local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/grbit/.local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.1'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/grbit/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3978658459=/tmp/go-build -gno-record-gcc-switches'

### What did you do?

go mod download -x gitlab.com/nextpax/nextpax-commons/v2@latest

### What did you see happen?

go mod download -x gitlab.com/nextpax/nextpax-commons/v2@latest
# get URL
# get URL 404 Not Found (0.264s)
# get URL
# get URL 404 Not Found (0.255s)
go: gitlab.com/nextpax/nextpax-commons/v2@latest: unrecognized import path "gitlab.com/nextpax/nextpax-commons/v2": reading URL 404 Not Found

### What did you expect to see?

I expect that module will be correctly downloaded. Something like

[0] $ go mod download -x gitlab.com/nextpax/nextpax-commons/v2@latest
# get URL
# get URL 200 OK (0.253s)
# get URL
# get URL 200 OK (0.186s)

From the same command line curl get 200 OK for this URL

$ curl -o /dev/null -s -w "%{http_code}\n" URL
200
$ curl URL

I want to debug what exactly go get does on my local machine, because I can not reproduce this behavior on any other machine. But the only option I have is `-x` option. I also have strace, but it doesn't give much info. The IP addresses are the same, but what `go mod` writes/reads to gitlab is different. Since it's https it's hard to dive inside to see the real difference.

If you could give my any clues on how to debug it, that would be nice.

**Related Issues and Documentation**

 - cmd/go: "package?go-get=1 404 not found" errors occurs when go get private project in internal private gitlab repository #64223 (closed)
 - cmd/go: get fails on gitlab subgroups due to go-import meta tags referring to nonexistent repos #34094 (closed)
 - cmd/go: get fail with private and subdirectory repo in module mode #29470 (closed)
 - cmd/go: "no go-import meta tags" when fetching from a private GitLab repo #37504 (closed)
 - cmd/go: GO111MODULE=on go get -v -insecure gitlab.com/xxx/xxx failed #32569 (closed)
 - go get -u all is attempting to find a VCS repository for a module path that is replaced with a local directory #40326 (closed)
 - Go modules issue with gitlab groups and sub-groups #34469 (closed)
 - x/tools/gopls 410 on private repository (not default branch) #39569 (closed)
 - cmd/go: "unknown revision" error is misleading if the entire repo can't be found #47028
 - Can't import package from non-github repo #43251 (closed)

 (Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For questions please refer to URL

Turned out it's a gitlab bug with access levels using tokens from `.netrc`, so techincally, the issue could be closed.

However, I see it as a big problem that you cannot debug `go mod` or `go get` behavior.
If anyone could suggest any ways to debug `go mod` that would be AMAZING, because I've spent hours trying to find a problem with no result. It refuses to use `http_proxy` env variable, it has nothing like curl `SSLKEYLOGFILE` functionality to read it's requests with wireshark. It's a total pain to debug it.

The final solution that helped me was `strace` that showed all the files read by `go mod`. That's how I found .netrc file with credentials and detected this gitlab access problem.

I wanted just a simple thing: add more verbosity to the way request is built by go, but I'm afraid there is no way to do it, and that's a problem.

@GRbit These are good issues to bring up in a forum, rather than the issue tracker. See URL Thanks.

cmd/go: get fails on gitlab subgroups due to go-import meta tags referring to nonexistent repos
### What version of Go are you using (`go version`)?

$ go version
go version go1.13 darwin/amd64

### Does this issue reproduce with the latest release?

yes

### What operating system and processor architecture are you using (`go env`)?

 go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/umputun/Library/Caches/go-build"
GOENV="/Users/umputun/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/umputun/go-home"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/usr/local/Cellar/go/1.13/libexec"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/umputun/tmp/t/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/fx/rzs1_n8137qfktxcbt_2v8pc0000gp/T/go-build570104617=/tmp/go-build -gno-record-gcc-switches -fno-common"

### What did you do?

1. Created a public project on gitlab URL with a module gitlab.com/umputuntests/sub/example
1. Tried to get it, i.e. `go get -v gitlab.com/umputuntests/sub/example`
1. go get failed

get "gitlab.com/umputuntests/sub/example": found meta tag get.metaImport{Prefix:"gitlab.com/umputuntests/sub/example", VCS:"git", RepoRoot:" URL at //gitlab.com/umputuntests/sub/example?go-get=1
get "gitlab.com/umputuntests/sub": found meta tag get.metaImport{Prefix:"gitlab.com/umputuntests/sub", VCS:"git", RepoRoot:" URL at //gitlab.com/umputuntests/sub?go-get=1
go: finding gitlab.com/umputuntests/sub/example v0.0.2
go: downloading gitlab.com/umputuntests/sub/example v0.0.2
go: extracting gitlab.com/umputuntests/sub/example v0.0.2
go get gitlab.com/umputuntests/sub/example: git ls-remote -q URL in /Users/umputun/go-home/pkg/mod/cache/vcs/410d993df4daac0579ff6b4402c511af12bd3d00851d05ab6183293d03664961: exit status 128:
 fatal: could not read Username for ' URL terminal prompts disabled
Confirm the import path was entered correctly.
If this is a private repository, see URL for additional information.

### What did you expect to see?

with prev versions of go (1.12.x) it works file:

 go get -v gitlab.com/umputuntests/sub/example
Fetching URL
Parsing meta tags from URL (status code 200)
get "gitlab.com/umputuntests/sub/example": found meta tag get.metaImport{Prefix:"gitlab.com/umputuntests/sub/example", VCS:"git", RepoRoot:" URL at URL
go: finding gitlab.com/umputuntests/sub/example v0.0.2
go: finding github.com/stretchr/testify v1.3.0
go: finding github.com/stretchr/objx v0.1.0
go: finding github.com/davecgh/go-spew v1.1.0
go: finding github.com/pmezard/go-difflib v1.0.0
go: downloading gitlab.com/umputuntests/sub/example v0.0.2
go: extracting gitlab.com/umputuntests/sub/example v0.0.2
gitlab.com/umputuntests/sub/example/strategy
gitlab.com/umputuntests/sub/example

### additional notes

I think this is both gitlab problem and go 1.13 change. Gitlab seems to return `go-import` tag on the parent, which doesn't exist and this seems to confuse "go get", trying to check module's parent.

curl " URL

In fact, gitlab returns good-looking `go-import` on any random path, for example:

curl " URL

Go 1.13 tries all module prefixes in parallel, and if another error other than "not-found" happens, the query fails. Of course the root cause is on gitlab side, but I think it's reasonable to ignore all errors if at least one attempt succeeds.
A quick workaround is clearing `err` if `found` is not empty in `queryPrefixModules()` in `cmd/go/internal/modload/query.go`.

I could see doing that if the provided Git URL itself returned a 404 or 410 status code, but note that `gitlab.com` today does not:

~$ curl -sI URL | grep HTTP
HTTP/1.1 401 Unauthorized

I'm running into issues with GitLab subgroups as well, but I'm getting a different error:

$ go get -u example.com/group/subgroup/my-go-project.git
go: finding example.com/group/subgroup/my-go-project.git latest
go get example.com/group/subgroup/my-go-project.git: git ls-remote -q URL in C:\Users\dev\go\pkg\mod\cache\vcs\5af58fdf9c9bd0fd298253dde7a0add3f4e5d6be34206b0b46f6805ee365d4ea: exit status 128:
 remote: The project you were looking for could not be found.
 fatal: repository ' URL not found

It almost seems like it's assuming that the second part of the path must be the project. Going back to 1.12 fixes it.

@bcmills I mean if a try on `gitlab.com/group/project` succeeds, we can ignore errors encountered trying `gitlab.com/group` and `gitlab.com/group/project/submodule`, no matter what they are.

@leonshaw, maybe..? The problem with that is that it's asymmetric.

If _I_ have credentials for module `example.com/foo` containing subdirectory `./bar/baz`, and _you_ have credentials for `example.com/foo/bar` containing subdirectory `./baz`, and we both run `go get example.com/foo/bar/baz`, then we'll end up with different results for the exact same query.

The solution to that is to treat responses other than 404/410 as hard errors. Then I'll fail to fetch `example.com/foo/bar`, and you'll fail to fetch `example.com/foo`, and we'll both (consistently!) know that we don't have enough credentials to produce a consistent result.

(More generally: if servers want to avoid leaking information to unauthenticated users, then it's more robust to deny the existence of every module rather than claim the existence of every module — especially now that #29888 is fixed.)

I don't think this is possible, at least with giltab, as they don't have "directory-level permissions" but repository-level only. Probably the same for gihub.

Even in case, if a user has credentials to every repo on the server, `go get` will fail to get that non-existing parent, but instead of the authorization failure `git ls-remote` complains about "Could not read from remote repository."

get "example.com/commons/pkg": found meta tag get.metaImport{Prefix:"example.com/commons/pkg", VCS:"git", RepoRoot:" URL at //example.com/commons/pkg?go-get=1
get "example.com/commons/pkg/multierror": found meta tag get.metaImport{Prefix:"example.com/commons/pkg/multierror", VCS:"git", RepoRoot:" URL at //example.com/commons/pkg/multierror?go-get=1
go get example.com/commons/pkg/multierror: git ls-remote -q URL in /Users/umputun/go-home/pkg/mod/cache/vcs/882b5ac6f69791979e3abd70af30e871e32fe91173f2e25079ef6a88464ec13e: exit status 128:

 fatal: Could not read from remote repository.

Is this something more fundamental? (A module can't be uniquely located by an import path.)

GitLab and GitHub are not the only ways to host a module. Ideally, the semantics of the `go` command should generalize to self-hosted domains with arbitrary structure.

A _module_ has a unique path. The mapping of _package paths_ to modules is not guaranteed to be 1:1, although the `go` command fails with an error message if any one package within the package `import` graph is provided by more than one module in the module graph.

Yes, this is the problem. We need a way to avoid the collision, if possible. If it's simply treated as error, `example.com/foo/bar` will be unusable if `example.com/foo` exists.

Probably, self-hosted giltab used by a majority of self-hosted git systems. However, this new behavior seems to conflict not with giltab only, but gitea as well and may conflict with any system surprised by parent discovery calls. I appreciate the generalized approach and concerns about asymmetrical behavior in some theoretical cases, but the current problem if very practical one.

I have most of a solution coded up, but there is a bad interaction with proxy fallback that I still need to work out.

Even then, my expectation is that a server that wishes to indicate “there is no repository here” (for a repository explicitly mentioned in a `go-import` ` ` tag) will serve a 404 or a 410 for the URL. I'm not sure whether `gitlab.com` does that for authenticated users, but for unauthenticated users they're currently serving 401s instead.

Change URL mentions this issue: `cmd/go/internal/modfetch: report the module path for errors in (*codeRepo).Versions`

Change URL mentions this issue: `cmd/go/internal/modfetch/codehost: treat nonexistent repositories as “not found”`

@gopherbot, please backport to 1.13: this is a regression, and prevents previously-working modules from being fetched.

Backport issue(s) opened: #34215 (for 1.13).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to URL

I've implemented the approach described in URL That should solve the problem *if* GitLab is correctly serving 404 or 410 responses for nonexistent paths for signed-in users.

However, I don't know whether they're doing that, so please help me confirm.

@umputun (or one of the other folks with this problem): please try a `go` command built from head and let me know whether your problem is resolved. (The easy way to try a `go` command built from head is to install `golang.org/x/dl/gotip`, then run `gotip download` and use `gotip` in place of the regular `go` command.)

Change URL mentions this issue: `[release-branch.go1.13] cmd/go/internal/modfetch/codehost: treat nonexistent repositories as “not found”`

@bcmills I have tried to test it with both public gitlab as well as self-hosted and it doesn't seem to work. I have also tried it with full credentials and git's "insteadOf" mapping from ` URL to `git@...` and it failed either. Both are working fine with 1.12.

You can try it with public repo from the original ticket, i.e. `go get -v gitlab.com/umputuntests/sub/example` vs `gotip get -v gitlab.com/umputuntests/sub/example`.

I don't think giltab does it. To me it looks like they return 401 on any non-existent paths. Probably adding 401 to the list of the errors on the parent discovery you consider as "missing module" may fix it.

The ticket I have opened on gitlab was closed by them as a duplicate to another, 2y old ticket they refused to address.

From what I understand, gitlab considers 404 on non-existent repos as a security issue, i.e. someone could realize what private repo exists. I don't think it has anything to do with authorized status - 401 seems to be returned on any nonexisting path regardless of the auth status.

Generally speaking, such behavior is a little bit odd, but not obviously wrong. `go get` is trying to access parent(s) of the repo which may not be repo at all, but some protected page/service. Sure it will be nice if gitlab return no `go-import` in such a case, but I guess they consider it security issue as well.

Ironically, GitHub seems to take the opposite approach: they return 404 for unauthenticated users.

For the example of `gitlab.com/umputuntests/sub/example`, the cat is already out of the bag: the non-401 response for ` URL already reveals the existence of the entities `gitlab.com/umputuntests` and `gitlab.com/umputuntests/sub`.

The same would seem to be true for private subgroups and appropriately-credentialed users.
So the “security issue” explanation does not seem to hold water.

Moreover, given that #29888 has been addressed in Go 1.13, it seems that they could simply stop serving the `go-import` meta tags in 401 responses in order to avoid revealing information to unauthenticated users.

Not sure I understand. Both `gitlab.com/umputuntests/sub` and `gitlab.com/umputuntests/sub/example` are public. If you try anything completely random, you will get 401 for any non-existent as well as any private repo. By doing this they are trying to hide the presence of private repos.

http URL
HTTP/1.1 401 Unauthorized

Http access to the real private repo as well as to non-existent repo redirects to gitlab.com/users/sign_in

I see what you mean, but technically it is not entirely accurate - they serve meta tags with 200 status, not 401

Sure, but the `go` command is not trying “anything completely random”. It is trying prefixes of the requested import path, and we are assuming that the user has sufficient credentials to at least reveal the existence of _some_ module with a matching prefix.

Understood. I believe the root cause is meta, gitlab returns unconditionally with 200 on any path, but for the end-user, it looks and feels like a regression in go 1.3 - before update modules worked with gitlab, and after the update, it stopped to work.

I'm not sure what changed with the parent discovery between 1.2 and 1.3, but if this is due to "Go 1.13 tries all module prefixes in parallel, and if another error other than "not-found" happens, the query fails." can this logic be adjusted to succeed if the repo has go.mod regardless of the parrent status? If such behavior is not acceptable generally, maybe some env param to make gitlab happy and allow such forgiving modules discovery?

@jamesramsay

With CL 194679 in, there are several possible fixes:

1. You could continue to serve ` ` tags for all URLs that could potentially exist as repositories, but serve 404s or 410s (instead of 401s) for requests for the actual repository (` URL when that the user is authorized to access any repository that has the requested path as a prefix.
 * For example: if the user is authorized to see ` URL then a response for ` URL or ` URL should have code 404 or 410, not 401.

2. You could remove the ` ` tags from ` URL responses for all URLs that don't correspond to actual repositories. (The HTTP response code does not matter as long as it is not a redirect.)
 * To preserve path secrecy, you would presumably want to also remove ` ` tags for repositories that the requester is not authorized to see. Unfortunately, that might cause `go get` to fail for users on Go 1.12 due to #29888 (which is fixed in 1.13).

3. You could remove the ` ` tags from ` URL responses for all URLs that don't correspond to actual repositories _when the user is authorized to access a repository that has the requested path as a prefix_.
 * For example, if the user is authorized to see ` URL then a response for ` URL should omit the ` ` tag, since the user already knows that that URL does not correspond to an actual repository.

@leonshaw

That's true, but turns out not to matter that much: the `go` command intentionally looks for ` ` tags even within 404 (or 401) responses.

(That is: the _content_ is what matters for the `?go-get=1` request, but the _status_ is what matters for the `.git` request, and the two are mostly orthogonal.)

@jamesramsay

In CL 173017, I changed the `go` command's algorithm for mapping an unresolved import path to the corresponding module path.

It was previously a sequential search starting from the longest path, working downward to progressively shorter paths, and the error handling was a bit sloppy.

Now, it searches in parallel for modules at all possible prefixes of the import path, which can significantly reduce overall latency (especially when a proxy is involved). However, the fact that the search occurs in parallel means that we end up trying a lot of potential module paths that turn out not to be valid.

We're fine with an invalid module path as long as the error is that the module does not exist.

* The main mechanism for a server to indicate “the module does not exist” is to not serve a ` ` tag for the `?go-get=1` request for that path.

* As of CL 194679, which is merged but not released, we also support a secondary mechanism: if the server provides a ` ` tag with an HTTPS URL, and that URL serves status 404 or 410, we interpret that to mean “the module would be at that URL if it existed, but it's not there so it doesn't exist.”

@bcmills - I had a chance to test this issue with gitea. For 1.13 the situation is similar to gitlab's, i.e. the same regression (worked with 1.12 and fails on 1.13). However, with gotip it worked fine. gitea seems to return go meta on any path, pretty much the same way as gitlab. However for those non-existing repos gitea, unlike gitlab, returns 404.

Thanks @bcmills and @umputun for all that context.

Our plan is to start returning a `404` in response to the first stage `?go-get=1` request if the project doesn't exist or if the user is not sufficiently authenticated. We're tracking the issue URL We don't have capacity to look into this in the current development cycle, but I'll try to have this scheduled soon. Of course, anyone from the community would also be welcome to contribute a fix too 😄

I'm having an issue related to getting a 410 when trying to get modules which previously worked in 1.12. The actual error I get is:

verifying gitlab.com/mycompany/subgroup/project.git@v1.0.4/go.mod: gitlab.com/mycompany/subgroup/project.git@v1.0.4/go.mod: reading URL 410 Gone

Is this related?

In my ~/.gitconfig, I have the following:

 [url "git@gitlab.com:"]
 insteadOf = git://gitlab.com/
 [url "git@gitlab.com:"]
 insteadOf = URL

Is there a reason you can't do the module search in parallel but still walk the results in reverse order of specificity, thus ignoring errors unless every path had an error?

The permissions argument doesn't seem like it really applies much. In general, Go assumes one module path means one source code repository. If you were to return different results based on permissions, you could do that at the git layer in the same way you might at the `?go-get=` resolution layer. Either way, you're seriously breaking the go view of the world, and you'll probably know you are, but have deliberately decided to take on any pain associated with differing code results.

The way things are now implemented, that potential for pain for offenders now becomes real pain for anybody who relied on the more obvious behavior before, including indirectly, as in the case of those simply using these version control systems.

Yeah, given the timeframe for fixes to the serving paths we should probably just do that.

(I'm not particularly happy about burying errors in general, but it seems like the least-unpleasant solution here.)

Change URL mentions this issue: `cmd/go: suppress errors in package-to-module queries if the package is already found`

Change URL mentions this issue: `[release-branch.go1.13] cmd/go: suppress errors in package-to-module queries if the package is already found`

Just tested the latest build on `release-branch.go1.13` and can confirm it works with a private GitLab subgroup.

Thanks for confirming.

In general we don't have a lot of different configurations of Git servers running in our test environment, so please do be sure to try out Beta and RC releases to catch any future regressions. (We do our best to test the cases we know about, but we don't know about all of the possible interactions.)

I'm going to leave this open to add a regression test on our end — I think this behavior, at least, we can replicate.

Does this mean that this will get fixed for Go1.14, but will still not work for 1.13?

@xavivars, this has already been fixed at head and backported to the 1.13 branch. It will be included in Go 1.13.3.

I've just tried with Go 1.13.3 but I still failed in `go get` my subgroup repository.

$ go version
go version go1.13.3 linux/amd64

$ go get -v gitlab.com/foo/bar/example
get "gitlab.com/foo/bar": found meta tag get.metaImport{Prefix:"gitlab.com/foo/bar", VCS:"git", RepoRoot:" URL at //gitlab.com/foo/bar?go-get=1
get "gitlab.com/foo/bar/example": found meta tag get.metaImport{Prefix:"gitlab.com/foo/bar", VCS:"git", RepoRoot:" URL at //gitlab.com/foo/bar/example?go-get=1
get "gitlab.com/foo/bar/example": verifying non-authoritative meta tag
go get gitlab.com/foo/bar/example: git ls-remote -q URL in /home/koala/Workspace/gopath/pkg/mod/cache/vcs/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: exit status 128:
 The project you were looking for could not be found.
 fatal: Could not read from remote repository.

 Please make sure you have the correct access rights
 and the repository exists.

@yookoala, you probably need to configure a `git` credential helper, or add a `.netrc` file containing credentials. (The `go` command is not intended to prompt for interactive logins.)

See URL and #29953.

I'm still seeing an issue with 1.13.3 on linux. It's pulling the code, but fails with an error.

go version go1.13.3 linux/amd64

GOPRIVATE=gitlab.my-org.com/* go get gitlab.my-org.com/subgroup/test/go-micro-example
go: finding gitlab.my-org.com/subgroup/test/go-micro-example latest
# runtime
/usr/local/go/src/runtime/stubs_x86.go:10:6: stackcheck redeclared in this block
 previous declaration at /usr/local/go/src/runtime/stubs_amd64x.go:10:6
/usr/local/go/src/runtime/unaligned1.go:11:6: readUnaligned32 redeclared in this block
 previous declaration at /usr/local/go/src/runtime/alg.go:321:40
/usr/local/go/src/runtime/unaligned1.go:15:6: readUnaligned64 redeclared in this block
 previous declaration at /usr/local/go/src/runtime/alg.go:329:40

@six-arm, that error message seems unrelated to the issue reported here. Please open a new issue with steps to reproduce.

Given that there is no `src/runtime/stubs_x86.go` file on `release-branch.go1.13`, I suspect that there is some problem with your `GOROOT` setting vs. the `go` command in use.

go version 1.13.3 fixed the problem. I have tried it against public (gitlab hosted) repo as well as self-hosted giltab. In both cases worked as expected. thx @bcmills and others helped to diagnose and address the problem.

should I close the ticket? This was my first ticket here and I'm not sure what the rule.

@umputun, thanks for confirming! I'm planning to leave the issue open for adding a more realistic regression test in 1.14 (probably during the freeze).

My go version:

simple description:
with private subgroup can not be `go get`, see below:
**my-group are public**
**my-private-group and it's project sample all are private**
**my-group and it's project sample all are public**
**private-demo are private**

go: finding git2.my-gitlab.net.cn/my-group/my-subgroup/sample latest
go: downloading git2.my-gitlab.net.cn/my-group/my-subgroup/sample v0.0.0-20191022081546-6534fce037e9
go: extracting git2.my-gitlab.net.cn/my-group/my-subgroup/sample v0.0.0-20191022081546-6534fce037e9

go get git2.my-gitlab.net.cn/my-group/my-private-subgroup/sample: git ls-remote -q origin in D:\workspace\code\go\pkg\mod\cache\vcs\8314af4c2579c0ee8b974f039f8246d179834d34c834680bfe59ce583888c820: exit status 128:
 remote: The project you were looking for could not be found.
 fatal: repository ' URL not found

go: finding git2.my-gitlab.net.cn/my-group/private-demo latest
go: downloading git2.my-gitlab.net.cn/my-group/private-demo v0.0.0-20191022084509-90eb539586c8
go: extracting git2.my-gitlab.net.cn/my-group/private-demo v0.0.0-20191022084509-90eb539586c8

So, have you tested private group or subgroup on gitlab?

Thanks anyway!

No, I didn't but tried it now with similar setup - `commons` group public, `pkg` subgroup public and `syncs` repo private (internal in gitlab's permissions). I see very similar results:

go version go1.13.3 darwin/amd64

go get -v git.internal.com/commons/pkg/syncs
get "git.internal.com/commons/pkg": found meta tag get.metaImport{Prefix:"git.internal.com/commons/pkg", VCS:"git", RepoRoot:" URL at //git.internal.com/commons/pkg?go-get=1
get "git.internal.com/commons/pkg/syncs": found meta tag get.metaImport{Prefix:"git.internal.com/commons/pkg", VCS:"git", RepoRoot:" URL at //git.internal.com/commons/pkg/syncs?go-get=1
get "git.internal.com/commons/pkg/syncs": verifying non-authoritative meta tag
go get git.internal.com/commons/pkg/syncs: git ls-remote -q URL in /Users/umputun/go-home/pkg/mod/cache/vcs/882b5ac6f69791979e3abd70af30e871e32fe91173f2e25079ef6a88464ec13e: exit status 128:

 fatal: Could not read from remote repository.

 Please make sure you have the correct access rights
 and the repository exists.

Not sure if important, but to access private repos from go I use insteadOf rewrite:

 [url "git@git.internal.com:"]
 insteadOf = URL

@umputun, thanks for the additional detail.

This line in particular:

get "git.internal.com/commons/pkg/syncs": found meta tag get.metaImport{Prefix:"git.internal.com/commons/pkg", VCS:"git", RepoRoot:" URL at //git.internal.com/commons/pkg/syncs?go-get=1

seems to indicate a bug or misconfiguration on the server side. If the repo is hosted at `git.internal.com/commons/pkg/syncs`, then the server should reply with that as the prefix and ` URL as the repo root (instead of the `git.internal.com/commons/pkg` subgroup as shown).

Did that repository work with Go 1.12?

doesn't work with 1.12 either

go version go1.12.12 linux/amd64, from `golang:1.12` container:

go get -v git.internal.com/commons/pkg/syncs

Fetching URL
Parsing meta tags from URL (status code 200)
get "git.internal.com/commons/pkg/syncs": found meta tag get.metaImport{Prefix:"git.internal.com/commons/pkg", VCS:"git", RepoRoot:" URL at URL
get "git.internal.com/commons/pkg/syncs": verifying non-authoritative meta tag
Fetching URL
Parsing meta tags from URL (status code 200)
Fetching URL
Parsing meta tags from URL (status code 200)
get "git.internal.com/commons/pkg": found meta tag get.metaImport{Prefix:"git.internal.com/commons/pkg", VCS:"git", RepoRoot:" URL at URL
Fetching URL
Parsing meta tags from URL (status code 200)
Fetching URL
Parsing meta tags from URL (status code 200)
go get git.internal.com/commons/pkg/syncs: git ls-remote -q origin in /go/pkg/mod/cache/vcs/82b580717104e8b7bf1de06ef2b675a3ca5bf7d044f776fac4629633677f22da: exit status 128:

 fatal: Could not read from remote repository.

 Please make sure you have the correct access rights
 and the repository exists.

However with ~/.netrc everyting seems to work (1.1.13):

go get -v git.internal.com/commons/pkg/syncs
get "git.internal.com/commons/pkg": found meta tag get.metaImport{Prefix:"git.internal.com/commons/pkg", VCS:"git", RepoRoot:" URL at //git.internal.com/commons/pkg?go-get=1
get "git.internal.com/commons/pkg/syncs": found meta tag get.metaImport{Prefix:"git.internal.com/commons/pkg/syncs", VCS:"git", RepoRoot:" URL at //git.internal.com/commons/pkg/syncs?go-get=1
go: finding git.internal.com/commons/pkg/syncs v1.1.0
go: downloading git.internal.com/commons/pkg/syncs v1.1.0
go: extracting git.internal.com/commons/pkg/syncs v1.1.0
get "git.internal.com/commons/pkg/multierror": found meta tag get.metaImport{Prefix:"git.internal.com/commons/pkg/multierror", VCS:"git", RepoRoot:" URL at //git.internal.com/commons/pkg/multierror?go-get=1
git.internal.com/commons/pkg/multierror
git.internal.com/commons/pkg/syncs

So, looks like .gitconfig insteadOf doesn't play well with go mods, but .netrc is fine.

`.netrc` is what I would recommend anyway, so it sounds like the overall state is improving, at least. (`.netrc` wasn't working well in 1.12.)

I'm still facing this issue with `go version go1.13.3 darwin/amd64`

@sha256x, “this issue” as reported by its original author has been verified as fixed. If you're seeing a similar symptom, please open a new issue with details and steps to reproduce it.

@bcmills @sha256x @umputun There is still the issue where with git-based URL rewriting in combination with GitLab groups you cannot successfully `go get ...` a repo unless you tell `go get` in the import path where the git repo actually is, such as `foo.bar.org/user/group1/group2/project.git` -- and then go modules throw up because the canonical path of that module is `foo.bar.org/user/group1/group2/project` without any `.git` adornments. Am I supposed to change the canonical import paths of my private Go modules now to carry that `.git` adornment?

Can you please explain? (otherwise, I cannot see how your reply might be of use to those who are not enlightened enough, such as me.)

@TheDiveO We had a similar problem, we solved it by using the `replace` directive. For example:

require (
 private.gitlab.instance/project/team/somename v1.0.0
)

replace (
 private.gitlab.instance/project/team/somename => private.gitlab.instance/project/team/somename.git v1.0.0
)

However please be aware that this solution does not work cleanly when trying to upgrade that said package to non-tagged versions, for example you would need to do something like:

go get private.gitlab.instance/project/team/somename.git@somecommithash

Which then will fail with a message similar to:

go: finding private.gitlab.instance/project/team somecommithash
go: finding private.gitlab.instance/project/team/somename.git somecommithash
go: downloading private.gitlab.instance/project/team/somename.git vXYZ-somecommithash
go: extracting private.gitlab.instance/project/team/somename.git vXYZ-somecommithash
go get: private.gitlab.instance/project/team/somename.git@vXYZ-somecommithash: parsing go.mod:
 module declares its path as: private.gitlab.instance/project/team/somename
 but was required as: private.gitlab.instance/project/team/somename.git

We literally have to copy `vXYZ-somecommithash`, manually edit `go.mod` and the overwrite that value, changing it to something like

require (
 private.gitlab.instance/project/team/somename v1.0.0
)

replace (
 private.gitlab.instance/project/team/somename => private.gitlab.instance/project/team/somename.git vXYZ-somecommithash
)

@TheDiveO, @MarioCarrion: if you are having issues with GitLab subgroups for reasons unrelated to the root cause originally reported for this issue, please open a new issue with details and steps to reproduce. Thanks.

I didn't get to the more realistic regression test during the 1.14 cycle, and by now I don't remember which cases were remaining to be tested. 😞

I'm happy to review further improvements to GitLab integration testing, but I don't think we need to leave this issue open.

GitLab Community Edition 12.3.5 self-hosted
golang 1.13.8 & 1.14
this issue still there

@Yi-Hunter, “this issue” as reported by its original author has been verified as fixed. If you're seeing a similar symptom, please open a new issue with details and steps to reproduce it.


Question: TypeError: Cannot read properties of undefined (reading 'sourceName')?

That's the first item in the checklist.

That's a llimitation of npm when a peer dependency and a pre-release version are mixed. You might need to use `npm install --force` when installing the `hardhat@ir` beta version.

TypeError: Cannot read properties of undefined (reading 'sourceName')
### Version of Hardhat

2.12.7

### What happened?

21 passing (2s)
 1 failing

/Users/k06a/Projects/limit-order-protocol/node_modules/hardhat/internal/hardhat-network/stack-traces/solidity-errors.js:111
 return new SolidityCallSite(sourceReference.sourceName, sourceReference.contract, sourceReference.function !== undefined
 ^

TypeError: Cannot read properties of undefined (reading 'sourceName')
(Use `node --trace-uncaught ...` to show where the exception was thrown)
error Command failed with exit code 7.
info Visit URL for documentation about this command.

### Minimal reproduction steps

On the following commit URL

yarn && yarn test:ci --bail

### Search terms

_No response_

Hey,

This should be fixed by #3415. I published a pre-release version of it as `hardhat@viair` and run your tests and now I get

Can you check if that error is correct?

@alcuadrado seems like something which can be correct for sure.

Resolved the error for me.

`MultiSolcUserConfig` compiler entry

{
 version: "0.8.14",
 settings: {
 viaIR: true,
 optimizer: {
 enabled: true,
 runs: 200,
 details: {
 constantOptimizer: false,
 deduplicate: true,
 yul: true,
 },
 },
 outputSelection: {
 "*": {
 "*": [
 "metadata",
 "abi",
 "storageLayout",
 "evm.methodIdentifiers",
 "devdoc",
 "userdoc",
 "evm.gasEstimates",
 "evm.byteCode",
 ],
 },
 },
 },
},

Pretty sure this is caused by #3365, so I'm tentatively closing this.

Support for IR
This is the tracking issue for having full support for solc's IR-based code generation.

We have already released a beta version with some basic support under the `ir` npm tag. This version can be installed with `npm install hardhat@ir`.

There are some pending things before we can release this in a stable version of Hardhat:

- [ ] Reverts with a reason string sometimes are not correctly handled (see discussion in #2453). I'm not sure if this was fixed on the `ir` version or not.
- [ ] What are exactly the best settings to have `viaIR` enabled but not lose important information used by stack traces and error inferring? Can we enable those settings automatically or should users do it?
- [ ] `solidity-coverage` seems to have issues when `viaIR` is enabled (see for example this comment). It's not clear if this is a problem in Hardhat or in the coverage plugin, or in both. It might also be just a documentation issue.
- [ ] At some point the "contract too large" heuristic wasn't working (see #2115). I believe this is fixed in the `ir` version, but we should double-check.

The issue I'm having is my tests are now failing with viaIR: true, specifically the ones that check the revertedWith message. Which is a lot of them.

For now, I'm having to turn viaIR off. Help me help us get to the bottom of it!

Also, turns out that hardhat@ir doesn't work with my version of solidity-coverage:

pm ERR! While resolving: @nomicfoundation/hardhat-toolbox@1.0.2
npm ERR! Found: solidity-coverage@0.8.2
npm ERR! node_modules/solidity-coverage
npm ERR! dev solidity-coverage@"^0.8.2" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer solidity-coverage@"^0.7.21" from @nomicfoundation/hardhat-toolbox@1.0.2
npm ERR! node_modules/@nomicfoundation/hardhat-toolbox
npm ERR! @nomicfoundation/hardhat-toolbox@"^1.0.2" from the root project
npm ERR!
npm ERR! Conflicting peer dependency: solidity-coverage@0.7.22
npm ERR! node_modules/solidity-coverage
npm ERR! peer solidity-coverage@"^0.7.21" from @nomicfoundation/hardhat-toolbox@1.0.2
npm ERR! node_modules/@nomicfoundation/hardhat-toolbox
npm ERR! @nomicfoundation/hardhat-toolbox@"^1.0.2" from the root project

Yup, thanks. I did --force and that worked.

It also works when running npm hardhat test. But when running coverage I get stack too deep.

Is there a timeline for this to be included in the main release? Now that it's mark as ready I mean

@jmendiola222 we want to release this ASAP. Hopefully this or next week; definitely January.

With IR, I get the following exception:

AssertionError: Expected transaction to be reverted with ABC, but other
exception was thrown: ProviderError: Error: Transaction reverted: function
was called with incorrect parameters

from a function as simple as:

function f() public {
 revert("ABC");
}

When IR is not used, or other parts of the contracts are tinkered, or YUL steps are tinkered, the issue resolves. This issue is very similar to URL so I suspect it's a Hardhat issue.

I tried many combinations of recent Solidity versions with Hardhat `2.12.6` and `2.12.1-ir.0`. My compiler settings are:

viaIR: true,
optimizer: {
 enabled: true,
 runs: 200
}

Currently working around the issue with a custom order of YUL optimization steps.

Let me know if you think if this's a Solidity issue.

This's the stack trace from Hardhat `2.12.6`:

eth_estimateGas
 Error: Transaction reverted: function was called with incorrect parameters
 at Contract.f
 at processTicksAndRejections (node:internal/process/task_queues:96:5)
 at async EthModule._estimateGasAction (node_modules/hardhat/src/internal/hardhat-network/provider/modules/eth.ts:429:7)
 at async HardhatNetworkProvider._sendWithLogging (node_modules/hardhat/src/internal/hardhat-network/provider/provider.ts:139:22)
 at async HardhatNetworkProvider.request (node_modules/hardhat/src/internal/hardhat-network/provider/provider.ts:116:18)
 at async JsonRpcHandler._handleRequest (node_modules/hardhat/src/internal/hardhat-network/jsonrpc/handler.ts:188:20)
 at async JsonRpcHandler._handleSingleRequest (node_modules/hardhat/src/internal/hardhat-network/jsonrpc/handler.ts:167:17)
 at async Server.JsonRpcHandler.handleHttp (node_modules/hardhat/src/internal/hardhat-network/jsonrpc/handler.ts:52:21)

It didn't make it to the last release. :( Any update on the plan? @fvictorio

I'm planning on merging that PR today, so it will definitely be included in the next release (this time for real :sweat_smile:).

this warning when running tests

Your solidity settings have viaIR enabled, which is not fully supported yet. You can still use Hardhat, but some features, like stack traces, might not work correctly.

and losing information about error strings

AssertionError: error string Error: Transaction reverted and Hardhat couldn't infer the reason.

with 2.13.0


Question: Places: cannot edit page (editorial team not on Fre side)?

Also occurring on the Know the hazards in your community page.

Related Drupal error message here.

InvalidArgumentException: The URI '/en/prevent-prepare-wildfire#prepare-for-an-approaching-wildfire' is invalid. You must use a valid URI scheme. in Drupal\Core\Url::fromUri() (line 293 of /var/www/yukon-ca-d10/docroot/core/lib/Drupal/Core/Url.php).

Places: cannot edit page (editorial team not on Fre side)
Users are not able to edit a places record. This is because on the French side, the editorial team is not selected. Linked to URL

Linked to
Editing page leads to "encountered unexpected error" (InvalidArgumentException error) · Issue #746 · ytgov/yukon-ca

Department field missing on French side of Places · Issue #810 · ytgov/yukon-ca

Please review this PR - #824

This is a custom function that will update data on hitting the URL below:

 URL

Editing page leads to "encountered unexpected error" (InvalidArgumentException error)
When trying to edit a node, the site crashes with the error:

This seems to apply only to certain roles.

This is when accessing URL with a use having the following roles:
- Writer
- Editor
- Publisher
- Author In-Page Alerts
- Blog Author
- Author Site-Wide Alerts

I am able to load the node-edit page with a user having the "administrator" role.

Error reported from Drupal (visible in Watchdog):

Reported by YHC

I'm unable to re-save that record, as it doesn't have any "Places record type" value. It looks like D7 doesn't have one either. Strange.

I've since made the "Places record type" not required on D10, and re-save the record. It now appears editable by others.

Curiously, the list of available paragraph types from the "Places record type" list doesn't match what it's configured for.

<img width="719" alt="Screen Shot 2024-12-06 at 12 37 28 PM" src=" URL

<img width="925" alt="Screen Shot 2024-12-06 at 12 38 21 PM" src=" URL

This was reported again for URL e.g. URL

Same also on prod.

Linked to
Places: cannot edit page (editorial team not on Fre side) · Issue #817 · ytgov/yukon-ca
Department field missing on French side of Places · Issue #810 · ytgov/yukon-ca

Please review this PR - #824

This is a config change. This was because of Linkit module. We have changed the setting as shown in the screenshot.

 URL

This was recently reported for some campground pages

- URL
- URL
- URL
- URL

The watchdog log showed:

We can address issue as it arises, but that can be a lot of work when it's a large grouping of pages.

Updating the widget option linkit >> link for solve latest comment issue.

Affecting campground pages. Seems to be fixed if Text format dropdown menu under Site description (app) field is changed to plain text

 Camping Nunatuk | Yukon.ca

Camping Rock River | Yukon.ca

Camping Simpson Lake | Yukon.ca


Question: [PRE REVIEW]: blendR: An R package for blending survival curves?

Check final proof :point_right: URL

If the paper PDF and Crossref deposit XML look good in URL then you can now move forward with accepting the submission by compiling again with the flag `deposit=true` e.g.

@whedon accept deposit=true

[PRE REVIEW]: blendR: An R package for blending survival curves
**Submitting author:** @n8thangreen ( )
**Repository:** URL
**Branch with paper.md** (empty if default branch): JOSS-paper
**Version:** v1.0.0
**Editor:** @lrnv
**Reviewers:** @NicolasNgo, @Nicolas-Schmidt
**Managing EiC:** Chris Vernon

## Status

status

Status badge code:

HTML: <a href=" URL src=" URL
Markdown: status

**Author instructions**

Thanks for submitting your paper to JOSS @n8thangreen. **Currently, there isn't a JOSS editor assigned** to your paper.

@n8thangreen if you have any suggestions for potential reviewers then please mention them here in this thread (without tagging them with an @). You can search the list of people that have already agreed to review and may be suitable for this submission.

**Editor instructions**

The JOSS submission bot @editorialbot is here to help you find and assign reviewers and start the main review. To find out what @editorialbot can do for you type:

@editorialbot commands

**License info**:

🟡 License found: `GNU General Public License v3.0` (Check here for OSI approval)

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

**Five most similar historical JOSS papers:**

⚠ **Important note to authors:** Please do not directly contact the authors of these papers. If you believe these papers are relevant to your submission, please mention this in your submission or communicate with your handling editor.

BayesMFSurv: An R Package to Estimate Bayesian Split-Population Survival Models With (and Without) Misclassified Failure Events
Submitting author:
@Nicolas-Schmidt

Handling editor:
@marcosvital (Active)

Reviewers:
@alletsee, @andybega

Similarity score: 0.6731

survxai: an R package for structure-agnostic explanations of survival models
Submitting author:
@AleksandraDabrowska

Handling editor:
@yochannah (Retired)

Reviewers:
@hiendn, @dirmeier

Similarity score: 0.6620

SurPyval: Survival Analysis with Python
Submitting author:
@derrynknife

Handling editor:
@dfm (Retired)

Reviewers:
@CamDavidsonPilon, @MatthewReid854

Similarity score: 0.6473

RBF: An R package to compute a robust backfitting estimator for additive models
Submitting author:
@alemermartinez

Handling editor:
@mikldk (Retired)

Reviewers:
@mcavs, @mmrabe

Similarity score: 0.6397

PyMSM: Python package for Competing Risks and Multi-State models for Survival Data
Submitting author:
@hrossman

Handling editor:
@majensen (Active)

Reviewers:
@CamDavidsonPilon, @stefanocoretta

Similarity score: 0.6302

⚠ **Note to editors:** If these papers look like they might be a good match, click through to the review issue for that paper and invite one or more of the authors *before* considering asking the reviewers of these papers to review again for JOSS.

Sorry but I am not available to perform this review

Have a great day

Sincerely,

Mathieu FAUVERNIER

Le mer. 27 août 2025 à 15:23, Oskar Laverny ***@***.***> a
écrit :

I would be interested in this review, but I won't be available before October.

Kind regards,

@Nicolas-Schmidt, @NicolasNgo , @n8thangreen, let us change thread for the review itself.

[REVIEW]: survxai: an R package for model agnostic explanations of survival models
**Submitting author:** @AleksandraDabrowska ( )
**Repository:** URL
**Version:** 0.2.0
**Editor:** @yochannah
**Reviewer:** @hiendn, @dirmeier
**Archive:** 10.5281/zenodo.1477857

## Status

status

Status badge code:

HTML: target repository and link to those issues (especially acceptance-blockers) in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)

## Reviewer instructions & questions

@hiendn & @dirmeier, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:
1. Make sure you're logged in to your GitHub account
2. Be sure to accept the invite at this URL: URL

The reviewer guidelines are available here: URL Any questions/concerns please let @yochannah know.

✨ **Please try and complete your review in the next two weeks** ✨

## Review checklist for @hiendn
### Conflict of interest

- [x] As the reviewer I confirm that I have read the JOSS conflict of interest policy and that there are no conflicts of interest for me to review this work.

### Code of Conduct

- [x] I confirm that I read and will adhere to the JOSS code of conduct.

### General checks

- [x] **Repository:** Is the source code for this software available at the ?
- [x] **License:** Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
- [x] **Version:** Does the release version given match the GitHub release (0.2.0)?
- [x] **Authorship:** Has the submitting author (@AleksandraDabrowska) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

### Functionality

- [x] **Installation:** Does installation proceed as outlined in the documentation?
- [x] **Functionality:** Have the functional claims of the software been confirmed?
- [x] **Performance:** If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

### Documentation

- [x] **A statement of need:** Do the authors clearly state what problems the software is designed to solve and who the target audience is?
- [x] **Installation instructions:** Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
- [x] **Example usage:** Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
- [x] **Functionality documentation:** Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
- [x] **Automated tests:** Are there automated tests or manual steps described so that the function of the software can be verified?
- [x] **Community guidelines:** Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

### Software paper

- [x] **Authors:** Does the `paper.md` file include a list of authors with their affiliations?
- [x] **A statement of need:** Do the authors clearly state what problems the software is designed to solve and who the target audience is?
- [x] **References:** Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?

## Review checklist for @dirmeier
### Conflict of interest

- [x] As the reviewer I confirm that I have read the JOSS conflict of interest policy and that there are no conflicts of interest for me to review this work.

### Code of Conduct

- [x] I confirm that I read and will adhere to the JOSS code of conduct.

### General checks

- [x] **Repository:** Is the source code for this software available at the ?
- [x] **License:** Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
- [x] **Version:** Does the release version given match the GitHub release (0.2.0)?
- [x] **Authorship:** Has the submitting author (@AleksandraDabrowska) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

### Functionality

- [x] **Installation:** Does installation proceed as outlined in the documentation?
- [x] **Functionality:** Have the functional claims of the software been confirmed?
- [x] **Performance:** If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

### Documentation

- [x] **A statement of need:** Do the authors clearly state what problems the software is designed to solve and who the target audience is?
- [x] **Installation instructions:** Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
- [x] **Example usage:** Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
- [x] **Functionality documentation:** Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
- [x] **Automated tests:** Are there automated tests or manual steps described so that the function of the software can be verified?
- [x] **Community guidelines:** Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

### Software paper

- [x] **Authors:** Does the `paper.md` file include a list of authors with their affiliations?
- [x] **A statement of need:** Do the authors clearly state what problems the software is designed to solve and who the target audience is?
- [x] **References:** Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @hiendn, it looks like you're currently assigned as the reviewer for this paper :tada:.

**:star: Important :star:**

If you haven't already, you should seriously consider unsubscribing from GitHub notifications for this ( URL repository. As a reviewer, you're probably currently watching this repository which means for GitHub's default behaviour you will receive notifications (emails) for all reviews 😿

To fix this do the following two things:

1. Set yourself as 'Not watching' URL

watching

2. You may also like to change your default settings for this watching repositories in your GitHub profile here: URL

notifications

For a list of things I can do to help you, just type:

@whedon commands

Hi @AleksandraDabrowska, I am one of your reviewers! My comments and suggestions will be posted on the issues page of your repository.

Quick status check - looking at the original repo, issues 18 to [21[( URL need to be addressed before we can take this one forward, right?

Yeah, exactly. From my side these two and 20. All of them are minor changes.

@yochannah that's correct, resolving 22 would be good as well, if possible.

Hey @AleksandraDabrowska - could you rebuild the pdf once you are finished with the reviews? Then I can close the respective issues in your repository.

:point_right: Check article proof :page_facing_up: :point_left:

@hiendn @dirmeier Thank you very much for reviewing and for your kind words! :)
Should we now issue a DOI for our archive, as it is written in "The review process" section ( URL

@AleksandraDabrowska Looking good! Before generating the archive, though, there is one issue with the manuscript I'd like to fix. Figures 3 and 4 are interspersed with the references in the most recent proof, but I'm reasonably sure they should be up in the main paper text. Can you fix this? Once this is fixed, please do generate an archive and share the URL in this thread!! 🎉

Doing it live! Attempting automated processing of paper acceptance...

🚨🚨🚨 **THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS!** 🚨🚨🚨

 Here's what you must now do:

0. Check final PDF and Crossref metadata that was deposited :point_right: URL
1. Wait a couple of minutes to verify that the paper DOI resolves URL
2. If everything looks good, then close this review issue.
3. Party like you just published a paper! 🎉🌈🦄💃👻🤘

 Any issues? notify your editorial technical team...

@hiendn, @dirmeier - many thanks for your reviews here, and to @yochannah for editing this submission ✨

@AleksandraDabrowska - your paper is now accepted into JOSS :zap: :rocket: :boom:

:tada::tada::tada: Congratulations on your paper acceptance! :tada::tada::tada:

If you would like to include a link to your paper from your README use the following code snippets:

Markdown:
DOI

HTML:

reStructuredText:
.. image:: URL
 :target: URL

This is how it will look in your documentation:

DOI

**We need your help!**

Journal of Open Source Software is a community-run journal and relies upon volunteer effort. If you'd like to support us please consider doing either one (or both) of the the following:

- Volunteering to review for us sometime in the future. You can add your name to the reviewer list here: URL
- Making a small donation to support our running costs here: URL