Bug#742882: apt: Does not support LFS .deb packages on 32-bit systems

2014-07-08 Thread Michael Vogt
On Sat, Jul 05, 2014 at 01:17:24AM +0200, Guillem Jover wrote:
[..]
 Ok, here's a first rough go at a patch. It breaks ABI, and just noticed
 an ABI breaking release was recently uploaded to experimental. :(
 
 Just wanted to publish it for now, in case your policy allows to merge
 this in the ABI breaking release. Otherwise I could rework it to stage
 the change in preprocessor macros in a similar way as how you seem to
 handle these. I've only test-built it though.

Thanks a bunch. This looks good! I updated the version of libapt-inst
to 1.6 in the branch as well. Breaking the ABI is ok at this point
because the package has only reached experimental so far.

python-apt is now updated too so that is uses the new long long in
Process() and the testsuite is also happy, so all appears to be well
:)

Thanks,
 Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#742882: apt: Does not support LFS .deb packages on 32-bit systems

2014-07-04 Thread Guillem Jover
Control: tags -1 patch

Hi!

On Fri, 2014-03-28 at 14:42:41 +0100, Guillem Jover wrote:
 Package: apt
 Version: 0.9.16.1
 Severity: normal

 Somewhat recently apt was fixed to add LFS for the ar containers, but
 the tarballs within are still not LFS-safe on 32-bit systems.
 
 Here's a list of issues I've spotted by code staring, I've not tested
 anything, and I should create LFS .deb tests for the tar members too
 in dpkg/pkg-tests.git.
 
 Types (should be off_t, long long or any other 64-bit-safe type):
 
  - ARArchive::Member::Start.
  - pkgDirStream::Size.
  - pkgDirStream::Process(), Size and Pos arguments.
  - ExtractTar::Go(), Size and Read variables, and cast truncation.
 
 The following I guess more out of correctness, as I don't expect to
 see  4 GiB control files around:
 
  - debDebFile::MemControlExtract::Length.
  - debDebFile::MemControlExtract::Process(), Size and Pos arguments.
  - debDebFile::MemControlExtract::TakeControl(), Size argument.
 
 These are minor issues, and would be related to either bogus or
 malicious archives, but probably still good to handle:
 
  - ExtractTar::Go(), GNU_LongLink and GNU_LongName short Length which
would truncate from Itm.Size.

