Patch for incorrect charset in notification emails

[Jesse Long]

Binary package hint: sudo

sudo uses strftime() to generate the date string in the notification mails sent to administrators when something fishy happens. strftime() generates the date according to locale env vars. This could result in date strings containing arbitrary characters in arbitrary charsets (think UTF-8 in far eastern languages).

By default, email messages are us-ascii. sudo does no conversion of the data returned by strftime (which is in the user's current charset) to the default us-ascii charset. This causes non-ascii dates to come through as garbage.

Solution:
 1. stop using strftime. The code actually has the strftime code in a IFDEF, remove that whole ifdef, and use ctime, which is ascii.
 2. insert charset information into the notification email. add header (Content-Type: text/plain; charset="<nl_langinfo(CODESET)>") and (Content-Transfer-Encoding: 8bit).

downside of solution 2:
 1. 8bit transfer encoding is required. 8bit is not strictly supported by SMTP, although is supported by most MTA's, probably all MTA's in the Ubuntu repo.
 2. Also, since the strftime uses the locale of the user, it could represent the date in some language unreadable by the sysadmin (who receives the notification, but does not necessarily read the same language as the user who committed whatever offense). ctime() always represents the date in English ASCII. I think we can safely assume the large majority of sysadmins out there can read English ASCII?

I've attached a patch to only use ctime in notification emails and logging. Since launch pad only allows one attachment at time of bug creation, I'll try attach the other patch after I've submitted this. Here's hoping I can do that.

[Jesse Long (jpl-unknown)]

Just for clarity, propose one of the two solutions, not both. You choice. I prefer using only ctime()

[Lars Ljung (larslj)]

This is more or less a duplicate of bug 124944 and/or bug 27121. I'll leave it to someone else to decide if this should be fixed in sudo or mailx.

[Jesse Long (jpl-unknown)]

No, cant possibly be a mailx duplicate, because mailx is not used by sudo. Agreed, similar issue, but sudo talks directly to sendmail, and builds the mail content manually, itself. Ideally, sudo should probably be using some mail creation library or utility to generate valid messages, but until then, we need to fix sudo.

[Lars Ljung (larslj)]

Yes, you are right. It does use sendmail.

[Jesse Long (jpl-unknown)]

ping bug 491352
0 bytes from ubuntu: comment_seq=7 ttl=1 month time=6 months

[Lorenzo De Liso (blackz)]

For the first patch: looks like it has been included upstream.

For the second patch: I forwarded it to upstream.

[Lorenzo De Liso (blackz)]

> For the second patch: I forwarded it to upstream.

You can track its status at http://www.gratisoft.us/bugzilla/show_bug.cgi?id=457 . However, I added a bug watch to this bug report.

[Jesse Long (jpl-unknown)]

Hi,

1. No point is using both solutions. Only of of the solutions will suffice.
2. No, the first patch is not included upstream, at least not in sudo-1.7.5b1. The problem has moved from logging.c to timestr.c, but remains.

I'll also update the bugzilla page...

[Benjamin Drung (bdrung)]

Hi, I tried to check all sudo bugs with attached patches. Sadly the upstream bug link is broken. So I cannot follow-up the upstream progress. The git history revealed no reference to bug number 457.

Looking at the upstream code, I found following in lib/eventlog/eventlog.c:

#if defined(HAVE_NL_LANGINFO) && defined(CODESET)
    locale = setlocale(LC_ALL, NULL);
    if (locale[0] != 'C' || locale[1] != '\0')
 (void) fprintf(mail, "\nContent-Type: text/plain; charset=\"%s\"\nContent-Transfer-Encoding: 8bit", nl_langinfo(CODESET));
#endif /* HAVE_NL_LANGINFO && CODESET */

So I assume that it was fixed upstream. This code snippet was introduced in commit bd1ca79cca827a92e904f022e49df121931d4ff5 and was part of sudo 1.9.4 which landed in Ubuntu 22.04 (jammy).

If my assumption is wrong, please reopen this bug report.