g-node / gin-dex Goto Github PK

Due to GitHub handle change (to lowercase) for long term purpose, go get may fail fetching github.com/Unknwon/com.
Please consider take some time to update it to github.com/unknwon/com in the go.mod file.
I truly apology for the inconvenience and unintended troubles caused.

Upstream fixes on GOGS for CSRF vulnerabilities require auth tokens for API calls (gogs/gogs#5399). gin-dex uses the user's browser cookie to make API calls, which doesn't work anymore. Getting a token for a user on behalf of gin-dex is probably not possible (and is probably a bad idea anyway).

API calls from gin-dex to GIN-GOGS are made to list user repositories for limiting search results. In general, for our peripheral services (DOI, valid), we prefer to keep them decoupled from GOGS, so the external services are designed to query the GOGS API when needed. In this case, the coupling is necessarily tighter (menu items and search forms are added to the GOGS explore pages). I suggest we redesign queries so that they only depend on information flowing from GOGS to gin-dex and the inverse only for responses.

Current method

• User enters query in GOGS
• GOGS calls gin-dex API with search query
• gin-dex retrieves user cookie and CSRF token
• gin-dex queries GOGS on behalf of the user to get a list of repository IDs the user has access to
• gin-dex queries elasticsearch, limiting search (and results) only to repositories the user has access to
• gin-dex returns results to GOGS

Proposed method

• User enters query in GOGS
• GOGS collects repository IDs the user has access to
• GOGS calls gin-dex API with search query + repository IDs
• gin-dex queries elasticsearch (with repo limits like before)
• gin-dex returns results to GOGS
• GOGS validates returned repository IDs

Security considerations

gin-dex security is important because lax security can leak private repository data. One issue with the proposed method is that if gin-dex API is exposed to public queries, an attacker can use it to retrieve private data simply by submitting a general query with a wide range of repository IDs. We shouldn't base our security on gin-dex always being inaccessible to the public internet. To clarify, it may be necessary (or desirable) in the future to run gin-dex on a separate (virtual) machine, in which case GOGS will need to query a publicly available endpoint.

Proposed secure method

We could add a shared key (like we do with gin-doi) to encrypt queries from GOGS to gin-dex. The proposed method will then be adapted as follows:

• GOGS and gin-dex are configured with a shared key
• User enters query in GOGS
• GOGS collects repository IDs the user has access to
• GOGS calls gin-dex API with search query + encrypted repository IDs
• gin-dex decrypts the repository ID list and checks
• gin-dex queries elasticsearch
• gin-dex returns encrypted results to GOGS
• GOGS decrypts results

The last step of the proposed methods is probably redundant if the security is designed properly, but I'd rather keep it.

I initially considered adding a nonce to the query to avoid replay attacks but then I realised encrypting the response should be enough.