Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
On 2015-01-28 03:21, Michael Gilbert wrote: There is a new sudo RC bug #776137 (not related to this issue). That also needs fixing before an unblock will likely be granted. Thank you for pointing this out. I submitted a patch, but it still needs independent testing. Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
Control: tags -1 - moreinfo Hi, On 2015-01-17 20:38, Ivo De Decker wrote: Don't remove the moreinfo tag from this bug when the upload enters t-p-u (unless you have other info to add to the discussion). Leave it there for at least 5 days. After that, remove the moreinfo tag from this bug and let us know whether you had any reports about the upload (good or bad). We will review the situation at that point. sudo 1.8.10p3-1+deb8u1 was uploaded to t-p-u on 2015-01-19. In the week since then, no new bugs were reported, nor have I become aware of any other issues. Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
On Tue, Jan 27, 2015 at 4:24 AM, Christian Kastner wrote: Control: tags -1 - moreinfo Hi, On 2015-01-17 20:38, Ivo De Decker wrote: Don't remove the moreinfo tag from this bug when the upload enters t-p-u (unless you have other info to add to the discussion). Leave it there for at least 5 days. After that, remove the moreinfo tag from this bug and let us know whether you had any reports about the upload (good or bad). We will review the situation at that point. sudo 1.8.10p3-1+deb8u1 was uploaded to t-p-u on 2015-01-19. In the week since then, no new bugs were reported, nor have I become aware of any other issues. There is a new sudo RC bug #776137 (not related to this issue). That also needs fixing before an unblock will likely be granted. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
On Sat, Jan 17, 2015 at 2:38 PM, Ivo De Decker wrote: Control: tags -1 moreinfo Hi, On Sat, Jan 17, 2015 at 04:13:37PM +0100, Christian Kastner wrote: On 2015-01-17 07:57, martin f krafft wrote: Christian, I suppose it'll have to be 1.8.10p3-1.1 via t-p-u. Doable? Martin, did you actually test that version? If so, please let us know. Sure. Updated debdiff attached. (Did I get the revision right? Note that I dropped the nmu-ish .1 as I felt the +deb8u1 qualifier consumes it) Ivo had concerns with regards to a t-p-u upload, and said he'd prefer instead a path via unstable. To summarize my verbose reply: this fix has been in unstable for 3 weeks now, albeit in the newer sudo version. The attached debdiff just backports this fix to the older sudo. So if everyone is OK with the above, I guess all that remains is for someone to sponsor the upload. I'm still not convinced. You didn't really give an argument why an update via unstable wouldn't work. The update fixing this bug has already happened. That is work already done in unstable. What remains is for the changes to transition to testing. Since the release team rejected the newer upstream in unstable, the right approach now is via tpu. The suggestion to revert the upstream version in unstable with an epoch is not needed at all. I will review and sponsor Christian's tpu so this can be done. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
Control: tags -1 moreinfo Hi, On Sat, Jan 17, 2015 at 04:13:37PM +0100, Christian Kastner wrote: On 2015-01-17 07:57, martin f krafft wrote: Christian, I suppose it'll have to be 1.8.10p3-1.1 via t-p-u. Doable? Martin, did you actually test that version? If so, please let us know. Sure. Updated debdiff attached. (Did I get the revision right? Note that I dropped the nmu-ish .1 as I felt the +deb8u1 qualifier consumes it) Ivo had concerns with regards to a t-p-u upload, and said he'd prefer instead a path via unstable. To summarize my verbose reply: this fix has been in unstable for 3 weeks now, albeit in the newer sudo version. The attached debdiff just backports this fix to the older sudo. So if everyone is OK with the above, I guess all that remains is for someone to sponsor the upload. I'm still not convinced. You didn't really give an argument why an update via unstable wouldn't work. As my main concern is about tests for this version, I suggest you go ahead with the upload to t-p-u based on your patch (the version in your patch is ok). Once that version is in t-p-u, people can at least get it from there if they want to test is (which might not happen that often, but without the upload, it won't happen at all). Don't remove the moreinfo tag from this bug when the upload enters t-p-u (unless you have other info to add to the discussion). Leave it there for at least 5 days. After that, remove the moreinfo tag from this bug and let us know whether you had any reports about the upload (good or bad). We will review the situation at that point. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
also sprach Ivo De Decker iv...@debian.org [2015-01-17 20:38 +0100]: Martin, did you actually test that version? If so, please let us know. Yes I did, a long time ago though. I'm still not convinced. You didn't really give an argument why an update via unstable wouldn't work. Because a newer version is already in unstable. It's my understanding that you cannot upload 1.8.10p3-1.1 to unstable when 1.8.11p2-1.1 is already there. Am I wrong? -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems never eat more than you can lift. -- miss piggy digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
On 2015-01-17 07:57, martin f krafft wrote:
Christian, I suppose it'll have to be 1.8.10p3-1.1 via t-p-u.
Doable?
Sure. Updated debdiff attached. (Did I get the revision right? Note that
I dropped the nmu-ish .1 as I felt the +deb8u1 qualifier consumes it)
Ivo had concerns with regards to a t-p-u upload, and said he'd prefer
instead a path via unstable. To summarize my verbose reply: this fix has
been in unstable for 3 weeks now, albeit in the newer sudo version. The
attached debdiff just backports this fix to the older sudo.
So if everyone is OK with the above, I guess all that remains is for
someone to sponsor the upload.
Regards,
Christian
diff -Nru sudo-1.8.10p3/debian/changelog sudo-1.8.10p3/debian/changelog
--- sudo-1.8.10p3/debian/changelog 2014-09-14 18:26:06.0 +0200
+++ sudo-1.8.10p3/debian/changelog 2015-01-17 15:44:24.0 +0100
@@ -1,3 +1,11 @@
+sudo (1.8.10p3-1+deb8u1) jessie; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport upstream's fix for host specifications using a FQDN. These were
+no longer working since 1.8.8. Closes: #731583
+
+ -- Christian Kastner deb...@kvr.at Sat, 17 Jan 2015 15:39:31 +0100
+
sudo (1.8.10p3-1) unstable; urgency=low
* new upstream release
diff -Nru
sudo-1.8.10p3/debian/patches/Fix-for-broken-FQDN-host-specifications.diff
sudo-1.8.10p3/debian/patches/Fix-for-broken-FQDN-host-specifications.diff
--- sudo-1.8.10p3/debian/patches/Fix-for-broken-FQDN-host-specifications.diff
1970-01-01 01:00:00.0 +0100
+++ sudo-1.8.10p3/debian/patches/Fix-for-broken-FQDN-host-specifications.diff
2015-01-17 15:29:14.0 +0100
@@ -0,0 +1,92 @@
+From: Christian Kastner deb...@kvr.at
+Date: Fri, 05 Dec 2014 14:58:50 +0100
+Subject: Fix for broken FQDN host specifications
+
+A bug was introduced in sudo 1.8.8 which broke host specifications using a
+FQDN, eg Host_Alias = host.example.com. Upstream has fixed this in 1.8.12.
+
+This patch contains the fix backported to 1.8.10p3.
+
+Origin: http://www.sudo.ws/repos/sudo/rev/4f75b01d4884
+Bug: http://www.sudo.ws/bugs/show_bug.cgi?id=678
+Bug-Debian: https://bugs.debian.org/731583
+Last-Update: 2014-05-12
+
+Index: sudo-1.8.10p3/plugins/sudoers/sudoers.c
+===
+--- sudo-1.8.10p3.orig/plugins/sudoers/sudoers.c
sudo-1.8.10p3/plugins/sudoers/sudoers.c
+@@ -799,32 +799,69 @@ set_loginclass(struct passwd *pw)
+ #endif
+
+ /*
+- * Look up the fully qualified domain name and set user_host and user_shost.
++ * Look up the fully qualified domain name of user_host and user_runhost.
++ * Sets user_host, user_shost, user_runhost and user_srunhost.
+ * Use AI_FQDN if available since canonical is not always the same as fqdn.
+ */
+ static void
+ set_fqdn(void)
+ {
+ struct addrinfo *res0, hint;
++bool remote;
+ char *p;
+ debug_decl(set_fqdn, SUDO_DEBUG_PLUGIN)
+
++/* If the -h flag was given we need to resolve both host and runhost. */
++remote = strcmp(user_runhost, user_host) != 0;
++
+ memset(hint, 0, sizeof(hint));
+ hint.ai_family = PF_UNSPEC;
+ hint.ai_flags = AI_FQDN;
++
++/* First resolve user_host, sets user_host and user_shost. */
+ if (getaddrinfo(user_host, NULL, hint, res0) != 0) {
+ log_warning(MSG_ONLY, N_(unable to resolve host %s), user_host);
+ } else {
+ if (user_shost != user_host)
+ efree(user_shost);
+ efree(user_host);
+- user_host = estrdup(res0-ai_canonname);
++ user_host = user_shost = estrdup(res0-ai_canonname);
+ freeaddrinfo(res0);
+ if ((p = strchr(user_host, '.')) != NULL)
+ user_shost = estrndup(user_host, (size_t)(p - user_host));
+- else
+- user_shost = user_host;
+ }
++
++/* Next resolve user_runhost, sets user_runhost and user_srunhost. */
++if (remote) {
++ if (getaddrinfo(user_runhost, NULL, hint, res0) != 0) {
++ log_warning(MSG_ONLY,
++ N_(unable to resolve host %s), user_runhost);
++ } else {
++ if (user_srunhost != user_runhost)
++ efree(user_srunhost);
++ efree(user_runhost);
++ user_runhost = user_srunhost = estrdup(res0-ai_canonname);
++ freeaddrinfo(res0);
++ if ((p = strchr(user_runhost, '.'))) {
++ user_srunhost =
++ estrndup(user_runhost, (size_t)(p - user_runhost));
++ }
++ }
++} else {
++ /* Not remote, just use user_host. */
++ if (user_srunhost != user_runhost)
++ efree(user_srunhost);
++ efree(user_runhost);
++ user_runhost = user_srunhost = estrdup(user_host);
++ if ((p = strchr(user_runhost, '.'))) {
++ user_srunhost =
++ estrndup(user_runhost, (size_t)(p - user_runhost));
++ }
++}
++
++sudo_debug_printf(SUDO_DEBUG_INFO|SUDO_DEBUG_LINENO,
++ host %s, shost %s, runhost %s, srunhost %s,
++ user_host, user_shost,
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
also sprach Christian Kastner deb...@kvr.at [2015-01-17 16:13 +0100]: So if everyone is OK with the above, I guess all that remains is for someone to sponsor the upload. Which cannot go via unstable anymore unless you introduce an epoch. Since the fix has been in unstable for 3 weeks (along with other changes), and there were no new bugs, I think a package containing just the one patch can surely go via t-p-u. And I would keep it at -1.1 as this *is* a NMU… unless you join the packaging team, then make it -2. +sudo (1.8.10p3-1+deb8u1) jessie; urgency=medium I think the +deb8u1 postfix should be reserved for stable updates and not used yet. But if the release team suggested that, then I'll rest my case. -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems der glaube an den kausalnexus ist der aberglaube -- wittgenstein digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
On 2015-01-14 21:40, martin f krafft wrote: also sprach Ivo De Decker iv...@debian.org [2015-01-14 21:58 +0100]: I'm reluctant to allow this, as this essentially means dumping this new version into jessie untested. I would prefer if it was just uploaded to unstable (reverting the new upstream version there), to allow it to be tested there, and migrate to jessie that way. If there is a good reason why this isn't possible (if it introduces other issues in unstable by doing this), please explain why and I'll consider allowing a t-p-u upload. It's my understanding that unstable contains a fixed non-new upstream version which could migrate to jessie now. It is a new upstream version. Jessie has 1.8.10, sid has 1.8.11. (The diff is also significant, even after stripping obvious noise.) Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
also sprach Adam D. Barratt a...@adam-barratt.org.uk [2015-01-17 00:20 +0100]: It is a new upstream version. Jessie has 1.8.10, sid has 1.8.11. (The diff is also significant, even after stripping obvious noise.) Ah, sorry. I had somehow overlooked that. Christian, I suppose it'll have to be 1.8.10p3-1.1 via t-p-u. Doable? -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems mirrors should reflect a little before throwing back images. -- jean cocteau digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
Control: tags -1 moreinfo Hi, On Tue, Dec 16, 2014 at 10:02:55PM +0100, Christian Kastner wrote: (rearranging the original mail a bit) controversial Furthermore, I was wondering though whether you'd consider allowing sudo/1.8.11p2 from unstable to migrate. The diff between testing and unstable is huge (MBs), so this would be very difficult to review and of course totally against freeze policy. However, I am under the impression that (a) it would be highly preferrable to support 1.8.11p2 in Jessie, especially from a security POV (b) According to [2,3,4], most of the changes are bugfixes. In fact, I only count 7 non-fix changes and non-translation changes, and most of the fix changes appear to be highly desirable. Furthermore, the largest part of this code base, [3], has unstable since 2014-10-10, and its migration to testing was only interrupted by the upload of revision -2 of [3] on 2014-10-20, so apparently juuust not enough for the full 10-day period. This upload merely added two patches. Then again, on 2014-10-30, [4] was uploaded. This new upstream release contained only a single (apparently urgent) bugfix. However, this upload reset the 10-day clock again, so 1.8.11p* did not enter testing again. So there really isn't anything that new to Debian in the version in unstable. Looking back, the easiest solution would probably have been to ask for an unblock of [4] (the one-change fix) just after its upload on 2014-10-30, but that's water under the bridge now. /controversial It baffles me that the maintainer showed such a blatant disregard for the freeze policy. 1.8.11p1 could have migrated easily in October if the maintainer paid even the slightest bit of attention. If allowing 1.8.11p2 to migrate is something you'd consider discussing, please let me know how I can help in your deliberations. Obviously it isn't going to be unblocked now. simple Based on a patch provided by upstream, I created a debdiff (attached) for 1.8.10p3 in testing with the following changelog entry: * Backport upstream's fix for host specifications using a FQDN. These were no longer working since 1.8.8. Closes: #731583 Considering that the severity of #731583 is serious, I assume an upload to t-p-u should be OK? /simple I'm reluctant to allow this, as this essentially means dumping this new version into jessie untested. I would prefer if it was just uploaded to unstable (reverting the new upstream version there), to allow it to be tested there, and migrate to jessie that way. If there is a good reason why this isn't possible (if it introduces other issues in unstable by doing this), please explain why and I'll consider allowing a t-p-u upload. Please remove the moreinfo tag when you add info to this bug. If this change is simply too big, please let me know if you are OK with the t-p-u upload of the attached debdiff for 1.8.10p3, and I will then contact the maintainer / look for NMU sponsorship. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
Control: tags -1 - moreinfo On 2015-01-14 21:58, Ivo De Decker wrote: simple Based on a patch provided by upstream, I created a debdiff (attached) for 1.8.10p3 in testing with the following changelog entry: * Backport upstream's fix for host specifications using a FQDN. These were no longer working since 1.8.8. Closes: #731583 Considering that the severity of #731583 is serious, I assume an upload to t-p-u should be OK? /simple I'm reluctant to allow this, as this essentially means dumping this new version into jessie untested. This fix already entered unstable in the meantime, with NMU 1.8.11p2-1.1 (which was an NMU against 1.8.11p2-1 with just this one fix added). So it received about three weeks of general testing without new bug reports. Personally, I've been using 1.8.10p3-1.1 (as per my original debdiff) on all my Jessie systems since it was first proposed, and can report that it works as intended. I would prefer if it was just uploaded to unstable (reverting the new upstream version there), to allow it to be tested there, and migrate to jessie that way. If there is a good reason why this isn't possible (if it introduces other issues in unstable by doing this), please explain why and I'll consider allowing a t-p-u upload. Would you consider the new information above satisfactory WRT sufficient testing, so that perhaps the unstable shuffling could be avoided? Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
also sprach Ivo De Decker iv...@debian.org [2015-01-14 21:58 +0100]: I'm reluctant to allow this, as this essentially means dumping this new version into jessie untested. I would prefer if it was just uploaded to unstable (reverting the new upstream version there), to allow it to be tested there, and migrate to jessie that way. If there is a good reason why this isn't possible (if it introduces other issues in unstable by doing this), please explain why and I'll consider allowing a t-p-u upload. It's my understanding that unstable contains a fixed non-new upstream version which could migrate to jessie now. Christian would still like to get p3 into jessie, but I agree that this should not happen without testing. So how about unblocking p2-1.1 and letting it into jessie, then uploading p3-1 to unstable and revisiting the issue in a few days? In the unlikely event that we need to push p2-1.2 or p2-2 to jessie, we would need to use t-p-u to bypass unstable. -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
Hi, On 2014-12-16 22:02, Christian Kastner wrote: If allowing 1.8.11p2 to migrate is something you'd consider discussing, please let me know how I can help in your deliberations. If this change is simply too big, please let me know if you are OK with the t-p-u upload of the attached debdiff for 1.8.10p3, and I will then contact the maintainer / look for NMU sponsorship. quick followup: 1.8.11p2-1.1 has been uploaded to unstable, including (only) the fix found in the above-mentioned debdiff. If unblocking 1.8.11p2-1.1 is a no-go, the sponsor of the aforementioned upload said he would be available for a 1.8.10p3-1.1 upload (that's the debdiff I posted here) to t-p-u. Regards, Christian77 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
On 2014-12-22 15:15, Christian Kastner wrote: On 2014-12-16 22:02, Christian Kastner wrote: If allowing 1.8.11p2 to migrate is something you'd consider discussing, please let me know how I can help in your deliberations. If this change is simply too big, please let me know if you are OK with the t-p-u upload of the attached debdiff for 1.8.10p3, and I will then contact the maintainer / look for NMU sponsorship. quick followup: 1.8.11p2-1.1 has been uploaded to unstable, including (only) the fix found in the above-mentioned debdiff. ...adapted to 1.8.11p2-1.1, of course. The debdiff I initially attached, and keep referring to, is against the version in testing. Sorry for the confusion. If unblocking 1.8.11p2-1.1 is a no-go, the sponsor of the aforementioned upload said he would be available for a 1.8.10p3-1.1 upload (that's the debdiff I posted here) to t-p-u. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773319: pre-approval: unblock: sudo/1.8.10p3-1.1; possibly sudo/1.8.11p2-1.1?
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi release team,
With the maintainer's permission [1], I'd like to ask for your opinion
on how to proceed with #731583.
simple
Based on a patch provided by upstream, I created a debdiff (attached)
for 1.8.10p3 in testing with the following changelog entry:
* Backport upstream's fix for host specifications using a FQDN.
These were no longer working since 1.8.8. Closes: #731583
Considering that the severity of #731583 is serious, I assume an upload
to t-p-u should be OK?
/simple
controversial
Furthermore, I was wondering though whether you'd consider allowing
sudo/1.8.11p2 from unstable to migrate.
The diff between testing and unstable is huge (MBs), so this would be
very difficult to review and of course totally against freeze policy.
However, I am under the impression that
(a) it would be highly preferrable to support 1.8.11p2 in Jessie,
especially from a security POV
(b) According to [2,3,4], most of the changes are bugfixes. In fact,
I only count 7 non-fix changes and non-translation changes,
and most of the fix changes appear to be highly desirable.
Furthermore, the largest part of this code base, [3], has unstable since
2014-10-10, and its migration to testing was only interrupted by the
upload of revision -2 of [3] on 2014-10-20, so apparently juuust not
enough for the full 10-day period. This upload merely added two patches.
Then again, on 2014-10-30, [4] was uploaded. This new upstream release
contained only a single (apparently urgent) bugfix. However, this upload
reset the 10-day clock again, so 1.8.11p* did not enter testing again.
So there really isn't anything that new to Debian in the version in
unstable. Looking back, the easiest solution would probably have been to
ask for an unblock of [4] (the one-change fix) just after its upload on
2014-10-30, but that's water under the bridge now.
/controversial
If allowing 1.8.11p2 to migrate is something you'd consider discussing,
please let me know how I can help in your deliberations. If this change
is simply too big, please let me know if you are OK with the t-p-u
upload of the attached debdiff for 1.8.10p3, and I will then contact the
maintainer / look for NMU sponsorship.
Regards,
Christian
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731583#104
[2] http://www.sudo.ws/sudo/stable.html#1.8.11
[3] http://www.sudo.ws/sudo/stable.html#1.8.11p1
[4] http://www.sudo.ws/sudo/stable.html#1.8.11p2
diff -Nru sudo-1.8.10p3/debian/changelog sudo-1.8.10p3/debian/changelog
--- sudo-1.8.10p3/debian/changelog 2014-09-14 18:26:06.0 +0200
+++ sudo-1.8.10p3/debian/changelog 2014-12-05 15:12:47.0 +0100
@@ -1,3 +1,11 @@
+sudo (1.8.10p3-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport upstream's fix for host specifications using a FQDN. These were
+no longer working since 1.8.8. Closes: #731583
+
+ -- Christian Kastner deb...@kvr.at Fri, 05 Dec 2014 15:10:30 +0100
+
sudo (1.8.10p3-1) unstable; urgency=low
* new upstream release
diff -Nru
sudo-1.8.10p3/debian/patches/Fix-for-broken-FQDN-host-specifications.diff
sudo-1.8.10p3/debian/patches/Fix-for-broken-FQDN-host-specifications.diff
--- sudo-1.8.10p3/debian/patches/Fix-for-broken-FQDN-host-specifications.diff
1970-01-01 01:00:00.0 +0100
+++ sudo-1.8.10p3/debian/patches/Fix-for-broken-FQDN-host-specifications.diff
2014-12-05 15:20:43.0 +0100
@@ -0,0 +1,92 @@
+From: Christian Kastner deb...@kvr.at
+Date: Fri, 05 Dec 2014 14:58:50 +0100
+Subject: Fix for broken FQDN host specifications
+
+A bug was introduced in sudo 1.8.8 which broke host specifications using a
+FQDN, eg Host_Alias = host.example.com. Upstream has fixed this in 1.8.12.
+
+This patch contains the fix backported to 1.8.10p3.
+
+Origin: http://www.sudo.ws/repos/sudo/rev/4f75b01d4884
+Bug: http://www.sudo.ws/bugs/show_bug.cgi?id=678
+Bug-Debian: https://bugs.debian.org/731583
+Last-Update: 2014-05-12
+
+Index: sudo-1.8.10p3/plugins/sudoers/sudoers.c
+===
+--- sudo-1.8.10p3.orig/plugins/sudoers/sudoers.c
sudo-1.8.10p3/plugins/sudoers/sudoers.c
+@@ -799,32 +799,69 @@ set_loginclass(struct passwd *pw)
+ #endif
+
+ /*
+- * Look up the fully qualified domain name and set user_host and user_shost.
++ * Look up the fully qualified domain name of user_host and user_runhost.
++ * Sets user_host, user_shost, user_runhost and user_srunhost.
+ * Use AI_FQDN if available since canonical is not always the same as fqdn.
+ */
+ static void
+ set_fqdn(void)
+ {
+ struct addrinfo *res0, hint;
++bool remote;
+ char *p;
+ debug_decl(set_fqdn, SUDO_DEBUG_PLUGIN)
+
++/* If the -h flag was given we need to resolve both host and runhost. */
++remote = strcmp(user_runhost, user_host) != 0;
++
+ memset(hint, 0, sizeof(hint));
+
