[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1105892: [pre-approval request] unblock: screen/4.9.1-2.1



Control: tags -1 confirmed

On 2025-05-16 18:34:31 +0200, Salvatore Bonaccorso wrote:
> Package: release.debian.org
> Severity: normal
> X-Debbugs-Cc: screen@packages.debian.org, Axel Beckert (Debian Developer) <abe@debian.org>, Christian Hofstaedtler <zeha@debian.org>, debian-boot@lists.debian.org, kibi@debian.org, carnil@debian.org
> Control: affects -1 + src:screen
> User: release.debian.org@packages.debian.org
> Usertags: unblock
> 
> Hi Release team,
> 
> [Cc'ing as well debian-boot and Cyril, as screen produces a udeb and
> needs an ack for d-i, additionally we are freezing udebs for the d-i
> preparation]
> 
> Please unblock package screen
> 
> screen as announced in [oss-security] is affected by several
> vulnerabilities, furtunately by default in Debian screen is not
> installed setuid. We think that having fixes for those (and later
> maybe via  point release in bookworm as well) might be sensible.
> 
> The concrete CVEs are CVE-2025-46802, CVE-2025-46804 and
> CVE-2025-46805.
> 
>  [oss-security]:  <https://www.openwall.com/lists/oss-security/2025/05/12/1>
> 
> One very important remark for the CVE-2025-46802 patches, from the
> finding:
> | Shortly before the publication of this report it was pointed out to us
> | that this patch likely breaks some reattach use cases [12] in screen.
> | We can confirm this problem, but at the same time found out that this
> | specific use case was obviously already broken before, even in Screen
> | 4.9.1 [13]. For this reason we decided not to move the publication
> | date again or to adjust this patch in a hurry with uncertain results.
> | The patch still fixes the security issue and upstream can now fix this
> | regression, that already seems to have existed earlier, in the open.
> 
> Additionally there is an Upload from Chris Hofstaedtler
> <zeha@debian.org> which has not yet migrated to testing (but would if
> the additional time would pass without RC report).
> 
> Talking with Chris he would be fine to have additional time to wait
> for his change to go in and so the we can either wait for the second
> upload and first make 4.9.1-2 go to testing or override the upload.

I aged -2 and it migrated. Please go ahead.

Cheers
-- 
Sebastian Ramacher


Reply to: