NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: linux_3.16.36-1_mips.changes
  ACCEPT

Re: Thinking about a "jessie and a half" release

[Nicholas D Steeves]

On 4 July 2016 at 18:38, Ben Hutchings  wrote:
> On Mon, 2016-07-04 at 16:01 -0400, Nicholas D Steeves wrote:
> [...]

> [...]
>> So for radeon hardware enablement, there is 1) the proprietary driver
>
> fglrx is dead upstream and removed from unstable.  (It's still in
> jessie-backports, but should be removed there as well.)

Ok, so a very real need for the new radeon driver bpo is/has probably
emerging/ed.  And Bug #828087 on others mentioned in another email to
this thread are blockers to a bpo of xorg-core, which would need to
happen first.

> [...]
>> Also, I imagine this might one day be necessary,
>> particularly if tracking backported linux-src due to ABI changes
>> between kernels, eg: if the out-of-tree drivers in testing begin to
>> require >> linux-src=3.16.0 ABI.
>
> I think you mean API.  We don't ship out-of-tree drivers as binaries.
>

Yes, you're absolutely right, I meant API.  Given that people with,
for example broadcom wifi chipsets will be using this new Debian spin
(Maybe it should be called Debian Fresh Spin?) in the hopes of
hardware enablement, do you think it should pin the bpo versions of
out-of-tree drivers, and also include bpo non-free firmware?

Cheers,
Nicholas

Re: Thinking about a "jessie and a half" release

[Nicholas D Steeves]

On 5 July 2016 at 08:40, Samuel Henrique  wrote:
>
> 2016-07-05 7:43 GMT-03:00 Jose R R :
>>
>> We're getting to the point where there's a fairly pressing need for
>> arm64 - the more useful hardware is starting to get a wider distribution
>> and we don't really have anything for people who want to run Debian
>> that gets them a supported system with an upgrade path.
>
>
> We have Debian Stretch, which is what i recommend to anybody who wants do
> install Debian as a desktop.
>
> I understand the difference of running Debian Testing and Debian Stable with
> some backported packages, but is it really worth it?
> Shouldn't we discuss more the usability of Testing as a solid release, or
> maybe start doing a stable release and another release kinda like Testing
> but with more stability guarantees?
>
> I'm not really sure, but i think opensuse has a model like that.
>
...
> They always end up using Debian Testing, knowing that the main risk comes
> when the unfreeze happens and that while the freeze is rolling they will
> have a more stable debian (compared to when unfreezed).

I personally like to test stable+1 on my laptop by changing stable to
stable+1_codename about a month after the freeze happens; it then
transitions to stable automatically, and no trouble with the unfreeze.
As for building off of a [semi]rolling release model, from testing,
I'm pessimistic because of historical precedents for success.  For
example: http://cut.debian.net/
https://www.reddit.com/r/debian/comments/3yeg6z/what_happened_with_debian_cut/

Tanglu seems to have stalled, and SolydXK is now stable+bpos, but
maybe they will go back to using stable+1 once it freezes? And a
recent discussion on running testing ->
http://forums.debian.net/viewtopic.php?f=30=128598=0

Of course, I'd also love to see it work! :-)  I'm guessing it requires
a substantial investment of time and a very dedicated—and large
enough—team.

Cheers,
Nicholas

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: tcpreplay_3.4.4-2+deb8u1_amd64.changes
  ACCEPT
Processing changes file: tcpreplay_3.4.4-2+deb8u1_arm64.changes
  ACCEPT
Processing changes file: tcpreplay_3.4.4-2+deb8u1_armel.changes
  ACCEPT
Processing changes file: tcpreplay_3.4.4-2+deb8u1_armhf.changes
  ACCEPT
Processing changes file: tcpreplay_3.4.4-2+deb8u1_i386.changes
  ACCEPT
Processing changes file: tcpreplay_3.4.4-2+deb8u1_mips.changes
  ACCEPT
Processing changes file: tcpreplay_3.4.4-2+deb8u1_mipsel.changes
  ACCEPT
Processing changes file: tcpreplay_3.4.4-2+deb8u1_powerpc.changes
  ACCEPT
