curl - Debian Package Tracker

general

source: curl (main)
version: 8.20.0-1
maintainer: Debian Curl Maintainers (DMD)
uploaders: Sergio Durigan Junior [DMD] – Samuel Henrique [DMD] – Carlos Henrique Lima Melara [DMD]
arch: all any
std-ver: 4.7.4
VCS: Git (Browse, QA)

versions [more versions can be listed by madison] [old versions available from snapshot.debian.org]

[pool directory]

o-o-stable: 7.74.0-1.3+deb11u13
o-o-sec: 7.74.0-1.3+deb11u16
o-o-p-u: 7.74.0-1.3+deb11u13
oldstable: 7.88.1-10+deb12u14
old-sec: 7.88.1-10+deb12u5
old-bpo: 8.14.1-2+deb13u2~bpo13+1
stable: 8.14.1-2+deb13u2
stable-bpo: 8.19.0-1~bpo13+1
stable-p-u: 8.14.1-2+deb13u3
testing: 8.19.0-3
unstable: 8.20.0-1
exp: 8.20.0-1+exp

versioned links

7.74.0-1.3+deb11u13: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
7.74.0-1.3+deb11u16: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
7.88.1-10+deb12u5: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
7.88.1-10+deb12u14: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.14.1-2+deb13u2~bpo13+1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.14.1-2+deb13u2: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.14.1-2+deb13u3: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.19.0-1~bpo13+1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.19.0-3: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.20.0-1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
8.20.0-1+exp: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]

binaries

curl (31 bugs: 0, 21, 10, 0)
libcurl3t64-gnutls
libcurl4-doc
libcurl4-gnutls-dev
libcurl4-openssl-dev (4 bugs: 0, 4, 0, 0)
libcurl4t64

action needed

The VCS repository is not up to date, push the missing commits. high

vcswatch reports that the current version of the package is not in its VCS.
Either you need to push your commits and/or your tags, or the information about the package's VCS are out of date. A common cause of the latter issue when using the Git VCS is not specifying the correct branch when the packaging is not in the default one (remote HEAD branch), which is usually "master" but can be modified in salsa.debian.org in the project's general settings with the "Default Branch" field). Alternatively the Vcs-Git field in debian/control can contain a "-b <branch-name>" suffix to indicate what branch is used for the Debian packaging.

Created: 2026-04-30 Last update: 2026-04-30 09:32

7 security issues in forky high

There are 7 open security issues in forky.

7 important issues:

CVE-2026-4873:
CVE-2026-5545:
CVE-2026-5773:
CVE-2026-6253:
CVE-2026-6276:
CVE-2026-6429:
CVE-2026-7168:

Created: 2026-04-29 Last update: 2026-04-30 09:31

17 security issues in bullseye high

There are 17 open security issues in bullseye.

7 important issues:

CVE-2026-4873:
CVE-2026-5545:
CVE-2026-5773:
CVE-2026-6253:
CVE-2026-6276:
CVE-2026-6429:
CVE-2026-7168:

4 issues postponed or untriaged:

CVE-2026-1965: (postponed; to be fixed through a stable update) libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).
CVE-2026-3783: (postponed; to be fixed through a stable update) When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.
CVE-2026-3784: (postponed; to be fixed through a stable update) curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.
CVE-2025-14524: (postponed; to be fixed through a stable update) When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP, POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new target host.

6 ignored issues:

