[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#930971: marked as done (unblock: cron/3.0pl1-134)



Your message dated Tue, 25 Jun 2019 17:55:00 +0000
with message-id <ca690ea8-54d7-513d-a1fb-3b6a085eb1c6@thykier.net>
and subject line Re: Bug#930971: unblock: cron/3.0pl1-134
has caused the Debian Bug report #930971,
regarding unblock: cron/3.0pl1-134
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
930971: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930971
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: unblock

Dear Release Team,

Please unblock cron/3.0pl1-134. This is a one-line change that increases
the hard-coded LOC limits for crontabs from 1,000 to 10,000.

Looking at the feedback so far for #925276, I believe that this change
is necessary and sufficient.

I debated for a long time whether to make this limit dynamically
configurable, which would be the more user-friendly option, but
ultimately decided against it. The problem with that solution is that
currently, only the daemon reads /etc/default/cron, so the crontab
executable would have to start reading it, too -- and that feels just
too much of a departure from the original cron codebase.

If this still causes problems for users, I'd revisit the issue, but
right now I'd rather just wait and see if 10,000 really is a problem for
somebody.

Full debdiff -w attached.

Regards,
Christian
diff -wu cron-3.0pl1/cron.h cron-3.0pl1/cron.h
--- cron-3.0pl1/cron.h
+++ cron-3.0pl1/cron.h
@@ -82,7 +82,7 @@
 #define	MAX_COMMAND	1000	/* max length of internally generated cmd */
 #define	MAX_TEMPSTR	1000	/* max length of envvar=value\0 strings */
 #define	MAX_ENVSTR	MAX_TEMPSTR	/* DO NOT change - buffer overruns otherwise */
-#define MAX_TAB_LINES	1000	/* max length of crontabs */
+#define MAX_TAB_LINES	10000	/* max length of crontabs */
 #define	MAX_UNAME	20	/* max length of username, should be overkill */
 #define	ROOT_UID	0	/* don't change this, it really must be root */
 #define	ROOT_USER	"root"	/* ditto */
diff -wu cron-3.0pl1/debian/NEWS cron-3.0pl1/debian/NEWS
--- cron-3.0pl1/debian/NEWS
+++ cron-3.0pl1/debian/NEWS
@@ -1,3 +1,9 @@
+cron (3.0pl1-134) unstable; urgency=medium
+
+  * crontabs are now limited to 10,000 lines, up from the previous 1,000.
+
+ -- Christian Kastner <ckk@debian.org>  Sun, 23 Jun 2019 19:45:57 +0200
+
 cron (3.0pl1-133) unstable; urgency=medium
 
   * As a reasonable protective measure, crontabs are now limited to 1000 lines
diff -wu cron-3.0pl1/debian/changelog cron-3.0pl1/debian/changelog
--- cron-3.0pl1/debian/changelog
+++ cron-3.0pl1/debian/changelog
@@ -1,3 +1,12 @@
+cron (3.0pl1-134) unstable; urgency=medium
+
+  * Increase maximum crontab length to 10,000 lines.
+    The previous limit proved to be too low for users with edge cases.
+    (Closes: #925276)
+  * Add NEWS entry for crontab line limit increase.
+
+ -- Christian Kastner <ckk@debian.org>  Sun, 23 Jun 2019 19:49:01 +0200
+
 cron (3.0pl1-133) unstable; urgency=medium
 
   * SECURITY: Fix bypass of /etc/cron.{allow,deny} on failure to open

--- End Message ---
--- Begin Message ---
Christian Kastner:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: unblock
> 
> Dear Release Team,
> 
> Please unblock cron/3.0pl1-134. This is a one-line change that increases
> the hard-coded LOC limits for crontabs from 1,000 to 10,000.
> 
> Looking at the feedback so far for #925276, I believe that this change
> is necessary and sufficient.
> 
> I debated for a long time whether to make this limit dynamically
> configurable, which would be the more user-friendly option, but
> ultimately decided against it. The problem with that solution is that
> currently, only the daemon reads /etc/default/cron, so the crontab
> executable would have to start reading it, too -- and that feels just
> too much of a departure from the original cron codebase.
> 
> If this still causes problems for users, I'd revisit the issue, but
> right now I'd rather just wait and see if 10,000 really is a problem for
> somebody.
> 
> Full debdiff -w attached.
> 
> Regards,
> Christian
> 

Unblocked, thanks.
~Niels

--- End Message ---

Reply to: