Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.2 2015-10-23T16:06:23Z 2015-10-23T16:06:23Z Julian Andres Klode jak@debian.org 2015-10-23T16:02:30Z urn:sha1:f77ea39c94988ab6adcb2d6bbf5466b0bc65953b More safety, less writeable memory. 2015-08-27T12:51:47Z Julian Andres Klode jak@debian.org 2015-08-21T16:00:37Z urn:sha1:1c73b0fc41c23a08994ef1464c529e0aacff16de This could allow an attacker to mark a package as installed in a remote package index, as long as the package was not listed in the dpkg status file. This way, an attacker could force the installation of a package during a dist-upgrade, by providing two packages in an index, an older marked as installed, and a newer - apt would "upgrade" to the newer version. 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-07-20T10:32:46Z urn:sha1:7f8c0eed6983db7b8959f1498fc8bc80c98d719e Now that we can dynamically create dependencies and provides as needed rather than requiring to know with which architectures we will deal before running we can allow the listparser to parse all records rather than skipping records of "unknown" architectures. This can e.g. happen if a user has foreign architecture packages in his status file without dpkg knowing about this architecture (or apt configured in this way). A sideeffect is that now arch:all packages are (correctly) recorded as available from any Packages file, not just from the native one – which has its downsides for the resolver as mixed-arch source packages can appear in different architectures at different times, but that is the problem of the resolver and dealing with it in the parser is at best a hack (and also depends on a helpful repository). Another sideeffect is that his allows :none packages to appear in Packages files again as we don't do any kind of checks now, but given that they aren't really supported (anymore) by anyone we can live with that. 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-07-20T08:17:29Z urn:sha1:c9443c01208377f0cba9706412ea3a98ad97b56d Trade deduplication of code for a bunch of new virtuals, so it is actually visible how the different indexes behave cleaning up the interface at large in the process. Git-Dch: Ignore 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-07-16T17:41:45Z urn:sha1:ecc138f858fab61e0b888d3d13854d1422c3432b Expecting the worst is easy to code, but has its disadvantages e.g. by creating package structures which otherwise would have never existed. By creating the provides instead at the time a package structure is added we are well prepared for the introduction of partial architectures, massive amounts of M-A:foreign (and :allowed) and co as far as provides are concerned at least. We have something relatively similar for dependencies already. Many tests are added for both M-A states and the code cleaned to properly support implicit provides for foreign architectures and architectures we 'just' happen to parse. Git-Dch: Ignore 2015-08-10T15:27:58Z David Kalnischkies david@kalnischkies.de 2015-07-15T11:21:21Z urn:sha1:4dc77823d360158d6870a5710cc8c17064f1308f We aren't and we will not be really compatible again with the previous stable abi, so lets drop these markers (which never made it into a released version) for good as they have outlived their intend already. Git-Dch: Ignore 2015-08-10T15:27:17Z David Kalnischkies david@kalnischkies.de 2015-07-08T22:35:40Z urn:sha1:3b3028467ceccca0b73a8f53051c0fa4de313111 C++11 adds the 'override' specifier to mark that a method is overriding a base class method and error out if not. We hide it in the APT_OVERRIDE macro to ensure that we keep compiling in pre-c++11 standards. Reported-By: clang-modernize -add-override -override-macros Git-Dch: Ignore 2015-08-10T15:25:25Z David Kalnischkies david@kalnischkies.de 2015-06-17T07:29:00Z urn:sha1:6c55f07a5fa3612a5d59c61a17da5fe640eadc8b Doing this disables the implicit copy assignment operator (among others) which would cause hovac if used on the classes as it would just copy the pointer, not the data the d-pointer points to. For most of the classes we don't need a copy assignment operator anyway and in many classes it was broken before as many contain a pointer of some sort. Only for our Cacheset Container interfaces we define an explicit copy assignment operator which could later be implemented to copy the data from one d-pointer to the other if we need it. Git-Dch: Ignore 2015-06-12T14:33:37Z David Kalnischkies david@kalnischkies.de 2015-06-12T00:08:53Z urn:sha1:b07aeb1a6e24825e534167a737043441e871de9f We used to read the Release file for each Packages file and store the data in the PackageFile struct even through potentially many Packages (and Translation-*) files could use the same data. The point of the exercise isn't the duplicated data through. Having the Release files as first-class citizens in the Cache allows us to properly track their state as well as allows us to use the information also for files which aren't in the cache, but where we know to which Release file they belong (Sources are an example for this). This modifies the pkgCache structs, especially the PackagesFile struct which depending on how libapt users access the data in these structs can mean huge breakage or no visible change. As a single data point: aptitude seems to be fine with this. Even if there is breakage it is trivial to fix in a backportable way while avoiding breakage for everyone would be a huge pain for us. Note that not all PackageFile structs have a corresponding ReleaseFile. In particular the dpkg/status file as well as *.deb files have not. As these have only a Archive property need, the Component property takes over this duty and the ReleaseFile remains zero. This is also the reason why it isn't needed nor particularily recommended to change from PackagesFile to ReleaseFile blindly. Sticking with the earlier is usually the better option. 2014-11-08T13:28:28Z David Kalnischkies david@kalnischkies.de 2014-11-06T11:41:04Z urn:sha1:dce45dbe97531de6806707445da97d3f22285db8 We have a bunch of classes which are of no use for the outside world, but were still exported and so needed to preserve ABI/API. Marking them as hidden to not export them any longer is a big API break in theory, but in practice nobody is using them – as if they would its a bug.