CVE-2024-9681: When curl is asked to use HSTS, the expiry time for a subdomain might overwrite a parent domain's cache entry, making it end sooner or later than otherwise intended. This affects curl using applications that enable HSTS and use URLs with the insecure `HTTP://` scheme and perform transfers with hosts like `x.example.com` as well as `example.com` where the first host is a subdomain of the second host. (The HSTS cache either needs to have been populated manually or there needs to have been previous HTTPS accesses done as the cache needs to have entries for the domains involved to trigger this problem.) When `x.example.com` responds with `Strict-Transport-Security:` headers, this bug can make the subdomain's expiry timeout *bleed over* and get set for the parent domain `example.com` in curl's HSTS cache. The result of a triggered bug is that HTTP accesses to `example.com` get converted to HTTPS for a different period of time than what was asked for by the origin server. If `example.com` for example stops supporting HTTPS at its expiry time, curl might then fail to access `http://example.com` until the (wrongly set) timeout expires. This bug can also expire the parent's entry *earlier*, thus making curl inadvertently switch back to insecure HTTP earlier than otherwise intended.
CVE-2022-42916: In curl before 7.86.0, the HSTS check could be bypassed to trick it into staying with HTTP. Using its HSTS support, curl can be instructed to use HTTPS directly (instead of using an insecure cleartext HTTP step) even when HTTP is provided in the URL. This mechanism could be bypassed if the host name in the given URL uses IDN characters that get replaced with ASCII counterparts as part of the IDN conversion, e.g., using the character UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) instead of the common ASCII full stop of U+002E (.). The earliest affected version is 7.77.0 2021-05-26.
CVE-2022-43551: A vulnerability exists in curl <7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. However, the HSTS mechanism could be bypassed if the host name in the given URL first uses IDN characters that get replaced to ASCII counterparts as part of the IDN conversion. Like using the character UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) instead of the common ASCII full stop (U+002E) `.`. Then in a subsequent request, it does not detect the HSTS state and makes a clear text transfer. Because it would store the info IDN encoded but look for it IDN decoded.
CVE-2023-23914: A cleartext transmission of sensitive information vulnerability exists in curl <v7.88.0 that could cause HSTS functionality fail when multiple URLs are requested serially. Using its HSTS support, curl can be instructed to use HTTPS instead of usingan insecure clear-text HTTP step even when HTTP is provided in the URL. ThisHSTS mechanism would however surprisingly be ignored by subsequent transferswhen done on the same command line because the state would not be properlycarried on.
CVE-2023-23915: A cleartext transmission of sensitive information vulnerability exists in curl <v7.88.0 that could cause HSTS functionality to behave incorrectly when multiple URLs are requested in parallel. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. This HSTS mechanism would however surprisingly fail when multiple transfers are done in parallel as the HSTS cache file gets overwritten by the most recentlycompleted transfer. A later HTTP-only transfer to the earlier host name would then *not* get upgraded properly to HSTS.
CVE-2023-46219: When saving HSTS data to an excessively long file name, curl could end up removing all contents, making subsequent requests using that file unaware of the HSTS status they should otherwise use.

Created: 2026-04-29 Last update: 2026-04-30 09:31

9 bugs tagged patch in the BTS normal

The BTS contains patches fixing 9 bugs (10 if counting merged bugs), consider including or untagging them.

Created: 2026-04-06 Last update: 2026-05-03 03:30

lintian reports 1 warning normal

Lintian reports 1 warning about this package. You should make the package lintian clean getting rid of them.

Created: 2026-04-30 Last update: 2026-04-30 09:30

13 low-priority security issues in trixie low

There are 13 open security issues in trixie.

13 issues left for the package maintainer to handle:

CVE-2026-1965: (needs triaging) libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).
CVE-2026-3783: (needs triaging) When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.
CVE-2026-3784: (needs triaging) curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.
CVE-2026-3805: (needs triaging) When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.
CVE-2026-4873: (needs triaging)
CVE-2026-5545: (needs triaging)
CVE-2026-5773: (needs triaging)
CVE-2026-6253: (needs triaging)
CVE-2026-6276: (needs triaging)
CVE-2026-6429: (needs triaging)
CVE-2026-7168: (needs triaging)
CVE-2025-14524: (needs triaging) When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP, POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new target host.
CVE-2025-14819: (needs triaging) When doing TLS related transfers with reused easy or multi handles and altering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally reuse a CA store cached in memory for which the partial chain option was reversed. Contrary to the user's wishes and expectations. This could make libcurl find and accept a trust chain that it otherwise would not.

You can find information about how to handle these issues in the security team's documentation.

1 issue that should be fixed with the next stable update:

CVE-2025-13034: When using `CURLOPT_PINNEDPUBLICKEY` option with libcurl or `--pinnedpubkey` with the curl tool,curl should check the public key of the server certificate to verify the peer. This check was skipped in a certain condition that would then make curl allow the connection without performing the proper check, thus not noticing a possible impostor. To skip this check, the connection had to be done with QUIC with ngtcp2 built to use GnuTLS and the user had to explicitly disable the standard certificate verification.

Created: 2026-01-07 Last update: 2026-04-30 09:31

13 low-priority security issues in bookworm low

There are 13 open security issues in bookworm.

12 issues left for the package maintainer to handle:

