Bug#869557: apt: please make the output of apt-ftparchive reproducible
[Original complainer chiming in here] Thanks Chris & David for working on this. As it turns out, the problem was in a sense a case of PEBKAC -- we didn't realize that apt-sortpkgs existed! Now that we know that, the random ordering coming out of apt-ftparchive is no longer an issue for us... although one could argue that there is instead a documentation bug, in that apt-ftparchive(1) should say something along the lines of "packages will be listed in an unpredictable order; you may wish to run apt-sortpkgs to fix this". Since the question of why we're using apt-ftparchive: For reasons of paranoia (we run an encrypted online backup service, so it's important to ensure that the binaries people are running are the right ones) we build packages and sign everything in a very locked-down environment. Using low level tools makes it possible to do exactly what we want under exactly the right conditions, in a way which isn't possible with a high level tool which does everything. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
Bug#632585: bsdiff: make it a little less memory hungry
Hi, I disapprove of using 'signed int' here since 'int' isn't always a consistent size. Either int32_t (if you want a 2GB limit) or ssize_t (if you want anything which will fit into RAM) is what you want. Aside from that these look reasonable; but I'm not going to commit them to the central bsdiff repo (aka. usr.bin/bsdiff in the FreeBSD src tree) because there's bigger issues I need to work on and I don't want to muck around with minor changes like this when I have a complete rewrite pending. But you can consider these changes "blessed" if that has any meaning for debian. On 07/04/11 01:38, Jari Aalto wrote: > forwarded 632585 Colin Percival (upstream) > thanks > > 2011-07-03 22:04 Sebastian Andrzej Siewior : > | Package: bsdiff > | Version: 4.3-10 > | Severity: wishlist > | Tags: patch > | > | bsdiff requires 17x the size of the old file in the initial phase which > | is something. This two patches try push it down to 8x. The limitation is > | that max old file size is 2GiB - 1. A diff of file of that size requires > | with patches 16GiB of extra memory (without 32GiB). > | Please find the patches attached including a proper description. > > Hi Colin, > > Would you take a look at these patches and include them in original > sources: > > http://bugs.debian.org/632585 > > Thanks, > Jari -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#409664: bsdiff: is extremely slow on some files, sometimes hangs
Hi,
Jari Aalto wrote:
> Could you take a look at Debian bug
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409664
>
> and see if any of the suggested algorithm solutions could be applied.
It should be possible to fix this problem via algorithmic changes, yes.
Unfortunately I haven't had the {time, money} to make the necessary
adjustments.
--
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#374525: [Pkg-shadow-devel] Bug#374525: Bug#366546: Mail delivery failed: returning message to sender
Tomasz K?oczko wrote: > On Wed, 5 Jul 2006, Colin Percival wrote: >> I moved FreeBSD's nologin to /usr/sbin two years ago, because >> 1. nologin needs to be statically linked to avoid linker environment >> security issues, > > Key word in this case is "avoiding". If some bad things sits in ld.so why > not fix this directly ? > Also strange thing IMO is in this case is nologin static linking. Yes I > know about ssh pass LD_* but IMO fixing this by static linking is > incorrect way because this is only next "avoiding" .. FreeBSD's dynamic linker knows about the security issues involving LD_* (set[ug]id binaries and noexec filesystems) and acts accordingly. However, /usr/sbin/nologin is not set[ug]id, and unlike other shells, we care if a user can subvert it by preloading libraries. Debian might have a different solution to this problem; but this one works for FreeBSD. Colin Percival -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374525: [Pkg-shadow-devel] Bug#374525: Bug#366546: Mail delivery failed: returning message to sender
Christian Perrier wrote: > As a first reaction and as one of the shadow maintainer, I'm now > inclined to agree with the choice of the FreeBSD team here. > > The rationale is clear... > > I'd like to hear the one from OpenBSD to put nologin in /sbin > though.. they might have a different definition of what goes in /sbin FWIW, nologin was in /sbin in BSD 4.4; this is almost certainly why OpenBSD still has /sbin/nologin. I moved FreeBSD's nologin to /usr/sbin two years ago, because 1. nologin needs to be statically linked to avoid linker environment security issues, 2. logging attempts to log in to a nologinned account requires that syslog code be pulled in (which significantly increases the size of a statically linked binary), 3. we like to keep the root filesystem small, and 4. Since nologin is intended for use in multiuser mode, there's no reason for it to be on the root filesystem -- in single user mode, users who aren't supposed to be allowed to login will never get to the point of running a shell (nologin or otherwise). In short, under the BSD hierarchy rules, nologin should be in /usr/sbin; any systems behaving otherwise are doing so for historical reasons only. Colin Percival -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322147: [Fwd: Copyright violation in utils/bsdiff 4.2-1]
Daniel Baumann wrote: > Colin Percival wrote: >>I don't think I need to explain the problem any further... > > Nevertheless, maybe you can give me a hint why you obviously don't want > the text to be part of bsdiff? I don't like having my work copied without my permission; the fact that it is a "teeny-weeny" web page is irrelevant. If you had bothered to ask for permission, there's a good chance that I would have given it, but copying without even asking for permission is simply Not Acceptable. Colin Percival -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