Ok, here's a first rough go at a patch. It breaks ABI, and just noticed
an ABI breaking release was recently uploaded to experimental. :(

Just wanted to publish it for now, in case your policy allows to merge
this in the ABI breaking release. Otherwise I could rework it to stage
the change in preprocessor macros in a similar way as how you seem to
handle these. I've only test-built it though.

Some other comments:

 * MaxInSize is not used anywhere, but I guess it could be useful to
   handle bundled archives. Otherwise it might make sense to just
   remove it, and the arg in the constructor.
 * Also changed the in-core loaders because they are virtuals.
 * The in-core handling could possibly check for huge sizes before
   trying to allocate stuff, but it should fail with
   ENOMEM or std::bad_alloc otherwise I guess.
 * The patch description is rather terseā€¦

Thanks,
Guillem
From 78a9cbf46aa0d073b8f88d949df5495f73a4fa23 Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Wed, 2 Jul 2014 03:12:00 +0200
Subject: [PATCH 1/2] Add new Base256ToNum long long overload function

---
 apt-pkg/contrib/strutl.cc | 19 ++-
 apt-pkg/contrib/strutl.h  |  1 +
 debian/libapt-pkg4.12.symbols |  1 +
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/apt-pkg/contrib/strutl.cc b/apt-pkg/contrib/strutl.cc
index ce69c7a..0f48860 100644
--- a/apt-pkg/contrib/strutl.cc
+++ b/apt-pkg/contrib/strutl.cc
@@ -1046,7 +1046,7 @@ bool StrToNum(const char *Str,unsigned long long Res,unsigned Len,unsigned Base
 // -
 /* This is used in decoding the 256bit encoded fixed length fields in
tar files */
-bool Base256ToNum(const char *Str,unsigned long Res,unsigned int Len)
+bool Base256ToNum(const char *Str,unsigned long long Res,unsigned int Len)
 {
if ((Str[0]  0x80) == 0)
   return false;
@@ -1059,6 +1059,23 @@ bool Base256ToNum(const char *Str,unsigned long Res,unsigned int Len)
}
 }
 	/*}}}*/
+// Base256ToNum - Convert a fixed length binary to a number /*{{{*/
+// -
+/* This is used in decoding the 256bit encoded fixed length fields in
+   tar files */
+bool Base256ToNum(const char *Str,unsigned long Res,unsigned int Len)
+{
+   unsigned long long Num;
+   bool rc;
+
+   rc = Base256ToNum(Str, Num, Len);
+   Res = Num;
+   if (Res != Num)
+  return false;
+
+   return rc;
+}
+	/*}}}*/
 // HexDigit - Convert a hex character into an integer			/*{{{*/
 // -
 /* Helper for Hex2Num */
diff --git a/apt-pkg/contrib/strutl.h b/apt-pkg/contrib/strutl.h
index 185cdc3..5733fd6 100644
--- a/apt-pkg/contrib/strutl.h
+++ b/apt-pkg/contrib/strutl.h
@@ -72,6 +72,7 @@ bool ReadMessages(int Fd, std::vectorstd::string List);
 bool StrToNum(const char *Str,unsigned long Res,unsigned Len,unsigned Base = 0);
 bool StrToNum(const char *Str,unsigned long long Res,unsigned Len,unsigned Base = 0);
 bool Base256ToNum(const char *Str,unsigned long Res,unsigned int Len);
+bool Base256ToNum(const char *Str,unsigned long long Res,unsigned int Len);
 bool Hex2Num(const std::string Str,unsigned char *Num,unsigned int Length);
 
 // input changing string split
diff --git a/debian/libapt-pkg4.12.symbols b/debian/libapt-pkg4.12.symbols
index 3fa128c..f99d3dd 100644
--- a/debian/libapt-pkg4.12.symbols
+++ b/debian/libapt-pkg4.12.symbols
@@ -22,6 +22,7 @@ libapt-pkg.so.4.12 libapt-pkg4.12 #MINVER#
  (c++)StringToBool(std::basic_stringchar, std::char_traitschar, std::allocatorchar  const, int)@Base 0.8.0
  (c++)UnmountCdrom(std::basic_stringchar, std::char_traitschar, std::allocatorchar )@Base 

Bug#742882: apt: Does not support LFS .deb packages on 32-bit systems

2014-03-28 Thread Guillem Jover
Package: apt
Version: 0.9.16.1
Severity: normal

Hi!

Somewhat recently apt was fixed to add LFS for the ar containers, but
the tarballs within are still not LFS-safe on 32-bit systems.

Here's a list of issues I've spotted by code staring, I've not tested
anything, and I should create LFS .deb tests for the tar members too
in dpkg/pkg-tests.git.

Types (should be off_t, long long or any other 64-bit-safe type):

 - ARArchive::Member::Start.
 - pkgDirStream::Size.
 - pkgDirStream::Process(), Size and Pos arguments.
 - ExtractTar::Go(), Size and Read variables, and cast truncation.

The following I guess more out of correctness, as I don't expect to
see  4 GiB control files around:

 - debDebFile::MemControlExtract::Length.
 - debDebFile::MemControlExtract::Process(), Size and Pos arguments.
 - debDebFile::MemControlExtract::TakeControl(), Size argument.

These are minor issues, and would be related to either bogus or
malicious archives, but probably still good to handle:

 - ExtractTar::Go(), GNU_LongLink and GNU_LongName short Length which
   would truncate from Itm.Size.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org