CVE-2026-1965: (needs triaging) libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).
CVE-2026-3783: (needs triaging) When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.
CVE-2026-3784: (needs triaging) curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.
CVE-2026-4873: (needs triaging)
CVE-2026-5545: (needs triaging)
CVE-2026-5773: (needs triaging)
CVE-2026-6253: (needs triaging)
CVE-2026-6276: (needs triaging)
CVE-2026-6429: (needs triaging)
CVE-2026-7168: (needs triaging)
CVE-2025-14524: (needs triaging) When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP, POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new target host.
CVE-2025-14819: (needs triaging) When doing TLS related transfers with reused easy or multi handles and altering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally reuse a CA store cached in memory for which the partial chain option was reversed. Contrary to the user's wishes and expectations. This could make libcurl find and accept a trust chain that it otherwise would not.

You can find information about how to handle these issues in the security team's documentation.

1 ignored issue:

CVE-2025-10148: curl's websocket code did not update the 32 bit mask pattern for each new outgoing frame as the specification says. Instead it used a fixed mask that persisted and was used throughout the entire connection. A predictable mask pattern allows for a malicious server to induce traffic between the two communicating parties that could be interpreted by an involved proxy (configured or transparent) as genuine, real, HTTP traffic with content and thereby poison its cache. That cached poisoned content could then be served to all users of that proxy.

Created: 2025-09-10 Last update: 2026-04-30 09:31

debian/patches: 1 patch to forward upstream low

Among the 3 debian patches available in version 8.20.0-1 of the package, we noticed the following issues:

1 patch where the metadata indicates that the patch has not yet been forwarded upstream. You should either forward the patch upstream or update the metadata to document its real status.

Created: 2023-02-26 Last update: 2026-04-30 07:05

testing migrations

This package will soon be part of the auto-openssl transition. You might want to ensure that your package is ready for it. You can probably find supplementary information in the debian-release archives or in the corresponding release.debian.org bug.
excuses:
- Migration status for curl (8.19.0-3 to 8.20.0-1): BLOCKED: Rejected/violates migration policy/introduces a regression
- Issues preventing migration:
- ∙ ∙ Autopkgtest for caddy/2.11.2-1: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Pass, riscv64: Pass, s390x: Test triggered
- ∙ ∙ Autopkgtest for cimg/3.5.2+dfsg-1: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Pass, riscv64: Test triggered (failure will be ignored), s390x: Pass
- ∙ ∙ Autopkgtest for cmake/4.3.1-1: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Pass, riscv64: Test triggered (failure will be ignored), s390x: Pass
- ∙ ∙ Autopkgtest for curl/8.20.0-1: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Pass, riscv64: Pass, s390x: Pass
- ∙ ∙ Autopkgtest for debian-edu-config/2.12.904: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Pass, riscv64: Pass, s390x: Regression ♻ (reference ♻)
- ∙ ∙ Autopkgtest for debusine/0.14.7: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Pass, riscv64: Test triggered (failure will be ignored), s390x: Regression ♻ (reference ♻)
- ∙ ∙ Autopkgtest for dracut/110-12: amd64: Pass, arm64: Pass, i386: No tests, superficial or marked flaky ♻, ppc64el: Pass, riscv64: Test triggered (failure will be ignored), s390x: Pass
- ∙ ∙ Autopkgtest for libreoffice/4:26.2.2.2-3: amd64: Pass, arm64: Test triggered (failure will be ignored), i386: Test triggered (failure will be ignored), ppc64el: Pass, riscv64: Pass, s390x: Pass
- ∙ ∙ Autopkgtest for nodejs/22.22.2+dfsg+~cs22.19.15-3: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Pass, riscv64: Test triggered (failure will be ignored), s390x: Pass
- ∙ ∙ Autopkgtest for puppetserver/8.7.0-7: amd64: Pass, arm64: Regression ♻ (reference ♻), i386: No tests, superficial or marked flaky ♻, ppc64el: No tests, superficial or marked flaky ♻, riscv64: No tests, superficial or marked flaky ♻, s390x: Test triggered
- ∙ ∙ Autopkgtest for ruby-curb/1.3.1-1: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻), riscv64: Failed (not a regression) ♻ (reference ♻), s390x: Regression ♻ (reference ♻)
- ∙ ∙ Autopkgtest for trurl/0.16.1-3: amd64: Regression ♻ (reference ♻), arm64: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻), riscv64: Regression ♻ (reference ♻), s390x: Regression ♻ (reference ♻)
- ∙ ∙ Too young, only 3 of 5 days old
- Additional info (not blocking):
- ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/c/curl.html
- ∙ ∙ Reproduced on amd64
- ∙ ∙ Reproduced on arm64
- ∙ ∙ Reproduced on armhf
- ∙ ∙ Reproduced on i386
- ∙ ∙ Reproducibility check waiting for results on ppc64el
- Not considered

