apt/apt-pkg/tagfile.cc, branch 2.9.0

pkgTagFile::Jump: Use lookback buffer to rejump to current position

2024-03-21T21:31:04Z

If we get called twice with the same offset, our d->Start and d->iOffset will already point at the offset for the next section. But since we have the start of the last parsed section still in the buffer, just make sure to always go back to the start first. Closes: #1067440

Modernize standard library includes

2024-02-20T12:49:04Z

This was automated with sed and git-clang-format, and then I had to fix up the top of policy.cc by hand as git-clang-format accidentally indented it by two spaces.

Use pkgTagSection::Key in more places in src:apt

2022-04-01T12:16:19Z

The speed critical paths were converted earlier, but the remaining could benefit a tiny bit from this as well especially as we have the facility now available and can therefore brush up the code in various places in the process as well. Also takes the time to add the hidden Exists method advertised in the headers, but previously not implemented.

Avoid .c_str() on strings feed into pkgTagSection::FindS

2022-04-01T12:16:19Z

FindS has a APT::StringView based API nowadays, so we can avoid these explicit calls also allowing us to avoid the std::string in input or output entirely or at least move it a few branches down.

Parse records including empty tag names correctly

2020-02-26T17:12:18Z

No sensible file should include these, but even insensible files do not gain unfair advantages with it as this parser does not deal with security critical files before they haven't passed other checks like signatures or hashsums. The problem is that the parser accepts and parses empty tag names correctly, but does not store the data parsed which will effect later passes over the data resulting e.g. in the following tag containing the name and value of the previous (empty) tag, its own tagname and its own value or a crash due to an attempt to access invalid memory depending on who passes over the data and what is done with it. This commit fixes both, the incidient of the crash reported by Anatoly Trosinenko who reproduced it via apt-sortpkgs: | $ cat /tmp/Packages-null | 0: | PACKAGE:0 | | : | PACKAGE: | | PACKAGE:: | $ apt-sortpkgs /tmp/Packages-null and the deeper parsing issue shown by the included testcase. Reported-By: Anatoly Trosinenko References: 8710a36a01c0cb1648926792c2ad05185535558e

tagfile: Check out-of-bounds access to Tags vector

2020-02-20T12:35:51Z

Check that the index we're going to use is within the size of the array.

tagfile: Check if memchr() returned null before using

2020-02-20T12:35:27Z

This fixes a segmentation fault trying to read from nullptr+1, aka address 1.

Follow gcc-9 -Wnoexcept suggestion for FileChunk constructor

2019-04-16T10:59:54Z

warning: but ‘pkgTagFilePrivate::FileChunk::FileChunk(bool, size_t)’ does not throw; perhaps it should be declared ‘noexcept’ [-Wnoexcept] Reported-By: gcc-9 Gbp-Dch: Ignore

tagfile: Remove deprecated pkgUserTagSection and TFRewrite

2019-02-26T15:31:20Z

Step over empty sections in TagFiles with comments

2019-02-01T13:51:56Z

Implementing a parser with recursion isn't the best idea, but in practice we should get away with it for the time being to avoid needless codechurn. Closes: #920317 #921037