Bug#1058938: bookworm-pu: package onionprobe/1.0.0+ds-2.1+deb12u1

[Antoine Beaupré]

I have reviewed this patch and it looks sane to me. I have deployed the
updated package on our servers and it is so far running without flaw.

A.

-- 
There is no cloud, it's just someone else's computer.
   - Chris Watterson

Bug#1056358: bookworm-pu: package needrestart/3.6-4+deb12u1

[Antoine Beaupré]

Control: tags -1 - moreinfo

On 2023-12-02 18:52:39, Adam D. Barratt wrote:
> There doesn't appear to be a debdiff attached.

What is wrong with me.

diff -Nru needrestart-3.6/debian/changelog needrestart-3.6/debian/changelog
--- needrestart-3.6/debian/changelog	2023-05-31 10:47:03.0 -0400
+++ needrestart-3.6/debian/changelog	2023-11-15 15:05:37.0 -0500
@@ -1,3 +1,9 @@
+needrestart (3.6-4+deb12u1) bookworm; urgency=medium
+
+  * fix microcode check regression on AMD CPUs (Closes: #1013285)
+
+ -- Antoine Beaupré   Wed, 15 Nov 2023 15:05:37 -0500
+
 needrestart (3.6-4) unstable; urgency=medium
 
   * Remove leftover conffile 30-pacman with 3.6-4.
diff -Nru needrestart-3.6/debian/patches/05-fix-AMD-ucode-checking-in-non-debug-mode.patch needrestart-3.6/debian/patches/05-fix-AMD-ucode-checking-in-non-debug-mode.patch
--- needrestart-3.6/debian/patches/05-fix-AMD-ucode-checking-in-non-debug-mode.patch	1969-12-31 19:00:00.0 -0500
+++ needrestart-3.6/debian/patches/05-fix-AMD-ucode-checking-in-non-debug-mode.patch	2023-11-15 15:05:37.0 -0500
@@ -0,0 +1,33 @@
+From b073fb6d9969597173daa8c511a85bae9b03ed37 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Wed, 15 Nov 2023 15:20:37 -0500
+Subject: [PATCH] fix AMD ucode checking in non-debug mode
+
+It looks like the assignment when the ucode exist was not
+done *unless* `debug` (`-v`) was set. Therefore, all AMD microcode
+checks were returning UNKNOWN, including in Nagios checks, unless the
+`-v` ("verbose", but actually `debug`) was passed.
+
+Closes: #249
+---
+ perl/lib/NeedRestart/uCode/AMD.pm | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/perl/lib/NeedRestart/uCode/AMD.pm b/perl/lib/NeedRestart/uCode/AMD.pm
+index 638e68d..6daad8f 100644
+--- a/perl/lib/NeedRestart/uCode/AMD.pm
 b/perl/lib/NeedRestart/uCode/AMD.pm
+@@ -185,8 +185,8 @@ sub nr_ucode_check_real {
+ if ( exists( $_ucodes->{cpuid}->{$cpuid} ) ) {
+ my $prid = $_ucodes->{cpuid}->{$cpuid};
+ if ( exists( $_ucodes->{prid}->{$prid} ) ) {
+-$vars{AVAIL} = sprintf( "0x%08x", $_ucodes->{prid}->{$prid} ),
+-		print STDERR "$LOGPREF #$info->{processor} found ucode $vars{AVAIL}\n" if ($debug);
++$vars{AVAIL} = sprintf( "0x%08x", $_ucodes->{prid}->{$prid} );
++print STDERR "$LOGPREF #$info->{processor} found ucode $vars{AVAIL}\n" if ($debug);
+ 	}
+ }
+ 
+-- 
+2.39.2
+
diff -Nru needrestart-3.6/debian/patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.patch needrestart-3.6/debian/patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.patch
--- needrestart-3.6/debian/patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.patch	1969-12-31 19:00:00.0 -0500
+++ needrestart-3.6/debian/patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.patch	2023-11-15 15:05:37.0 -0500
@@ -0,0 +1,30 @@
+From e85bfe33b595b88cc8052a7815d13612ecc2a841 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Stefan=20B=C3=BChler?= 
+Date: Sun, 28 May 2023 17:42:28 +0200
+Subject: [PATCH] [uCode] fix uninitialized value in logging of processor index
+
+This got broken in f8c2609f8d5a0e10bd988497b8ea9815a7bb2fa8.
+
+Before that it would have effectively logged
+`$processors{$pid}->{processor}`, but the `processor` entry
+is also the key in `%processors`, i.e. equals `$pid`.
+---
+ perl/lib/NeedRestart/uCode.pm | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/perl/lib/NeedRestart/uCode.pm b/perl/lib/NeedRestart/uCode.pm
+index 6251339..db81375 100644
+--- a/perl/lib/NeedRestart/uCode.pm
 b/perl/lib/NeedRestart/uCode.pm
+@@ -148,7 +148,7 @@ sub nr_ucode_check {
+ }
+ $ui->progress_step;
+ 
+-my $nstate = compare_ucode_versions( $debug, $processors{processor}, @nvars );
++my $nstate = compare_ucode_versions( $debug, $pid, @nvars );
+ if ( $nstate > $state ) {
+ ( $state, @vars ) = ( $nstate, @nvars );
+ }
+-- 
+2.39.2
+
diff -Nru needrestart-3.6/debian/patches/07-mark-unavailable-firmware-as-CURRENT.patch needrestart-3.6/debian/patches/07-mark-unavailable-firmware-as-CURRENT.patch
--- needrestart-3.6/debian/patches/07-mark-unavailable-firmware-as-CURRENT.patch	1969-12-31 19:00:00.0 -0500
+++ needrestart-3.6/debian/patches/07-mark-unavailable-firmware-as-CURRENT.patch	2023-11-15 15:05:37.0 -0500
@@ -0,0 +1,61 @@
+From 0e1ffe8025416a918ddf169f2d858762733d7238 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Tue, 21 Nov 2023 10:59:32 -0500
+Subject: [PATCH] mark unavailable firmware as CURRENT
+
+This changes the policy of reporting missing firmware updates as
+"UNKNOWN". Now, if there's no available firmware, we report
+"current". That fixes needrestart on platforms that do

Bug#1054442: forgot debdiff

[Antoine Beaupré]

On 2023-11-29 22:24:25, Adam D. Barratt wrote:
> On Mon, 2023-10-23 at 15:36 -0400, Antoine Beaupré wrote:
>> And of course I forgot the debdiff, sorry!
>
> Please go ahead.

Uploaded, thanks for the review!!

-- 
Science knows still practically nothing about the real nature of
matter, energy, dimension, or time; and even less about those
remarkable things called life and thought. But whatever the meaning
and purpose of this universe, you are a legitimate part of it.
- Gene Roddenberry

Bug#1054442: forgot debdiff

[Antoine Beaupré]

And of course I forgot the debdiff, sorry!

diff -Nru hash-slinger-3.1/debian/changelog hash-slinger-3.1/debian/changelog
--- hash-slinger-3.1/debian/changelog	2022-02-10 01:03:46.0 -0500
+++ hash-slinger-3.1/debian/changelog	2023-10-05 10:37:58.0 -0400
@@ -1,3 +1,10 @@
+hash-slinger (3.1-1.1+deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Bug fix: "tlsa can produce invalid records" (Closes: #1053483)
+
+ -- Antoine Beaupré   Thu, 05 Oct 2023 10:37:58 -0400
+
 hash-slinger (3.1-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru hash-slinger-3.1/debian/patches/0001-fix-generic-TLSA-record-generation.patch hash-slinger-3.1/debian/patches/0001-fix-generic-TLSA-record-generation.patch
--- hash-slinger-3.1/debian/patches/0001-fix-generic-TLSA-record-generation.patch	1969-12-31 19:00:00.0 -0500
+++ hash-slinger-3.1/debian/patches/0001-fix-generic-TLSA-record-generation.patch	2023-10-05 10:36:07.0 -0400
@@ -0,0 +1,34 @@
+From e3bec6e2a6b1bda7c52b4c585474fd7cc23ab643 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Charaoui?= 
+Date: Wed, 4 Oct 2023 22:05:26 -0400
+Subject: [PATCH] fix generic TLSA record generation
+Applied-Upstream: https://github.com/letoams/hash-slinger/commit/0bb0dba91c51d367d9a37297f13e07f33c01bfdc
+
+It seems like the calculation for the TLSA record never really worked,
+as we're doing float division here on the `len()` field. In our case,
+that field returned `35.0` which is not valid in our environment.
+
+Doing an integer division gives the correct result in most cases, I
+believe.
+
+Closes: #45
+---
+ tlsa | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tlsa b/tlsa
+index cea7230..ec97150 100755
+--- a/tlsa
 b/tlsa
+@@ -513,7 +513,7 @@ class TLSARecord:
+ 	def getRecord(self, generic=False):
+ 		"""Returns the RR string of this TLSARecord, either in rfc (default) or generic format"""
+ 		if generic:
+-			return '%s IN TYPE52 \# %s %s%s%s%s' % (self.name, (len(self.cert)/2)+3 , self._toHex(self.usage), self._toHex(self.selector), self._toHex(self.mtype), self.cert)
++			return '%s IN TYPE52 \# %s %s%s%s%s' % (self.name, (len(self.cert)//2)+3 , self._toHex(self.usage), self._toHex(self.selector), self._toHex(self.mtype), self.cert)
+ 		return '%s IN TLSA %s %s %s %s' % (self.name, self.usage, self.selector, self.mtype, self.cert)
+ 
+ 	def _toHex(self, val):
+-- 
+2.39.2
+
diff -Nru hash-slinger-3.1/debian/patches/series hash-slinger-3.1/debian/patches/series
--- hash-slinger-3.1/debian/patches/series	2021-02-14 11:40:02.0 -0500
+++ hash-slinger-3.1/debian/patches/series	2023-10-05 10:36:07.0 -0400
@@ -1 +1,2 @@
 0001-Debian-default-root.key-resides-in-usr-share-dns-roo.patch
+0001-fix-generic-TLSA-record-generation.patch

Bug#1001180: bullseye-pu: package isync/1.3.0-2.2+deb11u1

[Antoine Beaupré]

On 2021-12-05 16:13:11, Antoine Beaupré wrote:

[...]

> It also seems to sync correctly: I'm testing a full sync now which
> should complete within an hour. So far so good.

And I can confirm a full and/or incremental sync both work fine. All
looks good to me.

-- 
To understand how any society functions you must understand the
relationship between the men and the women
- Angela Davis

Bug#1001180: bullseye-pu: package isync/1.3.0-2.2+deb11u1

[Antoine Beaupré]

On 2021-12-05 21:30:14, Salvatore Bonaccorso wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: car...@debian.org,anar...@debian.org
>
> Hi SRM,
>
> isync in bullseye is affected by CVE-2021-3657[1]. Upstream is
> providing as well explicit patches for the 1.3.x series. That said, I
> could not explicitly thest the package for the CVE is question.
>
> But I'm X-Debbugs-CC'ing Antoine which might additionally be able to
> expose the package for bullseye to some real situation testing.

Hi!

So unfortunately I don't have a reproducer for CVE-2021-3657. I was able
to trigger CVE-2021-3657 (#999804) with 1.4+, but I didn't have crashes
when running 1.3 in bullseye.

I did test a build of 1.3.0-2.2+deb11u1 based on carnil's debdiff, and
it compiles fine, which is a good start. :)

It also seems to sync correctly: I'm testing a full sync now which
should complete within an hour. So far so good.

a.

-- 
Rock journalism is people who can't write, interviewing people who can't
talk, in order to provide articles for people who can't read.
- Frank Zappa


signature.asc
Description: PGP signature

Bug#944538: buster-pu: package ganeti-instance-debootstrap/0.16-6.1

[Antoine Beaupré]

On 2020-04-26 10:46:41, Antoine Beaupré wrote:

[...]

> I will also mention that this has landed in buster ages ago, and no ill
> effects were found there.

I meant bullseye here, sorry.

Any news? :)

a.

-- 
Striving for social justice is the most valuable thing to do in life
   - Albert Einstein

Bug#944538: buster-pu: package ganeti-instance-debootstrap/0.16-6.1

[Antoine Beaupré]

On 2020-04-26 15:45:02, Julien Cristau wrote:
> On Fri, Feb 07, 2020 at 05:21:21PM -0500, Antoine Beaupré wrote:
>> [sorry for the dupe, hit send by mistake :(]
>> 
>> On 2019-11-24 12:13:20, Antoine Beaupré wrote:
>> > On 2019-11-23 18:34:25, Julien Cristau wrote:
>> >> I'm a bit uneasy about a blanket "include all", to be honest.  It's
>> >> probably harmless since it's all coming straight out of debootstrap, but
>> >> I'd have been happier with something like "include security.*" if that's
>> >> what we expect to see.
>> >
>> > What kind of problems would you expect with including too many ACLs?
>> 
>> I'm still curious to hear what kind of problems you expect here. I've
>> been running this patch in production for months now and would really
>> like to see this land in buster (and hopefully stretch next).
>> 
> I don't know, that's kind of the point.  For changes in stable I tend to
> err on the side of "if there's no demonstrated need for a change then it
> shouldn't be done".  Things like "because why not" tend to be red flags.

I don't know what to say here. I'm not familiar with the security.* flag
you are refering to, and I do not know whether it will fix my bug. I
also do not know if there are other similar bugs lurking that we just
haven't found yet, exactly about this.

It seems to me we should have the most faithful archive and recovery
when we do a snapshot. This is what this patch does.

You bring up the concern of "include all" yet you also explicitely say
that it's "probably harmless". So I'm truly confused as to why we're
still blocking on this. I understand we want to be conservative in
stable, but this is not like I'm introducing a 1000-line long patch
here.

I would argue that restricting the number of extended attributes is
*more* likely to create bugs than the opposite.

I will also mention that this has landed in buster ages ago, and no ill
effects were found there.

A.

-- 
Use for yourself little but give to others much.
   - Albert Einstein

Bug#944538: buster-pu: package ganeti-instance-debootstrap/0.16-6.1

[Antoine Beaupré]

On 2019-11-24 12:13:20, Antoine Beaupré wrote:
> On 2019-11-23 18:34:25, Julien Cristau wrote:
>> On Mon, Nov 11, 2019 at 10:40:58AM -0500, Antoine Beaupre wrote:
>>> diff -Nru ganeti-instance-debootstrap-0.16/debian/changelog 
>>> ganeti-instance-debootstrap-0.16/debian/changelog
>>> --- ganeti-instance-debootstrap-0.16/debian/changelog   2018-06-20 
>>> 06:57:18.0 -0400
>>> +++ ganeti-instance-debootstrap-0.16/debian/changelog   2019-11-01 
>>> 19:01:50.0 -0400
>>> @@ -1,3 +1,10 @@
>>> +ganeti-instance-debootstrap (0.16-6.1) unstable; urgency=medium
>>
>> Version number and distribution don't look right.
>
> Ah yes, that would be 0.16-6+deb10u1, right?
>

[...]

Attached a new debdiff with a better version number.

>> I'm a bit uneasy about a blanket "include all", to be honest.  It's
>> probably harmless since it's all coming straight out of debootstrap, but
>> I'd have been happier with something like "include security.*" if that's
>> what we expect to see.
>
> What kind of problems would you expect with including too many ACLs?
>
> A.
>
> -- 
> Qui vit sans folie n'est pas si sage qu'il croit.
> - François de La Rochefoucauld

-- 
Information is not knowledge. Knowledge is not wisdom.
Wisdom is not truth. Truth is not beauty.
Beauty is not love. Love is not music.
Music is the best.  - Frank Zappa

Bug#944538: buster-pu: package ganeti-instance-debootstrap/0.16-6.1

[Antoine Beaupré]

[sorry for the dupe, hit send by mistake :(]

On 2019-11-24 12:13:20, Antoine Beaupré wrote:
> On 2019-11-23 18:34:25, Julien Cristau wrote:
>> On Mon, Nov 11, 2019 at 10:40:58AM -0500, Antoine Beaupre wrote:
>>> diff -Nru ganeti-instance-debootstrap-0.16/debian/changelog 
>>> ganeti-instance-debootstrap-0.16/debian/changelog
>>> --- ganeti-instance-debootstrap-0.16/debian/changelog   2018-06-20 
>>> 06:57:18.0 -0400
>>> +++ ganeti-instance-debootstrap-0.16/debian/changelog   2019-11-01 
>>> 19:01:50.0 -0400
>>> @@ -1,3 +1,10 @@
>>> +ganeti-instance-debootstrap (0.16-6.1) unstable; urgency=medium
>>
>> Version number and distribution don't look right.
>
> Ah yes, that would be 0.16-6+deb10u1, right?

Attached a better debdiff with the right version number. I'm now part of
the ganeti team so this is actually a team upload now, and the patch has
been merged in the salsa repo.

[...]

>>
>> I'm a bit uneasy about a blanket "include all", to be honest.  It's
>> probably harmless since it's all coming straight out of debootstrap, but
>> I'd have been happier with something like "include security.*" if that's
>> what we expect to see.
>
> What kind of problems would you expect with including too many ACLs?

I'm still curious to hear what kind of problems you expect here. I've
been running this patch in production for months now and would really
like to see this land in buster (and hopefully stretch next).

Can I upload the package now?

Thanks!
-- 
Men are taught to apologize for their weaknesses, women for their
strengths.
- Lois Wyse
diff -Nru ganeti-instance-debootstrap-0.16/debian/changelog ganeti-instance-debootstrap-0.16/debian/changelog
--- ganeti-instance-debootstrap-0.16/debian/changelog	2018-06-20 06:57:18.0 -0400
+++ ganeti-instance-debootstrap-0.16/debian/changelog	2020-02-07 17:11:06.0 -0500
@@ -1,3 +1,10 @@
+ganeti-instance-debootstrap (0.16-6+deb10u1) buster; urgency=medium
+
+  * Team upload.
+  * add patch to respect linux caps (Closes: #942114)
+
+ -- Antoine Beaupré   Fri, 07 Feb 2020 17:11:06 -0500
+
 ganeti-instance-debootstrap (0.16-6) unstable; urgency=medium
 
   * Bump Standards-Version to 4.1.4; no changes needed
diff -Nru ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch
--- ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch	1969-12-31 19:00:00.0 -0500
+++ ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch	2020-02-07 17:11:06.0 -0500
@@ -0,0 +1,48 @@
+From cd34bcc48a2af92f484535b81fba2d46dad1dbb6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Thu, 10 Oct 2019 11:07:51 -0400
+Subject: [PATCH] respect Linux capabilities(7) in cache
+
+The default GNU tar configuration does not carry fancy extended
+attributes and that is where, among other things, stuff like Linux
+capabilities(7) are stored. This is kind of important because that's
+how ping(8) works for regular users.
+
+We shove --selinux and --acls in there while we're at it, because why
+not. We never know what the future might bring, and it seems
+silly *not* to create a complete archive.
+
+Note that --xattrs-include='*' is important because, by default, GNU
+tar will not include capabilities /even/ if --xattrs is specified on
+the commandline, see this bug report for details:
+
+https://bugzilla.redhat.com/show_bug.cgi?id=771927
+---
+ create | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/create b/create
+index 607bab2..7526e71 100755
+--- a/create
 b/create
+@@ -83,7 +83,7 @@ if [ "$CLEAN_CACHE" -a -d "$CACHE_DIR" ]; then
+ fi
+ 
+ if [ -f "$CACHE_FILE" ]; then
+-  tar xf "$CACHE_FILE" -C $TMPDIR
++  tar --acls --selinux --xattrs --xattrs-include='*' -x -f "$CACHE_FILE" -C $TMPDIR
+ else
+   if [ "$PROXY" ]; then
+ export http_proxy="$PROXY"
+@@ -109,7 +109,7 @@ else
+ 
+   if [ "$GENERATE_CACHE" = "yes" ]; then
+ TMP_CACHE=`mktemp "${CACHE_FILE}.XX"`
+-tar cf "$TMP_CACHE" -C $TMPDIR .
++tar --acls --selinux --xattrs --xattrs-include='*' -c -f "$TMP_CACHE" -C $TMPDIR .
+ mv -f "$TMP_CACHE" "$CACHE_FILE"
+   fi
+ fi
+-- 
+2.20.1
+
diff -Nru ganeti-instance-debootstrap-0.16/debian/patches/series ganeti-instance-debootstrap-0.16/debian/patches/series
--- ganeti-instance-debootstrap-0.16/debian/patches/series	2018-06-20 06:57:18.0 -0400
+++ ganeti-instance-debootstrap-0.16/debian/patches/series	2020-02-07 17:11:06.0 -0500
@@ -1 +1,2 @@
+respect-Linux-capabilities-7-in-cache.patch
 fix-sfdisk-BLKRRPART.patch

Bug#950369: buster-pu: package python-internetarchive/1.8.1-1

[Antoine Beaupré]

On 2020-01-31 20:35:55, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
>
> On Fri, 2020-01-31 at 15:13 -0500, Antoine Beaupre wrote:
>> The version of "internetarchive" in Debian has some serious
>> scalability and reliability issues. In particular, it has trouble
>> handling more than 1024 files (#950289) but upstream also made a few
>> other changes which we might want to merge in. We're shipping a
>> modified version of 1.8.1 in buster, and upstream has released a few
>> releases up to 1.8.5 and 1.9.0 since then, the latter of which is in
>> Debian.
>> 
>> I just uploaded a patch for #950289 to unstable. I'm hoping this
>> patch could also be shipped to stable, but I am wondering if we
>> wouldn't be better off syncing the entire package with upstream, to
>> 1.8.5 or maybe even what will become 1.9.1 once they ship the fix for
>> #950289 upstream.
>
> The window for getting updates into 10.3 closes this weekend, so let's
> go with the minimal fix for now and we can revisit whether larger
> updates make sense later; thanks.

I never quite remember the workflow here, but I've uploaded the package
to buster, so feel free to do whatever needs to happen to this bug
now. :)

Thanks!

-- 
If you want to go fast, go alone. If you want to go far, go together.
- African proverb

Bug#944538: buster-pu: package ganeti-instance-debootstrap/0.16-6.1

[Antoine Beaupré]

On 2019-11-23 18:34:25, Julien Cristau wrote:
> On Mon, Nov 11, 2019 at 10:40:58AM -0500, Antoine Beaupre wrote:
>> diff -Nru ganeti-instance-debootstrap-0.16/debian/changelog 
>> ganeti-instance-debootstrap-0.16/debian/changelog
>> --- ganeti-instance-debootstrap-0.16/debian/changelog2018-06-20 
>> 06:57:18.0 -0400
>> +++ ganeti-instance-debootstrap-0.16/debian/changelog2019-11-01 
>> 19:01:50.0 -0400
>> @@ -1,3 +1,10 @@
>> +ganeti-instance-debootstrap (0.16-6.1) unstable; urgency=medium
>
> Version number and distribution don't look right.

Ah yes, that would be 0.16-6+deb10u1, right?

>> +
>> +  * Non-maintainer upload
>> +  * add patch to respect linux caps (Closes: #942114)
>> +
>> + -- Antoine Beaupré   Fri, 01 Nov 2019 19:01:50 -0400
>> +
>>  ganeti-instance-debootstrap (0.16-6) unstable; urgency=medium
>>  
>>* Bump Standards-Version to 4.1.4; no changes needed
>> diff -Nru 
>> ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch
>>  
>> ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch
>> --- 
>> ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch
>>   1969-12-31 19:00:00.0 -0500
>> +++ 
>> ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch
>>   2019-11-01 19:01:50.0 -0400
>> @@ -0,0 +1,48 @@
>> +From cd34bcc48a2af92f484535b81fba2d46dad1dbb6 Mon Sep 17 00:00:00 2001
>> +From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
>> +Date: Thu, 10 Oct 2019 11:07:51 -0400
>> +Subject: [PATCH] respect Linux capabilities(7) in cache
>> +
>> +The default GNU tar configuration does not carry fancy extended
>> +attributes and that is where, among other things, stuff like Linux
>> +capabilities(7) are stored. This is kind of important because that's
>> +how ping(8) works for regular users.
>> +
>> +We shove --selinux and --acls in there while we're at it, because why
>> +not. We never know what the future might bring, and it seems
>> +silly *not* to create a complete archive.
>> +
>> +Note that --xattrs-include='*' is important because, by default, GNU
>> +tar will not include capabilities /even/ if --xattrs is specified on
>> +the commandline, see this bug report for details:
>> +
>
> I'm a bit uneasy about a blanket "include all", to be honest.  It's
> probably harmless since it's all coming straight out of debootstrap, but
> I'd have been happier with something like "include security.*" if that's
> what we expect to see.

What kind of problems would you expect with including too many ACLs?

A.

-- 
Qui vit sans folie n'est pas si sage qu'il croit.
- François de La Rochefoucauld

Bug#929487: unblock: dmarc-cat/0.9.2-4

[Antoine Beaupré]

Control: tags -1 -moreinfo

On 2019-05-25 11:27:28, Paul Gevers wrote:
> That isn't available to unblock at the moment.

Oops. Somehow forgot to upload.

> Please upload to unstable and remove the moreinfo tag when it is build
> and installed.

It's been "ACCEPTED" so i presume it will trickle down everywhere...

a.
-- 
The illusion of freedom will continue as long as it's profitable to
continue the illusion. At the point where the illusion becomes too
expensive to maintain, they will just take down the scenery, they will
pull back the curtains, they will move the tables and chairs out of
the way and you will see the brick wall at the back of the theater.
 - Frank Zappa

Bug#929487: unblock: dmarc-cat/0.9.2-4

[Antoine Beaupré]

Control: retitle -1 unblock: dmarc-cat/0.9.2-4

The right package version is actually -4, I have tried to upload the -3
back into unstable, but that failed, naturally...

So please:

unblock dmarc-cat/0.9.2-4

The debdiff is almost identical, except for the extra changelog entry.

diff -Nru dmarc-cat-0.9.2/debian/changelog dmarc-cat-0.9.2/debian/changelog
--- dmarc-cat-0.9.2/debian/changelog2019-05-21 10:13:55.0 -0400
+++ dmarc-cat-0.9.2/debian/changelog2019-05-24 10:45:11.0 -0400
@@ -1,3 +1,15 @@
+dmarc-cat (0.9.2-4) unstable; urgency=medium
+
+  * upload to unstable
+
+ -- Antoine Beaupré   Fri, 24 May 2019 10:45:11 -0400
+
+dmarc-cat (0.9.2-3) experimental; urgency=medium
+
+  * fix autopkgtest missing build-tree requirement
+
+ -- Antoine Beaupré   Thu, 23 May 2019 14:51:42 -0400
+
 dmarc-cat (0.9.2-2) unstable; urgency=medium
 
   * move test suite to autopkgtest because of network access (Closes:
diff -Nru dmarc-cat-0.9.2/debian/tests/control 
dmarc-cat-0.9.2/debian/tests/control
--- dmarc-cat-0.9.2/debian/tests/control2019-05-21 10:13:55.0 
-0400
+++ dmarc-cat-0.9.2/debian/tests/control2019-05-24 10:45:11.0 
-0400
@@ -1,2 +1,3 @@
 Test-command: HOME=$AUTOPKGTEST_TMP dh_auto_test -O--buildsystem=golang
 Depends: @, @builddeps@
+Restrictions: build-needed

Bug#928092: unblock: youtube-dl/2019.01.17-1.1

[Antoine Beaupré]

Control: tags -1 -moreinfo

Package made it to unstable.

Bug#928081: unblock: matrix-synapse/0.99.2-3.1

[Antoine Beaupré]

On 2019-04-27 19:47:40, Andrej Shadura wrote:
> On Sat, 27 Apr 2019 12:30:03 -0400 Antoine Beaupre 
> wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>> 
>> Please unblock package matrix-synapse
>> 
>> The package currently in buster generates gigabytes of logs which can
>> easily fill up disks on servers (RC bug #927057).
>> 
>> The following patch fixes the problem, and I can upload the fix
>> if this is approved.
>> 
>> unblock matrix-synapse/0.99.2-3.1
>
> Thanks for preparing the NMU, but I will upload this change myself.

Awesome, thanks! I'll let you talk with the release team as well, is
that alright?

A.
-- 
You can't conquer a free man; the most you can do is kill him.
   -  Robert A. Heinlein

Bug#901814: stretch-pu: package monkeysign/2.2.3

[Antoine Beaupré]

On 2018-12-03 10:44:55, Antoine Beaupré wrote:
> On 2018-12-03 15:41:01, Adam D. Barratt wrote:
>> On 2018-12-03 15:32, Antoine Beaupré wrote:
>>> So I'll just upload 2.2.4~deb9u1 to stable now?
>>
>> Yes, please. (With the changelog distribution set to "stretch", please.)
>
> Got it, incoming.

I ended up uploading 2.2.3+deb9u1 because setuptools-scm crashes on the
2.2.4~deb9u1 version number, see #915408.

A.

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of speech
because I have nothing to say."
- Edward Snowden

Bug#901814: stretch-pu: package monkeysign/2.2.3

[Antoine Beaupré]

On 2018-12-03 15:41:01, Adam D. Barratt wrote:
> On 2018-12-03 15:32, Antoine Beaupré wrote:
>> So I'll just upload 2.2.4~deb9u1 to stable now?
>
> Yes, please. (With the changelog distribution set to "stretch", please.)

Got it, incoming.

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of speech
because I have nothing to say."
- Edward Snowden

Bug#901814: stretch-pu: package monkeysign/2.2.3

[Antoine Beaupré]

On 2018-12-03 15:25:29, Adam D. Barratt wrote:
> On 2018-12-03 14:53, Holger Levsen wrote:
>> On Mon, Dec 03, 2018 at 02:37:03PM +, Adam D. Barratt wrote:
>>> > > This would need to be versioned as 2.2.3+deb9u1.
>>> > But it's exactly the 2.2.4 release published to unstable - why the
>>> > different version number?
>>> (It's not "exactly the same" - the stretch upload will be built in a 
>>> stretch
>>> chroot, so may well end up with different dependencies. At the very 
>>> least,
>>> it needs a d/changelog entry detailing that it was uploaded to stable, 
>>> which
>>> makes it different from the unstable upload.)
>> 
>> so why not 2.2.4~deb9u1 then?
>
> That would be fine also, assuming the stable upload includes all of the 
> changes from the unstable upload of 2.2.4.

Okay, then I'll pick that, it seems more reasonable than 2.2.3+something
as it's not 2.2.3.

> I read Antoine's original message as specifically trying to use the 
> exact version string "2.2.4"; apologies if that was not the intent.

Correct, I still don't quite see why we can't just reuse that, but it
seems to be there are technical reasons keeping this from happening.

So I'll just upload 2.2.4~deb9u1 to stable now?

a.

-- 
Never attribute to malice that which can be adequately explained by
stupidity, but don't rule out malice.
 - Albert Einstein

Bug#901814: stretch-pu: package monkeysign/2.2.3

[Antoine Beaupré]

On 2018-12-03 14:37:03, Adam D. Barratt wrote:
> On 2018-12-03 14:23, Antoine Beaupré wrote:
>> On 2018-12-03 08:16:47, Julien Cristau wrote:
>>> Control: tag -1 confirmed
>>> 
>>> On Mon, Jun 18, 2018 at 01:56:11PM -0400, Antoine Beaupre wrote:
>>>> diff -Nru monkeysign-2.2.3/debian/changelog 
>>>> monkeysign-2.2.4/debian/changelog
>>>> --- monkeysign-2.2.3/debian/changelog  2017-01-24 15:40:35.0 
>>>> -0500
>>>> +++ monkeysign-2.2.4/debian/changelog  2018-06-18 12:18:46.0 
>>>> -0400
>>>> @@ -1,3 +1,14 @@
>>>> +monkeysign (2.2.4) unstable; urgency=medium
>>>> +
>>>> +  [ Tobias Rueetschi ]
>>>> +  * false isn't defined, that must be False
>>>> +
>>>> +  [ Antoine Beaupré ]
>>>> +  * actually send multiple emails instead of a single one
>>>> +  * CVE-2018-12020: add no verbose to avoid fake signatures
>>>> +
>>>> + -- Antoine Beaupré   Mon, 18 Jun 2018 12:18:46 
>>>> -0400
>>>> +
>>>>  monkeysign (2.2.3) unstable; urgency=medium
>>>> 
>>>>[ Simon Fondrie-Teitler ]
>>> 
>>> This would need to be versioned as 2.2.3+deb9u1.
>> 
>> But it's exactly the 2.2.4 release published to unstable - why the
>> different version number?
>
> Because, as you say, a package with the version "2.2.4" has already been 
> uploaded to Debian. One can't have a different package in stable and 
> unstable with the same version number.

Sure you can. If a package is not updated between the time the unstable
package trickles down into testing and then becomes table, it will have
the exact same version number and binary builds.

> (It's not "exactly the same" - the stretch upload will be built in a 
> stretch chroot, so may well end up with different dependencies. At the 
> very least, it needs a d/changelog entry detailing that it was uploaded 
> to stable, which makes it different from the unstable upload.)

It seems quite strange to me to have to rebuild a package with a
different version number in this very specific case. Monkeysign is in
maintenance mode now and the only reason I did this release with that
specific numbering scheme is specifically targeting Debian stable.

First I was told to upload it to unstable before uploading it to stable,
and now I am told the 2.2.4 release cannot be uploaded to stable. I hope
you understand I might find the process a tad confusing. :)

A.

Bug#901814: stretch-pu: package monkeysign/2.2.3

[Antoine Beaupré]

On 2018-12-03 08:16:47, Julien Cristau wrote:
> Control: tag -1 confirmed
>
> On Mon, Jun 18, 2018 at 01:56:11PM -0400, Antoine Beaupre wrote:
>> diff -Nru monkeysign-2.2.3/debian/changelog monkeysign-2.2.4/debian/changelog
>> --- monkeysign-2.2.3/debian/changelog2017-01-24 15:40:35.0 
>> -0500
>> +++ monkeysign-2.2.4/debian/changelog2018-06-18 12:18:46.0 
>> -0400
>> @@ -1,3 +1,14 @@
>> +monkeysign (2.2.4) unstable; urgency=medium
>> +
>> +  [ Tobias Rueetschi ]
>> +  * false isn't defined, that must be False
>> +
>> +  [ Antoine Beaupré ]
>> +  * actually send multiple emails instead of a single one
>> +  * CVE-2018-12020: add no verbose to avoid fake signatures
>> +
>> + -- Antoine Beaupré   Mon, 18 Jun 2018 12:18:46 -0400
>> +
>>  monkeysign (2.2.3) unstable; urgency=medium
>>  
>>[ Simon Fondrie-Teitler ]
>
> This would need to be versioned as 2.2.3+deb9u1.

But it's exactly the 2.2.4 release published to unstable - why the
different version number?

a.

-- 
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin, 1755

Bug#871937: stretch-pu: package monkeysign/2.2.3

[Antoine Beaupré]

Control: reopen 871937

On 2018-12-02 16:47:48, Julien Cristau wrote:
> On Sat, Sep 09, 2017 at 03:23:13PM +0200, Julien Cristau wrote:
>> Control: tag -1 moreinfo
>> 
>> On Sat, Aug 12, 2017 at 14:21:11 -0400, Antoine Beaupre wrote:
>> 
>> > Package: release.debian.org
>> > Severity: normal
>> > Tags: stretch
>> > User: release.debian@packages.debian.org
>> > Usertags: pu
>> > 
>> > Hi,
>> > 
>> > I am working on a new release of Monkeysign, which I'd like to upload
>> > in Debian. If it would be just me, I would tag the current HEAD with
>> > 2.2.4, considering the changes are mostly minor and non-disruptive:
>> > 
>> > angela:monkeysign$ git diff 2.2.3 --stat
>> >  CONTRIBUTING.rst|   9 +-
>> >  debian/gbp.conf |   2 +-
>> >  doc/usage.rst   |   4 +
>> >  monkeysign/cli.py   |  11 +-
>> >  monkeysign/gpg.py   |  35 ++--
>> >  monkeysign/gtkui.py |  81 ++---
>> >  monkeysign/tests/files/7B75921E.asc | 331 
>> > -
>> >  monkeysign/tests/test_gpg.py|  21 +--
>> >  monkeysign/tests/test_ui.py | 147 -
>> >  monkeysign/ui.py| 168 ---
>> >  po/nl.po| 725 
>> > 
>> >  11 files changed, 1225 insertions(+), 309 deletions(-)
>> > 
>> > as you can see, more than half of the diff (725 lines) is just a
>> > translation file update. The rest is fixes for tests and critical
>> > bugfixes (although the bugfixes have not been reported directly in the
>> > Debian BTS, but discovered through my own testing).
>> > 
>> > Attached is the actual diff. Should I upload this as 2.2.4 to unstable
>> > and stable-pu? Or should i minimize this diff to a bare minimum and
>> > release a more targeted 2.2.4 to stable and a 2.3.0 to unstable?
>> > 
>> There's no such thing as uploading the same package version to unstable
>> and proposed-updates.  Please first get the changes in unstable, with
>> whatever version number.  Let them sit for a while, and then come back
>> with a request for stable, with a description and justification of the
>> changes (which I couldn't see here).
>> 
> That doesn't seem to have happened; closing.

I'm confused. I *did* upload the changes to unstable:

https://tracker.debian.org/news/966367/accepted-monkeysign-224-source-all-into-unstable/

They migrated to testing and everything. I guess I should have pinged
this bug report back again?

I can rephrase a description of the changes, but the changelog above is
pretty straightforward:

   [ Tobias Rueetschi ]
   * false isn't defined, that must be False

   [ Antoine Beaupré ]
   * actually send multiple emails instead of a single one
   * CVE-2018-12020: add no verbose to avoid fake signatures

Here's the actual diff, according to git:

diff --git c/debian/changelog w/debian/changelog
index db96510..1f1d667 100644
--- c/debian/changelog
+++ w/debian/changelog
@@ -1,3 +1,14 @@
+monkeysign (2.2.4) unstable; urgency=medium
+
+  [ Tobias Rueetschi ]
+  * false isn't defined, that must be False
+
+  [ Antoine Beaupré ]
+  * actually send multiple emails instead of a single one
+  * CVE-2018-12020: add no verbose to avoid fake signatures
+
+ -- Antoine Beaupré   Mon, 18 Jun 2018 12:18:46 -0400
+
 monkeysign (2.2.3) unstable; urgency=medium
 
   [ Simon Fondrie-Teitler ]
diff --git c/monkeysign/gpg.py w/monkeysign/gpg.py
index 223073c..7746861 100644
--- c/monkeysign/gpg.py
+++ w/monkeysign/gpg.py
@@ -102,6 +102,7 @@ class Context():
 'with-colons': None,
 'with-fingerprint': None,
 'fixed-list-mode': None,
+'no-verbose': None,
 'list-options': 'show-sig-subpackets,show-uid-validity,show-unusable-uids,show-unusable-subkeys,show-keyring,show-sig-expire',
 }
 
@@ -126,7 +127,7 @@ def unset_option(self, option):
 if option in self.options:
 del self.options[option]
 else:
-return false
+return False
 
 def build_command(self, command):
 """internal helper to build a proper gpg commandline
diff --git c/monkeysign/tests/test_gpg.py w/monkeysign/tests/test_gpg.py
index 5ca8472..445ce2e 100755
--- c/monkeysign/tests/test_gpg.py
+++ w/monkeysign/tests/test_gpg.py
@@ -42,7 +42,7 @@ class TestContext(unittest.TestCase):
 options = Context.options
 
 # ... and this is the rendered v

Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1

[Antoine Beaupré]

On 2018-06-13 16:00:41, Adam D. Barratt wrote:
> On Tue, 2016-09-13 at 12:04 +0200, Julien Cristau wrote:
>> On Sun, Sep 11, 2016 at 16:58:34 -0400, Antoine Beaupré wrote:
>> 
>> > 1. ignore the above two extra issues and simply add the patch for
>> > #215
>> > to the pile of patches in jessie
>> > 2. import the new gnutls.c module from an eventual new 3.5 release
>> > upstream directly in jessie - this may be difficult because of
>> > internal
>> > API changes
>> > 3. import 3.5.x directly in jessie
>> > 
>> > I would like to have feedback from the release team as to which
>> > approach
>> > to take forward.
>> > 
>> 
>> I don't think 3 is a reasonable option.  The rest will depend on
>> specifics.
>
> There's been no further activity on this bug since the above, so I
> think it's reasonable to say it's unlikely to be getting fixed in
> jessie at this point?

Hmm... I am not sure what to do with this... 3.4 is pretty much dead at
this point, and I suspect most people will have migrated to 3.5. the
complete fix is pretty invasive so I guess we can just punt this away
for ever and assume people will upgrade to stretch already... :/

a.
-- 
Software gets slower faster than hardware gets faster.
 - Wirth's law

Bug#867461: Bug#858539: should ca-certificates certdata.txt synchronize across all suites?

[Antoine Beaupré]

On 2017-07-19 11:35:56, Michael Shuler wrote:
> On 07/06/2017 11:13 PM, Paul Wise wrote:
>> On Fri, Jul 7, 2017 at 2:01 AM, Antoine Beaupré wrote:
>> 
>>> For what it's worth, my opinion is that we should attempt to synchronize
>>> certdata.txt (and blacklist.txt, for that matter) across all suites (but
>>> not other changes to the packaging). This would remove another decision
>>> point in our infrastructure and ensure harmonious X509 processing across
>>> suites.
>> 
>> I would like to see that happen too.
>
> I spent a few sessions over the past few days getting the mozilla bundle
> 2.14 committed to all the suite branches wheezy and newer. I have some
> more verification to work on and I'll get some packages rolled up and
> tested for all the suites.
>
> I appreciate the notes here!

Hi!

Any update here? According to our records, this issue is still
pending... I see you pushed the updates to wheezy, but didn't upload the
results... Do you need help preparing the upload?

Thanks,

A.

-- 
What people say, what people do, and what they say they do are
entirely different things.
- Margaret Mead

Bug#867461: should ca-certificates certdata.txt synchronize across all suites?

[Antoine Beaupré]

On 2017-07-21 22:19:20, Philipp Kern wrote:
> My point was that you state what your delta is and essentially boils 
> down to attach the diff of what will actually happen to the .deb. I 
> think it's generally fine to add new CAs and remove fully distrusted 
> ones, instead of saying "it should just be in sync with unstable". The 
> latter contains a lot more nuance if you know that some of the rules are 
> only available in code.

Thank you for taking the time to clarify your position, I understand it
much better now. :)

Makes perfect sense, I'll try to be clearer in future communications to
avoid such confusion.

A.

-- 
Si les triangles avaient un Dieu, ils lui donneraient trois côtés.
- Montesquieu, Lettres persanes

Bug#867461: should ca-certificates certdata.txt synchronize across all suites?

[Antoine Beaupré]

On 2017-07-20 18:15:00, Philipp Kern wrote:
> On 07/17/2017 09:41 PM, Antoine Beaupré wrote:
>> Let's not jump the gun here. We're not shipping NSS in ca-certificates,
>> just a tiny part of it: one text file, more or less.
>
> Yeah, and the consensus of the world external to Debian seems to be that
> this might not be the smartest choice.

I'm not sure I understand what you are proposing as an alternative
here. Should we stop shipping ca-certificates? Or make it a binary
package of the NSS source package?

>> Also, what Mozilla enforced in NSS, we enforced in ca-certificates in
>> other ways, through the use of a blacklist.txt file. So we can
>> definitely fix #858539 without syncing all of NSS to wheezy.
>
> That is incorrect. nss/lib/certhigh/certvfy.c contains code specific to
> the StartCom/WoSign mitigation. Now the time has come for full distrust,
> we can sync dropping the certs entirely by adding them to blacklist.txt,
> sure. (Although they will continue to live on in the NSS source
> additionally.)

I don't understand this: how is it incorrect? #858539 applies only to
ca-certificates, and can be fixed without patching NSS.

Now to update the NSS package itself is another question, again.

> But my point stands that in the next round of distrust (say, uh,
> Symantec), we might actually need to push code changes to NSS.

Sure, but that doesn't necessarily affect ca-certificates directly, in
that we can update ca-certificates orthogonally right now.

>> The proposed patch here, is more or less only to merge that very file,
>> blacklist.txt. The *other* thing proposed to the release team (in
>> #867461) is to sync the *other* changes to certdata.txt from sid. But
>> considering *that* work seems mostly stalled, I wonder how hard to push
>> on that. Of course, we could also just decide, in LTS, to sync with
>> jessie at least: we do not need release-team approval for this. This
>> would be (let's be honest here) really to get Let's Encrypt directly in
>> wheezy, and I think it would be worthwhile.
>
> I think it's useful to phrase the goal which is:
>
> - Remove StartCom
> - Remove WoSign
> - Add Let's Encrypt
>
> Which is easier to get behind than "should we synchronize the file".

Sure. The point I was trying to make here was that we seem to be
favoring certain well-known CAs over other less well-known. I'm actually
with that (e.g. because I don't like Amazon very much), but I'm not sure
that's a position that should be reflected in our work.

> What's the timeline on Let's Encrypt dropping the cross certification?
> Is that actually planned? Because the whole point of that was that
> adding LE directly isn't actually critical. (And people should use the
> chain provided by ACME rather than relying on certificates shipped by
> Debian.)

I can't answer those questions, unfortunately, but it's a fair point.

Pabs? What was the idea behind migrating LE down to wheezy?

A.

-- 
La publicité est la dictature invisible de notre société.
- Jacques Ellul

Bug#861541: jessie-pu: package kedpm/1.0

[Antoine Beaupré]

On 2017-06-27 22:39:23, Cyril Brulebois wrote:
> Control: tag -1 confirmed
>
> Antoine Beaupre <anar...@debian.org> (2017-04-30):
>> diff -Nru kedpm-1.0/debian/changelog kedpm-1.0+deb8u1/debian/changelog
>> --- kedpm-1.0/debian/changelog   2012-11-30 15:45:14.0 -0500
>> +++ kedpm-1.0+deb8u1/debian/changelog2017-04-26 20:44:11.0 
>> -0400
>> @@ -1,3 +1,10 @@
>> +kedpm (1.0+deb8u1) jessie; urgency=high
>> +
>> +  * Non-maintainer upload by the Security Team.
>> +  * fix information leak via command history file (Closes: #860817)
>> +
>> + -- Antoine Beaupré <anar...@debian.org>  Wed, 26 Apr 2017 20:44:11 -0400
>> +
>>  kedpm (1.0) unstable; urgency=low
>>  
>>* New upstream release.
>> diff -Nru 
>> kedpm-1.0/debian/patches/0001-always-prompt-for-password-and-do-not-save-to-databa.patch
>>  
>> kedpm-1.0+deb8u1/debian/patches/0001-always-prompt-for-password-and-do-not-save-to-databa.patch
>> --- 
>> kedpm-1.0/debian/patches/0001-always-prompt-for-password-and-do-not-save-to-databa.patch
>>  1969-12-31 19:00:00.0 -0500
>> +++ 
>> kedpm-1.0+deb8u1/debian/patches/0001-always-prompt-for-password-and-do-not-save-to-databa.patch
>>   2017-04-26 20:43:55.0 -0400
>> @@ -0,0 +1,61 @@
>> +From b8f7e8b3b2cb37425cb89b205c9836c6ac02a048 Mon Sep 17 00:00:00 2001
>> +From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= <anar...@debian.org>
>> +Date: Wed, 26 Apr 2017 16:58:56 -0400
>> +Subject: [PATCH 1/2] always prompt for password and do not save to database
>
> The 1/2 part seems a bit weird here; was the second patch relevant for
> this security fix?

No, it wasn't.

>> +-"""Change master password for opened database
>> +-
>> +-Syntax:
>> +-password [new password]
>> +-
>> +-If new password is not provided with command, you will be promted to enter 
>> new
>> +-one.
>> +-"""
>> +-
>> +-if not arg:
>> +-# Password is not provided with command. Ask user for it
>> +-pass1 = getpass(_("New password: "))
>> +-pass2 = getpass(_("Repeat password: "))
>> +-if pass1 == '':
>> +-print _("Empty passwords are really insecure. You should " 
>> \
>> +-"create one.")
>> +-return
>> +-if pass1!=pass2:
>> +-print _("Passwords don't match! Please repeat.")
>> +-return
>> +-new_pass = pass1
>> +-else:
>> +-new_pass = arg
>> ++"""Change master password for opened database"""
>> ++
>> ++# remove possibly master password from history file
>> ++
>> readline.remove_history_item(readline.get_current_history_length()-1)
>
> I'm assuming the history was already updated to include the last/current
> command?

Yes: the command handling framework automatically records the current
command in the history.

>> ++# Password is not provided with command. Ask user for it
>
> I suppose this became a bit of a lie. :) Feel free to replace it with
> “Always ask the user for the password”, or remove it entirely.
>
> With or without the comment fix, feel free to upload.

Thanks.

A.

-- 
We are discreet sheep; we wait to see how the drove is going, and then go
with the drove.
- Mark Twain

Bug#861541: jessie-pu: package kedpm/1.0

[Antoine Beaupré]

On 2017-06-27 21:45:17, Adam D. Barratt wrote:
> On Tue, 2017-06-27 at 22:39 +0200, Cyril Brulebois wrote:
>> Control: tag -1 confirmed
>> 
>> Antoine Beaupre  (2017-04-30):
>> > diff -Nru kedpm-1.0/debian/changelog kedpm-1.0+deb8u1/debian/changelog
>> > --- kedpm-1.0/debian/changelog 2012-11-30 15:45:14.0 -0500
>> > +++ kedpm-1.0+deb8u1/debian/changelog  2017-04-26 20:44:11.0 
>> > -0400
>> > @@ -1,3 +1,10 @@
>> > +kedpm (1.0+deb8u1) jessie; urgency=high
>> > +
>> > +  * Non-maintainer upload by the Security Team.
>
> On a side note, the above appears to be incorrect.

Bad habit, will fix.

A.

-- 
There has been only one Christian.
They caught him and crucified him -- early.
- Mark Twain

Bug#867461: Bug#858539: should ca-certificates certdata.txt synchronize across all suites?

[Antoine Beaupré]

On 2017-07-19 11:35:56, Michael Shuler wrote:
> On 07/06/2017 11:13 PM, Paul Wise wrote:
>> On Fri, Jul 7, 2017 at 2:01 AM, Antoine Beaupré wrote:
>> 
>>> For what it's worth, my opinion is that we should attempt to synchronize
>>> certdata.txt (and blacklist.txt, for that matter) across all suites (but
>>> not other changes to the packaging). This would remove another decision
>>> point in our infrastructure and ensure harmonious X509 processing across
>>> suites.
>> 
>> I would like to see that happen too.
>
> I spent a few sessions over the past few days getting the mozilla bundle
> 2.14 committed to all the suite branches wheezy and newer. I have some
> more verification to work on and I'll get some packages rolled up and
> tested for all the suites.
>
> I appreciate the notes here!

Thanks!

let us know if you need help with the LTS bits.

a.

-- 
On reconnait la grandeur et la valeur d'une nation à la façon dont
celle-ci traite ses animaux.
- Mahatma Gandhi

Bug#867461: should ca-certificates certdata.txt synchronize across all suites?

[Antoine Beaupré]

On 2017-07-07 16:02:51, Guido Günther wrote:
> On Fri, Jul 07, 2017 at 03:57:35PM +0200, Philipp Kern wrote:
>> On 07/06/2017 08:01 PM, Antoine Beaupré wrote:
>> > In looking at fixing #858539 (blocking WoSign and StartCom, in CC) for
>> > wheezy, I noticed the issue was also pending in jessie. Furthermore, the
>> > idea originally raised by pabs[1] was to also update the packages for
>> > the latest changes in certdata.txt in wheezy, including the ISRG Root
>> > for Let's Encrypt (LE).
>> > 
>> > While it should be fairly trivial to do this update, I wonder if the
>> > same logic should apply to jessie itself. Right now, jessie and stretch
>> > are synchronized, but that's only because there's an update pending in
>> > unstable to synchronize with the upstream 2.11 NSS database.
>> > 
>> > This raises the question of how synchronized we want this file to be? It
>> > seems a little arbitrary to me to synchronize the file from jessie to
>> > wheezy only for this one certificate authority (LE). How about the other
>> > authorities? It doesn't seem like we should be calling the shots on
>> > this: if we follow the Mozilla policies here, either we update all
>> > supported suites at once, or we accept that some suites will have
>> > outdated material.
>> > 
>> > I have therefore opened this specific discussion with the release team
>> > in #867461 (in CC as well). Hopefully this will bring a consistent
>> > policy.
>> > 
>> > For what it's worth, my opinion is that we should attempt to synchronize
>> > certdata.txt (and blacklist.txt, for that matter) across all suites (but
>> > not other changes to the packaging). This would remove another decision
>> > point in our infrastructure and ensure harmonious X509 processing across
>> > suites.
>> > 
>> > [1]: https://lists.debian.org/1490430746.9127.2.ca...@debian.org
>> > 
>> > Thanks for any feedback. For now I'll hold on another week or so for the
>> > wheezy update, since it seems unreasonable to push that update out
>> > before jessie is updated and that question is resolved.
>> 
>> But it's not just about certdata.txt. The WoSign and StartCom distrust
>> was actually hardcoded in NSS and hence what Mozilla enforced in NSS we
>> couldn't check in any other tools using ca-certificates. We also do not
>> sync the NSS version or backport the cert checks when such distrusts
>> happen. So we can only react in a similar way when the time for full
>> distrust has come (which is sort of the case now with these two),
>> otherwise we diverge in logic and potentially break users with different
>> expectations[1].
>
> Which brings us back to #824872 (same nss/nspr in all suites). We're
> basically shipping new NSS with firefox / thunderbird but not for the
> rest.

Let's not jump the gun here. We're not shipping NSS in ca-certificates,
just a tiny part of it: one text file, more or less.

Also, what Mozilla enforced in NSS, we enforced in ca-certificates in
other ways, through the use of a blacklist.txt file. So we can
definitely fix #858539 without syncing all of NSS to wheezy.

The proposed patch here, is more or less only to merge that very file,
blacklist.txt. The *other* thing proposed to the release team (in
#867461) is to sync the *other* changes to certdata.txt from sid. But
considering *that* work seems mostly stalled, I wonder how hard to push
on that. Of course, we could also just decide, in LTS, to sync with
jessie at least: we do not need release-team approval for this. This
would be (let's be honest here) really to get Let's Encrypt directly in
wheezy, and I think it would be worthwhile.

Also I would very well see another NMU that would release those new
changes and sync up ca-certificates with NSS, at least in sid. Then it
could trickle down to buster, and from there, if everyone is okay,
trickle down to all suites. But that discussion concerns mostly the
release team and the maintainer at this point.

I'm not sure I want to bring back the question of syncing NSS across all
suites here again. It's a different question: NSS is a library, not
just a set of policies and certificates (which is, after all, what
ca-certificates is). Backporting it forcefully across all suites
may/will have an impact on programs that link against it, something that
we won't have with ca-certicates.

So while I would like NSS to be sync'd across suites as well, I'd like
to keep the questions separate here because ca-certificates is easier to
fix.

Thanks for your feedback, keep it coming.

A.

-- 
L'homme construit des maisons parce qu'il est vivant, mais il écrit des
livres parce qu'il se sait mortel.
- Daniel Pennac, Comme un roman

Bug#867461: should ca-certificates certdata.txt synchronize across all suites?

[Antoine Beaupré]

Hi everyone,

In looking at fixing #858539 (blocking WoSign and StartCom, in CC) for
wheezy, I noticed the issue was also pending in jessie. Furthermore, the
idea originally raised by pabs[1] was to also update the packages for
the latest changes in certdata.txt in wheezy, including the ISRG Root
for Let's Encrypt (LE).

While it should be fairly trivial to do this update, I wonder if the
same logic should apply to jessie itself. Right now, jessie and stretch
are synchronized, but that's only because there's an update pending in
unstable to synchronize with the upstream 2.11 NSS database.

This raises the question of how synchronized we want this file to be? It
seems a little arbitrary to me to synchronize the file from jessie to
wheezy only for this one certificate authority (LE). How about the other
authorities? It doesn't seem like we should be calling the shots on
this: if we follow the Mozilla policies here, either we update all
supported suites at once, or we accept that some suites will have
outdated material.

I have therefore opened this specific discussion with the release team
in #867461 (in CC as well). Hopefully this will bring a consistent
policy.

For what it's worth, my opinion is that we should attempt to synchronize
certdata.txt (and blacklist.txt, for that matter) across all suites (but
not other changes to the packaging). This would remove another decision
point in our infrastructure and ensure harmonious X509 processing across
suites.

[1]: https://lists.debian.org/1490430746.9127.2.ca...@debian.org

Thanks for any feedback. For now I'll hold on another week or so for the
wheezy update, since it seems unreasonable to push that update out
before jessie is updated and that question is resolved.

A.

-- 
We won't have a society if we destroy the environment.
- Margaret Mead

Bug#833865: jessie-pu: package youtube-dl/2014.08.05-1+deb8u1

[Antoine Beaupré]

On 2016-12-17 05:34:35, Julien Cristau wrote:
> On Thu, Nov 24, 2016 at 14:52:44 -0500, Antoine Beaupré wrote:
>
>> On 2016-11-24 13:04:21, Julien Cristau wrote:
>> > On Tue, Aug  9, 2016 at 11:50:27 -0400, Antoine Beaupré wrote:
>> >
>> >> This is a tentative of opening the discussion regarding a more regular
>> >> update of the youtube-dl package in Debian stable.
>> >> 
>> > TBH I think this should never have reached stable in the first place...
>> 
>> So what should happen now? Should it be removed from stretch?
>> 
>> What do we do with the version that *is* in testing?
>> 
>> Isn't that what volatile (now -updates) was designed for?
>> 
>> https://lists.debian.org/debian-volatile-announce/2012/msg0.html
>> 
>> It explicitly mentions:
>> 
>> """
>>  * Fixes to leaf packages that were broken by external changes (e.g.
>>video downloading tools and tor).
>> """
> 
> So once upon a time libquvi-scripts was supposed to help with that, by
> being a relatively self-contained set of per-site lua scripts that could
> get updated and then used by a variety of packages.  Unfortunately that
> appears to be dead, so I'm not sure what to suggest nowadays.

Yeah, I was a user of libquvi-scripts. I even prodded joeyh so that he
implements support for it in git-annex so that we could have URL-backed
youtube videos in there... Only to discover it would rot like that...

It's too bad, really: quvi was the right approach - but youtube-dl seems
to have won the race. It supports more platforms and keeps up with the
changes.

Really, it's an algorithmic problem: you can't just push that stuff in
metadata and treat it as simple databases that need to be independently
of the main program logic...

A.

-- 
In god we trust, others pay cash.
- Richard Desjardins, Miami

Bug#833865: jessie-pu: package youtube-dl/2014.08.05-1+deb8u1

[Antoine Beaupré]

On 2016-11-24 13:04:21, Julien Cristau wrote:
> On Tue, Aug  9, 2016 at 11:50:27 -0400, Antoine Beaupré wrote:
>
>> This is a tentative of opening the discussion regarding a more regular
>> update of the youtube-dl package in Debian stable.
>> 
> TBH I think this should never have reached stable in the first place...

So what should happen now? Should it be removed from stretch?

What do we do with the version that *is* in testing?

Isn't that what volatile (now -updates) was designed for?

https://lists.debian.org/debian-volatile-announce/2012/msg0.html

It explicitly mentions:

"""
 * Fixes to leaf packages that were broken by external changes (e.g.
   video downloading tools and tor).
"""

A.

-- 
Qui vit sans folie n'est pas si sage qu'il croit.
- François de La Rochefoucauld

Bug#833865: jessie-pu: package youtube-dl/2014.08.05-1+deb8u1

[Antoine Beaupré]

Control: tag -1 -moreinfo

On 2016-11-20 13:15:13, Jonathan Wiltshire wrote:
> On Tue, Aug 09, 2016 at 11:50:27AM -0400, Antoine Beaupré wrote:
>> Unfortunately, this is a scenario in which providing a small patch to
>> fix the problem is probably impossible. What I would suggest here is
>> to simply ship the version from testing as a proposed update for the
>> next stable release.
>
> Hmm. How crazy does a diff of that currently look?

 771 files changed, 78540 insertions(+), 18325 deletions(-)

The debdiff is 4.6MB. I am assuming that's too insane to CC here.

The thing is, at this point I doubt anybody can even *use* the version
in jessie: youtube doesn't work and while there are other sites
supported, I think it's safe to assume that's what most people use it
for.

A.

-- 
La démocratie réelle se définit d'abord et avant tout par la
participation massive des citoyens à la gestion des affaires de la cité.
Elle est directe et participative. Elle trouve son expression la plus
authentique dans l'assemblée populaire et le dialogue permanent sur
l'organisation de la vie en commun.  - De la servitude moderne

Bug#839242: jessie-pu: package linkchecker/9.3-1

[Antoine Beaupré]

On 2016-10-03 09:49:42, Adam D. Barratt wrote:
> Control: reopen -1
>
> [p-u bugs get closed when the package is in stable, not as part of the 
> upload]

Ack, I was wondering too.

> On 2016-10-03 14:26, Antoine Beaupré wrote:
>> On 2016-10-02 18:05:07, Adam D. Barratt wrote:
> [...
>>> Thanks. With the changelog distribution changed to "jessie", please go
>>> ahead.
>> 
>> I assume you meant "stable", as documented in the developer's reference
>> and that I have used before.
>
> No, I meant "jessie" - please presume I might know what I'm doing here. 
> :-) "stable" will work, but the codename is preferred, as it is more 
> self-documenting.

Ouch, ok. :/ Sorry about that - previous p-u I made were made with the
"stable" codename, so I assumed I was correct.

> DevRef is not an authorative source, particularly over the request of 
> the person wearing the relevant hat.

I understand. I assumed you simply were implying "stable" and not
meaning litterally "jessie".

> (Nevertheless, it does correctly 
> document ${codename}-security for uploads to the security archive, so it 
> would be useful to be explicit for stable as well.)

Understood.

Is there anything I should be doing now short of fixing the fine
documentation? :)

Thanks again for the hand holding and sorry for the trouble.

A.
-- 
A lot of people never use their initiative because no-one told them to.
- Bansky

Bug#839242: jessie-pu: package linkchecker/9.3-1

[Antoine Beaupré]

On 2016-10-02 12:40:47, Adam D. Barratt wrote:
> On Sun, 2016-10-02 at 12:21 -0400, Antoine Beaupré wrote:
>> On 2016-10-01 13:08:06, Adam D. Barratt wrote:
>> > Control: tags -1 + moreinfo
>> >
>> > On Fri, 2016-09-30 at 11:38 -0400, Antoine Beaupré wrote:
>> >> Attached is a debdiff between the -1 and -1.1 version.
>> >
>> > Apparently not.
>> 
>> Sorry.
>
> Thanks.
>
> At first glance, I'm rather confused by:
>
> --- linkchecker-9.3/debian/source/include-binaries  1969-12-31 
> 19:00:00.0 -0500
> +++ linkchecker-9.3/debian/source/include-binaries  2016-05-19 
> 14:33:11.0 -0400
> @@ -0,0 +1,27 @@
>
> particularly its appearance in an NMU. None of the paths sound like
> files that you'd want to include in the source package, and indeed none
> of them appear to have been included in the package in unstable; at
> least most also appear to be automatically removed by upstream's clean
> targets.

Uh. That *is* quite odd - I don't actually know where that is coming
from. I agree it is out of scope for a NMU, but considering the poor
state of the package (it's orphaned) I hope I can be forgiven,
especially since others uploaded new NMUs on top of mine...

Anyways, here's a reduced diff that seems to compile well on my jessie
chroot:



linkchecker_9.3-1+deb8u1.debdiff
Description: Binary data

a.

-- 
Prolétaires de tous les pays, qui lave vos chaussettes?
- Audrey Lorde

Bug#839242: jessie-pu: package linkchecker/9.3-1

[Antoine Beaupré]

On 2016-10-01 13:08:06, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
>
> On Fri, 2016-09-30 at 11:38 -0400, Antoine Beaupré wrote:
>> Attached is a debdiff between the -1 and -1.1 version.
>
> Apparently not.

Sorry.



linkchecker_9.3-1.1.debdiff
Description: Binary data

>> I suggest
>> uploading the -1.1 version straight to stable since newer releases
>> were done in stable. I am concerned by a subsequent QA upload that
>> fixed a related issue, however:
>> 
>> https://packages.qa.debian.org/l/linkchecker/news/20160723T130426Z.html
>> 
>> I am not sure this bugfix applies to jessie, however, as I am using
>> -1.1 here in jessie without problems.
>
> Confirming one way or the other would be appreciated.

At first glance, it seems unrelated.

A.
-- 
Prolétaires de tous les pays, qui lave vos chaussettes?
- Audrey Lorde

Bug#839242: jessie-pu: package linkchecker/9.3-1

[Antoine Beaupré]

Package: release.debian.org
Severity: normal
Tags: jessie patch
User: release.debian@packages.debian.org
Usertags: pu

linkchecker, a package to check links in a webpage, suffers from a
serious bug (#839241) which makes it impossible to check any HTTPS
webpage or any page that contains a HTTPS URL.  Although it correctly
checks plaintext URLs, the HTTPS URLs are so common that it makes it
impossible to use it on any site that has any link to an HTTPS site,
or is an HTTPS site itself, which I consider a "grave" bug because it
"makes it unusable by most users".

I have made a NMU to fix the bug in Debian:

https://packages.qa.debian.org/l/linkchecker/news/20160519T192043Z.html

 and submitted the patch upstream:

https://github.com/wummel/linkchecker/pull/656

Attached is a debdiff between the -1 and -1.1 version. I suggest
uploading the -1.1 version straight to stable since newer releases
were done in stable. I am concerned by a subsequent QA upload that
fixed a related issue, however:

https://packages.qa.debian.org/l/linkchecker/news/20160723T130426Z.html

I am not sure this bugfix applies to jessie, however, as I am using
-1.1 here in jessie without problems.

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1

[Antoine Beaupré]

Control: tags -1 -moreinfo

Hi,

New developments on the Charybdis front: a patch has been developed
upstream to fix the issue, but it is pretty invasive. They have
basically rewritten the whole GNUTLS backend to make it on par with the
other implementations. It's a good thing: there were memory leaks and
all sorts of other issues, namely one that I mentioned earlier.

At the very least, we'd need to factor in this p-u a patch like this
one:

https://github.com/charybdis-ircd/charybdis/issues/215#issuecomment-246202759

... to fix timeout issues in the gnutls code that crashes the ssld. But
even with that, there are at least two major issues that should be fixed
here:

1. Charybdis 3.4 supports only SHA-1 for certificates, which has serious
security vulnerabilities. To give an unrelated example, the APT team
plans to remove all SHA-1 support in their repositories next year

2. 3.4 also has several memory leaks that are fixed by the gnutls
rewrite.

There are three way forward here:

1. ignore the above two extra issues and simply add the patch for #215
to the pile of patches in jessie
2. import the new gnutls.c module from an eventual new 3.5 release
upstream directly in jessie - this may be difficult because of internal
API changes
3. import 3.5.x directly in jessie

I would like to have feedback from the release team as to which approach
to take forward.

Thanks!

A.

-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker

Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1

[Antoine Beaupré]

Control: tags -1 +moreinfo

On 2016-09-06 09:10:43, Antoine Beaupré wrote:
> On 2016-09-06 03:58:44, Adam D. Barratt wrote:
>> On 2016-09-06 1:31, Antoine Beaupré wrote:
>>> Turns out this took about three weeks instead of 24h. But 3.5.3 is
>>> released, and I will push the update to unstable now.
>>> 
>>> The situation is a tad more complicated now because there was a 
>>> security
>>> issue disclosed in the meantime:
>>> 
>>> https://security-tracker.debian.org/tracker/CVE-2016-7143
>>> 
>>> ... which 3.5.3 fixes. I have prepared a deb8u2 update for the security
>>> team in #836714, which the attached debdiff builds upon.
>>
>> When's that likely to be released? We can't really accept ~debu3 via p-u 
>> containing the security update until there actually is a published 
>> security update.
>
> I just got approval from the security team for the upload, i should
> complete this during the day.
>
> 3.5.3 was accepted in unstable, FWIW.

Sigh... found another regression from wheezy, reported upstream here:

https://github.com/charybdis-ircd/charybdis/issues/215

Let's hold off on the p-u a little more while upstream collects their
thoughts.

a.

-- 
People in glass houses shouldn't throw stones.
People in glass cities shouldn't fire missiles.
- Bansky

Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1

[Antoine Beaupré]

On 2016-09-06 03:58:44, Adam D. Barratt wrote:
> On 2016-09-06 1:31, Antoine Beaupré wrote:
>> Turns out this took about three weeks instead of 24h. But 3.5.3 is
>> released, and I will push the update to unstable now.
>> 
>> The situation is a tad more complicated now because there was a 
>> security
>> issue disclosed in the meantime:
>> 
>> https://security-tracker.debian.org/tracker/CVE-2016-7143
>> 
>> ... which 3.5.3 fixes. I have prepared a deb8u2 update for the security
>> team in #836714, which the attached debdiff builds upon.
>
> When's that likely to be released? We can't really accept ~debu3 via p-u 
> containing the security update until there actually is a published 
> security update.

I just got approval from the security team for the upload, i should
complete this during the day.

3.5.3 was accepted in unstable, FWIW.

Thanks

-- 
The individual has always had to struggle to keep from being overwhelmed
by the tribe. If you try it, you will be lonely often, and sometimes
frightened. But no price is too high to pay for the privilege of owning
yourself.- Friedrich Nietzsche

Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1

[Antoine Beaupré]

Control: tags -1 -moreinfo

On 2016-08-19 18:05:34, Antoine Beaupré wrote:
> On 2016-08-19 17:56:29, Adam D. Barratt wrote:
>> On Fri, 2016-08-19 at 17:35 -0400, Antoine Beaupré wrote:
>>> TL;DR: Charybdis 3.4 (Jessie) introduces a regression (CertFP broken)
>>> from Charybdis 3.3 (Wheezy). 7-line patch (attached) fixes the issue.
>>> 
>>> Charybdis 3.4 suffers from a regression which breaks authentication in
>>> certain scenarios. The bug is now documented upstream here:
>>> 
>>> https://github.com/charybdis-ircd/charybdis/pull/211
>> [...]
>>> I have produced a simple patch which fixes the issue for Charybdis 3.5
>>> here:
>>> 
>>> https://github.com/charybdis-ircd/charybdis/pull/211/commits/0ff0a0592de84dec2a2f46d9f8d6e22f6c1ee467
>>
>> That patch doesn't appear to have been applied to the package in
>> unstable. That's a pre-requisite for considering it for an update in
>> stable.
>
> Understood. I am waiting for upstream to release 3.5.3 which will
> include that patch, tonight, before doing a new upload.

Turns out this took about three weeks instead of 24h. But 3.5.3 is
released, and I will push the update to unstable now.

The situation is a tad more complicated now because there was a security
issue disclosed in the meantime:

https://security-tracker.debian.org/tracker/CVE-2016-7143

... which 3.5.3 fixes. I have prepared a deb8u2 update for the security
team in #836714, which the attached debdiff builds upon.

diff -Nru charybdis-3.4.2/debian/changelog charybdis-3.4.2/debian/changelog
--- charybdis-3.4.2/debian/changelog	2016-09-05 19:45:08.0 -0400
+++ charybdis-3.4.2/debian/changelog	2016-09-05 20:11:24.0 -0400
@@ -1,3 +1,10 @@
+charybdis (3.4.2-5+deb8u3) stable; urgency=medium
+
+  * backport patch from testing: fix error handling in gnutls certfp
+support
+
+ -- Antoine Beaupré <anar...@debian.org>  Mon, 05 Sep 2016 20:11:19 -0400
+
 charybdis (3.4.2-5+deb8u2) jessie-security; urgency=high
 
   * add fix for CVE-2016-7143, backported from upstream (Closes: #836714)
diff -Nru charybdis-3.4.2/debian/patches/0001-fix-error-handling-in-gnutls-certfp-support.patch charybdis-3.4.2/debian/patches/0001-fix-error-handling-in-gnutls-certfp-support.patch
--- charybdis-3.4.2/debian/patches/0001-fix-error-handling-in-gnutls-certfp-support.patch	1969-12-31 19:00:00.0 -0500
+++ charybdis-3.4.2/debian/patches/0001-fix-error-handling-in-gnutls-certfp-support.patch	2016-09-05 20:11:24.0 -0400
@@ -0,0 +1,41 @@
+Bug: https://github.com/charybdis-ircd/charybdis/pull/211
+
+will be factored into 3.5.3, so hold on before merging...
+
+From 0ff0a0592de84dec2a2f46d9f8d6e22f6c1ee467 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= <anar...@debian.org>
+Date: Fri, 19 Aug 2016 11:53:59 -0400
+Subject: [PATCH] fix error handling in gnutls certfp support
+
+---
+ libratbox/src/gnutls.c | 13 ++---
+ 1 file changed, 6 insertions(+), 7 deletions(-)
+
+diff --git a/libratbox/src/gnutls.c b/libratbox/src/gnutls.c
+index f51211f..9bb69bb 100644
+--- a/libratbox/src/gnutls.c
 b/libratbox/src/gnutls.c
+@@ -608,18 +608,17 @@ rb_get_ssl_certfp(rb_fde_t *F, uint8_t certfp[RB_SSL_CERTFP_LEN], int method)
+ 	if (gnutls_certificate_type_get(SSL_P(F)) != GNUTLS_CRT_X509)
+ 		return 0;
+ 
+-	if (gnutls_x509_crt_init() < 0)
+-		return 0;
+-
+ 	cert_list_size = 0;
+ 	cert_list = gnutls_certificate_get_peers(SSL_P(F), _list_size);
+-	if (cert_list == NULL)
++	if (cert_list_size <= 0)
+ 	{
+-		gnutls_x509_crt_deinit(cert);
+ 		return 0;
+ 	}
+ 
+-	if (gnutls_x509_crt_import(cert, _list[0], GNUTLS_X509_FMT_DER) < 0)
++	if (gnutls_x509_crt_init() != GNUTLS_E_SUCCESS)
++		return 0;
++
++	if (gnutls_x509_crt_import(cert, _list[0], GNUTLS_X509_FMT_DER) != GNUTLS_E_SUCCESS)
+ 	{
+ 		gnutls_x509_crt_deinit(cert);
+ 		return 0;
diff -Nru charybdis-3.4.2/debian/patches/series charybdis-3.4.2/debian/patches/series
--- charybdis-3.4.2/debian/patches/series	2016-09-05 19:45:08.0 -0400
+++ charybdis-3.4.2/debian/patches/series	2016-09-05 20:11:24.0 -0400
@@ -7,3 +7,4 @@
 gnutls30
 libratbox-gnutls-add-gnutls-v3-api-compatibility-wit.patch
 CVE-2015-5290
+0001-fix-error-handling-in-gnutls-certfp-support.patch

I am running with those patches in production now.

Thanks and sorry for the delay.

A.

-- 
La propriété est un piège: ce que nous croyons posséder nous possède.
- Alphonse Karr

Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1

[Antoine Beaupré]

On 2016-08-19 17:56:29, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
>
> On Fri, 2016-08-19 at 17:35 -0400, Antoine Beaupré wrote:
>> TL;DR: Charybdis 3.4 (Jessie) introduces a regression (CertFP broken)
>> from Charybdis 3.3 (Wheezy). 7-line patch (attached) fixes the issue.
>> 
>> Charybdis 3.4 suffers from a regression which breaks authentication in
>> certain scenarios. The bug is now documented upstream here:
>> 
>> https://github.com/charybdis-ircd/charybdis/pull/211
> [...]
>> I have produced a simple patch which fixes the issue for Charybdis 3.5
>> here:
>> 
>> https://github.com/charybdis-ircd/charybdis/pull/211/commits/0ff0a0592de84dec2a2f46d9f8d6e22f6c1ee467
>
> That patch doesn't appear to have been applied to the package in
> unstable. That's a pre-requisite for considering it for an update in
> stable.

Understood. I am waiting for upstream to release 3.5.3 which will
include that patch, tonight, before doing a new upload.

>> I'd be happy to provide a debdiff if that is necessary, but that would
>> be actually harder to use than the provided patch, which is just put
>> in debian/patches with a proper changelog mention.
>
> We'll need to see a debdiff before agreeing an upload, yes, as has
> always been the policy for stable updates.

Of course.

> In what way is it "harder to use"? What does it consist of other than
> the patch, a series update and the changelog stanza?

I always find it harder to review a debdiff than the actual file in
debian/patches because of the "+ " prefixes that break syntax
highlighting.

But I'll be happy to provide a debdiff as soon as I ship the fix in
unstable, which should happen shortly.

Thanks!

A.

-- 
A ballot is like a bullet. You don't throw your ballots until you see
a target, and if that target is not within your reach, keep your
ballot in your pocket.
 - Malcom X

Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1

[Antoine Beaupré]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

TL;DR: Charybdis 3.4 (Jessie) introduces a regression (CertFP broken)
from Charybdis 3.3 (Wheezy). 7-line patch (attached) fixes the issue.

Charybdis 3.4 suffers from a regression which breaks authentication in
certain scenarios. The bug is now documented upstream here:

https://github.com/charybdis-ircd/charybdis/pull/211

To provide some context, IRC servers support authentication through
two main mechanisms: passwords and X509 certificates (or CertFP). The
latter works fine in 3.3, but has been broken by a code refactoring in
3.4. Since upstream does not test our code path often (GnuTLS, used
primarly to avoid OpenSSL licensing issues), this bug has been
overlooked for a while.

I have produced a simple patch which fixes the issue for Charybdis 3.5
here:

https://github.com/charybdis-ircd/charybdis/pull/211/commits/0ff0a0592de84dec2a2f46d9f8d6e22f6c1ee467

The patch can be trivially ported to Charybdis 3.4. Such a patch is
attached to this bug report.

Upstream made its own version of the patch, but I do not recommend
using it as it is harder to review and more difficult to backport to
3.4:

https://github.com/charybdis-ircd/charybdis/commit/3288fc46483db508acf2dcdd546a5aea54401de5

If this update isn't possible, I will have to go through backports to
ship 3.5 in Jessie, but that would be unfortunate because I believe
that backports are more for new functionalities than fixing such
regressions.

Another option would be to ship 3.5 directly in Jessie, as it is now
considered to be the "stable" upstream version. However, that diff is
actually much larger:

 299 files changed, 20157 insertions(+), 14302 deletions(-)

I'd be happy to provide a debdiff if that is necessary, but that would
be actually harder to use than the provided patch, which is just put
in debian/patches with a proper changelog mention.

Thanks for your consideration and hard work!

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug: https://github.com/charybdis-ircd/charybdis/pull/211

will be factored into 3.5.3, so hold on before merging...

>From 0ff0a0592de84dec2a2f46d9f8d6e22f6c1ee467 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Fri, 19 Aug 2016 11:53:59 -0400
Subject: [PATCH] fix error handling in gnutls certfp support

---
 libratbox/src/gnutls.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/libratbox/src/gnutls.c b/libratbox/src/gnutls.c
index f51211f..9bb69bb 100644
--- a/libratbox/src/gnutls.c
+++ b/libratbox/src/gnutls.c
@@ -608,18 +608,17 @@ rb_get_ssl_certfp(rb_fde_t *F, uint8_t certfp[RB_SSL_CERTFP_LEN], int method)
 	if (gnutls_certificate_type_get(SSL_P(F)) != GNUTLS_CRT_X509)
 		return 0;
 
-	if (gnutls_x509_crt_init() < 0)
-		return 0;
-
 	cert_list_size = 0;
 	cert_list = gnutls_certificate_get_peers(SSL_P(F), _list_size);
-	if (cert_list == NULL)
+	if (cert_list_size <= 0)
 	{
-		gnutls_x509_crt_deinit(cert);
 		return 0;
 	}
 
-	if (gnutls_x509_crt_import(cert, _list[0], GNUTLS_X509_FMT_DER) < 0)
+	if (gnutls_x509_crt_init() != GNUTLS_E_SUCCESS)
+		return 0;
+
+	if (gnutls_x509_crt_import(cert, _list[0], GNUTLS_X509_FMT_DER) != GNUTLS_E_SUCCESS)
 	{
 		gnutls_x509_crt_deinit(cert);
 		return 0;

Bug#833865: jessie-pu: package youtube-dl/2014.08.05-1+deb8u1

[Antoine Beaupré]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

This is a tentative of opening the discussion regarding a more regular
update of the youtube-dl package in Debian stable.

Currently, Youtube-dl does not work in stable: it fails to download
videos from youtube completely. While other sites may work, its
primary purpose simply fails and tells users to ugrade their package
to the latest version using their package manager, which fails because
it *is* the latest version.

An example of this scenario is Bug#781180, which clearly shows the
software doesn't work at all.

Unfortunately, this is a scenario in which providing a small patch to
fix the problem is probably impossible. What I would suggest here is
to simply ship the version from testing as a proposed update for the
next stable release. Note that upstream does not have a stable release
branch, and they make frequent (ie. about monthly) releases which may
be difficult to keep up with. However, I believe the release schedule
of stable may be sufficient to keep up with the largest changes on the
bigger websites.

If youtube-dl cannot be updated in this fashion, then it is my opinion
that it should be completely removed from stable and blocked from
entering testing in the future so that we don't have the same problem
in future releases. It would mean denying users access to an excellent
piece of softwae, however, which would be a shame.

Thanks for considering this request!

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Re: Using the same nss upstream version in all suites?

[Antoine Beaupré]

On 2016-04-08 10:15:02, Julien Cristau wrote:
> On Thu, Apr  7, 2016 at 16:15:36 -0400, anarcat wrote:
>
>> It would also make sense NSS is basically part of Firefox, which *has*
>> the same version in all suites.
>> 
> That's a weird argument.  nss is a library, firefox isn't.  Unless
> you're arguing for removing all nss rdeps just as happened a few years
> ago to xulrunner rdeps, but then why have an nss package at all.

I am not arguing for removing all the NSS rdeps, of course. My point is
more that the NSS library seems to be more or less ABI stable across
releases - Chromium 49 seems to use the 3.14 in Jessie and 3.17 in Sid
without any ill effects...

But maybe I'm missing something obvious here.

A.

-- 
Le monochrome, c'est pour ceux qui s'intéressent (encore) au contenu.
Usenet dans ces conditions, c'est comme le web avec lynx, on prend
trop conscience du vide, c'est déprimant.
- JLC dans le Guide du linuxien pervers:
  "Coup de cafard..."

Bug#805127: jessie-pu: package charybdis/3.4.2-4+b1

[Antoine Beaupré]

Control: fixed -1 3.4.2-5~deb8u1

On 2015-11-21 12:48:44, Adam D. Barratt wrote:
> Please go ahead.

Done. Forgot to mention this bug report in the changelog though, but it
should end up in the pu queue soon.

I don't have any more wheezy machine to test this so i think i'll just
skip the update on there.

Thanks for the support!

a.
-- 
La guerre, c'est le massacre d'hommes qui ne se connaissent pas,
au profit d'hommes qui se connaissent mais ne se massacreront pas.
- Paul Valéry

Bug#805127: jessie-pu: package charybdis/3.4.2-4+b1

[Antoine Beaupré]

On 2015-11-19 10:23:38, Adam D. Barratt wrote:
> On Sun, 2015-11-15 at 08:08 -0500, Antoine Beaupré wrote:
>> On 2015-11-14 22:42:08, Adam D. Barratt wrote:
>> > Control: tags -1 + moreinfo
>> >
>> > On Sat, 2015-11-14 at 19:32 -0500, Antoine Beaupré wrote:
>> >> Charybdis is unfortunately in very bad shape in stable right now. There
>> >> was an oversight during the release process that made this bug not
>> >> appear as release critical:
>> >> 
>> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768339
>> > [...]
>> >> So i would like to upload the -5 release to stable (jessie) directly. I
>> >> attached the debdiff between -4 and -5 to this mail.
>> >
>> > There didn't appear to be an attachment.
>> >
>> > Additionally, -5 can't be uploaded directly, as that version has already
>> > been used for the unstable upload. Please prepare an upload targeted at
>> > "jessie" and versioned as either -4+deb8u1 or -5~deb8u1 (depending on
>> > which way you prepare the changelog) and send the debdiff for that.
>> 
>> Okay, i'd roll a new changelog then.
>
> As -4+deb8u1, or -5~deb8u1?
>
>> here's the diff.
>
> Whilst that looks okay from a quick glance, it's still the diff for the
> unstable upload, not for the package that you're proposing to upload to
> stable.

Sure, sorry for the oversight. Here's a patch for jessie.



chary-5-jessie.debdiff
Description: Binary data


-- 
"Faith" means not wanting to know what is true.
 - Friedrich Nietzshe

Bug#805127: jessie-pu: package charybdis/3.4.2-4+b1

[Antoine Beaupré]

On 2015-11-14 22:42:08, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
>
> On Sat, 2015-11-14 at 19:32 -0500, Antoine Beaupré wrote:
>> Charybdis is unfortunately in very bad shape in stable right now. There
>> was an oversight during the release process that made this bug not
>> appear as release critical:
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768339
> [...]
>> So i would like to upload the -5 release to stable (jessie) directly. I
>> attached the debdiff between -4 and -5 to this mail.
>
> There didn't appear to be an attachment.
>
> Additionally, -5 can't be uploaded directly, as that version has already
> been used for the unstable upload. Please prepare an upload targeted at
> "jessie" and versioned as either -4+deb8u1 or -5~deb8u1 (depending on
> which way you prepare the changelog) and send the debdiff for that.

Okay, i'd roll a new changelog then.

here's the diff.



chary-5.dsc
Description: Binary data

-- 
La guerre, c'est le massacre d'hommes qui ne se connaissent pas,
au profit d'hommes qui se connaissent mais ne se massacreront pas.
- Paul Valéry

Bug#805127: jessie-pu: package charybdis/3.4.2-4+b1

[Antoine Beaupré]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi,

Charybdis is unfortunately in very bad shape in stable right now. There
was an oversight during the release process that made this bug not
appear as release critical:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768339

Yet because of this bug, charybdis is basically unusable with TLS
enabled (which is the default). The error message is obscure and it is
unlikely that anyone can fix this problem on their own without having a
strong intuition.

I have therefore made a small upload for the package on sid. It fixes
that issue, but also a minor security vulnerability that was also
unfixed in jessie (and wheezy):

https://tracker.debian.org/news/725820

I have talked with the security team and they agree that a DSA is not
necessary because of the workaround (and the fact that charybdis is
broken anyways). The CVE has been marked as no-dsa by the team here:

https://security-tracker.debian.org/tracker/CVE-2015-5290

So i would like to upload the -5 release to stable (jessie) directly. I
attached the debdiff between -4 and -5 to this mail.

Since upstream is not maintaining 3.3 anymore and the upgrade is
transparent, i would also suggest that -5 is uploaded to wheezy as well,
but i understand that would be quite a stretch (no pun intended).

Wheezy, as far as i know, is not affected by #768339 so is more stable,
but it *is* affected by the security vulnerability. The patch I
cherry-picked for -5 *seems* to apply to the wheezy version, but i don't
have an environment to test this right now.

Thanks for any feedback.

A.

-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#771033: unblock: monkeysign/2.0.2 (pre-approval)

[Antoine Beaupré]

Control: tag -1 -moreinfo
On 2014-11-26 17:32:33, Jonathan Wiltshire wrote:
[...]
 They're all ok. You'll upset your translators though... please get as many
 translations into your upload as possible, but don't leave it past 3rd
 December. You can have a waiver for further translations after that.

 Please remove the moreinfo tag when it's in sid.

Unfortunately, there is little translation available on the project at
this point and little workforce to update it, so I went ahead and
uploaded a 2.0.2 release with the documented changes (plus another to
fix another RC bug, #77090.

An annoying part of the diff is a change in a OpenPGP ascii-armored key
file that I had to perform in order to fix the test suite, which was
making the package FTBS since well... today. :/ Sorry about that, but it
seems necessary.

The final debdiff is attached.

 debian/changelog   |   27 ++
 monkeysign/__init__.py |2
 monkeysign/cli.py  |   12
 monkeysign/gpg.py  |   65 +++-
 monkeysign/gtkui.py|   28 +-
 monkeysign/ui.py   |3
 tests/6D866396.asc |  661 +
 tests/test_gpg.py  |5
 8 files changed, 447 insertions(+), 356 deletions(-)

diff -Nru monkeysign-2.0.1/debian/changelog monkeysign-2.0.2/debian/changelog
--- monkeysign-2.0.1/debian/changelog	2014-10-20 22:29:41.0 -0400
+++ monkeysign-2.0.2/debian/changelog	2014-12-01 22:02:20.0 -0500
@@ -1,3 +1,30 @@
+monkeysign (2.0.2) unstable; urgency=medium
+
+  * this patch releases fixes critical issues...
+  * reported in the Debian BTS:
+* encode prompt properly before prompting (closes: #771032)
+* try to handle error when import actually works in GTK UI
+  (closes: #770900)
+* improve debugging by wrapping all writes to gnupg in debug
+* use the proper index when selecting key to sign
+  (closes: #771034)
+  * reported on the Monkeysphere mailing list:
+* hotfix: properly verify the image signature file
+* hotfix: disable scrolling in qrcode window
+* don't try to remove non-existent video device, and clarify error
+  message
+* output --version to stdout and don't make it an error
+  * those fix FTBS issues:
+* fix tests after cd4e18c: guess encoding properly
+* update zack's key so tests succeed again
+
+  * and this makes sure this package will be easier to support for the
+lifetime of jessie
+* improve error handling again: distinguish different failure cases
+  and clearly transmit GPG errors
+
+ -- Antoine Beaupré anar...@debian.org  Mon, 01 Dec 2014 21:03:56 -0500
+
 monkeysign (2.0.1) unstable; urgency=medium
 
   * hot patch release while we still can before jessie:
diff -Nru monkeysign-2.0.1/monkeysign/cli.py monkeysign-2.0.2/monkeysign/cli.py
--- monkeysign-2.0.1/monkeysign/cli.py	2014-10-20 22:29:41.0 -0400
+++ monkeysign-2.0.2/monkeysign/cli.py	2014-12-01 22:02:20.0 -0500
@@ -15,6 +15,7 @@
 #You should have received a copy of the GNU General Public License
 #along with this program.  If not, see http://www.gnu.org/licenses/.
 
+import locale
 import sys
 import os
 import getpass
@@ -78,14 +79,14 @@
 # implicit
 
 def yes_no(self, prompt, default = None):
-ans = raw_input(prompt.encode('utf-8'))
+ans = raw_input(prompt.encode(sys.stdout.encoding or locale.getpreferredencoding(True)))
 while default is None and ans.lower() not in [y, n]:
-ans = raw_input(prompt)
+ans = raw_input(prompt.encode(sys.stdout.encoding or locale.getpreferredencoding(True)))
 if default: return default
 else: return ans.lower() == 'y'
 
 def prompt_line(self, prompt):
-return raw_input(prompt.encode('utf-8'))
+return raw_input(prompt.encode(sys.stdout.encoding or locale.getpreferredencoding(True)))
 
 def prompt_pass(self, prompt):
 return getpass.getpass(prompt)
@@ -99,10 +100,11 @@
 
 prompt += _(' (1-%d or full UID, control-c to abort): ') % len(allowed_uids)
 
-pattern = raw_input(prompt)
+# workaround http://bugs.python.org/issue7768
+pattern = raw_input(prompt.encode(sys.stdout.encoding or locale.getpreferredencoding(True)))
 while not (pattern in allowed_uids or (pattern.isdigit() and int(pattern)-1 in range(0,len(allowed_uids:
 print _('invalid uid')
-pattern = raw_input(prompt)
+pattern = raw_input(prompt.encode(sys.stdout.encoding or locale.getpreferredencoding(True)))
 if pattern.isdigit():
 pattern = allowed_uids[int(pattern)-1]
 return pattern
diff -Nru monkeysign-2.0.1/monkeysign/gpg.py monkeysign-2.0.2/monkeysign/gpg.py
--- monkeysign-2.0.1/monkeysign/gpg.py	2014-10-20 22:29:41.0 -0400
+++ monkeysign-2.0.2/monkeysign/gpg.py	2014-12-01 22:02:20.0 -0500
@@ -242,6 +242,16 @@
 
 return self.expect_pattern

Bug#771033: unblock: monkeysign/2.0.2 (pre-approval)

[Antoine Beaupré]

 da227d9bc1fa48368395c32fd292b5cfb3601816
Author: Antoine Beaupré anar...@koumbit.org
Date:   Fri Nov 21 19:52:43 2014 -0500

Revert improve error handling again: distinguish different failure cases 
and clearly transmit GPG errors

We are trying to get those hotfixes in jessie, and this is unlikely to
make it as it is mostly cosmetic.

This reverts commit 69172223b8bcbe8f03091db08c15d6d8189fb670.

diff --git a/monkeysign/gpg.py b/monkeysign/gpg.py
index 4c5f928..15164d7 100644
--- a/monkeysign/gpg.py
+++ b/monkeysign/gpg.py
@@ -468,9 +468,9 @@ def sign_key(self, pattern, signall = False, local = False):
 try:
 multiuid = self.context.seek(proc.stderr, 'GET_BOOL 
keyedit.sign_all.okay')
 except GpgProtocolError as e:
-raise GpgRuntimeError(self.context.returncode, _('cannot 
select uid for signing: %s') % e.found().decode('utf-8'))
+raise GpgRuntimeError(self.context.returncode, _('cannot 
sign: %s') % re.sub(r'^.*found (.*)', r'\1', str(e)).decode('utf-8'))
 else:
-raise GpgRuntimeError(self.context.returncode, _('cannot 
select uid for signing: %s') % e.found().decode('utf-8'))
+raise GpgRuntimeError(self.context.returncode, _('cannot sign: 
%s') % re.sub(r'^.*found (.*)', r'\1', str(e)).decode('utf-8'))
 if multiuid:
 if signall: # special case, sign all keys
 print proc.stdin, y
@@ -483,7 +483,7 @@ def sign_key(self, pattern, signall = False, local = False):
 raise GpgRuntimeError(self.context.returncode, _('you 
already signed that key'))
 else:
 # propagate gpg error message up
-raise GpgRuntimeError(self.context.returncode, 
_('unable to confirm key signing: %s') % e.found().decode('utf-8'))
+raise GpgRuntimeError(self.context.returncode, 
_('unable to open key for editing: %s') % re.sub(r'^expected.*, found (.*)$', 
r'\1', str(e)).decode('utf-8'))
 print proc.stdin, 'y'
 self.context.expect(proc.stderr, 'GOT_IT')
 # expect the passphrase confirmation
@@ -516,7 +516,7 @@ def sign_key(self, pattern, signall = False, local = False):
 self.context.expect(proc.stderr, 'GET_BOOL sign_uid.okay')
 except GpgProtocolError as e:
 # propagate gpg error message up
-raise GpgRuntimeError(self.context.returncode, _('unable to 
confirm signing one key: %s') % e.found().decode('utf-8'))
+raise GpgRuntimeError(self.context.returncode, _('unable to 
open key for editing: %s') % re.sub(r'^expected.*, found (.*)$', r'\1', 
str(e)).decode('utf-8'))
 
 # we fallthrough here if there's only one key to sign
 print proc.stdin, 'y'
@@ -529,7 +529,7 @@ def sign_key(self, pattern, signall = False, local = False):
 if 'EXPIRED' in str(e):
 raise GpgRuntimeError(self.context.returncode, _('key is 
expired, cannot sign'))
 else:
-raise GpgRuntimeError(self.context.returncode, _('unable to 
signing a single key: %s') % e.found().decode('utf-8') + proc.stderr.read())
+raise GpgRuntimeError(self.context.returncode, _('cannot sign, 
unknown error from gpg: %s') % str(e) + proc.stderr.read())
 # expect the passphrase confirmation
 try:
 self.context.seek(proc.stderr, 'GOOD_PASSPHRASE')
@@ -764,21 +764,7 @@ class GpgProtocolError(IOError):
 module should instead raise a GpgRutimeError with a user-readable
 error message (e.g. key not found).
 
-
-def match(self):
-return re.search(r'(?:\[Errno [0-9]*\] )?expected ([^]*), found 
(.*)\n*', str(self))
-
-def found(self):
-if self.match():
-return self.match().group(2)
-else:
-return 'no error found in GPG output'
-
-def expected(self):
-if self.match():
-return self.match().group(1)
-else:
-return 'not waiting for pattern'
+pass
 
 class GpgRuntimeError(IOError):
 pass
diff --git a/tests/test_gpg.py b/tests/test_gpg.py
index 39fef0c..40517e9 100755
--- a/tests/test_gpg.py
+++ b/tests/test_gpg.py
@@ -245,11 +245,10 @@ def test_sign_key_as_user(self):
 self.gpg.context.set_option('local-user', '96F47C6A')
 self.assertTrue(self.gpg.sign_key('7B75921E', True))
 
+@unittest.expectedFailure
 def test_sign_already_signed(self):
 test if signing a already signed key fails with a meaningful 
message
-self.assertTrue(self.gpg.sign_key('Antoine Beaupré 
anar...@debian.org'))
-with self.assertRaises(GpgRuntimeError):
-self.gpg.sign_key('Antoine Beaupré anar...@debian.org')
+raise NotImplementedError('not detecting already signed keys properly 
yet')
 
 def test_encrypt_decrypt_data_armored_untrusted(self

Bug#771033: unblock: monkeysign/2.0.2 (pre-approval)

[Antoine Beaupré]

when it rains, it pours... i also would like to add the patch from
#771034:

commit 43b8bc41be45c5f9b734ac239bba8f2ddca60979
Author: Antoine Beaupré anar...@koumbit.org
Date:   Tue Nov 25 23:26:00 2014 -0500

use the proper index when selecting key to sign (closes #771034)

before this patch, we would miss the selected key off by one

thanks to jerome for debugging

diff --git a/monkeysign/gpg.py b/monkeysign/gpg.py
index 15164d7..be3c54c 100644
--- a/monkeysign/gpg.py
+++ b/monkeysign/gpg.py
@@ -503,7 +503,7 @@ def sign_key(self, pattern, signall = False, local = False):
 # XXX: this will hang if the pattern requested is not found, 
we need a better way!
 m = self.context.seek_pattern(proc.stdout, 
'^uid:.([^:]*):::[^:]*:(\d+),[^:]*:')
 if m and m.group(1) == pattern:
-index = int(m.group(2)) + 1
+index = int(m.group(2))
 break
 print proc.stdin, str(index)
 self.context.expect(proc.stderr, 'GOT_IT')

thanks!

a.

-- 
From the age of uniformity, from the age of solitude, from the age of
Big Brother, from the age of doublethink - greetings!
- Winston Smith, 1984


signature.asc
Description: PGP signature

Bug#770264: unblock: liblwpx-paranoidagent-perl/1.10-5

[Antoine Beaupré]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package liblwpx-paranoidagent-perl

it fixes a grave issue (#761635) makes the package basically useless
for SNI hosts.

the diff is trivial:

--- a/lib/LWPx/Protocol/http_paranoid.pm
+++ b/lib/LWPx/Protocol/http_paranoid.pm
@@ -68,6 +68,7 @@ sub _new_socket
 $timeout;
 $sock = $self-socket_class-new(PeerAddr = $addr,
  PeerHost = $host,
+ SSL_hostname = $host,
  PeerPort = $port,
  Proto= 'tcp',
  Timeout  = $conn_timeout,

and it is the only change between -4 (jessie) and -5 (sid). actual
debdiff attached.

unblock liblwpx-paranoidagent-perl/1.10-5

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru liblwpx-paranoidagent-perl-1.10/debian/changelog liblwpx-paranoidagent-perl-1.10/debian/changelog
--- liblwpx-paranoidagent-perl-1.10/debian/changelog	2014-09-09 03:34:18.0 -0400
+++ liblwpx-paranoidagent-perl-1.10/debian/changelog	2014-11-18 16:22:25.0 -0500
@@ -1,3 +1,10 @@
+liblwpx-paranoidagent-perl (1.10-5) unstable; urgency=medium
+
+  * Added patch for passing the right parameters through IO::Socket::SSL
+(Closes: #761635)
+
+ -- Hilko Bengen ben...@debian.org  Tue, 18 Nov 2014 22:22:17 +0100
+
 liblwpx-paranoidagent-perl (1.10-4) unstable; urgency=medium
 
   * Switched debian/watch to metacpan
diff -Nru liblwpx-paranoidagent-perl-1.10/debian/patches/0003-Fix-SNI-for-IO-Socket-SSL.patch liblwpx-paranoidagent-perl-1.10/debian/patches/0003-Fix-SNI-for-IO-Socket-SSL.patch
--- liblwpx-paranoidagent-perl-1.10/debian/patches/0003-Fix-SNI-for-IO-Socket-SSL.patch	1969-12-31 19:00:00.0 -0500
+++ liblwpx-paranoidagent-perl-1.10/debian/patches/0003-Fix-SNI-for-IO-Socket-SSL.patch	2014-11-18 16:20:37.0 -0500
@@ -0,0 +1,21 @@
+From: Hilko Bengen ben...@debian.org
+Date: Tue, 18 Nov 2014 22:20:32 +0100
+Subject: Fix SNI for IO::Socket::SSL
+
+Source: http://ikiwiki.info/plugins/openid/troubleshooting/
+---
+ lib/LWPx/Protocol/http_paranoid.pm | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/lib/LWPx/Protocol/http_paranoid.pm b/lib/LWPx/Protocol/http_paranoid.pm
+index 13d8504..23a23c5 100644
+--- a/lib/LWPx/Protocol/http_paranoid.pm
 b/lib/LWPx/Protocol/http_paranoid.pm
+@@ -68,6 +68,7 @@ sub _new_socket
+ $timeout;
+ $sock = $self-socket_class-new(PeerAddr = $addr,
+  PeerHost = $host,
++ SSL_hostname = $host,
+  PeerPort = $port,
+  Proto= 'tcp',
+  Timeout  = $conn_timeout,
diff -Nru liblwpx-paranoidagent-perl-1.10/debian/patches/series liblwpx-paranoidagent-perl-1.10/debian/patches/series
--- liblwpx-paranoidagent-perl-1.10/debian/patches/series	2014-09-09 03:33:24.0 -0400
+++ liblwpx-paranoidagent-perl-1.10/debian/patches/series	2014-11-18 16:20:37.0 -0500
@@ -1,2 +1,3 @@
 0001-Fix-HTTPS.patch
 0002-Use-ca-certificates.patch
+0003-Fix-SNI-for-IO-Socket-SSL.patch

Bug#725731: RM: irssi-plugin-otr/0.3-2

[Antoine Beaupré]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

The pre-1.0 versions of the OTR plugin are very broken for all
software (xchat, irssi, etc) and are considered insecure as OTRv1 is
susceptible to downgrade attacks (if my memory is correct).

I have been asked by numerous users to remove xchat-otr from squeeze,
so here it the formal request. I am going to backport the irssi-otr
plugin to wheezy soon, if if there are enough requests, to
squeeze-sloppy-backports too.

Note, however, that the new version of the package doesn't support
xchat anymore, but that is because upstream was never updated.

-- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 3.10-0.bpo.2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131007191458.27953.17881.report...@angela.anarcat.ath.cx

Bug#725731: RM: irssi-plugin-otr/0.3-2

[Antoine Beaupré]

On 2013-10-07 15:55:26, intrigeri wrote:
 Hi,

 (Probably OT as far as the release team is concerned: it might be
 worth filing CVE's against the clients that still support v1 and v2.
 Antoine, do you want to ask the OTR developers what's their take
 on it?)

I wouldn't bother, personnally. It took me enough time to file this RM
request... :P

Cheers,

A.
-- 
Travail, du latin Tri Palium trois pieux, instrument de torture.


pgp7iVIb8ms5N.pgp
Description: PGP signature

Bug#703193: unblock: smokeping/2.6.9-1

[Antoine Beaupré]

On 2013-03-16, Jonathan Wiltshire wrote:
 Sorry, no. No new upstreams, or vague fixes stuff. Your next quoted
 paragraph should have put you off this already:
  
 Most of this are bugfixes, the only new feature I can see is the
 SendEmail probe. The debdiff is attached.

 I'm open to targetted fixes in line with freeze policy, that is all.

Alright, I'll reroll a package targeting only the security issue,
someone came up with the patch for 2.6.8 in the issue.

Thanks for the quick feedback!

A.
-- 
Wherever they's a fight so hungry people can eat, I'll be there.
Wherever they's a cop beatin' up a guy, I'll be there.
If Casy knowed, why, I'll be in the way guys yell when they're mad an'
I'll be in the way kids laugh when they're hungry an' they know
supper's ready. An' when our folks eat the stuff they raise an' live
in the house they build, why I'll be there.
- John Steinbeck, The Grapes of Wrath


pgpDkzgTikuDO.pgp
Description: PGP signature

Bug#703193: unblock: smokeping/2.6.9-1

[Antoine Beaupré]

On 2013-03-16, Antoine Beaupré wrote:
 Alright, I'll reroll a package targeting only the security issue,
 someone came up with the patch for 2.6.8 in the issue.

That is now done - 2.6.8-2 should hit sid pretty soon.

So please:

unblock smokeping/2.6.8-2

Thanks!

diff -Nru smokeping-2.6.8/debian/changelog smokeping-2.6.8/debian/changelog
--- smokeping-2.6.8/debian/changelog	2013-03-16 11:50:09.0 -0400
+++ smokeping-2.6.8/debian/changelog	2013-03-16 20:21:28.0 -0400
@@ -1,3 +1,10 @@
+smokeping (2.6.8-2) unstable; urgency=high
+
+  * Acknowledge gregor's NMU, thanks!
+  * Urgency high to fix CVE-2012-0790 again (Closes: #659899)
+
+ -- Antoine Beaupré anar...@debian.org  Sat, 16 Mar 2013 20:19:34 -0400
+
 smokeping (2.6.8-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru smokeping-2.6.8/debian/patches/CVE-2012-0790.patch smokeping-2.6.8/debian/patches/CVE-2012-0790.patch
--- smokeping-2.6.8/debian/patches/CVE-2012-0790.patch	1969-12-31 19:00:00.0 -0500
+++ smokeping-2.6.8/debian/patches/CVE-2012-0790.patch	2013-03-16 20:21:28.0 -0400
@@ -0,0 +1,75 @@
+Index: smokeping-2.6.8/lib/Smokeping.pm
+===
+--- smokeping-2.6.8.orig/lib/Smokeping.pm	2012-02-26 18:19:45.0 +
 smokeping-2.6.8/lib/Smokeping.pm	2013-03-16 23:07:00.0 +
+@@ -28,6 +28,8 @@
+ # make sure we do not end up with , in odd places where one would expect a '.'
+ # we set the environment variable so that our 'kids' get the benefit too
+ 
++my $xssBadRx = qr/[%';]/;
++
+ $ENV{'LC_NUMERIC'}='C';
+ if (setlocale(LC_NUMERIC,) ne C) {
+ if ($ENV{'LC_ALL'} eq 'C') {
+@@ -170,7 +172,7 @@
+ my $hierarchy = '';
+ my $h = $q-param('hierarchy');
+ if ($q-param('hierarchy')){
+-   $h =~ s/[%]/./g;
++   $h =~ s/$xssBadRx/_/g;
+$hierarchy = 'hierarchy='.$h.';';
+ }; 
+ return $hierarchy;
+@@ -212,7 +214,7 @@
+ my $address = $ENV{REMOTE_ADDR};
+ my $targetptr = $cfg-{Targets};
+ foreach my $step (@target){
+-$step =~ s/[%]/./g; 
++$step =~ s/$xssBadRx/_/g; 
+ return Error: Unknown target $step 
+   unless defined $targetptr-{$step};
+ $targetptr =  $targetptr-{$step};
+@@ -1024,6 +1026,7 @@
+ sub parse_datetime($){
+ my $in = shift;
+ for ($in){
++$in =~ s/$xssBadRx/_/g;
+ 	/^(\d+)$/  do { my $value = $1; $value = time if $value  2**32; return $value};
+ /^\s*(\d{4})-(\d{1,2})-(\d{1,2})(?:\s+(\d{1,2}):(\d{2})(?::(\d{2}))?)?\s*$/   
+ return POSIX::mktime($6||0,$5||0,$4||0,$3,$2-1,$1-1900,0,0,-1);
+@@ -1047,7 +1050,7 @@
+ my $tree = shift;
+ my $open = shift;
+ my $mode = shift || $q-param('displaymode') || 's';
+-$mode =~ s/[%]/./g; 
++$mode =~ s/$xssBadRx/_/g; 
+ my $phys_tree = $tree;
+ my $phys_open = $open;
+ if ($tree-{__tree_link}){
+@@ -1447,7 +1450,7 @@
+ $startstr =~ s/\s/%20/g;
+ $endstr =~ s/\s/%20/g;
+ my $t = $q-param('target');
+-$t =~ s/[%]/./g; 
++$t =~ s/$xssBadRx/_/g; 
+ for my $slave (@slaves){
+ my $s = $slave ? ~$slave : ;
+ $page .= div;
+@@ -1601,7 +1604,7 @@
+ my $t = $q-param('target');
+ if ( $t and $t !~ /\.\./ and $t =~ /(\S+)/){
+ $targ = $1;
+-$targ =~ s/[;%]/./g;
++$targ =~ s/$xssBadRx/_/g;
+ }
+ my ($path,$slave) = split(/~/,$targ);
+ if ($slave and $slave =~ /(\S+)/){
+@@ -1610,7 +1613,7 @@
+ $slave = $1;
+ }
+ my $hierarchy = $q-param('hierarchy');
+-$hierarchy =~ s/[;%]/./g;
++$hierarchy =~ s/$xssBadRx/_/g;
+ die ERROR: unknown hierarchy $hierarchy\n 
+ if $hierarchy and not $cfg-{Presentation}{hierarchies}{$hierarchy};
+ my $open = [ (split /\./,$path||'') ];
diff -Nru smokeping-2.6.8/debian/patches/series smokeping-2.6.8/debian/patches/series
--- smokeping-2.6.8/debian/patches/series	2013-03-16 11:50:09.0 -0400
+++ smokeping-2.6.8/debian/patches/series	2013-03-16 20:21:28.0 -0400
@@ -6,3 +6,4 @@
 fix-conf-path-cgi
 typo_642197
 fix-400d-graph
+CVE-2012-0790.patch

-- 
Modern man has a kind of poverty of the spirit which stands
in great contrast to his remarkable scientific and technological
achievements. We've learned to walk in outer space and yet we
haven't learned to walk to earth as brothers and sisters.
- Dr. Martin Luther King, Jr.


pgpXEdhvdgnVv.pgp
Description: PGP signature

Bug#702465: RM: tty-clock/1.1-1

[Antoine Beaupré]

On 2013-03-06, Jonathan Wiltshire wrote:
 On Wed, Mar 06, 2013 at 04:45:45PM -0500, Michael Gilbert wrote:
 Please remove tty-clock.  It's got lots of issues that aren't really
 being worked on (bug #700738).  It also has no reverse-dependencies
 and has yet to be included in a stable release.

 The bug you quote was filed on 16th Feb, and the most recent message was
 from the maintainer just two days ago. I see little evidence that the
 problems aren't being dealt with, just that they haven't been fixed as
 quickly as you would like.

 You should also include the maintainer, or at least the bug you quote, in
 your RM proposal. It's not like Antoine is MIA. I would be a bit insulted
 if this were my package.

 I am CCing Antoine to give a chance to rebut your request.

Right... I am not sure what issues you are refering to, but if it's only
#700738, this addresses unsafeties in the code. One very specific
issue with use after free calls has been addressed and David
mentionned something about there being other issues when ran under
valgrind.

I don't believe those should warrant a complete removal from wheezy. At
most, if the known use-after-free issues are *not* patched in a timely
manner, I agree the package should be removed, but those already have a
patch.

If you know what the other issues are, I suggest you make a clearer
explanation of what those are instead of asking for a complete exclusion
of this package.

(I was not insulted by the RM proposal, but would have appreciated being
CC'd in the original request...)

Awaiting your feedback,

A.


pgpZzP4DGLliS.pgp
Description: PGP signature

Bug#685880: please ship wheezy with Ekiga 4.0

[Antoine Beaupré]

I hereby add my voice to the number of people concerned at the state of
Ekiga in Debian. If 4.0 doesn't get unblocked to be shipped in wheezy,
we are going to be releasing a *very* buggy version to the world.

Whereas Ekiga hasn't always shined by its stability, within a few
minutes of using it, I was able to render my local configuration
completely unuseable - Ekiga would simply crash on startup. This is bug
#670405, which is fixed in experimental.

The version of Ekiga currently in wheezy is over 2 years old (june 201),
while the 3.2 series it's following is over 3 years old. Granted, 4.0
just came out, but from the looks of it, it's actually *more* stable
than the 3.2 release.

I understand that the diff is huge, and this would be a major exception,
but I think it's something that should seriously be
considered. Otherwise Ekiga should be considered from removal from
wheezy, as there is no way security patches can be maintained for that
old release onwards.

Thanks,

A.

-- 
Imagination is more important than knowledge
- Albert Einstein


pgpiNpzBur6fy.pgp
Description: PGP signature

Bug#693060: unblock: openvpn-auth-ldap/2.0.3-4

[Antoine Beaupré]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package openvpn-auth-ldap

The version in squeeze and wheezy has a critical bug that makes the
package inoperable after some time. The bug is:

#692936: No remote address supplied after a while

... and the 2.0.3-4 upload was performed only for that purpose.

Here's the magic stanza:

unblock openvpn-auth-ldap/2.0.3-4

Here's the debdiff:

diff -Nru openvpn-auth-ldap-2.0.3/debian/changelog 
openvpn-auth-ldap-2.0.3/debian/changelog
--- openvpn-auth-ldap-2.0.3/debian/changelog2012-06-05 09:59:11.0 
-0400
+++ openvpn-auth-ldap-2.0.3/debian/changelog2012-11-12 05:36:50.0 
-0500
@@ -1,3 +1,10 @@
+openvpn-auth-ldap (2.0.3-4) unstable; urgency=low
+
+  * Add patch from Antoine Beaupré to fix No remote address
+supplied error. (Closes: #692936)
+
+ -- Alberto Gonzalez Iniesta a...@inittab.org  Mon, 12 Nov 2012 11:35:43 
+0100
+
 openvpn-auth-ldap (2.0.3-3) unstable; urgency=low
 
   * Acknowledge Matthias Klose's NMU. Thanks!
diff -Nru 
openvpn-auth-ldap-2.0.3/debian/patches/openvpn_ldap_simpler_add_handler_4 
openvpn-auth-ldap-2.0.3/debian/patches/openvpn_ldap_simpler_add_handler_4
--- openvpn-auth-ldap-2.0.3/debian/patches/openvpn_ldap_simpler_add_handler_4   
1969-12-31 19:00:00.0 -0500
+++ openvpn-auth-ldap-2.0.3/debian/patches/openvpn_ldap_simpler_add_handler_4   
2012-11-12 04:40:39.0 -0500
@@ -0,0 +1,50 @@
+Description: move address checks further down to avoid certain failures
+ this tries to avoid certain failures with the LDAP plugin where it
+ doesn't get passed the remoteAddress in certain cases. since we do
+ may not care about this address, we fail only when really necessary.
+
+Author: Antoine Beaupr� anar...@debian.org
+
+Origin: vendor
+Bug: https://code.google.com/p/openvpn-auth-ldap/issues/detail?id=4
+Bug-Debian: http://bugs.debian.org/692936
+Forwarded: yes
+Last-Update: 2012-11-10
+
+--- openvpn-auth-ldap-2.0.3.orig/src/auth-ldap.m
 openvpn-auth-ldap-2.0.3/src/auth-ldap.m
+@@ -533,7 +533,10 @@ static int handle_client_connect_disconn
+   }
+ 
+   if (tableName)
+-  if (!pf_client_connect_disconnect(ctx, tableName, 
remoteAddress, connecting))
++  if (!remoteAddress) {
++  [TRLog debug: No remote address supplied to OpenVPN 
LDAP Plugin (OPENVPN_PLUGIN_CLIENT_CONNECT).];
++  ret = OPENVPN_PLUGIN_FUNC_ERROR;
++  } else if (!pf_client_connect_disconnect(ctx, tableName, 
remoteAddress, connecting))
+   return OPENVPN_PLUGIN_FUNC_ERROR;
+ #endif /* HAVE_PF */
+ 
+@@ -587,20 +590,10 @@ openvpn_plugin_func_v1(openvpn_plugin_ha
+   break;
+   /* New connection established */
+   case OPENVPN_PLUGIN_CLIENT_CONNECT:
+-  if (!remoteAddress) {
+-  [TRLog debug: No remote address supplied to 
OpenVPN LDAP Plugin (OPENVPN_PLUGIN_CLIENT_CONNECT).];
+-  ret = OPENVPN_PLUGIN_FUNC_ERROR;
+-  } else {
+-  ret = handle_client_connect_disconnect(ctx, 
ldap, ldapUser, remoteAddress, YES);
+-  }
++  ret = handle_client_connect_disconnect(ctx, ldap, 
ldapUser, remoteAddress, YES);
+   break;
+   case OPENVPN_PLUGIN_CLIENT_DISCONNECT:
+-  if (!remoteAddress) {
+-  [TRLog debug: No remote address supplied to 
OpenVPN LDAP Plugin (OPENVPN_PLUGIN_CLIENT_DISCONNECT).];
+-  ret = OPENVPN_PLUGIN_FUNC_ERROR;
+-  } else {
+-  ret = handle_client_connect_disconnect(ctx, 
ldap, ldapUser, remoteAddress, NO);
+-  }
++  ret = handle_client_connect_disconnect(ctx, ldap, 
ldapUser, remoteAddress, NO);
+   break;
+   default:
+   [TRLog debug: Unhandled plugin type in OpenVPN LDAP 
Plugin (type=%d), type];
diff -Nru openvpn-auth-ldap-2.0.3/debian/patches/series 
openvpn-auth-ldap-2.0.3/debian/patches/series
--- openvpn-auth-ldap-2.0.3/debian/patches/series   2012-06-05 
07:31:33.0 -0400
+++ openvpn-auth-ldap-2.0.3/debian/patches/series   2012-11-12 
04:43:28.0 -0500
@@ -1,2 +1,3 @@
 STARTTLS_before_auth.patch
 gobjc_4.7_runtime.patch
+openvpn_ldap_simpler_add_handler_4

Thanks,

A.

PS: maybe this could be considered for a squeeze update too?

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash


--
To UNSUBSCRIBE, email to debian

Bug#693060: unblock: openvpn-auth-ldap/2.0.3-4

[Antoine Beaupré]

On 2012-11-12, Adam D. Barratt wrote:
 On Mon, 2012-11-12 at 10:04 -0500, Antoine Beaupré wrote:
 #692936: No remote address supplied after a while
 
 ... and the 2.0.3-4 upload was performed only for that purpose.

 Has there been any response from upstream regarding the patch?

No. Upstream doesn't seem particularly responsive. The first and last
release performed by upstream is 4 years old:

https://code.google.com/p/openvpn-auth-ldap/downloads/list

Looking at the issue queue, it doesn't seem that any issue was factored
into a release. There has been some commits that started again since
february 2012, but no new release.

 PS: maybe this could be considered for a squeeze update too?

 Maybe, but that will need a separate bug (preferably once this one's
 resolved :-) )

Alright, thanks!

A.

-- 
It is better to sit alone than in company with the bad; and it is better
still to sit with the good than alone. It better to speak to a seeker of
knowledge than to remain silent; but silence is better than idle words.
- Imam Bukhari


pgpOmydXIuFIt.pgp
Description: PGP signature

Bug#689772: unblock: olsrd/0.6.3-5

[Antoine Beaupré]

On 2012-10-19, Adam D. Barratt wrote:
 Control: tags -1 + moreinfo

 On Sat, 2012-10-06 at 11:12 +0200, Antoine Beaupré wrote:
 Note that 0.6.2 was released more than a year ago and it would seem
 wrong to ship wheezy with it. 0.6.3 *was* in place in the archive when
 the freeze happened, and was blocked only because builds were failing
 on Debian/kFreeBSD, which is now fixed.

 The kFreeBSD issue was fixed in July according to the changelog. Why was
 this not raised until three months later?

I would assume this is an unfoturtunate oversight by the maintainers,
but I actually do not know.

A.

-- 
Freedom is being able to make decisions that affect mainly you. Power
is being able to make decisions that affect others more than you. If
we confuse power with freedom, we will fail to uphold real freedom.
- Richard Stallman


pgpa6VPJAJy78.pgp
Description: PGP signature

Bug#689772: unblock: olsrd/0.6.3-5

[Antoine Beaupré]

On 2012-10-06, Bart Martens wrote:
 Hi Antoine,

 You wrote on unblock request 689772 :
 critical bugs which are bound to be reported against this package once it is
 shipped with a stable Debian release.

 Please consider reporting those critical bugs in the bts.  Maybe olsrd should
 be removed from testing.

The idea was not to remove OLSR from Debian, but to improve the version
that is currently there.

We have already skipped a release, I feel this should be corrected.

A.

-- 
It is a miracle that curiosity survives formal education
- Albert Einstein


pgp1B4nBhIO09.pgp
Description: PGP signature

Bug#689772: unblock: olsrd/0.6.3-5

[Antoine Beaupré]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package olsrd

olsrd-0.6.3-5 ships OLSRd with hardening flags. It also updates OLSR
to the latest stable version upstream, which fixes critical bugs which
are bound to be reported against this package once it is shipped with
a stable Debian release.

The release notes are here:

http://olsr.org/?q=node/55

Note that 0.6.2 was released more than a year ago and it would seem
wrong to ship wheezy with it. 0.6.3 *was* in place in the archive when
the freeze happened, and was blocked only because builds were failing
on Debian/kFreeBSD, which is now fixed.

So please do:

unblock olsrd/0.6.3-5

The debdiff is quite long, so I will not attach it here, but a diffstat:

 CHANGELOG  
|   13
 Makefile   
|  120
 Makefile.inc   
|   28
 README-Olsr-Extensions 
|   43
 android/README 
|   30
 android/regex/Makefile.inc 
|   13
 android/regex/NOTICE   
|  382 +
 android/regex/cclass.h 
|2
 android/regex/cname.h  
|2
 android/regex/engine.c 
|7
 android/regex/re_format.7  
|  756 ---
 android/regex/regcomp.c
|   20
 android/regex/regerror.c   
|8
 android/regex/regex.3  
|  667 --
 android/regex/regexec.c
|2
 android/regex/regfree.c
|1
 android/regex/utils.h  
|2
 contrib/netsimpcap/Makefile
|2
 debian/changelog   
|   37
 debian/control 
|6
 debian/olsrd-adhoc-setup.1 
|   36
 debian/olsrd-default   
|   32
 debian/olsrd.conf  
|  217
 debian/olsrd.conf.funkfeuer
|   34
 debian/olsrd.init  
|9
 debian/olsrd.manpages  
|1
 debian/patches/100-debug_level.patch   
|   11
 debian/patches/230-usr-lib-olsrd.patch 
|6
 debian/patches/260-quagga-plugin-detect-protocol-version.patch 
|   10
 
debian/patches/270-gui-linux-gtk-align-olsr_ip_addr-to-olsr-definition-of-it.patch
 |   33
 debian/patches/280-fix-linux-gtk-build.patch   
|   28
 debian/patches/290-hardcode-etc-olsrd-olsrd-conf.patch 
|  104
 debian/patches/295-update-jsoninfo-plugin.patch
|  674 ++
 debian/patches/295-update-olsrd-adhoc-setup.patch  
|   81
 debian/patches/296-jsoninfo-fix-typo.patch 
|   25
 debian/patches/300-stop-hiding-compile-and-linking-flags.patch 
|  628 ++
 debian/patches/310-hardening-fixes.patch   
|   57
 debian/patches/320-build-tas-plugin-against-debian-lua.patch   
|   21
 debian/patches/series  
|9
 debian/rules   
|   25
 files/olsrd-adhoc-setup
|   76
 files/olsrd.conf.default.full  
|   64
 files/olsrd.conf.default.lq
|   36
 files/olsrd.conf.default.lq-fisheye
|   36
 files/olsrd.conf.default.rfc   
|   17
 gui/linux-gtk/CHANGELOG 

Re: Processed: block 680670 with 688793, tagging 680670

[Antoine Beaupré]

On 2012-09-30, Adam D. Barratt wrote:
 How is the unblock request blocking the fixing of the bug? The bug is
 already fixed and it's not even blocking the transition of the fix,
 given that the unblock was added.

True, it doesn't. However, there was nothing in the bug report here
refering to the unblock request, so I think it is good practice to refer
to that bug.

  tags 680670 + pending
 Bug #680670 {Done: Gaudenz Steinlin gaud...@debian.org} [obnam] obnam: 
 add_key doesn't encrypt symmetric key with new key
 Added tag(s) pending.

 Marking an already closed bug as pending is slightly unusual too, given
 the standard meaning of an upload will be made soon.

How else should we show bug squashers to not worry about this bug
through metadata (as opposed to spending the 5-10 minutes to look into
it? :)

A.

-- 
Antoine Beaupré +++ Réseau Koumbit Networks +++ +1.514.387.6262 #208



pgpHrwhdLqVwI.pgp
Description: PGP signature

Bug#685833: unblock: smokeping/2.6.8-1.1

[Antoine Beaupré]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package smokeping. The NMU done above actually fixes
upgrades from squeeze and therefore a critical bug.

unblock smokeping/2.6.8-1.1

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120824230625.29170.86872.report...@marcos.anarcat.ath.cx