news

[rss feed]

[2026-05-02] Accepted curl 8.14.1-2+deb13u3 (source) into proposed-updates (Debian FTP Masters) (signed by: Samuel Henrique)
[2026-04-30] Accepted curl 8.20.0-1+exp (source) into experimental (Samuel Henrique)
[2026-04-29] Accepted curl 8.20.0-1 (source) into unstable (Samuel Henrique)
[2026-04-23] Accepted curl 8.20.0~rc3-1 (source) into unstable (Samuel Henrique)
[2026-04-23] Accepted curl 8.20.0~rc3-1+exp1 (source) into experimental (Samuel Henrique)
[2026-04-15] Accepted curl 8.20.0~rc2-1+exp1 (source) into experimental (Carlos Henrique Lima Melara)
[2026-04-15] Accepted curl 8.20.0~rc2-1 (source) into unstable (Carlos Henrique Lima Melara)
[2026-04-08] Accepted curl 8.20.0~rc1-1+exp3 (source) into experimental (Carlos Henrique Lima Melara)
[2026-04-07] Accepted curl 8.20.0~rc1-1+exp2 (source) into experimental (Samuel Henrique)
[2026-04-04] Accepted curl 8.20.0~rc1-1+exp1 (source) into experimental (Samuel Henrique)
[2026-04-03] curl 8.19.0-3 MIGRATED to testing (Debian testing watch)
[2026-03-27] Accepted curl 8.19.0-3+exp2 (source) into experimental (Samuel Henrique)
[2026-03-27] Accepted curl 8.19.0-3+exp1 (source) into experimental (Samuel Henrique)
[2026-03-27] Accepted curl 8.19.0-3 (source) into unstable (Carlos Henrique Lima Melara)
[2026-03-27] Accepted curl 8.19.0-2 (source) into unstable (Carlos Henrique Lima Melara)
[2026-03-26] Accepted curl 8.19.0-1+exp1 (source) into experimental (Samuel Henrique)
[2026-03-18] Accepted curl 8.19.0-1~bpo13+1 (source) into stable-backports (Samuel Henrique)
[2026-03-18] curl 8.19.0-1 MIGRATED to testing (Debian testing watch)
[2026-03-12] Accepted curl 8.19.0-1 (source) into unstable (Carlos Henrique Lima Melara)
[2026-02-28] Accepted curl 8.19.0~rc3-1 (source) into unstable (Carlos Henrique Lima Melara)
[2026-02-24] Accepted curl 8.19.0~rc2-2 (source) into unstable (Carlos Henrique Lima Melara)
[2026-02-21] Accepted curl 8.19.0~rc2-1 (source) into unstable (Samuel Henrique)
[2026-02-15] Accepted curl 8.19.0~rc1-1~exp1 (source) into experimental (Samuel Henrique)
[2026-01-19] curl 8.18.0-2 MIGRATED to testing (Debian testing watch)
[2026-01-15] Accepted curl 8.18.0-2 (source) into unstable (Carlos Henrique Lima Melara)
[2026-01-14] Accepted curl 8.14.1-2+deb13u2~bpo13+1 (source) into oldstable-backports (Samuel Henrique)
[2026-01-14] Accepted curl 8.18.0-1~bpo13+1 (source) into stable-backports (Samuel Henrique)
[2026-01-12] curl 8.18.0-1 MIGRATED to testing (Debian testing watch)
[2026-01-08] Accepted curl 8.18.0-1 (source) into unstable (Carlos Henrique Lima Melara)
[2026-01-05] Accepted curl 7.74.0-1.3+deb11u16 (source) into oldoldstable-security (Alex) (signed by: Carlos Henrique Lima Melara)

bugs [bug history graph]

all: 48 52
RC: 0
I&N: 38 40
M&W: 10 12
F&P: 0
patch: 9 10

links

homepage
lintian (0, 1)
buildd: logs, exp, reproducibility, cross
popcon
browse source code
other distros
security tracker
screenshots
debian patches
debci

ubuntu

[Information about Ubuntu for Debian Developers]

version: 8.18.0-1ubuntu2
patches for 8.18.0-1ubuntu2