Bug#962188: cpio: Wrong CRC with new ASCII format when file > 2GB
Package: cpio
Version: 2.13+dfsg-2
Severity: normal
Dear Maintainer,
CRC is wrongly computed if filesize > 2GB and when new ASCII format is chosen
due to wrong signedness.
The attached patch fixes this.
To check this, just create a file > 2GB and run CPIO with the options "cpio -ov
-H crc"
Checksum for large files are set to 0 due to the bug. cpio itself does not
check them when unpackiung
(a different bug ?), but programs relying on the format and on the CRC comply
with error.
Bug is present in all cpio releases.
-- System Information:
Debian Release: bullseye/sid
APT prefers focal-updates
APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'),
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-33-generic (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cpio depends on:
ii libc6 2.31-0ubuntu9
cpio recommends no packages.
Versions of packages cpio suggests:
pn libarchive1
-- no debconf information
>From 77ff5f1be394eb2c786df561ff37dde7f982ec76 Mon Sep 17 00:00:00 2001
From: Stefano Babic
Date: Fri, 28 Jul 2017 13:20:52 +0200
Subject: [PATCH] Wrong CRC with ASCII CRC for large files
Due to signedness, the checksum is not computed when filesize is bigger
a 2GB.
Signed-off-by: Stefano Babic
---
src/copyout.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/copyout.c b/src/copyout.c
index 1f0987a..727aeca 100644
--- a/src/copyout.c
+++ b/src/copyout.c
@@ -34,13 +34,13 @@
compute and return a checksum for them. */
static uint32_t
-read_for_checksum (int in_file_des, int file_size, char *file_name)
+read_for_checksum (int in_file_des, unsigned int file_size, char *file_name)
{
uint32_t crc;
char buf[BUFSIZ];
- int bytes_left;
- int bytes_read;
- int i;
+ unsigned int bytes_left;
+ unsigned int bytes_read;
+ unsigned int i;
crc = 0;
--
2.7.4
Bug#950772: Patch: swupdate: FTBFS during separate arch/indep builds
Hi Bastian, On 18.02.20 01:36, Bastian Germann wrote: > Hi, > > I have created a merge request at > https://salsa.debian.org/debian/swupdate/merge_requests/2 which fixes > the issue. Please consider merging and uploading to sid. > Thanks for this - anyway, debian package was officially pushed by SZ Lin and Nobuhiro (both in CC), I have no write access to that repo. Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Bug#939598: marked as done (libubootenv-tool: trying to overwrite '/usr/bin/fw_printenv', which is also in package u-boot-tools 2019.01+dfsg-7)
Hi Vagrant, On 21/09/19 23:49, Vagrant Cascadian wrote: >> Preparing to unpack .../15-libubootenv-tool_0.1-1_amd64.deb ... >> Unpacking libubootenv-tool (0.1-1) ... >> dpkg: error processing archive >> /tmp/apt-dpkg-install-S5V5yb/15-libubootenv-tool_0.1-1_amd64.deb (--unpack >> ): >> trying to overwrite '/usr/bin/fw_printenv', which is also in package >> u-boot-tools 2019.01+dfsg-7 >> >> Since the packages are both u-boot related, the new program might have >> the same functionality as the existing one and hence using >> update-alternatives for the two variants maybe an option. > ... >> libubootenv (0.1-2) unstable; urgency=medium >> . >>* Add u-boot-tools Conflicts of libubootenv-tool (Closes: #939598) > > This seems like a rather sub-optimal solution to the problem; now it's > impossible to install u-boot-tools at the same time, which has other > functionality as well. There are also packages that depend or recommend > on u-boot-tools that won't be able to be installed or may have reduced > functionality when libubootenv-tool is installed. > > Many of these packages would seem quite reasonable to have installed > with both libubootenv-tool and u-boot-tools installed at the same > time, such as u-boot-sunxi... Right, but it looks like that u-boot-tools contains tools with different meaning that could be addressed with different packages. For example, tools like "netconsole" is missing. The package in libubootenv exposes the "envtools" from U-Boot, that is just the tool to modify the environment. > > Is there anything in the libubootenv's fw_printenv and fw_setenv > implementations that's significantly different from u-boot-tools? >From the user point of view, they are thought to be fully compatible. The syntax for the tool is the same as the original tools to avoid breakages in already implemented script. Anyway, the most important difference (at least for Debian) is the tools are hardware unaware. In fact, the original u-boot-tools must be compiled with the same machine (_defconfig) of the bootloader because the environment is statically linked to the binary. This is a severe issue if a board boots with the "default" environment, that is the environment linked together with the bootloader. The original fw_setenv tool is built just one machine: fw_setenv can brick the target because it cannot know the environment because it was not written to the flash and it is only present in the U-Boot binary. There is no way to instruct the original tool for this. With libubootenv, the environment is read from a file and the same binary can be used on different targets without exceptions. The original discussion about this topic was in this old thread on U-Boot's ML: http://u-boot.10912.n7.nabble.com/SWUpdate-U-Boot-environment-library-dependency-td340530.html Apart of this, libubootenv just addresses "envtools" from U-Boot, while u-boot-tools contains tools for different purposes: image generation (mkimage and friends), environment. My logical way to do is to split u-boot-tools in several sub-packages that won't conflict. This is the solution in OE, too, where a u-boot-mkimage package contains the image generation tool and u-boot-fw-utils contains the envtools. In OE libubootenv is set as replacement for u-boot-fw-utils (with PROVIDES) and there is no conflict. > > Couldn't libubootenv-tool depend on u-boot-tools instead of conflicting > with it? Depend ? No. > Or would it make sense for u-boot-tools to depend on > libubootenv-tool instead? Mmhh.. I do not know. u-boot-tools should not install fw_setenv / fw_printenv is libubootenv is already installed. > Is this likely to be merged in upstream u-boot > at some point? No. libubootenv is also thought to remove some limitations due to the U-Boot build environment. U-Boot cannot use standard library as they are, so code from libraries (libz, openssl, and so on..) is copied from the original library into U-Boot. If this is required for the bootloader that is an independent binary not linked with anything, it is a sub-optimal solution for a User Space tool: libubootenv is simply linked against the required libraries. > > Alternately, the original suggestion of using the alternatives system > would at least allow both packages to coexist at the same time, at the > cost of some additional complication in both packages maintainer > scripts. Best regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Bug#907041: ITP: swupdate -- SWUpdate provides a reliable way to update the software on an embedded system
Hi Shyam, On 12/07/19 13:53, Shyam Saini wrote: > Hi, > > Is there any update on this? > > Any tentative date or time when It could be officially added. > > We need swupdate as official debian package for one of our customer. > If it would not be added in next few months then we would probably > like to use swupdate with yocto. > The package was pushed by SZ (see link) to debian and he expects it will be merged sonn, now that "buster" is released. [1] https://ftp-master.debian.org/new.html Anyway, (not yet merged) packages are available. You can use the link above, or SWUpdate has a -debian branch to build the package on your own. > please let us me know about the status so that we can make our > decision accordingly. Weird, decision to take debian or Yocto should not be based on SWUpdate's availability. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Bug#907184: RFS: swupdate/2018.03 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "swupdate" * Package name: swupdate Version : 2018.03 Upstream Author : Stefano Babic * URL : https://github.com/sbabic/swupdate * License : GPL-2 Section : embedded It builds those binary packages: swupdate - reliable way to update an embedded system To access further information about this package, please visit the following URL: https://mentors.debian.net/package/swupdate Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/swupdate/swupdate_2018.03.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: * Initial release (Closes: #907041) Regards, Stefano Babic
Bug#907041: ITP: swupdate -- SWUpdate provides a reliable way to update the software on an embedded system
Package: wnpp Severity: wishlist Owner: Stefano Babic * Package name: swupdate Version : 2018.03 Upstream Author : Name * URL : https://github.com/sbabic/swupdate * License : GPL Programming Lang: C, Lua Description : SWUpdate provides a reliable way to update the software on an embedded system SWUpdate is a Linux Update agent with the goal to provide an efficient and safe way to update an embedded system. SWUpdate supports local and remote updates, multiple update strategies It supports the common media on embedded devices such as NOR / NAND flashes, UBI volumes, SD / eMMC, and can be easily extended to introduce project specific update procedures. Pre- and postinstall scripts are supported, and a Lua interpreter helps to customize the update process. An update package is described by the sw-description file, using the libconfig syntax or JSON. It is even possible to use Lua with a custom syntax. Here a short list of the main features: Install on embedded media (eMMC, SD, Raw NAND, NOR and SPI-NOR flashes) Allow delivery single image for multiple devices Multiple interfaces for getting software local storage integrated web server integrated REST client connector to hawkBit remote server download Software delivered as images, gzipped tarball, etc. Allow custom handlers for installing FPGA firmware, microcontroller firmware via custom protocols. Power-Off safe Hardware / Software compatibility. It depends from these packages: libconfig libjson-c libcurl lua I am the author / maintainer of this project, and I provide rules to maintain the package in the sources. Full documentation for the project is here: https://sbabic.github.io/swupdate/index.html Having it in Debian will help people to understand how an update works on embedded system and it can be simply used on debian for ARM.