Processing changes file: tcpreplay_3.4.4-2+deb8u1_ppc64el.changes
  ACCEPT
Processing changes file: tcpreplay_3.4.4-2+deb8u1_s390x.changes
  ACCEPT
Processing changes file: wget_1.16-1+deb8u1_arm64.changes
  ACCEPT
Processing changes file: wget_1.16-1+deb8u1_armel.changes
  ACCEPT
Processing changes file: wget_1.16-1+deb8u1_armhf.changes
  ACCEPT
Processing changes file: wget_1.16-1+deb8u1_i386.changes
  ACCEPT
Processing changes file: wget_1.16-1+deb8u1_mips.changes
  ACCEPT
Processing changes file: wget_1.16-1+deb8u1_mipsel.changes
  ACCEPT
Processing changes file: wget_1.16-1+deb8u1_powerpc.changes
  ACCEPT
Processing changes file: wget_1.16-1+deb8u1_ppc64el.changes
  ACCEPT
Processing changes file: wget_1.16-1+deb8u1_s390x.changes
  ACCEPT

Re: [Piuparts-devel] Please reschedule some jessie-pu and jessie2proposed checks

[Holger Levsen]

Hi Adam,

On Fri, Jul 08, 2016 at 02:52:17PM +0200, Adam D. Barratt wrote:
> The list only contains those logs that our tools highlighted as failing
> in jessie-pu or jessie2proposed checks. If it's not too difficult to
> check other currently failed tests, the logs should all contain the
> string:
>
>   tmp/scripts/pre_remove_exceptions: 49: tmp/scripts/pre_remove_exceptions: 
> Syntax error: ")" unexpected (expecting ";;")

thanks, I've rescheduled everything from your list and am now grepping
for "tmp/scripts/pre_remove_exceptions: Syntax error" in all failed,
bugged and affected logs, to reschedule those too.

sorry for the mess!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

[Clint Byrum]

Excerpts from Otto Kekäläinen's message of 2016-07-03 12:46:29 +0100:
> > 3. libmysqlclient.so.18
> 
> Here theres's no concensus yet within the pkg-mysql-maint team on this one.
> 

And IMO, there won't be one until MariaDB accepts that they've created a
forked library that is API-incompatible with libmysqlclient.

> I suggest we extend the mysql-defaults source package to provide a
> real default-mysqlclient-dev metapackage, which other packages can
> build depend on, using versions if needed (just as default-jdk does).
> 
> Current mariadb-10.0 source package does not ship any
> libmariadbclient18 nor libmariadbclient-dev packages at all, as
> previously it was seen as against the policy (but mariadb-5.5 in
> Debian did). I suggest we start producing them now again to make a
> libmysqlclient.so(.18) available from mariadb-10.0.
> 
> Having two libmysqlclient.so.18 files from two different packages is a
> controversial topic. They are not identical so it is ugly to use the
> same name. This is however a necessity dictated by the need to provide
> a drop-in-replacement that can be used directly without going into
> every single clienting program and editing the C headers and soname
> calls.
> 

It's _extremely_ ugly to use this name. MariaDB needs to stop shipping a
library that claims to be libmysqlclient, but is not.

