On Wed, 28 Jan 2026 05:57:36 +0530 Nilesh Patra <[email protected]>
wrote:
> On 28 Jan 2026, at 5:27 AM, Guillem Jover <[email protected]> wrote:
>
> Hi!
>
> On Tue, 2026-01-27 at 22:15:36 +0530, Nilesh Patra wrote:
>> Package: dpkg
>> Severity: important
>> X-Debbugs-Cc: [email protected]
<mailto:[email protected]>.org
>> Control: affects -1 + src:lintian
>> Version: 1.23.5
>
>> Lintian’s test suite reflects this error:
>>
>> | dpkg-source: warning: --auto-commit is not a valid option for Dpkg::Source::Package::V3::Native
>> | dpkg-source: error: cannot parse Maintainer field value "Colorful
<"[31mc[32mo[33ml[34mo[35mr[36mf[37mu[96ml[0m"@43-1.org>”
>> | dpkg-buildpackage: error: dpkg-source -iNEVER_MATCH_ANYTHING
-INEVER_MATCH_ANYTHING --auto-commit --before-build . subprocess failed with exit
status 255
>> | make: ***
[/tmp/autopkgtest-lxc.18_8mz9y/downtmp/autopkgtest_tmp/build-and-evaluate-test-packages/package-sources/checks/fields/terminal-control/colorful/Makefile:39:
colorful_1.0_amd64.changes] Error 255
>
> Hmm, TBH I don't think I'm comfortable allowing ANSI escapes as part
> of email addresses? This feels unnecessary and a recipe for terminal
> exploits and similar.
This happens to be allowed by RFC 6532 as such.
I'd be inclined to disregard RFC 6532 for ANSI escapes and have dpkg
continue to fail when they are used in those fields.
This would let us remove the `ansi-escape` tag in Lintian.
>> This is a fallout with #962277.
>>
>> dpkg should allow domains with non-ascii chars. For now I’ll try to
>> drop this test from lintian test suite.
>
> Otherwise the parser already supports UTF-8 characters in both the
> local and domain parts:
>
> $ perl -Mv5.40 -MDpkg::Email::Address -E '\
> my $e = Dpkg::Email::Address->new("Foo Bar <föo\@bår.org>"); \
> say $e->as_string(); \
> '
> Foo Bar <föo@bår.org>
>
> So, I'm inclined to close this one.
Lintian expects the .dsc/.changes file to be UTF encoded. If someone uses the
address, it leads to .changes with a nationally encoded email
and lintian would fail to parse that /o\
This is getting way more complicated than I did think originally.
I'm not sure I understand what a "nationally encoded email" is and how
using a non-ascii email leads to creating a non-compatible .changes?
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ [email protected] / veronneau.org
⠈⠳⣄
