Hi!
On Wed, 2026-01-28 at 16:51:42 -0500, Louis-Philippe Véronneau wrote:
> On Wed, 28 Jan 2026 05:57:36 +0530 Nilesh Patra wrote:
> > > On 28 Jan 2026, at 5:27 AM, Guillem Jover wrote:
> > > > On Tue, 2026-01-27 at 22:15:36 +0530, Nilesh Patra wrote:
> > > > > 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.
I think a similar sentiment about not allowing everything permitted
usually in an email context (but I don't think for this specific case)
was brought up on the policy report about updating the email spec. As
well as focusing on usability and readability, and ignoring any weird
encoding that might be needed to be able to actually send via say
SMTP (where that should be left for such programs that need to perform
such tasks).
(In dpkg this is caught by a regex matching on not \cK which I don't see
removing, as that would seem like a bad idea.)
> > >> 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?
I think in general "national encoding" means things like iso-8859-<n>
or similar encodings. In this case I'm not sure I understand because
dpkg-dev tools should preserve the input encoding on output, and if
this was a problem for the email address itself it would also be a
problem for the name. So either the user has specified something that
is not UTF-8 or they perhaps are running in a non-UTF-8 environment?
In any case this would already be a problem so I don't see it as a
regression. Say with:
Föo Bår <[email protected]>
So, unless I'm missing something, I'd still consider closing this one?
Thanks,
Guillem