This notion of a drop-in replacement is just a bait-and-switch tactic
(even if it isn't meant to be one). By allowing somebody to build
against a new API without changing their build scripts, it's just
allowing them to accidentally use that new API and then unknowingly be
dependent on symbols only available in the forked library. There's a
different between ABI equality, and ABI compatibility, and IMO, the
former is more important for Debian.

> It should be noted that the Debian packages shipped directly from
> mariadb.org have provided the libmysqlclient.so file since forever and
> there has not been problems and the drop-in-replacement function has
> been fullfilled as expected. All packages that used to depend on
> Oracle MySQL client library have continued to function with the
> MariaDB equivalent when mariadb.org repositories are activated.
> 

There have not been problems that users reported to MariaDB, because
the issue is extremely subtle and subversive. Those users would only
ever know that there was a problem if they wanted to distribute their
code and had another user try to build on libmysqlclient. For the
average MariaDB user, that's not such a big deal, as they may not be
distributing their code. For Debian, we're distributing all of it, and
we have a duty to give users reliable software. We don't want to build
against libmariadbclient-dev-compat and then the software just doesn't
work with libmysqlclient.so.18 from MySQL.

> It should also be noted that the soname version number 18 has been
> used in Oracle MySQL for a long time without bumping it despite
> changes in the API. The API changes have also gone undocumented all
> the time as the libmysqlclient18 package does not have .symbols file.
> Oracle has finally bumped the soname version to 20 in MySQL 5.7. The
> number 19 is not used anywhere, but was left as something that can be
> resorted to in 5.6, in case somebody would complain too much that 5.5
> and 5.6 API differ but have same version number. No one has, so for
> all practical purposes, the current situation is OK.
> 

The past was horrible, and MySQL obviously did weird things and our
packages were not sufficient to police this properly. But that doesn't
change the fact that MariaDB has hijacked the mysqlcient soname.

> The solution I suggest works nicely in the scope of
> libmysqlclient18/libmariadbclient18 and is resilent for scenarios
> where libmysqlclient20 is introduced or where even more client
> libraries are available (mainly libmariadb2), but I won't go into the
> details of those now, as I think here is enough information to decide
> on whether or not it is OK to provide libmysqlclient.so from a
> libmariadbclient18 package. This would also mean we introduce the
> default-libmysqlclient-dev pmetaackage which depends on either
> libmariadbclient-dev or libmysqlclient-dev package.
> 
> Please comment and advice on how to proceed with packaging to satisfy
> with the switchable defaults requirement.
>

IMO, it's only OK for MariaDB to provide libmysqlclient.so if it is 100%
equivalent to MySQL's libmysqlclient.so. If there are extra API calls,
and extra symbols, it's not the same, and it won't produce a compatible
program linked to libmysqlclient.so.18.

Bug#830221: jessie-pu: package tcpreplay/3.4.4-2

[Christoph Biedl]

Salvatore Bonaccorso wrote...

> On Thu, Jul 07, 2016 at 05:41:12PM +0200, Adam D. Barratt wrote:
>
> > Please go ahead.
> 
> I uploaded Christoph's package.

Thanks to you both for your work on this issue.

Christoph


signature.asc
Description: Digital signature

Bug#827160: jessie-pu: package dosfstools/3.0.27-1+deb8u1

[Julien Cristau]

On Tue, Jul  5, 2016 at 10:37:41 +0200, Petter Reinholdtsen wrote:

> [Andreas Bombe]
> > If you strongly expect it to be accepted as it is, then push it.
> >
> > Or wait with tagging until it is accepted. Moving tags and releases
> > that aren't releases after all is something I'd like to avoid.
> 
> Right.  I believe the changes are sound and suspect the release team
> agree with me that fixing also minor security issues in Stable is
> important. Because of this, I've pushed the changes, but not added the
> tag.  I suspect it would help if you the package maintainer believe
> these changes should go into stable too.
> 
I'm not sure I agree with that.  To me, "minor" kind of implies "not
important".

Cheers,
Julien

Re: About packages that depend on mysql-* / mariadb / virtual-mysql-*

[Julien Cristau]

On Tue, Jul  5, 2016 at 11:41:15 +0200, Jonathan Wiltshire wrote:

> We discussed this in the release team and concluded that having two
> libmysqlclient.so.18 files in two packages is likely to run into problems
> later if/when they diverge, so there is no point delaying that pain.
> Especially as they are not identical even now.
> 
> I wonder if pkgconfig can be any help here? That involves a one-time change
> to client packages if they don't already use pkgconfig but doesn't have to
> be repeated if the default switches.
> 
Client packages surely don't care about the specific SONAME?  So long as
the .so symlink in the -dev package doesn't change, clients shouldn't
notice.

Cheers,
Julien

Please reschedule some jessie-pu and jessie2proposed checks

[Adam D. Barratt]

Hi,

Following discussion on #debian-qa, please reschedule the tests listed
below, which were affected by the bug fixed in
custom-scripts/scripts/pre_remove_exceptions earlier today.

The list only contains those logs that our tools highlighted as failing
in jessie-pu or jessie2proposed checks. If it's not too difficult to
check other currently failed tests, the logs should all contain the
string:

  tmp/scripts/pre_remove_exceptions: 49: tmp/scripts/pre_remove_exceptions: 
Syntax error: ")" unexpected (expecting ";;")

Thanks,

Adam


https://piuparts.debian.org/jessie-pu/fail/tzdata_2016f-0+deb8u1.log

https://piuparts.debian.org/jessie2proposed/fail/tzdata_2016f-0
+deb8u1.log

https://piuparts.debian.org/jessie2proposed/fail/linux-compiler-gcc-4.8-x86_3.16.36-1.log

https://piuparts.debian.org/jessie2proposed/fail/linux-doc-3.16_3.16.36-1.log

https://piuparts.debian.org/jessie2proposed/fail/linux-headers-3.16.0-4-common_3.16.36-1.log

https://piuparts.debian.org/jessie2proposed/fail/linux-image-3.16.0-4-amd64_3.16.36-1.log

https://piuparts.debian.org/jessie2proposed/fail/linux-image-3.16.0-4-amd64-dbg_3.16.36-1.log

https://piuparts.debian.org/jessie2proposed/fail/linux-libc-dev_3.16.36-1.log

https://piuparts.debian.org/jessie2proposed/fail/linux-manual-3.16_3.16.36-1.log

https://piuparts.debian.org/jessie2proposed/fail/linux-source-3.16_3.16.36-1.log

https://piuparts.debian.org/jessie2proposed/fail/linux-support-3.16.0-4_3.16.36-1.log

https://piuparts.debian.org/jessie-pu/fail/linux-compiler-gcc-4.8-x86_3.16.36-1.log

https://piuparts.debian.org/jessie-pu/fail/linux-doc-3.16_3.16.36-1.log

https://piuparts.debian.org/jessie-pu/fail/linux-headers-3.16.0-4-common_3.16.36-1.log

https://piuparts.debian.org/jessie-pu/fail/linux-image-3.16.0-4-amd64_3.16.36-1.log

https://piuparts.debian.org/jessie-pu/fail/linux-image-3.16.0-4-amd64-dbg_3.16.36-1.log

https://piuparts.debian.org/jessie-pu/fail/linux-libc-dev_3.16.36-1.log

https://piuparts.debian.org/jessie-pu/fail/linux-manual-3.16_3.16.36-1.log

https://piuparts.debian.org/jessie-pu/fail/linux-source-3.16_3.16.36-1.log

https://piuparts.debian.org/jessie-pu/fail/linux-support-3.16.0-4_3.16.36-1.log

https://piuparts.debian.org/jessie2proposed/fail/python-django-horizon_2014.1.3-7+deb8u2.log

https://piuparts.debian.org/jessie-pu/fail/python-django-horizon_2014.1.3-7+deb8u2.log

https://piuparts.debian.org/jessie2proposed/fail/clamav-base_0.99.2
+dfsg-0+deb8u2.log

https://piuparts.debian.org/jessie2proposed/fail/clamav-docs_0.99.2
+dfsg-0+deb8u2.log

https://piuparts.debian.org/jessie2proposed/fail/clamav-testfiles_0.99.2
+dfsg-0+deb8u2.log

https://piuparts.debian.org/jessie-pu/fail/clamav-base_0.99.2+dfsg-0
+deb8u2.log

https://piuparts.debian.org/jessie-pu/fail/clamav-docs_0.99.2+dfsg-0
+deb8u2.log

https://piuparts.debian.org/jessie-pu/fail/clamav-testfiles_0.99.2
+dfsg-0+deb8u2.log

https://piuparts.debian.org/jessie-pu/fail/libclamav7_0.99.2+dfsg-0
+deb8u2.log

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: linux_3.16.36-1_mipsel.changes
  ACCEPT

Processed: Re: Bug#829130: marked as done (jessie-pu: package wget/1.16-1+deb8u1)

[Debian Bug Tracking System]

Processing control commands:

> reopen -1
Bug #829130 {Done: Noël Köthe } [release.debian.org] 
jessie-pu: package wget/1.16-1+deb8u1
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions wget/1.16-1+deb8u1.

-- 
829130: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829130
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#829130: marked as done (jessie-pu: package wget/1.16-1+deb8u1)

[Adam D. Barratt]

Control: reopen -1

On Fri, 2016-07-08 at 11:51 +, Debian Bug Tracking System wrote:
>  wget (1.16-1+deb8u1) jessie; urgency=medium
>  .
>* added patch for CVE-2016-4971. closes: #827003, #829130

Apologies for not having spotted it before, but please don't do that.

The release.debian.org bug is closed once a point release occurs and the
package is actually in stable, not by your upload.

Regards,

Adam

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: libbusiness-creditcard-perl_0.35-0+deb8u1_amd64.changes
  ACCEPT
Processing changes file: libdatetime-timezone-perl_1.75-2+2016f_amd64.changes
  ACCEPT
Processing changes file: tcpreplay_3.4.4-2+deb8u1_multi.changes
  ACCEPT
Processing changes file: wget_1.16-1+deb8u1_amd64.changes
  ACCEPT

Bug#829130: marked as done (jessie-pu: package wget/1.16-1+deb8u1)

[Debian Bug Tracking System]

Your message dated Fri, 08 Jul 2016 11:47:09 +
with message-id 
and subject line Bug#829130: fixed in wget 1.16-1+deb8u1
has caused the Debian Bug report #829130,
regarding jessie-pu: package wget/1.16-1+deb8u1
to be marked as done.

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

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


-- 
829130: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829130
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi stable release managers,

wget in stable is affected by CVE-2016-4971, an issue where wget does
not correctly handle filenames when beeing redirected from a HTTP to a
FTP URL. We think that this does not necessarly need a DSA, but still
would be good to be fixed in stable. I thus have prepared a debdiff,
attached. Bug in BTS is #827003.

The debdiff contains an increasing debian/wget.debhelper.log.

If you allow me to, I can prepare a new debdiff, to clean this up as
well, by using dh_prep instead of dh_clean -k for the build target.
Would that be fine?

But attached the debdiff without that packaging change.

Regards,
Salvatore
diff -Nru wget-1.16/debian/changelog wget-1.16/debian/changelog
--- wget-1.16/debian/changelog	2014-10-27 11:41:18.0 +0100
+++ wget-1.16/debian/changelog	2016-06-30 21:24:14.0 +0200
@@ -1,3 +1,11 @@
+wget (1.16-1+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2016-4971: Lack of filename checking allows arbitrary file upload via
+FTP redirect (Closes: #827003)
+
+ -- Salvatore Bonaccorso   Thu, 30 Jun 2016 21:18:47 +0200
+
 wget (1.16-1) unstable; urgency=medium
 
   * new upstream release from 2014-10-27
diff -Nru wget-1.16/debian/patches/ftp-understand-trust-server-names-on-a-HTTP-FTP-redi.patch wget-1.16/debian/patches/ftp-understand-trust-server-names-on-a-HTTP-FTP-redi.patch
--- wget-1.16/debian/patches/ftp-understand-trust-server-names-on-a-HTTP-FTP-redi.patch	1970-01-01 01:00:00.0 +0100
+++ wget-1.16/debian/patches/ftp-understand-trust-server-names-on-a-HTTP-FTP-redi.patch	2016-06-30 21:24:14.0 +0200
@@ -0,0 +1,270 @@
+Description: ftp: understand --trust-server-names on a HTTP->FTP redirect
+ If not --trust-server-names is used, FTP will also get the destination
+ file name from the original url specified by the user instead of the
+ redirected url.  Closes CVE-2016-4971.
+Origin: backport, http://git.savannah.gnu.org/cgit/wget.git/commit/?id=e996e322ffd42aaa051602da182d03178d0f13e1
+Bug-Debian: https://bugs.debian.org/827003
+Forwarded: not-needed
+Author: Giuseppe Scrivano 
+Reviewed-by: Salvatore Bonaccorso 
+Last-Update: 2016-06-30
+Applied-Upstream: 1.18
+---
+
+--- a/src/ftp.c
 b/src/ftp.c
+@@ -235,14 +235,15 @@ print_length (wgint size, wgint start, b
+   logputs (LOG_VERBOSE, !authoritative ? _(" (unauthoritative)\n") : "\n");
+ }
+ 
+-static uerr_t ftp_get_listing (struct url *, ccon *, struct fileinfo **);
++static uerr_t ftp_get_listing (struct url *, struct url *, ccon *, struct fileinfo **);
+ 
+ /* Retrieves a file with denoted parameters through opening an FTP
+connection to the server.  It always closes the data connection,
+and closes the control connection in case of error.  If warc_tmp
+is non-NULL, the downloaded data will be written there as well.  */
+ static uerr_t
+-getftp (struct url *u, wgint passed_expected_bytes, wgint *qtyread,
++getftp (struct url *u, struct url *original_url,
++wgint passed_expected_bytes, wgint *qtyread,
+ wgint restval, ccon *con, int count, wgint *last_expected_bytes,
+ FILE *warc_tmp)
+ {
+@@ -992,7 +993,7 @@ Error in server response, closing contro
+ {
+   bool exists = false;
+   struct fileinfo *f;
+-  uerr_t _res = ftp_get_listing (u, con, );
++  uerr_t _res = ftp_get_listing (u, original_url, con, );
+   /* Set the DO_RETR command flag again, because it gets unset when
+  calling ftp_get_listing() and would otherwise cause an assertion
+  failure earlier on when this function gets repeatedly called
+@@ -1536,7 +1537,8 @@ Error in server response, closing contro
+This loop either gets commands from con, or (if ON_YOUR_OWN is
+set), makes them up to retrieve the file given by the URL.  */
+ static uerr_t
+-ftp_loop_internal (struct url *u, struct fileinfo *f, ccon *con, char **local_file)
++ftp_loop_internal (struct url *u, struct url 

Bug#829130: jessie-pu: package wget/1.16-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2016-07-07 at 17:46 +0200, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2016-07-05 at 17:09 +0200, Noël Köthe wrote:
> > Hello Salvatore and Stable Release Managers,
> > 
> > Am Dienstag, den 05.07.2016, 15:44 +0200 schrieb Salvatore Bonaccorso:
> [...]
> > > > wget in stable is affected by CVE-2016-4971, an issue where wget 
> > ...
> > > JFTR, if actually Noël Köthe  would like to do the
> > > upload himself, I can happily hand over.
> > 
> > I wasn't aware of this release bugreport (sorry). Thanks for CC:.
> > DSA informed me that there will be no DSA for this CVE and liked to see
> > this fixed by a jessie point release.
> > https://security-tracker.debian.org/tracker/CVE-2016-4971 (at the end
> > "no DSA").
> > 
> > Attached the minor changed debdiff based on the backported patch from
> > Salvatore.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Processed: Re: Bug#829130: jessie-pu: package wget/1.16-1+deb8u1

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + pending
Bug #829130 [release.debian.org] jessie-pu: package wget/1.16-1+deb8u1
Added tag(s) pending.

-- 
829130: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829130
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#830221: jessie-pu: package tcpreplay/3.4.4-2

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2016-07-07 at 19:25 +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Thu, Jul 07, 2016 at 05:41:12PM +0200, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Thu, 2016-07-07 at 14:49 +0200, Christoph Biedl wrote:
> > > there is a way to trigger a segfault in the tcprewrite program,
> > > part of the tcpreplay package. This has been assigned 
> > > CVE-2016-6160, BTS#829350.
> > > 
> > > Security team has suggested to fix this in a point release, the
> > > debdiff for 3.4.4-2+deb8u1 is attached.
> > 
> > Please go ahead.
> 
> I uploaded Christoph's package.

Thanks; flagged for acceptance.

Regards,

Adam

Processed: Re: Bug#830221: jessie-pu: package tcpreplay/3.4.4-2

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + pending
Bug #830221 [release.debian.org] jessie-pu: package tcpreplay/3.4.4-2
Added tag(s) pending.

-- 
830221: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830221
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#829735: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2016f

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + pending
Bug #829735 [release.debian.org] jessie-pu: package 
libdatetime-timezone-perl/1:1.75-2+2016f
Added tag(s) pending.

-- 
829735: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829735
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#829735: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2016f

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2016-07-07 at 19:22 +0200, gregor herrmann wrote:
> On Thu, 07 Jul 2016 17:43:16 +0200, Adam D. Barratt wrote:
[...]
> > Please go ahead. I'll look at getting an SUA sorted, although it might
> > be once I'm back home after Debconf.
> 
> Perfectly fine, thanks.
> Uploaded.

Flagged for acceptance; thanks.

Regards,

Adam

Bug#828630: jessie-pu: package libbusiness-creditcard-perl/0.33-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2016-07-07 at 19:26 +0200, gregor herrmann wrote:
> On Thu, 07 Jul 2016 17:47:47 +0200, Adam D. Barratt wrote:
> 
> > > > I'd be okay with either of those options, having looked at the upstream
> > > > diff.
> > > Thanks, then I think we can proceed with the second option, i.e.
> > > updating to the "full" 0.35 release.
> > > I'm attaching a new debdiff for the proposed upload.
> > Please go ahead.
> 
> Thank you! Uploaded.

Flagged for acceptance; thanks.

Regards,

Adam

Processed: Re: Bug#828630: jessie-pu: package libbusiness-creditcard-perl/0.33-1+deb8u1

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + pending
Bug #828630 [release.debian.org] jessie-pu: package 
libbusiness-creditcard-perl/0.33-1+deb8u1
Added tag(s) pending.

-- 
828630: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828630
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#828966: transition: ros-ros-comm

[Emilio Pozuelo Monfort]

On 29/06/16 18:44, Emilio Pozuelo Monfort wrote:
> On 29/06/16 14:53, Leopold Palomo-Avellaneda wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> Dear Release Team,
>>
>> I'm filing this bug for a transition of ros-ros-comm . It is 
>> in experimental. It builds on all architectures in testing, where it built 
>> previously.
> 
>> All reverse dependencies test rebuilds. All rdepends are listed here:
>> https://release.debian.org/transitions/html/auto-ros-ros-comm.html
> 
> This tangles with the ongoing opencv transition. Let's wait for that to finish
> before starting this.

opencv migrated last night. You can proceed now.

Cheers,
Emilio

Bug#827160: jessie-pu: package dosfstools/3.0.27-1+deb8u1

[Petter Reinholdtsen]

[Adam D. Barratt]
> I intentionally asked for a debdiff, not a pointer to a repository. Bug
> reports should stand alone and not be reliant on external resources
> which may change or disappear.
>
> Is the diff in <2fla8ikrwpn@diskless.uio.no> still current?

I did not provide a debdiff, because the diff is still current, if you
only want the CVEs fixed, and I did not know if that was the case.  If
in addition the extra issue with invalid months reads should be fixed,
the attached patch should solve it.  It is the change currently in the
debian/jessie branch in git.  The only change between the two is the
upstr-11-out-of-bounds.diff file and associated updates to serial and
changelog.

So the questions I hope the release managers can answer is this: Is it
ok to update dosfstools with either of the two proposed patches?  If
not, should we limit it to only those fixing CVEs?

-- 
Happy hacking
Petter Reinholdtsen
diff --git a/debian/changelog b/debian/changelog
index 4f1e009..44f2105 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+dosfstools (3.0.27-1+deb8u1) unstable; urgency=medium
+
+  * Non-maintainer upload to fix security issue.
+  * Added d/gbp.conf to document git branch used for Jessie updates.
+  * [CVE-2015-8872] Invalid memory read in fsck.vfat
+  * [CVE-2016-4804] Heap overflow in function read_fat()
+  * Added upstr-11-out-of-bounds.diff to avoid invalid memory read in
+fsck.fat when month is negative.
+
+ -- Petter Reinholdtsen   Mon, 13 Jun 2016 08:17:24 +0200
+
 dosfstools (3.0.27-1) unstable; urgency=medium
 
   * New upstream version 3.0.27
diff --git a/debian/gbp.conf b/debian/gbp.conf
new file mode 100644
index 000..3926a07
--- /dev/null
+++ b/debian/gbp.conf
@@ -0,0 +1,3 @@
+[DEFAULT]
+debian-branch = debian/jessie
+pristine-tar = True
diff --git a/debian/patches/CVE-2015-8872.diff b/debian/patches/CVE-2015-8872.diff
new file mode 100644
index 000..8709cc4
--- /dev/null
+++ b/debian/patches/CVE-2015-8872.diff
@@ -0,0 +1,33 @@
+Description: Fix CVE-2015-8872 using patches from upstream.
+
+ The patch is based on file used to update the CVE in Wheezy.  It
+ contained the fix in
+ https://github.com/dosfstools/dosfstools/commit/39ce90fe75661ed8842551cd44ea7fec278a60a1
+ Then the dosfstools maintainer noticed the patch in
+ https://github.com/dosfstools/dosfstools/commit/07908124838afcc99c577d1d3e84cef2dbd39cb7
+ was missing.  It is included here (off by one error, fixed by using
+ +1 instead of -1.
+
+ See also https://bugs.debian.org/827160 .
+
+Index: dosfstools-collab/src/fat.c
+===
+--- dosfstools-collab.orig/src/fat.c	2016-06-13 08:07:44.669688617 +0200
 dosfstools-collab/src/fat.c	2016-06-13 08:07:44.665688587 +0200
+@@ -197,10 +197,12 @@
+ 	data[1] = new >> 4;
+ 	} else {
+ 	FAT_ENTRY subseqEntry;
+-	get_fat(, fs->fat, cluster + 1, fs);
++	if (cluster != fs->clusters + 1)
++	get_fat(, fs->fat, cluster + 1, fs);
++	else
++	subseqEntry.value = 0;
+ 	data[0] = new & 0xff;
+-	data[1] = (new >> 8) | (cluster == fs->clusters - 1 ? 0 :
+-(0xff & subseqEntry.value) << 4);
++	data[1] = (new >> 8) | ((0xff & subseqEntry.value) << 4);
+ 	}
+ 	size = 2;
+ 	break;
+ 
diff --git a/debian/patches/CVE-2016-4804.diff b/debian/patches/CVE-2016-4804.diff
new file mode 100644
index 000..d28174c
--- /dev/null
+++ b/debian/patches/CVE-2016-4804.diff
@@ -0,0 +1,64 @@
+https://github.com/dosfstools/dosfstools/commit/e8eff147e9da1185f9afd5b25948153a3b97cf52
+
+Index: dosfstools-collab/src/boot.c
+===
+--- dosfstools-collab.orig/src/boot.c	2016-06-13 07:59:10.337694024 +0200
 dosfstools-collab/src/boot.c	2016-06-13 08:00:46.290436480 +0200
+@@ -101,8 +101,8 @@
+ 	   (unsigned long long)fs->fat_start,
+ 	   (unsigned long long)fs->fat_start / lss);
+ printf("%10d FATs, %d bit entries\n", b->fats, fs->fat_bits);
+-printf("%10d bytes per FAT (= %u sectors)\n", fs->fat_size,
+-	   fs->fat_size / lss);
++printf("%10lld bytes per FAT (= %llu sectors)\n", (long long)fs->fat_size,
++	   (long long)fs->fat_size / lss);
+ if (!fs->root_cluster) {
+ 	printf("Root directory starts at byte %llu (sector %llu)\n",
+ 	   (unsigned long long)fs->root_start,
+@@ -326,7 +326,7 @@
+ struct boot_sector b;
+ unsigned total_sectors;
+ unsigned short logical_sector_size, sectors;
+-unsigned fat_length;
++off_t fat_length;
+ loff_t data_size;
+ 
+ fs_read(0, sizeof(b), );
+@@ -354,8 +354,12 @@
+ /* Can't access last odd sector anyway, so round down */
+ fs_test((loff_t) ((total_sectors & ~1) - 1) * (loff_t) logical_sector_size,
+ 	logical_sector_size);
++
+ fat_length = le16toh(b.fat_length) ?
+ 	le16toh(b.fat_length) : le32toh(b.fat32_length);
++if (!fat_length)
++die("FAT size is zero.");
++
+