mirror of
https://gitea.com/gitea/docs.git
synced 2026-09-19 20:48:52 +00:00
1524b67c00c942015da3dde86bc0d71860c64bd1
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Renovate Bot
|
1524b67c00 |
fix(deps): update dependency sharp to v0.35.0 [security] (#524)
This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---| | [sharp](https://sharp.pixelplumbing.com) ([source](https://github.com/lovell/sharp), [changelog](https://github.com/lovell/sharp/blob/main/docs/src/content/docs/changelog.md)) | [`0.34.5` → `0.35.0`](https://renovatebot.com/diffs/npm/sharp/0.34.5/0.35.0) |  |  | --- ### sharp inherited vulnerabilities in libvips: CVE-2026-33327, CVE-2026-33328, CVE-2026-35590, CVE-2026-35591 [GHSA-f88m-g3jw-g9cj](https://github.com/advisories/GHSA-f88m-g3jw-g9cj) <details> <summary>More information</summary> #### Details ##### Impact A number of vulnerabilities, two rated as "High" severity using CVSSv4, have been discovered and fixed in the upstream libvips dependency. Those processing untrusted input with versions of sharp prior to 0.35.0 are affected. ##### Patches ##### Using prebuilt binaries provided by sharp? Most people rely on the prebuilt binaries provided by sharp. Please upgrade sharp to the latest version, currently 0.35.3, which provides libvips 8.18.3. ##### Using a globally-installed libvips? Please ensure you are using the latest libvips 8.18.3. ##### Workarounds Add the following to your code to prevent sharp from decoding GIF, TIFF and VIPS images. ```js sharp.block({ operation: ["VipsForeignLoadNsgif", "VipsForeignLoadTiff", "VipsForeignLoadVips"] }); ``` #### Severity - CVSS Score: 7.0 / 10 (High) - Vector String: `CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N` #### References - [https://github.com/libvips/libvips/security/advisories/GHSA-2fcj-gj27-279x](https://github.com/libvips/libvips/security/advisories/GHSA-2fcj-gj27-279x) - [https://github.com/libvips/libvips/security/advisories/GHSA-523x-vhfw-6r76](https://github.com/libvips/libvips/security/advisories/GHSA-523x-vhfw-6r76) - [https://github.com/libvips/libvips/security/advisories/GHSA-jmwm-wc68-mhwm](https://github.com/libvips/libvips/security/advisories/GHSA-jmwm-wc68-mhwm) - [https://github.com/libvips/libvips/security/advisories/GHSA-r98w-4fp7-m9c7](https://github.com/libvips/libvips/security/advisories/GHSA-r98w-4fp7-m9c7) - [https://github.com/lovell/sharp/security/advisories/GHSA-f88m-g3jw-g9cj](https://github.com/lovell/sharp/security/advisories/GHSA-f88m-g3jw-g9cj) - [https://github.com/lovell/sharp](https://github.com/lovell/sharp) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-f88m-g3jw-g9cj) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### Release Notes <details> <summary>lovell/sharp (sharp)</summary> ### [`v0.35.0`](https://github.com/lovell/sharp/releases/tag/v0.35.0) [Compare Source](https://github.com/lovell/sharp/compare/v0.34.5...v0.35.0) - Breaking: Drop support for Node.js 18, now requires Node.js >= 20.9.0. - Breaking: Remove `install` script from `package.json` file. Compiling from source is now opt-in via the `build` script. - Breaking: Lossy AVIF output is now tuned using SSIMULACRA2-based `iq` quality metrics. - Breaking: Add `limitInputChannels` with a default value of 5. - Breaking: Remove deprecated `failOnError` constructor property. - Breaking: Remove deprecated `paletteBitDepth` from `metadata` response. - Breaking: Remove deprecated properties from `sharpen` operation. - Breaking: Rename `format.jp2k` as `format.jp2` for API consistency. - Upgrade to libvips v8.18.3 for upstream bug fixes. - Remove experimental status from WebAssembly binaries. - Add prebuilt binaries for FreeBSD (WebAssembly). - Deprecate Windows 32-bit (win32-ia32) prebuilt binaries. - Ensure TIFF output `bitdepth` option is limited to 1, 2 or 4. - Add AVIF/HEIF `tune` option for control over quality metrics. [#​4227](https://github.com/lovell/sharp/issues/4227) - Add `keepGainMap` and `withGainMap` to process HDR JPEG images with embedded gain maps. [#​4314](https://github.com/lovell/sharp/issues/4314) - Add `toUint8Array` for output image as a `TypedArray` backed by a transferable `ArrayBuffer`. [#​4355](https://github.com/lovell/sharp/issues/4355) - Require prebuilt binaries using static paths to aid code bundling. [#​4380](https://github.com/lovell/sharp/issues/4380) - TypeScript: Ensure `FormatEnum` keys match reality. [#​4475](https://github.com/lovell/sharp/issues/4475) - Add `margin` option to `trim` operation. [#​4480](https://github.com/lovell/sharp/issues/4480) [@​eddienubes](https://github.com/eddienubes) - Ensure HEIF primary item is used as default page/frame. [#​4487](https://github.com/lovell/sharp/issues/4487) - Add image Media Type (MIME Type) to metadata response. [#​4492](https://github.com/lovell/sharp/issues/4492) - Add `withDensity` to set output density in EXIF metadata. [#​4496](https://github.com/lovell/sharp/issues/4496) - Improve `pkg-config` path discovery. [#​4504](https://github.com/lovell/sharp/issues/4504) - Add WebP `exact` option for control over transparent pixel colour values. - Add support for ECMAScript Modules (ESM). [#​4509](https://github.com/lovell/sharp/pull/4509) [@​florian-lefebvre](https://github.com/florian-lefebvre) </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - "" - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xOTEuMiIsInVwZGF0ZWRJblZlciI6IjQzLjE5MS4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119--> <!-- cloudflare-preview --> Preview: https://pr-524.docs-gitea-com.pages.dev Reviewed-on: https://gitea.com/gitea/docs/pulls/524 Reviewed-by: silverwind <[email protected]> Co-authored-by: Renovate Bot <[email protected]> |
||
 Lunny Xiao
|
4e38ace168 |
feat(api): render and publish the openapi 3.0 documents (#514)
Closes #37. Gitea generates an OpenAPI 3.0 document since 1.27 (`templates/swagger/v1_openapi3_json.tmpl`, renamed to `templates/swagger/v1-openapi3.generated.json` on main, served by an instance at `/openapi3.v1.json`), but this site never picked it up and still published Swagger 2.0 only. That is what the issue is about: code generators such as `openapi-python-client` reject the document with "You may be trying to use a Swagger document; this is not supported by this project". **What this does** - `update_api_docs.sh` downloads the OpenAPI 3.0 document next to the Swagger 2.0 one, rewrites the same placeholders (they sit in `servers` instead of `basePath`) and writes `static/openapi3-latest.json` and `static/openapi3-<minor>.json`. Versions that do not have one (1.26 and older) are skipped with a message and keep their Swagger 2.0 document. - The OpenAPI 3.0 document is rendered where it exists (`/api/` and `/api/next/`), the older versions keep rendering Swagger 2.0. Both documents describe the same api and carry the same operation ids, so no url of an operation page changes; the `basePath` normalization is now only applied to the Swagger 2.0 documents, since a full url in `servers` is valid. - The overview page of each version links both documents for download, which is what the issue actually needs: `https://docs.gitea.com/openapi3-27.json` for the current release, `https://docs.gitea.com/openapi3-latest.json` for gitea main. - The scheduled workflow now refreshes and proposes both documents of gitea main. **Verification** - `pnpm dlx @redocly/cli lint static/openapi3-latest.json`: valid, only content warnings that come from upstream (missing 4xx responses, ambiguous paths). - `openapi-python-client generate --path static/openapi3-latest.json`, the tool from the issue, generates a client. The only warning left is `POST /markdown/raw`, whose request body is `text/plain`. - Operation ids of `static/swagger-27.json` and `static/openapi3-27.json` are identical (481 on both sides), so the operation pages keep their urls. - Built the api product and compared a rendered operation page against the Swagger 2.0 one: same sections, the request body is now marked required where the document says so. The released Swagger 2.0 documents are kept: they are the only description 1.26 and older ever produced, and some tooling still expects them. <!-- cloudflare-preview --> Preview: https://pr-514.docs-gitea-com.pages.dev Reviewed-on: https://gitea.com/gitea/docs/pulls/514 Reviewed-by: bircni <[email protected]> |
||
|
Lunny Xiao
|
63e1faa63c |
fix(search): scope the results to the version being read (#512)
Closes #146. The published site runs pagefind, not docsearch: `PUBLIC_DOCSEARCH_APP_ID` and `PUBLIC_DOCSEARCH_API_KEY` are not set, so `astro.config.mjs` falls back to `pagefind: true`, and a page of docs.gitea.com ships starlight's `#starlight__search` with the `/pagefind/` bundle. The version scoping we have is only implemented for docsearch (`docsearch:product` / `docsearch:version` meta tags plus `facetFilters` in `src/config/docsearch.ts`), so nothing consumes it today. Pagefind builds one index for the whole site, partitioned only by the html language, and nothing tags the pages with a version, so a search started in the 1.23 docs answers with every version of the same page and the latest one usually wins. That is what the issue reports; the original cause (the docusaurus search plugin) is gone, this one replaced it. **What this does** - `src/components/MarkdownContent.astro` wraps the content in two `data-pagefind-filter` elements, `product` and `version`, so the filters land in the index. One filter per element on purpose: pagefind reads the whole attribute as a single `name:value` pair, a comma separated value ends up as one filter named `product` with the value `docs,version:1.26`. - The same scope is written to a `gitea:search-filters` meta tag next to the docsearch ones (`src/lib/search.ts`). - Starlight builds the search ui from a build time configuration and has no option for per page filters, so its `@pagefind/default-ui` import is redirected to a subclass in `src/lib/pagefind-ui.ts` by the `gitea-pagefind-filters` plugin in `astro.config.mjs`, the same approach the `gitea-openapi-overview` plugin already uses. The subclass selects the filters of the page the modal was opened on. - A "Search all versions" checkbox below the search input drops the filters again and labels each result with the version (and the product for the api and the runner) it comes from, so the duplicates are distinguishable. Translated into 简体中文 and 繁體中文. - Pagefind's own filter panel is hidden, it is redundant next to the checkbox and starlight does not style it. The checkbox gets its native rendering back, pagefind resets everything it renders with `all: unset`. - A `gitea-pagefind-filters-check` integration fails the build if the redirect did not run, so a starlight upgrade that moves the import cannot silently bring back an unscoped search. `@pagefind/default-ui` is added to `sites/docs/package.json`; it was only reachable as a transitive dependency of starlight, and the version is the one already in the lockfile. **Verification** Built the whole site and drove the search with a headless browser against `astro preview` (the search does not run in `pnpm dev`): | Page | Query | Results | | --- | --- | --- | | `/1.23/usage/actions/comparison/` | email | only `/1.23/...` | | `/usage/actions/overview/` | email | only the version served at the root | | `/runner/registration/` | label | only `/runner/...` | | `/api/operations/tags/issue/` | label | only `/api/...` | | `/zh-cn/1.26/usage/actions/overview/` | email | only `/zh-cn/1.26/...` | | `/1.23/...` with the checkbox ticked | email | every version, results labelled `... · API 1.25`, `... · next` | `pnpm check` passes. The docsearch path is unchanged: when the credentials are set the plugin takes over, the redirect does not run and the check integration skips. <!-- cloudflare-preview --> Preview: https://pr-512.docs-gitea-com.pages.dev Reviewed-on: https://gitea.com/gitea/docs/pulls/512 |
||
 Lunny Xiaoandbircni
|
b137a0e0e1 |
Rebuild the site with Astro and Starlight (#496)
Replace [#307](https://gitea.com/gitea/docs/issues/307) Closes [#237](https://gitea.com/gitea/docs/issues/237) ## Summary Rebuilds docs.gitea.com with [Astro](https://astro.build) and [Starlight](https://starlight.astro.build), replacing Docusaurus. Every published url keeps working and no content file was moved: the site is a new rendering layer over the existing `docs/`, `versioned_docs/`, `i18n/`, `runner-docs/` and `static/swagger-*.json` trees. For the first time the API reference is part of the site rather than a Redoc bundle: all seven swagger documents are rendered into real pages, one per operation, so they are linkable, crawlable and searchable. ## Why - the Docusaurus build needs an 8 GB heap and about 2 minutes for 2478 pages; the Astro build produces 5751 pages, API reference included, in about 100 seconds - the API reference was a single client rendered Redoc page per version, absent from the site search and from search engines - sidebars, version lists and language lists were configured in three different places and drifted apart ## What is in here - **`packages/content-loader`** — the product × version × language matrix (`products.ts`) and an Astro content loader that reads the existing markdown trees directly. The matrix is the single source of truth: content loading, sidebars, the version and language pickers, the version banner, the search facets and the API schemas are all derived from it. - **Content compatibility** — frontmatter `slug`, `sidebar_position` and `sidebar_label` keep working, `_category_.json` still drives sidebar labels, order and the generated category pages, `@version@` style release variables are still substituted, `:::note` admonitions become Starlight asides and the 2778 relative `*.md` links are rewritten to urls while the site is built. - **API reference** — `starlight-openapi` renders the seven swagger documents. Operation urls are hyphenated (`/api/operations/list-admin-workflow-jobs/`), the sidebar shows the operations of the version being read with a coloured HTTP method badge, and the overview page links to one page per tag instead of repeating all 484 operations. - **Navigation** — a version picker that follows the reader to the same page in another version, a language picker that only offers the languages the current product is published in, and product links for Docs, API, Runner and Enterprise. - **Theme** — the light and dark palettes of about.gitea.com, mapped onto the Starlight variables. - **Search** — Pagefind by default; Algolia DocSearch takes over when `PUBLIC_DOCSEARCH_APP_ID` and `PUBLIC_DOCSEARCH_API_KEY` are set. Every page carries `docsearch:product`, `docsearch:version` and `docsearch:language` meta tags, so a search stays inside what is being read. `cloudflare/docsearch-crawler.json` holds the crawler configuration. ## Bugs fixed along the way - `GET /user/applications/oauth2` and `GET /user/applications/oauth2/{id}` have operation ids that only differ in case, so they collapsed onto the same url and one of the two pages was silently dropped. They are now `user-get-oauth2-application` and `user-get-oauth2-application-by-id`. - The API overview and every tag page were all titled "Overview". ## Url compatibility The routes of both builds were compared page by page during the migration with `scripts/url-diff.mjs`: ``` identical: 2368, missing: 0, accepted: 110, added: 3292 ``` The 110 accepted ones are all redirected in `cloudflare/_redirects`: the localized copies of the English-only API and Runner docs, the Docusaurus search page, and `/1.27/`, `/runner/3/`, `/api/1.27/` which are aliases of the versions served at the product root. The added ones are the API operation and tag pages plus the routes the Starlight language fallback serves in English when a translation is missing — Docusaurus answered those with a 404. ## Workflows - `checks` builds the site and type checks it on every pull request - `Build and Publish Docs site` publishes `sites/docs/dist` to S3/CloudFront and to Cloudflare Pages, and copies `cloudflare/_headers` and `cloudflare/_redirects` into the deployment - `update swagger files` and `update runner reference` are unchanged, they only touch content - `make cut-version PRODUCT=docs VERSION=1.28` replaces `docusaurus docs:version` ## Removed `docusaurus.config.js`, the swizzled theme under `src/`, and the Docusaurus UI translations (`i18n/*/code.json`, `i18n/*/docusaurus-theme-classic/`). The strings those carried — the product names, the footer column titles and the outdated translation notice — were ported to `sites/docs/src/config/strings.ts`; Starlight ships the rest of its interface in both Chinese locales. The documentation content itself is untouched. ## Follow ups - nine relative links are broken in the sources and reported by every build, the same ones Docusaurus warned about; `GITEA_DOCS_STRICT_LINKS=true` turns them into an error once they are fixed - `cloudflare/worker.js` has to be deployed for `/enterprise/` to keep resolving - the Algolia index has to be created and crawled before the search credentials are set ## Testing ```shell make install make serve-fast # english, the version served at the root make serve # the whole matrix make build # 5751 pages make check # 0 errors make serve-built # build and serve, the only way to try the search locally ``` ## Screenshots <img width="1371" alt="image.png" src="attachments/69acdd77-cc89-4635-a8bd-1163a34afa86"> <img width="1810" alt="image.png" src="attachments/76212416-4825-4b4d-bf59-3e549900c96f"> <img width="1789" alt="image.png" src="attachments/7be84cda-5abe-48bd-8839-7ae1ee7806e7"> --------- Co-authored-by: bircni <[email protected]> Reviewed-on: https://gitea.com/gitea/docs/pulls/496 Reviewed-by: bircni <[email protected]> |