* Emanuele Rocca:
> Hello!
>
> On 2023-11-24 01:34, Guillem Jover wrote:
>> According to https://bugs.debian.org/918914#73 there were no pending
>> toolchain issues related to this.
>
> That is correct. The GCC maintainers at Arm confirm that
> stack-clash-protection is supported on 32 bit too.
* Alexander:
> I make rop (suid root) for packing to .deb my programs.
> But see system rights problems when try run dpkg.
>
> As resolve in Debian this problem ?
>
> Rop very just:
>
> program rop;
> uses Unix;
> begin
> if ParamCount < 1 then Halt;
> fpSystem(ParamStr(1));
> end.
>
> If I run
* John Scott:
> On Sunday, December 20, 2020 3:45:47 PM EST Florian Weimer wrote:
>> glibc currently does [set errno on successful free]:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=17924
>
> Wow, I had no idea! Nevermind then, at least for now, although
* John Scott:
> No system is known to set errno when using free, successfully or
> otherwise, and POSIX Issue 8 is slated to protect it on success
> to simplify error handling:
> https://www.austingroupbugs.net/view.php?id=385
glibc currently does:
* Guillem Jover:
> On Sun, 2020-12-13 at 14:33:06 +0100, Florian Weimer wrote:
>> * Julian Andres Klode:
>> > On Sun, Dec 13, 2020 at 12:32:02PM +0100, Florian Weimer wrote:
>> >> It seems that “apt upgrade” clears “apt-mark hold” (in buster, so apt
>>
* Julian Andres Klode:
> On Sun, Dec 13, 2020 at 12:32:02PM +0100, Florian Weimer wrote:
>> It seems that “apt upgrade” clears “apt-mark hold” (in buster, so apt
>> 1.8.2 or thereabouts). APT does not install recommended packages
>> which are marked as held even if
* Sundaresh Venugopal:
> I have designed a perfect hash library, which features both ordered(gather)
> and unordered(scatter) hashing.Ordered hash functions preserve the sorted
> (partial)order of the keys, while minimizing collisions. Ordered (fixed
> length)string hashing is also
* Harlan Lieberman-Berg:
> Hello GCC Maintainers!
>
> It would be Really Awesome (TM) if we could add the
> -fstack-clash-protection flag to our default hardening posture. This
> would have provided protection against the recent System Down
> vulnerability (CVE-2018-16864, CVE-2018-16865,
of a method to a derived class.
These are source-compatible changes, but not binary-compatible.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
* Guillem Jover:
The same problem arises with non-significant zeros before digits, for
example:
0.001 == 0.1 == 00:000.1
Although this might be trickier to see in the wild, as dpkg itself
would not normalize these versions, but an unknowing packager could
generate those (somehow)
* Raphael Hertzog:
On Mon, 03 May 2010, Florian Weimer wrote:
But I think all implementations (except an obscure Ocaml one) agree on
the first equality. Leading zeros are not significant here.
On top of that, dpkg's epoch comparison algorithm yields different
results on different
Package: dpkg
Version: 1.14.28
dpkg's version comparison is architecture-dependent (due to changes in
the size of the C long type):
(i386)$ dpkg --compare-versions 4294967296:1 '' 4294967295:1 ; echo $?
1
(amd64)$ dpkg --compare-versions 4294967296:1 '' 4294967295:1 ; echo $?
0
The second
* Mike Hommey:
So, IMHO, what you really want to do is unpack, sync everything, and
then rename. Unfortunately, there exists nothing that permits to sync
only a set of files, and as was said in this thread, sync() doesn't
necessarily guarantees all writes happened once it returns, though that
* Guillem Jover:
On kFreeBSD there's FIOGETLBA, but it seems to only be implemented for
the cd9660 file system, so not of much use. Also AFAIU from taking a
look at Linux, FIBMAP is being phased out by FIEMAP?
FIBMAP is the correct system call here because FIEMAP does unnecessary
work. It's
* Goswin von Brederlow:
Wouldn't it be better to read the files asynchronous and let the
underlying elevator code sort them into physical block order?
Linux doesn't support asynchronous I/O which doesn't bypass the cache,
so it's pretty much unusable for this purpose. It's also doubtful if
* Morten Hustveit:
I haven't tried this, because it would require much more changes to
the dpkg code. The FIBMAP every .list file step takes less than
one second when operating from a cold disk cache, probably because
inodes aren't as scattered as file contents.
Very interesting. It turns
* Morten Hustveit:
When running dpkg from a cold cache on a system where
/var/lib/dpkg/info/ lies on a harddisk, a lot of time is spent
waiting for seeks between (typically) thousands of files. This
patch ensures that the package iterator used by
ensure_allinstfiles_available returns the
* Modestas Vainius:
While apparently, VT can't be implemented differently (except \d+),
what about size_t etc. then? They all can be implemented as regexps
too the most simple being 'any character'. However, in my opinion,
exact string matching is worthwhile to keep whenever possible.
Can't
$ python -c 'import apt_pkg; apt_pkg.init(); print apt_pkg.VersionCompare(1,
1-0)'
-1
$ dpkg --compare-versions '1' = '1-0'; echo $?
0
I think dpkg is right because policy says:
| The absence of a debian_revision is equivalent to a
| debian_revision of `0'.
So this looks like a bug in APT.
* Joey Hess:
I have a sourcev3 branch with my changes at git://kitenet.net/dpkg,
and have also attached a diff to this mail. I feel that this is ready
for review and hopefully merging into dpkg now. Looking forward to your
comments.
What about empty directories?
I really think you need to
* sean finney:
as a plus, it would drastically reduce the amount of code in dpkg. the
hundreds of lines of code dedicated toe
scanning/reading/writing/parsing/representing the various *.list
*.md5sums etc could be reduced to a small number of sql queries.
And other information could be
* Jonathan Bastien-Filiatrault:
The other day, while dpkg was running, I was wondering if it could be
sped up by using a database backend instead of flat files. I was
thinking it would be possible to graft sqlite to dpkg and eliminate the
current file-counting (Reading database ...)
* Marc Haber:
apt-ftparchive is in a position to help here by generating a proper
Source: line in the Packages: file. For example, bind9 1:9.2.1-2.0.1
should have Source: bind9 (1:9.2.1-2) in the Packages file. IMO, the
Source: line should only be suppressed if both package name and
version
* Scott James Remnant:
On Tue, 2005-07-12 at 18:10 +0200, Florian Weimer wrote:
dpkg-deb seems to contain a statically linked copy of zlib version
1.2.2. This means it's potentially vulnerable to CAN-2005-2096. Please
check, and advise the security team if an update for stable is required
Package: dpkg
Version: 1.9.21
Severity: minor
On x86, md5sum is compiled without large file support, which means you
can't run it directly on files larger than 2 GB.
(You can use redirection instead, though.)
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux alpha
25 matches
Mail list logo
