| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
This option controls the maximum size of Release/Release.gpg/InRelease
files. The rational is that we do not know the size of these files in
advance and we want to protect against a denial of service attack
where someone sends us endless amounts of data until the disk is full
(we do know the size all other files (Packages/Sources/debs)).
|
|\
| |
| |
| |
| |
| |
| | |
feature/acq-trans
Conflicts:
apt-pkg/acquire-item.cc
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The fileformat of a pdiff index stores currently only SHA1 hashes. With
this change, we look for all other hashes we support as well and take
what we get, so that we can work after the release of jessie to get
right of SHA1 if we want to.
Note that the completely patched file is and was checked against the
hashes collected from the Release file, so this transition isn't mission
critical.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We are the only possible users of private methods, so we are also the
only users who can potentially export them via using them in inline
methods. The point is: We don't need these symbols exported if we don't
do this, so marking them as hidden removes some methods from the API
without breaking anything as nobody could have used them.
Git-Dch: Ignore
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Using a different user for calling methods is intended to protect us
from methods running amok (via remotely exploited bugs) by limiting what
can be done by them. By using root:root for the final directories and
just have the files in partial writeable by the methods we enhance this
in sofar as a method can't modify already verified data in its parent
directory anymore.
As a side effect, this also clears most of the problems you could have
if the final directories are shared without user-sharing or if these
directories disappear as they are now again root owned and only the
partial directories contain _apt owned files (usually none if apt isn't
running) and the directory itself is autocreated with the right
permissions.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Move common code out but do not use subclassing for ::Done
to make it easier to understand what each class is doing when
its done
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| | |
feature/acq-trans
Conflicts:
apt-pkg/acquire-item.cc
apt-pkg/acquire-item.h
methods/gpgv.cc
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A long-lasting FIXME in the acquire code points out the problem that we
e.g. for decompressors assign c-string representations of c++-strings to
the Mode variable, which e.g. cppcheck points out as very bad.
In practice, nothing major happens as the c++-strings do not run out of
scope until Mode would do, but that is bad style and fragile, so the
obvious proper fix is to use a c++ string for storage to begin with.
The slight complications stems from the fact that progress reporting
code in frontends potentially uses Mode and compares it with NULL, which
can't be done with std::string, so instead of just changing the type we
introduce a new variable and deprecate the old one.
Git-Dch: Ignore
|
| |
| |
| |
| |
| |
| | |
Revert because its a API change and the gain does not justify the
extra work to make the required changes in the consumers of this
interface at this point.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Also rework the way we load the Release file, so it only after
Release.gpg verified the Release file. The rational is that we
never want to load untrusted data into our parsers. Only stuff
verified with gpg or by its hashes get loaded. To load untrusted
data you now need to use apt-get update --allow-unauthenticated.
|
| | |
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
feature/acq-trans
Conflicts:
apt-pkg/acquire-item.cc
apt-pkg/acquire-item.h
methods/copy.cc
test/integration/test-hashsum-verification
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
apt-pkg/acquire-item.cc
apt-pkg/acquire-item.h
apt-pkg/cachefilter.h
configure.ac
debian/changelog
|
| | |
| | |
| | |
| | |
| | |
| | | |
incorrect invalidating of unauthenticated data (CVE-2014-0488)
incorect verification of 304 reply (CVE-2014-0487)
incorrect verification of Acquire::Gzip indexes (CVE-2014-0489)
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The old way of handling this was that pkgAcqMetaIndex was responsible
to check/move both Release and Release.gpg in place. This breaks
the assumption of the transaction that each pkgAcquire::Item has
a single File that its responsible for.
|
|/ / |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
apt-pkg/deb/deblistparser.cc
doc/po/apt-doc.pot
doc/po/de.po
doc/po/es.po
doc/po/fr.po
doc/po/it.po
doc/po/ja.po
doc/po/pl.po
doc/po/pt.po
doc/po/pt_BR.po
po/da.po
po/mr.po
po/vi.po
|
| | |
|
| |
| |
| |
| | |
break
|
|\ \
| | |
| | |
| | | |
debian/experimental
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
Reported-By: clang++ -Werror
Conflicts:
apt-pkg/acquire-item.cc
apt-pkg/acquire-item.h
apt-pkg/deb/debmetaindex.h
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
debian/experimental
Conflicts:
apt-pkg/acquire-item.cc
apt-pkg/acquire-item.h
|
| | |
| | |
| | |
| | |
| | |
| | | |
Beside being another big API break with hopefully zero fallout in
reality it avoids having the same member and helper code in each and
every subclass.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It is not very extensible to have the supported Hashes hardcoded
everywhere and especially if it is part of virtual method names.
It is also possible that a method does not support the 'best' hash
(yet), so we might end up not being able to verify a file even though we
have a common subset of supported hashes. And those are just two of the
cases in which it is handy to have a more dynamic selection.
The downside is that this is a MAJOR API break, but the HashStringList
has a string constructor for compatibility, so with a bit of luck the
few frontends playing with the acquire system directly are okay.
|