> 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.
>> 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.
