Bug#1061155: cron: "crontab -e" does not report "unsafe" mail and so job output can be lost
BTW, although testing validity of email would indeed be nice, it is notoriously difficult. For example, this is valid: http://@jhnc.org; ( https://www.rfc-editor.org/rfc/rfc5322#section-3.4 ) but I believe fails the regex in your link (I can't test properly without turning off my adblocker, which I don't intend to do). The safe_p() function could perhaps be generalised to recognise a list of valid addresses separated by `\s*,\s*` but beyond that it is almost certainly, as you say: "asking a program to be more clever than its users is a waste of energy". My concern is that whatever checks are done, they get done at save, so any "errors" are caught early. -jonathan georges.khaznadar wrote: > To: deb...@jhnc.org, 1061...@bugs.debian.org > From: Khaznadar Georges > Date: Tue, 27 Feb 2024 09:57:39 +0100 (CET) > Subject: Re: cron: "crontab -e" does not report "unsafe" mail and so job > output can be lost > X-Mailer: Open-Xchange Mailer v7.6.3-Rev71 > >Hello Jonathan, > >I apologize, I had not paid attention to the extra space included in the > >list of MAILTO addresses. > >I suppose that we can sanitize the value of MAILTO, by checking it > >with a regular expression derived from RFC 5322 Official Standard > >(see [1]https://emailregex.com/), or do you suggest some lighter approach? > >Best regards, Georges. > >Jonathan H N Chin a écrit : >> Sorry, my mail server does not seem to have received any email >> from debian when you sent your email on 2024-01-21. Was I >> supposed to have been automatically Bcc'd? >> >> I disagree that the bug is not grave – I believe it meets the >> criterion of data being lost (and was in fact lost by the user). >> However, that does not really bother me. >> >> Note that I used quotation marks around the word unsafe because >> that is the wording used in the syslog message; the addresses are >> not unsafe. The problem is the space character. > > References > >Visible links >1. https://emailregex.com/
Bug#1061155: cron: "crontab -e" does not report "unsafe" mail and so job output can be lost
Perhaps amusingly, now I look at the code, I see in do_command.c that if safe_p() determines mailfrom contains spaces or parentheses, it will error out. However the very next line of code then sets it to contain both spaces and parentheses! (Yes, I know it is safe.) My suggestion is to call the sanity checks that already happen at runtime also at save time. If any fail, report them and deny save. My C is extremely rusty but if I understand the code, it seems checking happens in crontab.c in replace_cmd(). So one possibility might be: after load_env(), in the "case TRUE" clause, if envstr is MAILTO=x or MAILFROM=x, then call a safe_p() equivalent on x that invokes check_error() on failure instead of calling log_it(). To avoid code duplication, perhaps it would be better to generalise safe_p() with an extra argument to select how it reports errors (or do dependency injection of the logging function). I haven't looked to see what (if any) other sanity checks happen at runtime that could also usefully be tested at save time. -jonathan georges.khaznadar wrote: > To: deb...@jhnc.org, 1061...@bugs.debian.org > From: Khaznadar Georges > Date: Tue, 27 Feb 2024 09:57:39 +0100 (CET) > Subject: Re: cron: "crontab -e" does not report "unsafe" mail and so job > output can be lost > X-Mailer: Open-Xchange Mailer v7.6.3-Rev71 > >Hello Jonathan, > >I apologize, I had not paid attention to the extra space included in the > >list of MAILTO addresses. > >I suppose that we can sanitize the value of MAILTO, by checking it > >with a regular expression derived from RFC 5322 Official Standard > >(see [1]https://emailregex.com/), or do you suggest some lighter approach? > >Best regards, Georges. > >Jonathan H N Chin a écrit : >> Sorry, my mail server does not seem to have received any email >> from debian when you sent your email on 2024-01-21. Was I >> supposed to have been automatically Bcc'd? >> >> I disagree that the bug is not grave – I believe it meets the >> criterion of data being lost (and was in fact lost by the user). >> However, that does not really bother me. >> >> Note that I used quotation marks around the word unsafe because >> that is the wording used in the syslog message; the addresses are >> not unsafe. The problem is the space character. > > References > >Visible links >1. https://emailregex.com/
Bug#1061155: cron: "crontab -e" does not report "unsafe" mail and so job output can be lost
Hello Jonathan,I apologize, I had not paid attention to the extra space included in thelist of MAILTO addresses.I suppose that we can sanitize the value of MAILTO, by checking it with a regular _expression_ derived from RFC 5322 Official Standard(see https://emailregex.com/), or do you suggest some lighter approach?Best regards, Georges.Jonathan H N Chin a écrit :> Sorry, my mail server does not seem to have received any email> from debian when you sent your email on 2024-01-21. Was I> supposed to have been automatically Bcc'd?> > I disagree that the bug is not grave – I believe it meets the> criterion of data being lost (and was in fact lost by the user).> However, that does not really bother me.> > Note that I used quotation marks around the word unsafe because> that is the wording used in the syslog message; the addresses are> not unsafe. The problem is the space character.
Bug#1061155: cron: "crontab -e" does not report "unsafe" mail and so job output can be lost
Sorry, my mail server does not seem to have received any email from debian when you sent your email on 2024-01-21. Was I supposed to have been automatically Bcc'd? I disagree that the bug is not grave - I believe it meets the criterion of data being lost (and was in fact lost by the user). However, that does not really bother me. Note that I used quotation marks around the word unsafe because that is the wording used in the syslog message; the addresses are not unsafe. The problem is the space character. If you try to replicate my test, you will see that after adding the MAILTO line shown in my report, no error is displayed to the user. Later when the job runs, syslog receives an error and job output is discarded. This happens because of the erroneous space delimiter, not because of any unusual email address. I am suggesting that instead of waiting until the job runs (when it may be too late to notify the user), the check that is reported in syslog be performed when saving after editing, so that the error can be reported to the user immediately. To be clear, I'm not asking for cron to be "more clever than its users", but that it runs earlier the tests that it already performs. Refusing to save a crontab that would fail later avoids potential data loss. -jonathan georges.khaznadar wrote: > To: deb...@jhnc.org > Cc: 1061...@bugs.debian.org > From: Khaznadar Georges > Date: Mon, 26 Feb 2024 17:48:06 +0100 (CET) > Subject: Re: cron: "crontab -e" does not report "unsafe" mail and so job > output can be lost > X-Mailer: Open-Xchange Mailer v7.6.3-Rev71 > >Hello Joathan, have you received my previous reply to your bug report? >It was one month ago. If you did not read it, you can find it today at >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061155 > >The title of the present bug report says that crontab -e cannot >detect “unsafe” email addresses. > >However, the example you proposed is the usage of e-mail addresses like >a...@example.org, b...@example.com, which can be parsed by the usual > regular >expressions, as valid e-mail addresses. > >So, I ask you again for other suggestions about a secure way to >distinguish “safe” from “unsafe” e-mail addresses. > >I suspect that asking a program to be more clever than its users is a >waste of energy. For example, if I send this email to >no-deb...@jhnc.org, chances are that the e-mail will never be >distributed. It is my responsability to send this e-mail to >deb...@jhnc.org, isn't it? > >If you do not mind, I suggest to close this bug report in a few days. > >Best regards, Georges.
Bug#1061155: cron: "crontab -e" does not report "unsafe" mail and so job output can be lost
Hello Joathan, have you received my previous reply to your bug report?It was one month ago. If you did not read it, you can find it today athttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061155The title of the present bug report says that crontab -e cannotdetect “unsafe” email addresses.However, the example you proposed is the usage of e-mail addresses likea...@example.org, b...@example.com, which can be parsed by the usual regularexpressions, as valid e-mail addresses.So, I ask you again for other suggestions about a secure way todistinguish “safe” from “unsafe” e-mail addresses.I suspect that asking a program to be more clever than its users is awaste of energy. For example, if I send this email tono-deb...@jhnc.org, chances are that the e-mail will never bedistributed. It is my responsability to send this e-mail todeb...@jhnc.org, isn't it?If you do not mind, I suggest to close this bug report in a few days.Best regards, Georges.
Bug#1061155: cron: "crontab -e" does not report "unsafe" mail and so job output can be lost
Hello, Thank you for your bug report. I shall lower the severity of your bug report, since it "causes non-serious data loss" a...@example.org would be parsed as a valid e-mail address if one uses regexp matching. What improvement would you suggest? Should "crontab -e" send an e-mail to recipients stated by MAILTO and wait for a reply? Best regards, Georges. On Fri, 19 Jan 2024 18:06:52 + Jonathan H N Chin wrote: > Package: cron > Version: 3.0pl1-182 > Severity: grave > Justification: causes non-serious data loss > > Dear Maintainer, > > >* What led up to the situation? > > 1. A user ran "crontab -e" > > 2. He added the line (note the space): > > MAILTO=a...@example.org, b...@example.com > > > 3. He saved and exited > > 4. No errors were reported to the user. > > >* What was the outcome of this action? > > Subsequently, jobs ran but output was discarded. > > /var/log/syslog contains "UNSAFE MAIL" messages which the user cannot see. > > >* What outcome did you expect instead? > > At step 4, crontab should have reported an error to the user > and not applied the update. > > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.15.0-91-generic (SMP w/1 CPU thread) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages cron depends on: > ii cron-daemon-common 3.0pl1-182 > ii init-system-helpers 1.66 > ii libc62.37-13 > ii libpam-runtime 1.5.2-9.1 > ii libpam0g 1.5.2-9.1+b1 > ii libselinux1 3.5-1+b2 > ii sensible-utils 0.0.20 > > Versions of packages cron recommends: > ii exim4-daemon-heavy [mail-transport-agent] 4.97-4+b1 > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1061155: cron: "crontab -e" does not report "unsafe" mail and so job output can be lost
Package: cron Version: 3.0pl1-182 Severity: grave Justification: causes non-serious data loss Dear Maintainer, * What led up to the situation? 1. A user ran "crontab -e" 2. He added the line (note the space): MAILTO=a...@example.org, b...@example.com 3. He saved and exited 4. No errors were reported to the user. * What was the outcome of this action? Subsequently, jobs ran but output was discarded. /var/log/syslog contains "UNSAFE MAIL" messages which the user cannot see. * What outcome did you expect instead? At step 4, crontab should have reported an error to the user and not applied the update. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-91-generic (SMP w/1 CPU thread) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages cron depends on: ii cron-daemon-common 3.0pl1-182 ii init-system-helpers 1.66 ii libc62.37-13 ii libpam-runtime 1.5.2-9.1 ii libpam0g 1.5.2-9.1+b1 ii libselinux1 3.5-1+b2 ii sensible-utils 0.0.20 Versions of packages cron recommends: ii exim4-daemon-heavy [mail-transport-agent] 4.97-4+b1 Versions of packages cron suggests: pn anacron pn checksecurity ii logrotate 3.21.0-2 Versions of packages cron is related to: pn libnss-ldap pn libnss-ldapd pn libpam-ldap pn libpam-mount pn nis pn nscd -- no debconf information
